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

Groups > muc.lists.netbsd.tech.userlevel > #11928 > unrolled thread

Multiple null mounts with same parameters

Back to article view | Back to muc.lists.netbsd.tech.userlevel

Contents

  Multiple null mounts with same parameters Charlotte Koch <charlotte@NetBSD.org> - 2026-10-03 19:23 +0000
    Re: Multiple null mounts with same parameters Greg Troxel <gdt@lexort.com> - 2026-10-03 18:41 -0400
      Re: Multiple null mounts with same parameters Mouse <mouse@Rodents-Montreal.ORG> - 2026-10-03 19:52 -0400
      Re: Multiple null mounts with same parameters Robert Elz <kre@munnari.OZ.AU> - 2026-10-04 07:07 +0700
    Re: Multiple null mounts with same parameters Charlotte Koch <charlotte@NetBSD.org> - 2026-10-04 06:37 +0000

#11928 — Multiple null mounts with same parameters

Hi,

I discovered that there's nothing preventing anyone from making multiple
null mounts from the same source directory *to* the same mountpoint.

     # mount -t null /src /dest
     # mount -t null /src /dest
     # mount -t null /src /dest
     ...

You can umount /dest multiple times, too, and it just works. That's
pretty neat; I suppose the "stackable layer" design of the file system
doesn't prevent this sort of interaction from happening. But to me, it
still feels wrong to permit a mount with the *same* source and the
*same* destination multiple times.

Does it make sense to prevent the user from creating a null mount whose
parameters match an existing null mount?

Charlotte

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [next] | [standalone]

#11929

Charlotte Koch <charlotte@NetBSD.org> writes:

>     # mount -t null /src /dest
>     # mount -t null /src /dest
>     # mount -t null /src /dest
>     ...
>
> You can umount /dest multiple times, too, and it just works. That's
> pretty neat; I suppose the "stackable layer" design of the file system
> doesn't prevent this sort of interaction from happening. But to me, it
> still feels wrong to permit a mount with the *same* source and the
> *same* destination multiple times.
>
> Does it make sense to prevent the user from creating a null mount whose
> parameters match an existing null mount?

I don't think it really does.  In general, you can mount things to any
dir, whether or not it is previously mounted.  If you disallow a full
match, why don't you disallow

  mount -t null /src1 /dest
  mount -t null /src2 /dest

If that's ok, what about

  mount -t null /src1 /dest
  mount -t null /src2 /dest
  mount -t null /src1 /dest


If someon has a scheme that mounts multiple things and unwinds the
stack, why should they get an error if two things match?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

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

#11930

>>     # mount -t null /src /dest
>>     # mount -t null /src /dest
>>     # mount -t null /src /dest

>> Does it make sense to prevent the user from creating a null mount
>> whose parameters match an existing null mount?

> I don't think it really does.

I concur.  If it broke something in a way that were fundamentally
unfixable, then you might have a point.  But as far as I can see the
most this breaks is human-layer expectations, so IMO it falls into
"Unix does not prevent you from doing stupid things because that would
also prevent you from doing clever things".

At the moment, I see no `clever thing', no particular use for this,
though -o union strikes me as something to think hard about if you
really want one.  But I don't see any need to make an exception to the
usually-consistent stacking filesystem rules for it, either.  At the
very least I would say that any such prohibition should (a) be
implemented entirely in userland and (b) have an option to override it.

More generally, I don't see what problem you're trying to fix here.
Indeed, I don't see any problem here, possibly excepting human-layer
confusion, and that only if the human in question doesn't understand
how filesystem stacking works in general.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

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

#11931

    Date:        Sat, 03 Oct 2026 18:41:46 -0400
    From:        Greg Troxel <gdt@lexort.com>
    Message-ID:  <rmiy0ce76fp.fsf@s1.lexort.com>

I was going to reply to Charlotte's message, but this is
a better intro:

  | If someon has a scheme that mounts multiple things and unwinds the
  | stack, why should they get an error if two things match?

As I might have written before, I suspect, I use LOTS of filesystems,
and what's more, I mount and unmount them all the time, and I also use
null mounts, generally to provide a read-only portal into a read-write
mount for some script that needs just read access to the files - like
every time I do any kind of build.

So, I have scripts just like what Greg mooted might exist somewhere,
make a null mount, do stuff (in this case mostly a build), unmount
the null mount.   It would be irritating if that failed just because
a different build was happening at the same time - even worse if the
2nd mount was just treated as a no-on, in that case the 2nd build (which
might just be a quick one to test a change) might finish, and believing
it had mounted the null mount, unmount it - while the first one is
still running.

So, no problems with how things work, and no reason to change anything.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

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

#11932

Thanks, everyone, for helping me determine whether I'd run into an issue
or not.  Despite my initial surprise, it looks like we're all in
agreement -- nothing's broken.

Charlotte

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

[toc] | [prev] | [standalone]

Back to top | Article view | muc.lists.netbsd.tech.userlevel

csiph-web