Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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.