[wplug] FC2 to Debian-ish

[Michael Skowvron]

Duncan Hutty wrote:
> 
> I would suggest that you stay away from XFS unless you have one of:
> 1) very large filesystems (>2T)
> 2) very large number of files
> because it's probably not necessary and worth the bother.
> 
> You will need good UPS for your server, preferably enough backup time to 
> cope with and an automated mechanism for shutting your machine down. oh, 
> and I would only want to put XFS on RAID. As you say, unplanned 
> shutdowns are _very_ bad for XFS filesystems.

I would disagree with Duncan. I would trust no other filesystem with my 
data. XFS is as appropriate for a root drive as it is for "larger" 
drives and I am so confident in XFS that I would be comfortable dropping 
my server as many times as it takes to prove that XFS no worse than the 
others.

Are the other filesystems safer?

I believe that all filesystems are vulnerable to corruption. The simple 
fact that the kernel is going to buffer data before flushing it to disk 
is always going to expose the filesystem to some level of inconsistency 
if abruptly taken down. In addition, the disks themselves usually cache 
data before actually writing to the platter, so that adds another 
variable of uncertainty. If your data is valuable enough that you really 
want to minimize filesystem inconsistencies, you'll always want to have 
a UPS regardless of what filesystem you are using.

What makes XFS different?

XFS is going to provide better write throughput on a busy server because 
it delays the writing of data much more than other filesystems. It uses 
the extra time to cluster and coalesce writes and to make better 
decisions about where to allocate the space. That reduces file 
fragmentation even more than other filesystems. In some cases, if the 
data is short lived, or the file is removed very shortly after it is 
created; it never even hits the disk.

What's the downside of XFS?

There's a price to pay for this performance. Since XFS delays writes as 
much as possible to improve performance, there's a larger window of 
vulnerability before data is committed to disk. This is easily mitigated 
by having a UPS. Usually, you only need about 30 seconds of time after 
writes stop for the kernel to have everything flushed to disk. Data is 
usually held initially for about 5 seconds and then flushed at 1 second 
intervals. That gives you an idea of your vulnerable window. If your 
fileserver isn't actually busy when it takes a hit, there won't be any 
diry data in cache. As long as there are no dirty buffers in cache, 
nothing's going to get corrupted.

Do I really need XFS?

If the server is not particularly busy, you aren't going to find XFS any 
faster than the alternatives. The same is true if you have relatively 
small filesytems or your file count is small. The backup and restore 
utilities for XFS (xfsdump/xfsrestore) are excellent. They are very, 
very good; they operate with an understanding of the filesystem 
internals; and they are very fast. But, if you have no interest in them, 
then no points to XFS. XFS _may_ produce less fragmentation, but in your 
environment the alternatives may be just as good.

Summary

I like it. I trust it. It's got advantages compared to other filesystems 
and other filesystems have advantages over it. It's not a ticking 
timebomb waiting to eat your data, otherwise it wouldn't be used in 
mission critical systems. It may or may not be the best filesystem for 
your particular workload, but you can trust it too. It's mature, even on 
Linux and it doesn't deserve to be bad mouthed.

Michael

Duncan, have you personally had XFS corrupt your data? If so, when and 
on what kernel?