[DRBD-user] DRBD and JFS/XFS/ext3/whatever: whats your favorite file system for which purpose?

[H.D.]

On 05.04.2007 15:31, Leroy van Logchem wrote:
> Story type: Horror
> I will never use XFS again. It delays flushing changes to disk too long.
> So a power loss destroyed a complete filesystem; couldnt repair.
> xfs_force_shutdown and XFS_WANT_CORRUPTED_GOTO at line 1634
> where the messages thrown at the user and didnt get fixed since 2004.
> So went back to ext3, never failed. It's a little slower when sustained
> writes are congesting the journal but it's fine. I'am looking forward to
> try ext4 with delayed allocation, multiblock alloc and online defrag.
> The last time I could defrag a unix filesystem was Veritas vxfs on Sun.

XFS is mature and stable file system, but you really need to obey a few 
things:

XFS is solely designed for production grade hardware. If you have 
something in your storage subsystem that delays or lies about fsync/fua 
requests you are asking for trouble. The same goes for controllers 
without BBU. XFS absolutely requires your hardware to work as 
advertized. There have been tools around for quite some time to test the 
behaviour of hardware in case of power failures. If you are not 100% 
sure what hardware you got, and if you have it configured correctly, the 
time to test is now. A single misconfigured option in your raid 
controller might very well make you lose a huge amount of data with XFS. 
This is known, this is how it is designed, if you are uncomfortable with 
that, don't use XFS or fix your hardware.

> It delays flushing changes to disk too long.

XFS never delays flushing of metadata, and flushing data is the sole 
responsibility of the application. XFS does nothing to help broken 
applications to recover and there is no reason it should. Anything that 
doesn't conform to ACID should not be run on XFS (or any other meta 
journaling filesystem).

> So a power loss destroyed a complete filesystem; couldnt repair.

That really sounds like broken hardware. You should be able to power 
cycle all the day, without XFS ever needing xfs_repair. xfs_repair is 
there to recover from hardware failures.

> The last time I could defrag a unix filesystem was Veritas vxfs on Sun.

XFS ships with a good online repacker / defragger, xfs_fsr.

Besides that http://vleu.net/shake/ works quite well with most file systems.

> It's a little slower when sustained writes are congesting the journal but it's fine.

For our OLTP workload, XFS + deadline i/o gave about 38% more throughput 
compared to ext3 + anticipatory.

One more note:

Everything related to 4k stacks should have been fixed a long time ago, 
but I'd still recommend using an 8k kernel with XFS, it's more tested.


-- 
Regards,
H.D.