Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1176851 > unrolled thread

Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Feature request, "create on mount" to create mount point  directory on mount, implied remove on unmount jon <jon@jonshouse.co.uk> - 2015-07-05 10:30 +0200
    Re: Feature request, "create on mount" to create mount point  directory on mount, implied remove on unmount Al Viro <viro@ZenIV.linux.org.uk> - 2015-07-06 03:10 +0200
      Re: Feature request, "create on mount" to create mount point  directory on mount, implied remove on unmount jon <jon@jonshouse.co.uk> - 2015-07-06 04:40 +0200
        Re: Feature request, "create on mount" to create mount point  directory on mount, implied remove on unmount Al Viro <viro@ZenIV.linux.org.uk> - 2015-07-06 05:10 +0200

#1176851 — Re: Feature request, "create on mount" to create mount point directory on mount, implied remove on unmount

On Sat, 2015-07-04 at 16:56 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 03 Jul 2015 13:01:59 +0100, jon said:
> > Hi, could I make a hugely nieve user request :-)
> >
> > Would it be possible to add a new mount option to everything?
> >
> > New mount option 'com' = "create on mount" (implied remove on unmount).
> >
> >
> > Example fstab entry
> > /mounts/amountpoint	LABEL=notalwayshere	ext4,com
> 
> I'll bite.
Thank you :-)

>   What system administration problem does this solve?
Most auto mounters are based on an a system event being processed by a
user space tool. I am talking about a simple optional bit of code built
into mount() umount() calls.  So it could be an fstab entry, or typed
into a shell or any other source rather than an event processed through
user space tools in response to USB or a DVD read or similar. I am not
talking about an automount.

It solves these problems:
1) It solves the problem of processes writing data into the mount point
when not mounted (as does, I accept a user space automounter, but as I
explained the usage scenario differs). 

2) It would be useful for embedded devices, installers etc.  I do quite
a bit of work in the embedded space, sometimes running kernel+shell+user
process only, sometimes no udev, no systemd, not even full fat init.  

3) installers or similar could use such an option for mounting install
data. By specifying the flag user space processes can infer that the FS
is successfully mounted by the presence of the mount point without the
need to explicitly code against an event system or parse log files. 

3) Users can use it to have a slightly improved new mount behaviour and
also hopefully be used as a flag to indicate that "oh so clever user
space managers" should stay away entries using it in fstab.

> In particular, automount has been around in one form or another *at least*
> since SunOS3.2 in the mid 80's, and I have seen it work with huge user maps
> (10k+ users). 
Yes, but like I say automount is normally based on an event. I am simply
talking about a flag/switch that can be used for optional implied
mkdir,rmdir around calls to mount() unount() - nothing more, nothing
less !

Such a feature would mitigate the justification for some of the less
sensible behaviours of systemd or similar user space event processors.

By adding at as an option it would not break other behaviours where it
was not explicitly enabled.

To be completely clear, I am not after a kernel based auto mounter -
just a kernel based mount point creator/remover, it is not quite the
same thing !

>How did it cope for 30+ years without this feature?
By people saying "ahh bugger" when a mount fails and some process craps
out files all over the mount point directory I expect ......

<partial rant>
Or maybe by the new "improved" systemd way of failing to go multi user
when an device referenced in fstab is offline, fucking things up for
anyone without true remote administration - the price you pay for using
cheap PC hardware on a small scale, you know, like Linux cheerleaders
always claimed was its unique selling point ......  
As a bonus I would hope that systemd would take such a mount option to
mean that an FS specified in fstab would be optional, but that would
just be a bonus and is not my justification for such a a feature.
</rant>

I can probably think of other reasons, but off the top of my head it
just seems a useful behaviour to have as an option IMHO.

I know my suggestion is not as fashionable as hanging user space code
from the kernel events, but I personally would rather just have the
option natively in the kernel rather than an option for some 'pre' or
'post' mount() umount() event that some user space process needs to
handle.

Thanks,
Jon


--
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/

[toc] | [next] | [standalone]

#1177086

On Mon, Jul 06, 2015 at 12:35:48AM +0100, jon wrote:
> > Anyway, the underlying model hasn't changed much since _way_ back; each
> > thread of execution is a virtual machine of its own, with actual CPUs
> > switched between those.
> Ok, not sure I quite follow. What do you mean virtual machine  ? 
> My understanding was that a true VM has a hypervisor and I though also
> required some extra processor instructions to basically do an "outer"
> context switch (and some memory fiddling to fake up unqique address
> spaces) while the operating systems within the VMs own scheduler is
> doing the "inner" context switch (IE push/pop all on Intel style CPU).
> Not all architectures have any VM capability. 
> Are you talking about kernels on Intel with SMP enabled only ? 

Anything timesharing, starting with 7094 running CTSS.  Hypervisors allow to
virtualize priveleged mode parts of processor; it's a different beast.

Each process sees CPU and memory of its own; what the kernel does to give them
such an illusion depends upon the system (up to and including full write of
registers and user memory to disk, followed by reading that of the next
process back from disk - remember where the name "swap" had originally come
from?), but no matter how you do that, you give process a virtual CPU of
its own and multiplex the actual processor(s) between those.

From the process' point of view system call is just a weird instruction that
has rather convoluted side effects.  The fact that it actually triggers
a trap on the underlying hardware CPU, switches to kernel mode, marshals
the arguments, arranges execution environment for C code, executes it, etc.
is immaterial - as far as userland code is concerned, the kernel is a black
box.  For all it cares, there might be another CPU sitting there, with
entirely different instruction set and something running on it.  With
"system call" insn on your CPU raising a signal to attract attention of
the priveleged one and stopping itself until the priveleged one tells it to
resume.

It's considerably older than hypervisors (and both are much older than
x86).

> > Parts of those virtual machines can be shared - e.g. you can have descriptor
> > table not just identical to that of parent at the time of clone(), but
> > actually shared with it, so e.g. open() in child makes the resulting descriptor
> > visible to parent as well.
> Ok, I follow you. I often dont need anything more complex than fork(),
> when I thread I use pthreads so have not dug around into what is
> actually happening at the kernel level.  I was not aware that the parent
> could see file descriptors created by the child, is this always true or
> only true if the parent and child are explicitly a shared memory
> process.

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.

> 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 (and what's to
guarantee that all filesystems it had been mounted on are still alive
when the last mount goes away)?
--
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/

[toc] | [prev] | [next] | [standalone]

#1177097

On Mon, 2015-07-06 at 02:08 +0100, Al Viro wrote:
> On Mon, Jul 06, 2015 at 12:35:48AM +0100, jon wrote:
> > > Anyway, the underlying model hasn't changed much since _way_ back; each
> > > thread of execution is a virtual machine of its own, with actual CPUs
> > > switched between those.
> > Ok, not sure I quite follow. What do you mean virtual machine  ? 

> Anything timesharing, starting with 7094 running CTSS.  Hypervisors allow to
> virtualize priveleged mode parts of processor; it's a different beast.
This was my point.  To me "virtual machine" is a modern term that
describes something running with a hypervisor.
My confusion is you are retrospectively applying it to time sharing.
I managed to find the article that first taught me about schedulers, the
1979 Byte article "Introduction to Multiprogrammig" 

https://archive.org/details/byte-magazine-1979-09

Searching for the pdf for the term "virtual" gives one result, not in
that article.

I remember "virtual memory" and even "virtual addressing" but I think
the term "virtual machine" is modern, maybe someone else knows, google
did not help me much trying to prove it one way or the other.

> It's considerably older than hypervisors (and both are much older than
> x86).
Yes it is, but it was not called "virtual machine" at the time in anything I personally read.

> I was not aware that the parent
> > could see file descriptors created by the child, is this always true or
> > only true if the parent and child are explicitly a shared memory
> > process.
> 
> 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.


> > 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 ?
int mount(const char *source, const char *target,
 

>  (and what's to
> guarantee that all filesystems it had been mounted on are still alive
> when the last mount goes away)?
?The same rules that would be in play if it was cross mounted in some
other way, or am I being dumb here?

I assume Linux will not let me unmount a mount point from lower in the
directory tree. I've not tried in living memory so lets give it a
go ....

root@jonspc:/# mkdir mounttest
root@jonspc:/# cd mounttest/
root@jonspc:/mounttest# mkdir firstmount
root@jonspc:/mounttest# mount /dev/sdb1 /mounttest/firstmount
root@jonspc:/mounttest# cd firstmount/
root@jonspc:/mounttest/firstmount# mkdir secondmount
root@jonspc:/mounttest/firstmount# mount /dev/sdb1 /mounttest/firstmount/secondmount/
root@jonspc:/mounttest/firstmount# cd ..
root@jonspc:/mounttest# umount /mounttest/firstmount
umount: /mounttest/firstmount: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

It fails, as I expected.
 Also rmdir would fail if the mount point had was anything other than
empty, mkdir would fail if the mount point was already created.
I don't see how the kernel doing a pre mount mkdir and a post mount
rmdir would differ in outcome from user space performing the same
operations regardless of convoluted configuration was in use.
Like I said I dont use containers or Zen so can you show me a
(preferably simple) scenario that my proposal breaks.

I assume an entry in a table in the kernel is the source of the above
"device is busy" message, is this not also true if the name spaces
differ but the same file system is mounted in multiple places?

I would expect unmount <device> to unmount all mounted references to
that device and umount <mountpoint> to remove just that mountpoint or am
I miss remembering....



--
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/

[toc] | [prev] | [next] | [standalone]

#1177101

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web