[Linux-ha-dev] Filesystem command deficiencies
lmb at suse.de
Tue Apr 5 05:44:47 MDT 2005
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
> 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 ;-)
Lars Marowsky-Brée <lmb at suse.de>
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
More information about the Linux-HA-Dev