Re: file systems
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
Reply to: