prad put forth on 4/19/2011 1:45 PM: > we are thinking of redoing our existing servers and workstations in > june. our servers is low volume and run out of our home via cable. > > right now the servers are running freebsd and our personal machines use > arch linux, but we'd like to unify everything onto debian because > a) we've liked it in the past > b) we like the social contract > c) we appreciate the no-nonsense attitude about 'free' > > we are contemplating the fs to use: > ext4 (which we've used for a couple of years) > zfs (we've heard this is really good) > btrfs (ditto - though it's still 'new' and 'lacking' features) > > are there any feelings or recommendations regarding the above?
Yes, you left out the best, most mature, highest performance Linux filesystem of them all: XFS - Released on IRIX in 1994, GPLed in 2000, and mainlined in the Linux kernel in 2001. Highly active developer team, constant, regular performance improvements and bug fixes. XFS is the only Linux filesystem with an online file defragger: xfs_fsr which works very well (I run it twice a week via cron on most servers). The PIT snapshot feature that all Linux filesystems now enjoy via LVM was enabled by the xfs_freeze function being migrated from XFS code to the VFS layer. Thus all Linux filesystems owe their reliable PIT snapshot capability to XFS. This is but one of many XFS enterprise features that have been moved into VFS so all Linux filesystems could take advantage of them. XFS beats EXT4 hands down in nearly every category, at least for server workloads. EXT4 may have some advantages on single user workstations simply from a familiarity standpoint WRT tools, and slightly better performance with some single user workloads. ZFS, while boasting some nice features, is many years away from being production ready on Linux, is still highly experimental. BTRFS is in the same boat as ZFS, still experimental and years from being production ready. JFS has been abandoned by IBM, no longer being developed. I mention it for completeness, even though you did not mention it. So you have two realistic choices: XFS or EXT4 I suggest you read extensively about each, their capabilities and limitations, available tools, etc, and just as importantly, who is using each and for what purposes. Worth noting is that kernel.org switched all their servers to XFS starting in 2008. Every bit of kernel code than every Linux distribution, and individuals rolling their own kernels, has pulled from the kernel.org mirrors since 2008, has been served via XFS: http://xfs.org/index.php/XFS_Companies#The_Linux_Kernel_Archives In addition to xfs_fsr for defragmenting your files online, XFS includes many tools to investigate your filesystem. One allows you to easily check your level of fragmentation of a given filesystem, again, while mounted: $ xfs_db -c frag /dev/sda6 -r actual 1120, ideal 1046, fragmentation factor 6.61% (home directories with mbox mail storage) ~$ xfs_db -c frag /dev/sda7 -r actual 69941, ideal 69297, fragmentation factor 0.92% (Samba share with all kinds of files) You can even dig deeper and look at fragmentation at the file level. For instance, here is the extent and disk block map for my Linux RAID (mdadm) mailing list archive file, which is in mbox format, and thus highly susceptible to fragmentation: $ xfs_bmap /home/stan/mail/1-Linux-RAID 1-Linux-RAID: 0: [0..21343]: 49063432..49084775 1: [21344..21391]: 49096328..49096375 2: [21392..21399]: 49096408..49096415 3: [21400..21407]: 49096424..49096431 4: [21408..21423]: 49096440..49096455 5: [21424..21447]: 49096464..49096487 6: [21448..21455]: 49096504..49096511 7: [21456..21471]: 49096520..49096535 8: [21472..21487]: 49096544..49096559 9: [21488..21495]: 49096592..49096599 10: [21496..21503]: 49096632..49096639 11: [21504..21519]: 49096656..49096671 As you can see the file has 11 fragments due to a steady flow of inbound mail from this list being appended to the tail of an mbox file. This fragmentation will be fixed, and the file will be contained within a single extent, this Thursday at approximately 15:15, when xfs_fsr is next scheduled to run. I have it scheduled at 15:15 on Sunday and Thursday for this system. The dates and times were chosen to avoid contention with other cron'd tasks. XFS has a rich set of command for maintaining, debugging, checking, repairing, defragmenting, backing up and restoring an XFS filesystem, just to mention a few. Most of these can be performed on the mounted filesystem. xfs_repair is one of the few that requires unmounting the filesystem. As you can see, XFS has many advantages over EXT4 beyond performance. However, all of the plugs for XFS aside, the most important thing for you, given your host pool, is that you are familiar and comfortable with your chosen filesystem and its management tool set. If you feel comfortable switching to a new FS with a new tool set and commends, XFS is worth the switch. If you're not, I'd stick with EXT4 as you're already comfortable with it, and you don't have a need for extra performance. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dae0ff0.5070...@hardwarefreak.com