On Wednesday, 16 August 2017 11:12:06 AM AEST Rick Moen via luv-main wrote:
It's funny seeing XFS make a resurgence. I used it on Debian back before ext3 had become mainstream. At the time, it seemed solid technology but its Linux future was (then) in doubt because it was a huge patchset.
me too. I went from ext2 to XFS, then briefly to btrfs and then ZFS. At the time, XFS was **THE** rock-solid reliable journalling filesystem for linux, with features unmatched by any of the mainline filesystems. Nowadays I use a mixture of ext4 and ZFS - ext4 for /boot partitions, ZFS for everything else (even for the rootfs on most systems nowadays). On some systems I still use XFS for the rootfs, but only because I haven't bothered or have no compelling reason to convert them to root on ZFS. The only reason I use ext4 for /boot is because it will make disaster recovery easier if that's ever needed - e.g. so that I can have grub entries (memdisk) to load a rescue ISO with ZFS support. In other words, the usual reason for having a separate /boot partition. There's no reason to have /boot on XFS - it's too small to benefit from any of the features of XFS that make it superior to ext4. There's no particular reason not to use XFS for /boot, either (except maybe greater overhead - i'd have to check to be sure and it's not worth the time it would take me to google it). On Thu, Aug 17, 2017 at 01:37:24PM +1000, Tim Connors wrote:
Both XFS and btrfs enthusiastically like to silently throw any data written in the past 5 days on the floor when there's a power failure/kernel panic, so there's that commonality.
That's always been a false claim about XFS. The truth is far simpler, and far more reasonable. If there's a power failure or similar crash *while there is unsynced data in the write cache*, then after a reboot, if the crash circumstances were just right (or maybe "just wrong") then XFS can return a block of NUL bytes rather than whatever random garbage might have been in that unwritten block at the time. This confuses people because they see all those ugly NULs (e.g. embedded in their log file) and wonder WTF they're there. This is no worse, and arguably better (because silent corruption is worse than visible corruption), than what some other file systems do (which is return the random garbage that happened to be in the sector) - but in both cases, the data that you *wanted* written to the disk is gone because it hadn't actually been written yet at the time of the crash. This, BTW, is a race condition that's unavoidable by software alone (very fast non-volatile write cache mitigates a LOT), with varying results depending on the order of operations - e.g. whether metadata is written before data or vice-versa and also on whether journal/metadata is synced before or after data. Whichever way that is done, there's always going to be some risk that either or both will be lost in a power-failure or similar catastrophic failure craig -- craig sanders <cas@taz.net.au>