xfs.fsck change that is unhelpful
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.
Instead of doing the useful thing with an xfs file system and being a
link to ->/bin/true, someone thought it would be neat to return failure if
it couldn't find the file system that it was supposed to check (mount-by-name, name not yet present, => system refuse to boot).
I asked suse why they put this check in and they said it had been done upstream.
This was a bit back, but it keeps biting me with new revisions until I replace it with a link to /bin/true.
Note: if it actually did a check that was supposed to be done prior to mounting each file system, like ext2 or such, I wouldn't be doing such and probably wouldn't be using the file system if there was an alternative. I'd rather have the system come up to the best of its ability rather than failing for no good reason.
So, I'm here - asking, if this was done here, why? It serves a _less_ _than__useful_ _purpose_ --in that it hinders what is usually a perfectly functional system from coming up where after _REMOTELY_ logging in, the problem could be noted, debugged, and perhaps even fixed remotely. In the case of a /dev/Space/Test, file system, it might not be
necessary to do anything immediately.
I see absolutely no useful purpose served by this. If it's a key
file system (which in my case, it never has been -- it's the "peripheral file systems" that have occasionally been absent upon boot, the core file systems being located in the machine).
In my systems design, I'm in the camp that subscribe to having redundancy present to automatically work around problems and continue working as best as possible in the presence of any problem. I'm not in the camp of designing a 'human', who has a cut finger to immediately go unconscious due to a 'fault' in their skin integrity. Ideally you want the brain to come up so it can assess and deal with damage -- at least from my point of view. So I don't understand this 'change'.
Would it be unreasonable to request that this behavior be reverted? In my case, at least, it seems only to cause more harm than good. And while I can imagine scenarios in which you don't want the computer to come up at all, I think they would be in the minority compared to those systems where the admin would prefer the system come up so
it can be reached 'normally' ("normal" interactive login).
If not can you describe how the new functionality results in greater system reliability/availability than before, "cuz", I just don't see it.
thanks,
Linda Walsh
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 6 lines · Linda A. Walsh
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.
Quoted 3 lines
Instead of doing the useful thing with an xfs file system and being a link to ->/bin/true, someone thought it would be neat to return failure if it couldn't find the file system that it was supposed to check
If the device is not present when the bootup sequence is attempting to access it, then you've got a configuration error somewhere. It should return an error.
Quoted 1 line
(mount-by-name, name not yet present, => system refuse to boot).
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...
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Dave Chinner
Quoted 5 lines · Linda A. Walsh
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.
Quoted 4 lines
That sounds like a problem with the distro init scripts or you've stuffed up your
/etc/fstabconfig (i.e.fs_passnois wrong). Indeed, settingfs_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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · On Sunday 15 August 2010, 04:03:20 Linda Walsh wrote:
Quoted 7 lines · Dave Chinner
Quoted 5 lines · Linda A. Walsh
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.
Quoted 7 lines
Quoted 3 lines
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.
Linda, you're barking at the wrong tree, IMHO.
If xfs would tolerate any configuration failure, a lot of people would complain for a _good_ reason.
Quoted 11 lines
Quoted 4 lines
That sounds like a problem with the distro init scripts or you've stuffed up your
/etc/fstabconfig (i.e.fs_passnois wrong). Indeed, settingfs_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.
Quoted 6 lines
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?
Of course, most of the attending audience is being bitten by such a configuration failure, but to argue, that it is wrong behavior, if the init code decides to stop booting, because some devices configured to mount on boot failed to mount, is, hmm, incongruous..
By (current) definition, the init system has absolutely no business to _weight_ the _severity_ of such a basic failure. Nowadays, there are enough ways to delay the mount (noauto, autofs) for certain FS in order to avoid such a failure - if that is what you want - but generally ignoring any fsck failures, be them on journaling FS or not is not acceptable. And making xfs special in the regard is even more incongruous.
Pete
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Linda Walsh
Quoted 7 lines · Dave Chinner
Quoted 5 lines · Linda A. Walsh
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.
Quoted 6 lines
Quoted 3 lines
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.
I would suggest using autofs, so that you can keep fstab to an absolut minimum.
Except for devices related to booting, i personally mount everything either with autofs or manually(In that case it's normaly a one-shot thing).
In my case that are all "non boot related" devices, DVD-drive, network filesystems, some "tmpfs"es for playing, removable-devices, etc.
Bis denn
Signature · 9 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Linda Walsh
Quoted 7 lines · Dave Chinner
Quoted 5 lines · Linda A. Walsh
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.
Quoted 6 lines
Quoted 3 lines
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.
For whom?
Quoted 11 lines
Quoted 4 lines
That sounds like a problem with the distro init scripts or you've stuffed up your
/etc/fstabconfig (i.e.fs_passnois wrong). Indeed, settingfs_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.
It wasn't a feature - it was simply to ensure that initscripts worked. There was simply no reason for it to do anything else until someone discovered that their booot problems were caused by non-standard behaviour. i.e. fsck wasn't catching non-existent devices and telling the init scripts...
Fundamentally, a filesystem should integrate with common infrastructure as best as possible, and if that means behaving like other fsck programs for missing block devices, then IMO we absolutely should be doing that.
Quoted 4 lines
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?
Being different for the sake of being different is misguided at best. There's a time and place for differentiation between filesystems, but interactions with init scripts is definitely not that place.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · Dave Chinner
Quoted 1 line · Linda Walsh
It was long a *feature* of xfs, that xfs.fsck, was a noop.
It wasn't a feature - it was simply to ensure that initscripts worked. There was simply no reason for it to do anything else until someone discovered that their booot problems were caused by non-standard behaviour. i.e. fsck wasn't catching non-existent devices and telling the init scripts...
----
Fine. If it's required to be break at the slightest
provocation, then great. (*fume*)
I'd love to see that logic applied to any system that's
supposed to be reliable -- like the human body. Scrape a finger. Sorry -- can't gain consciousness. Must forever remain dormant until someone fixes my scraped finger.
I found the computer coming up to a point where I could
remotely log into it and fix the problem to be useful far more often than I've found it to be when it demands I sit at the console using a limited tool set to repair some damage left over after some upgrade or installation.
It's a pathological condition in either case. My preference
is to have it "do it's best", and not give up like a petulant child if all the t's are not crossed and all the i's are not dotted just so. That's why computers break so easily. I feel it is better design to have them try to do what is intended -- even if limpingly.
But it is required for 'init'(5) scripts -- which, apparently
are on their way out and possibly won't be used to start the machine in the next SuSE release. Perhaps the 'fall over and die' mentality is part of that decision -- and FWIW, please don't take any of my words as directed against *people*, involved in implementing the maladaptive behavior. I realize there is a job that must be done. I just don't always agree with a 1970's - 1980's era computer design philosphy that says give up at the first error.
It only bites me when I've done some measure upgrade or install and haven't
patched fsck -> /bin/true yet -- which I only do for XFS, because for XFS, it's the best possible action to take. If the device isn't there. It won't be mounted. If it really is critical to the system booting up, then the system will be stopped later. But on the off chance that /usr, /etc, /tmp...etc, are ok, the system might come up into some state where it can be remotely diagnosed and fixed.
I *LOVE* XFS, because I know it won't leave me hung out to dry during a
boot due to a failed fsck. So if init scripts need such broken mentality, I just need to remember to 1) patch it, and 2) as others have pointed out -- make changes in the system state, so that a missing file system won't prevent bootup.
That said -- how many people, who have their /home or /usr/people partition
'local' to their machine, automount it? I admit to thinking of the fsck field as having some meaning in the order in which file systems are mounted. I guess that order is random now, though how I'm supposed to tell mount that '/home needs to be mounted only after "/", but need to be mounted before /home/share, without some ordering in fstab is something that is supposed to be specified....where?
I.e. isn't that field also the order in which file systems are mounted, or
is there some other place that order is maintained other than in fstab?
Sorry, am definitely showing my ignorance in this area.
Linda
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Linda Walsh put forth on 8/15/2010 9:26 PM:
Quoted 3 lines
That said -- how many people, who have their /home or
/usr/people
partition
'local' to their machine, automount it?
I do. Who wouldn't? And why not?
/dev/sda6 /home xfs defaults 0 0 /dev/sda7 /samba xfs defaults 0 0
Quoted 9 lines
I admit to thinking of the fsck
field as having
some meaning in the order in which file systems are mounted. I guess that order is
random now, though how I'm supposed to tell mount that '/home needs to be mounted
only after "/", but need to be mounted before/home/share, without some ordering
in fstab is something that is supposed to be specified....where?
The device mount order is defined by the lines in the fstab file. Devices are mounted in order, top to bottom, as each line is read.
Quoted 5 lines
I.e. isn't that field also the order in which file systems are
mounted, or
is there some other place that order is maintained other than in fstab?Sorry, am definitely showing my ignorance in this area.
No need to apologize. This is easily remedied by learning. Start here:
In general, file system mount order is determined by the order in which
the file systems appear in the fstab file. The exceptions to this ordering are file systems mounted with the _netdev flag or filesystems that have their own init scripts.
A file system with its own init script is mounted later in the
initialization process, after the file systems in the fstab file.
File systems mounted with the _netdev flag are mounted when the network
has been enabled on the system.
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs