xfs.fsck change that is unhelpful

xfs.fsck change that is unhelpful

[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. 

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs.fsck change that is unhelpful

[Dave Chinner]

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.

> 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.

> (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.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: 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?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs.fsck change that is unhelpful

[Hans-Peter Jansen]

On Sunday 15 August 2010, 04:03:20 Linda Walsh wrote:
> 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.

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. 

> > 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?

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs.fsck change that is unhelpful

[Matthias Schniedermeyer]

On 14.08.2010 19:03, Linda Walsh wrote:
>
>
> 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.

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

-- 
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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs.fsck change that is unhelpful

[Dave Chinner]

On Sat, Aug 14, 2010 at 07:03:20PM -0700, Linda Walsh wrote:
> 
> 
> 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.

For whom?

> >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.

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.

> 	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.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs.fsck change that is unhelpful

[Linda Walsh]

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs.fsck change that is unhelpful

[Stan Hoeppner]

Linda Walsh put forth on 8/15/2010 9:26 PM:

>     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


> 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.

>     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.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs