On 10/12/2016 03:57 PM, cs@xxxxxxxxxx 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 -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
