Desktop Filesystem Benchmarks in 2.6.3

[Ivan Ivanov]

I don't think that XFS is a desktop filesystem at all.

This is from XFS FAQ:

qoute
------------
Q: Why do I see binary NULLS in some files after recovery when I
unplugged the power?

If it hurts don't do that!

* NOTE: XFS 1.1 and kernels => 2.4.18 has the asynchronous delete path
which means that you will see a lot less of these problems. If you still
have not updated to the 1.1 release or later, now would be a good time!

Basically this is normal behavior. XFS journals metadata updates, not
data updates. After a crash you are supposed to get a consistent
filesystem which looks like the state sometime shortly before the crash,
NOT what the in memory image looked like the instant before the crash.
Since XFS does not write data out to disk immediately unless you tell it
to with fsync or an O_SYNC open (the same is true of other filesystems),
you are looking at an inode which was flushed out to disk, but for which
the data was never flushed to disk. You will find that the inode is not
taking any disk space since all it has is a size, there are no disk
blocks allocated for it yet.

This same will apply to other metadata only journaling filesystems. The
current linux kernel VM will write out the metadata after 1/60th of a
second and the data after 30 seconds. So the possibility of losing data
when unplugging the power within 30 seconds is quite large. The only way
of being sure that your data will get to the disk is using fsync in the
program of sync after closing the program.
------------

I am trying XFS from 2.4.6 and I can reproduce this case easy. Simply
write some file and unplug the power during write. And we are talking
for desktop :). XFS is the worst case for recovery too.

For desktop filesystem speed is not mandatory. Hard disk speed is most
importatnt. And much more important is recovery. So I think that ext3 is
the best solution for desktop system. It performs well and is the most
recovarable linux filesystem.