Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Nix <nix@esperi.org.uk>]

On 20 Jun 2007, H. Peter Anvin verbalised:

> Right now it is actually impossible to conclusively determine a
> filesystem-relative path in the presence of bind (and possibly move)
> mounts.  This is highly desirable to be able to do in contexts that
> involve non-Linux (or not-the-current-instance-of-Linux) accesses to the
> filesystem, e.g. other filesystems or bootloaders.

It's also highly desirable if you want to be able to run a backup :) one
would desire to back up the filesystem as a whole, not some bind mount
of one directory out of it (and backing up both is needless
duplication).

So I applaud this and would be an immediate user, no matter what format
is chosen, as long as we can tell what is mounted where.

(As an aside, it would be nice if mount(8) could supply (a limited
amount of) extra (arbitrary?) textual options to the kernelq,
specifically so that mount options which are only interpreted by
userspace programs, like `user' and the quota options, could appear in
/proc/mounts. That way we could finally ditch bloody /etc/mtab for good.

(Any other approach requires mount(8) to keep track of these options in
a separate file, which brings back exactly the same synchronization
horrors that we're all so nauseatingly familiar with from /etc/mtab.)

> I'm personally leaning toward the second option (/dev/md6:/users/foo).
> Although that might confuse current utilities, those utilities are
> *already* liable to get confused by the fact that the line doesn't mean
> what they think it means.

Quite so. The output from df(8) in the presence of large numbers of bind
mounts was ludicrous before it started explicitly ignoring filesystems
of type `none', and that was arguably the wrong place to fix it.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/