All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: subvols, ro- and bind mounts - how?
Date: Thu, 10 Dec 2015 22:13:24 +0100	[thread overview]
Message-ID: <1449782004.7032.19.camel@scientia.net> (raw)
In-Reply-To: <pan$eafa8$b5da4379$31bc32b1$5bc4c9a0@cox.net>

[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]

Hey.

I'd have an additional question about subvols O:-)

Given the following setup:
5
|
+--root (subvol, /)
   +-- mnt (dir)

with the following done:
- init 1
- remount,ro / (i.e. the subvol root)
- mount /dev/btrfs-device /mnt (i.e. mount the top subvol at /mnt)

The following happened:
- / was ro-mounted (obviously, at least one thing that I had expected
  correctly)
- /mnt was ro-mounted either (and the /mnt/root/ nested subvol then as
  well).
  => why is /mnt (i.e. the top level subvol) mounted ro??
  => I would have expected that, since / (i.e. the subvol "root" is ro
     mounted), it's also ro mounted as the nested subvol below 5, i.e.
     my naive thinking was in terms of logic:
     "/ mounted ro" => "subvol root is mounted ro (everywhere)"
       => "thus /mnt/root/ is mounted ro as well"

However, the later doesn't seem to be true, cause then I did:
- remount,rw /mnt
=> now /mnt/*, including /mnt/root/* was rw moutned



So I guess my assumption of subvols behaving more or less as if they'd
be a fs (and thus mounted at one place ro => everywhere ro) is not
true, is it?

Do, ro,rw (and possibly others) instead only affect the respective
mountpoint?
And automatically any nested subvols of that mountpoint?

So I could have basically:
/mount-point1/subvol-a	; ro, noexec
/mount-point2/subvol-a	; rw, compress=yes
/root			; rw, compress=no
/root/here/it/is/nested/subvol-a ; (no mountpoint)

(with subvol-a being the same subvol)

And when I write via mount-point1 I'd get an error, but via mount-
point2 it works and in addition I get compression, while when writing
via the /root mountpoint, where it is nested, I'd get the rw and
compress=no from the "parent" mountpoint /root


Does that sounds correct?
It seems to make sense actually, though it's a bit unfamiliar... if I'm
not correctly wrong, than e.g. in terms of ext* I cannot have the same
fs mounted with different settings,... of course I cannot have it
mounted twice at all, but speaking of bind mounts.

So I guess, that when I'd do --bind mounts instead, I actually do get
the "old" behaviour, i.e. when the source is ro, then the --bind
mount's target is also forcibly ro.


Still, one unclear thing, why got /mnt mounted ro very above?



Thanks,
Chris.

btw: Not sure if I just missed it, but I guess the above should be more
or less documented, showing people that mounting subvols (especially
when mounting the same several times, either directly or as nested
subvol) has these implications.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

  reply	other threads:[~2015-12-10 21:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24  4:56 subvols and parents - how? Christoph Anton Mitterer
2015-11-24  8:29 ` Duncan
2015-11-24 21:25   ` Christoph Anton Mitterer
2015-11-24 21:55     ` Hugo Mills
2015-11-24 23:20       ` Christoph Anton Mitterer
2015-11-24 23:30         ` Hugo Mills
2015-11-24 23:38           ` Christoph Anton Mitterer
2015-11-27  1:02     ` Duncan
2015-12-09  4:36       ` Christoph Anton Mitterer
2015-12-09 10:53         ` Duncan
2015-12-09 19:04           ` Austin S Hemmelgarn
2015-12-10  3:56             ` Duncan
2015-12-10 12:31               ` Austin S Hemmelgarn
2015-12-12 19:58           ` Christoph Anton Mitterer
2015-11-27  2:02     ` Duncan
2015-12-09  4:38       ` Christoph Anton Mitterer
2015-12-09 11:26         ` Duncan
2015-12-10 21:13           ` Christoph Anton Mitterer [this message]
2015-12-10 22:36             ` subvols, ro- and bind mounts " S.J.
2015-12-10 23:41               ` Christoph Anton Mitterer
2015-12-11  2:32               ` Chris Murphy
2015-12-12 20:27                 ` Christoph Anton Mitterer
2015-12-12  2:32           ` subvols and parents " Christoph Anton Mitterer
2015-12-12  3:07             ` Christoph Anton Mitterer
2015-12-12 10:20             ` Duncan
2015-12-09 14:49       ` Axel Burri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1449782004.7032.19.camel@scientia.net \
    --to=calestyo@scientia.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.