plans and wishes

Bill's LFS Login lfsbill at
Fri Jan 23 04:25:37 PST 2004

On Thu, 22 Jan 2004, Joel Miller wrote:

> On Thu, 22 Jan 2004 22:51:39 +0100, Alex Groenewoud
> <alex at> wrote:

> > reading carefully, the FHS never speaks of subdirectories of /mnt, it
> > just says that _/mnt_ is provided to temporarily mount _a_ filesystem,
> > it doesn't mention subdirs nor speaks of filesystems.  I know it's
> > common practice to use subdirs of /mnt, but I don't like it.  What I in

I don't know if they intended to *imply* what you imply or if they are
just "Johnnie-come-latelys" who don't know the historical usage. IMO,
the proper interpretation of that should be "mount filesystems" rather
than mount "mount a single filesystem". Maybe they didn't realize what
they were saying literally. Maybe they are out to change the world.
Doesn't really matter I guess.

> see above. I'll also note that your extremely literal interpretation of
> that statement in the FHS is not in agreement with my interpretation of
> it. Thus we go back to different people with different
> preferences/interpretations. Again, a pointless argument.

Not really. The fact is that /mnt was intended to contain additional
mount points, and has traditionally been used that way, since the
earliest UNIX systems (my experience includes PWB V6/7, System III/IV/V
and many off-shoots and subsequent releases). So the argument morphs into
one of "convention", "de-facto standards" and avoidance of
"non-standard" usages that make use less intuitive when new folks work
on the system.

And the ability to mount an FS, containing another "mnt" (or any dir,
for that matter), implicitly provides a hierarchical FS capability under
mount. This was intended and has always been used in that manner but the
majority of the UNIX community.

What this says, strongly, is that anyone going against that convention
is making their system potentially less "friendly" to other experienced
folks that need to use/maintain the system because of their experience.

And yes, there are other reasons to have mount points outside of /mnt
and this is also fairly common. But it is *usually* reserved for
"permanent" mounts that need to appear in a "logical" hierarchy and are
not "temporary" mounts.

The convention I've seen most frequently seems to indicate that *all*
temporary mounts appear under /mnt or one of its subdirectories
(including mount points within other mount points) *unless* there is a
*need* for it to be elsewhere. Permanent mounts are traditionally

> > fact would like to see the book use is not $LFS, not /mnt/lfs, not /lfs,
> > but /mnt.  But I guessed that would receive universal opposition.

As mentioned above, /mnt has traditionally contained additional mount
points (subdirs). When you mount on /mnt, they are no longer available.
We should presume the user's host uses /mnt in the conventional way and
we must not make /mnt become unusable in the traditional way.

And, following the book's stated intention of minimal disruption/change
to the host, we must also *not* make any unneeded additional directories
and especially not in any unconventional places *unless* absolutely

All this says: /mnt/lfs is preferred, /lfs is deprecated and mounting on
/mnt is not a desirable option.

Yes, there are other cases where all this applies too. And maybe they
should also be addressed. The difference (ATM) is they originated from
"day one" in their current form and we are not suggesting changing them
from a more conventional use to a less conventional one.

Suggestion: leave /mnt/lfs alone, it is a "Good Thing".

> Even if I agreed with you, that would be crazy because the hosts people
> would be building from don't agree with your narrow interpretation of the
> /mnt directory. Any distro I have ever used creates subdirectories of /mnt
> to mount various things and if we were to mount the lfs partition onto
> /mnt directly then they would lose all their mount points.

I see I dupe some of what you say here. Oh well, reinforces learning I

> >> Making partition mounts under /mnt is the Unix way IMHO. Anything else
> Amen!

> > should obey the rules.  But if an admin is not free to do whatever she
> > pleases on her own system, where have we ended up?

Well, we end up with a greater likelihood that other admins may be more
effective in working on another admin's system. A Bad Thing in regards
to job security.

> >
> > Alex
> >

NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
Fix line above & use it to mail me direct.

More information about the lfs-dev mailing list