XFS on a Web Server?
WWYD asks: "I am going to be setting up a fresh web server for the company I work for and am looking for some advise. It will be a Redhat 7.3 / Apache / PHP standard everyday setup that will be hosting 50+ radio station sites. My question is about SGI's XFS file system. I've been running it at home and love the recovery time after the system dies. (I experiment a lot). Would XFS be a good filesystem for a web server?"
I've been using XFS for all my systems since the beggining of this year and I've personally had zero problems with XFS. I have heard some complaints from other people but when I asked them what they didn't like the complaint was that there were null bytes in files after a crash. Unfortunatly for them this is the intended behavior by XFS in some situations.
I think the most common kernel with XFS is 2.4.18 which is known to have some swapping problems.
So as long as the RedHat 7.3 kernel doesn't have that swapping problem I'd say go for it. Be sure to install the xfsdump package if it isn't already and run the xfs_fsr command weekly from a cron job to keep performance high.
I use XFS on an intranet web server and samba server with positive results. It's an older kernel (I needed the ACL kernel patches so the NT domain ACLs would work with samba), so I don't have to recover from crashes. But, performance-wise, I have no complaints. Granted, I have a fraction of the traffic that your site would have.
r y/l-fs10.html
I also followed Daniel Robbin's advice on XFS (which you've no doubt read already, but just in case: http://www-106.ibm.com/developerworks/linux/libra
Amateurs discuss tactics. Professionals discuss logistics.
As you should--that's the way it's supposed to work by default. If you want it to work differently, you need to configure it differently. You get three choices for what is recoverable. That's two more than most other journalling file systems give you.
and at times, my journal was, at times,(seemingly) corrupt, and I would have to boot into single user mode and manually fsck the disk, which took forever.
It can happen, I suppose, but I haven't noticed it, and I crash machines with ext3 a lot.