Message-ID: <20150706030728.GA17109@ZenIV.linux.org.uk>
Date:	Mon, 6 Jul 2015 04:07:29 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	jon <jon@...shouse.co.uk>
Cc:	Valdis.Kletnieks@...edu, coreutils@....org,
	linux-kernel@...r.kernel.org
Subject: Re: Feature request, "create on mount" to create mount point
 directory on mount, implied remove on unmount

On Mon, Jul 06, 2015 at 03:34:59AM +0100, jon wrote:
> > It is true if and only if clone(2) gets CLONE_FILES in its arguments.
> > Sharing address space is controlled by CLONE_VM and these can be used
> > independently; pthreads set both at the same time, but you can have shared
> > descriptor table without shared memory and vice versa.  Most of the time
> > you use shared descriptor tables, you want shared memory as well, but
> > it's not universally true.
> I mainly use fork(), file descriptors are copied (forward) but memory
> not shared.

fork() doesn't pass either.  Both the address space and descriptor table
are copied.

> > > Ok, I follow that :-) But logically it must be done with two functions
> > > or handlers or something, so I would assume that my proposed "remove
> > > mount directory" would simply hang off whatever call truly discards the
> > > file system from the kernel.
> > 
> > Er...  _Which_ mount directory would you have removed

> The one that was passed as "target" in the call ? I assume the kernel
> stores that ?

Which time?  You can mount the same fs many times, at many places, unmounting
them whenever you like...

mount -t ramfs none /mnt
mkdir /mnt/a
mount /dev/sda1 /tmp/a
mkdir /tmp/b
mount /dev/sda1 /tmp/b
umount /mnt/a
umount /mnt

and you've got sda1 active through all of that, with the original mountpoint
not busy anymore (moreover, the filesystem it used to be on already shut down).

What's more, there's mount --bind (attach a subtree to new location) and
mount --move (move whatever's mounted at <this> place to <that> place).

Basically, you have a (system-wide) set of active filesystems.  Mount trees
consist of subtrees in that forest (normally - entire trees) pasted together.
The same subtree (or smaller subtrees) might be seen any number of times at
any places.

You can say e.g.

mount -t xfs /dev/sda1 /mnt
mount --bind /mnt/a /usr
mount --bind /mnt/b /var
umount /mnt

and you'll get an active fs from sda1, with two subtrees (rooted at a and b
resp.) attached at /usr and /var.  By the end of that, the entire tree isn't
attached anywhere.

Seriously, say man mount and play with what's described there.  The model is
fairly simple, really...

As an aside, it's a bleeding shame that even as late as '79 *all* filesystems
on a box had to be of the same type; that's pretty much _the_ place where
Unix history went wrong - mount(2) had remained an afterthought (albeit a very
early one) all the way until v7.  Hell, as late as in v6 mounting something
on /usr and opening /usr/.. gave you /usr, not /   It was kludged up in
iget(9), of all things - mount table basically had been "when doing iget()
of this inumber on this device, use root directory inumber on that device
instead".  Consistent handling of .. had appeared only in v7.  It was very
much _not_ a first-class operation.

As far as I know, the real pressure to support heterogenous filesystem mix
had been created only by the need to support network filesystems.  Sure,
as soon as it had appeared in what was to become v8 (circa 82 or so?),
a filesystem to get rid of ptrace(2) (aka procfs) had appeared.  But it really
had been too late by then - to have netfs, you really need to have some kind
of networking API (if nothing else, to be able to implement userland servers).
And having _that_ happen before the "filesystem as a first-class object"
had pretty much doomed us to really shitty APIs.

Pity it hadn't happened in opposite order - very good reasons to do something
like e.g. procfs had all been there.  Take a look at v7 /usr/src/cmd/ps.c
someday...  And as soon as mount as the first-class operation would've been
there, a _lot_ of API design would've gone a different way...  Fucking shame
it hadn't happened in v7 - after that it had been too damn late ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists