[Linux-ha-dev] Filesystem command deficiencies

[Lars Marowsky-Bree]

On 2005-03-31T22:40:27, Alan Robertson <alanr at unix.sh> wrote:

> A while back this problem came up, and there was a bunch of email about it, 
> some disconnects about what people thought was wrong, references to bugs in 
> obsolete versions, etc.
> 
> Then we created a bugzilla entry which got even further out of hand, and 
> became infected with and advanced case of creeping featurism, seven 
> patches, including one with email quoting.  Although I never have liked the 
> Filesystem code, and it does need improvement, all its problems stacked on 
> top of each other are nothing compared to the mess the discussion about 
> them became.
> 
> The net result of this, is that I'm really confused about what Filesystem 
> ought to do, why it ought to do it.

This is one-hundred-percent my own feeling, and why I ended up no longer
replying to the bugzilla entry :-( Thanks for the clean slate!

I agree with all you've said, which is why I just focus on some specific
comments:

> START ACTIONS:
> --------------------------------------------------------
> 
> 5) It unconditionally inserts the SCSI module (no error check)
> 
> 6) It unconditionally inserts a kernel module with the same
>    name as the filesytem type
> 
> 7) It looks to see if a module is loaded with the same name
>    as the filesystem type

For the start, this irks me most. It really should go load modules.

> 8) It looks to see if it is a journalling filesystem, and if it isn't,
>    it performs a filesystem check on it.
> 
> 9) If the filesystem check performed above gives an error code >= 4
>    it considers the fsck to have failed, and exits without
>    trying further.

> 10) It flushes the buffers associated with the device using the
>     flushbufs function

Actually, step 10) probably needs to happen before 8).

> The code for detecting if a filesystem is mounted won't work correctly if 
> the /etc/mtab is hosed up.  It would be straightforward to implement a 
> better version in a function.  [Note that this proposed new function needs 
> to work on non-Linux systems too].

Just an observation: /etc/mtab might contain filesystems or options
which are not present in /proc/mounts. This needs to be accounted for; I
think loopback mounts for example are one of these cases. I'd suggest to
not make this our problem, but rely on the output of the "mount"
command: If that is not reliable, that needs fixing, not our code.

I recommend turning on a very strong Someone Elses Problem field here
;-)

> The code for killing/unmounting (16-18) has been criticized as being 
> insufficiently robust with respect to how long it takes processes to die 
> and get cleaned up, and with respect to being too rude regarding to the 
> signal used (SIGKILL).  I understand the timing issue, but am unimpressed 
> by the "rudeness" argument.  [I can elaborate on why I feel this way if 
> anyone cares].

I guess I do see your point already: Because anything here _should_
already have been stopped by the resource scripts before us. I admit I'd
still try the "graceful" -TERM first, but I can see your point and it's
probably not worth arguing about ;-)

Sincerely,
    Lars Marowsky-Brée <lmb at suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business