Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

There are many file systems for a Linux server administrator to choose from. Also, it is not always an easy task to figure out the appropriate layout and optimal file system for your needs.

Can you suggest some guidelines for choosing the "optimal" file system for a Linux server? I know this is a general question. Let us be more specific. I will put it this way.

1- I have a caching web proxy server. The proxy usually needs to store many small objects and also there are some medium and large objects. I think the web server case will be similar.

2- I have an email server. It needs to save the users' messages.

3- I have a database server.

All these three servers require very much IO access (read and write).

For other types of servers, I think it is not so critical. For example, a Linux-based firewall does not require HD access like a proxy or web server. Most of its processing is done in the memory.

I think the best answer will suggest the appropriate file system for each server (preferably with justifications). Let us focus on performance as the factor to base our suggestions on.

share|improve this question

4 Answers 4

up vote 5 down vote accepted
  • when in doubt, ext3
  • if you don't have to promise too much, ext4
  • if over 8TB and don't want ext4, XFS
  • if you're experimenting, btrfs
  • for everything else, ext3

most of my daywork involves spec'ing and managing multi-TB storage on setups where i don't want a lot of management, and none of the higher-level management know a word about filesystems. for those reasons, i need dependable, efficient and easy systems. i did lots of pull-the-plug disaster simulations, copied around tens of millions of files on (simulated) flaky hardware. ext3 worked admirably. XFS not so, but well above requirements. JFS and ReiserFS failed miserably.

share|improve this answer
    
Do you prefer ext3 to ext4? –  Khaled Oct 26 '10 at 19:38
    
Did you perform these tests against EXT4 in kernel 2.6.30 or newer? EXT4 reliabilty has improved alot.. –  pauska Oct 26 '10 at 19:54
    
that was a while ago, ext4 was too experimental. i'll repeat them in a few months, want to include ext4 and btrfs; but for now i use ext4 only for personal workstations, not (yet) for storing data –  Javier Oct 26 '10 at 20:23
    
I still prefer reiser to extX for filesystems holding lots of small files, though I don't have hard figures to back this up for ext4. –  symcbean Oct 27 '10 at 12:25

I've had great success with XFS, both small and large files, many or less. Various benchmarks around usually points it to be the combined winner of read/write speed. EXT4 is also quite fast, and perhaps easier to find documentation for. Just make sure you run a fresh kernel.

One good example where XFS shines is MySQL databases. I tried to import a 8GB .sql file into MySQL, wich used EXT3 for storage. It nearly timed out after filling up it's buffers (setting the buffer size to 16M or larger didnt help), and the system showed excessive I/O time wait. Switched to XFS, and every problem simply vanished - everything runs at full speed. It seems like XFS get almost zero penalty on fragmentation (wich is a quite often problem with large databases).

If performance were your only question, then XFS is in no doubt a good option. Just make sure you have a UPS, good backups and a disaster plan ready whenever you use a file system who does lazy updates/journaling (wich is just about every modern filesystem on the planet).

share|improve this answer
    
very interesting about MySQL. what table engine did you use? –  Javier Oct 26 '10 at 20:28
    
It was mostly (very large) MySAM indexes –  pauska Oct 26 '10 at 21:01

You can't go wrong with Ext3 for almost any medium workload. Plus, I've never lost data with it. Its journal recovery is solid.

Update: Ext4 is fine, if you have solid 'idiot-proof' Power protection.

I've lost data due to the default 'delayed write' nature of EXT4 writes on a local home+office server, that got rebooted due to a cable snag. Just my experience with ext4. Once bitten, twice shy.

share|improve this answer
    
EXT4 was marked "stable" in the Linux kernel in september 2008, I dont think there is any valid point in using EXT3 anymore. –  pauska Oct 26 '10 at 19:52
    
OK, +1 after your edit :) –  pauska Oct 26 '10 at 20:17
    
For more anecdotal evidence, I've lost data with ext3, so it's not like it's invincible. So far, no data loss with ext4, although to be fair I've used it much less than ext3. –  janneb Oct 26 '10 at 20:20

Which distro are you using? With RHEL 5 ext3 is the only supported option (well, with the AP you get GFS, and in some cases you get support for XFS too, apparently), for newer distros ext4 or XFS are IMHO better options.

Generally, both ext4 and XFS are pretty close. If you want to make a distinction

  • XFS is slower on metadata-intensive workloads.

  • XFS supports filesystems > 16 TB.

  • XFS has project quotas in addition to user and group quotas.

share|improve this answer
    
i have a 10TB XFS volume with a couple million files that is copied every night using rsync to another XFS volume. on sunday nights, there's very few (if any) changes, and it finishes in under a minute. when it was smaller, i used ext3, and no-change copies were 12-15min. XFS is fast –  Javier Oct 26 '10 at 20:26
    
@Javier: I was specifically thinking about XFS spending quite a lot of IO BW on relogging in many metadata-intensive workloads. FWIW, as of 2.6.35 there is an experimental mount option for addressing this. See e.g. mjmwired.net/kernel/Documentation/filesystems/… . For a practical example, consider rm -rf linux-kernel-source-tree. –  janneb Oct 26 '10 at 21:28
    
@jannenb: oh, yes absolutely. just tried it, same server, same (slow) disks, different LVs, warm caches: time to copy from /usr/src to ext3: 3.07sec to XFS: 8.5sec. time to rm -r on ext3: 0.75sec, on XFS: 7.9sec –  Javier Oct 26 '10 at 22:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.