[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Ext3 partition not appearing in df output



On Mon, Oct 29, 2001 at 09:25:08PM +0000, Andries Brouwer cwi nl wrote:
> 
> Perhaps, I am not convinced.
> Mount has only one real job, that of passing user-specified
> parameters to the kernel.
> 
> For lazy people some friendliness is built-in, but it is
> friendliness that is not guaranteed to work - it is pure
> guesswork. Basically an auto mount tries all known filesystem
> types in random order until one succeeds. But the call that
> succeeds need not at all be "right" - often it is fat or so,
> just because the kernel fat filesystem code has so little checking.

Well, the question though is *who* should be doing this kind of
automatic kind of stuff, such as trying to select between ext2 and
ext3.  If you look at it from a big-picture perspective, I suspect
mount may be a better place to put it than some other alternatives,
even if this means that we need to make mount "smarter", or contain
more filesystem specific gunk.  (For example, some operating systems
actually have mount be a dispatch wrapper program like fsck, and all
of the filesystem-specific options parsing code for NFS, etc., are
contained in fs-specific programs: mount.nfs, mount.ufs, etc.)

Because I was too lazy to hack mount :-), my personal alternative to
putting "auto" in /etc/fstab and letting mount try to do the right
thing is to simply have a shell script called
/etc/init.d/fix-ext3-fstab which probed /proc/filesystems (and it
should have checked for an ext3 module in /lib/modules/`uname -r`, but
mine didn't), and then ran sed over /etc/fstab.ext3 to create the
/etc/fstab file.  That way I could use ext3 if it were available in
the kernel, but have an intelligent fallback if I booted an old kernel
that didn't support ext3.

This was an ugly hack, no question..... but I was lazy, and it was
faster than dragging down the sources to util-linux, hacking them, and
recompiling.  :-)    

But it may be that the *right* answer is to let mount be more
intelligent.  And if the issue is that the mount maintainer doesn't
want to have the fs-specific code, perhaps the right answer is to have
mount use /sbin/mount.<fstype> if it exists, and then I can distribute
a mount.ext3 and mount.ext2 which is smart enough to do the right
thing along with e2fsprogs.  That way we don't have to keep the
filesystem specific knowledge inside the mount program, but we still
have something which is relatively clean yet still adequately
functional for the user.

> So, you cannot maintain that mount "*should*" do any guesswork.
> At most that it would be nice. And even there I do not agree.
> More and more people do not realize that the guesswork is
> guesswork and report a bug if the guess is wrong.
> But it is impossible to guess right.

Well, yes.  But maybe the answer is that we need to move things around
so that programs that can do the right thing more cleanly without
needing to guess get control at the right time.  

The question is, what makes the most amount of sense from the big
picture and which also provides a relatively idiot-proof user
interface?  Surely we can do better than having shell script which
runs sed over /etc/fstab!

						- Ted





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]