On 10/12/2016 03:57 PM, c...@zip.com.au wrote:
Except it the wildest scenarios, XFS fsks at mount, almost immediately.
Is that different from fsck.ext4 replaying the journal?
Go and cat (yes, cat) the fsck.xfs command.
OK. I'm not sure what you think I'll learn by doing so. fsck.xfs
exists because Linux's "fsck" supports multiple filesystems and Irix's
did not. On Irix, fsck was exclusively for EFS. XFS used xfs_check and
xfs_repair. When XFS was ported to Linux, the tools were not renamed;
instead fsck.xfs was put in place to direct users to the correct tool
when they ran "fsck -t xfs".
None of that makes XFS immune to corruption, nor reduce the time or the
memory required to fix an XFS filesystem if it's damaged.
"Never" is indeed not _literally_ true, but it is effectively true,
far far far far more than is so with ext4. Ext4 really needs fsck
after an unclean unmount, and it is not cheap for large filesystems.
With journaling and write barriers in place, I don't know any reason
that ext4 would be any more affected by a power loss than XFS would be,
and having had to perform recoveries on both, I don't find one to be
significantly better than the other.
Thus, my advice remains that users should test both because they do
differ in performance in different workloads. If one will be faster
under normal operation, 99.95% of the time, and require slightly more
down time to recover in the other .05% of the time, then selecting the
option which is superior 99.95% of the time is a perfectly rational
thing to do.
That's especially true of backup systems where down time does not carry
the same impact as down time in a production system does.
The two are like night and day in the recovery scenario (== xfs pretty
much never needs manual recovery, and recover is very fast).
That seems subjective. I've personally had to recover more XFS
filesystems than I have ext4 filesystems, and I use ext4 filesystems
more often. My subjective experience is quite different than yours.
users mailing list -- email@example.com
To unsubscribe send an email to users-le...@lists.fedoraproject.org