Re: xfs.fsck change that is unhelpful

Linda Walsh
2010-08-15T02:03:21Z

Dave Chinner wrote:
> On Sat, Aug 14, 2010 at 01:48:01PM -0700, Linda A. Walsh wrote:
>> Some time ago, when I upgraded a system, I ran into problems when
>> it hit a file system that was offline. It wasn't a critical
>> partition, so it normally wouldn't have been an issue, but somewhere
>> along the line
>> someone mangled fsck.xfs.
>
> fsck.xfs is behaving identically to e2fsck when presented with an
> invalid block device - it exits with an error of 8, which is defined
> as "operational error" in the e2fsck man page.
---
That may be fine for the ext2 fs, but I am asserting that in actual
practice, with xfs, it does more harm than good.

> That sounds like a problem with the distro init scripts or you've
> stuffed up your /etc/fstab config (i.e. fs_passno is wrong). Indeed,
> setting fs_passno = 0 will cause the filesysetm fsck to be skipped
> completely on boot, regardless of the fs type...
---
Yes, you are right. They are setup to be check in the order
I would want them mounted. But I don't see the benefit to being
compliant with a checking mechanism for a file system that is
actually needs fsck.

It was long a *feature* of xfs, that xfs.fsck, was a noop.

I don't see that making it fail in ways fsck does for a file
system that *needs* fsck, is productive. Sure, it may be dotting i's
and crossing t's, but in reality, is that a standard xfs should be
living down to?