xfs.fsck change that is unhelpful

[Linda Walsh]

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?