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
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
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 sanders <cas(a)taz.net.au>