Dave Chinner wrote:
On Sat, Aug 14, 2010 at 07:03:20PM -0700, Linda Walsh wrote:
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
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
