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?
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
