From: Goffredo Baroncelli <kreijack@libero.it>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes with different ro/rw options"
Date: Tue, 08 Jul 2014 06:07:23 +0200 [thread overview]
Message-ID: <53BB6E7B.6080205@libero.it> (raw)
In-Reply-To: <pan$5e578$d83c9a0b$aad1fa2b$9a41848@cox.net>
On 07/08/2014 04:43 AM, Duncan wrote:
> The remaining problem to deal with is that if say the root subvol (id=5)
> is mounted rw,subvolmode=rw, while a subvolume below it is mounted
> subvolmode=ro, then what happens if someone tries to make an edit in the
> portion of the filesystem visible in the subvolume, but from the parent,
> id=5/root in this case? Obviously if that modification is allowed from
> the parent, it'll change what's visible in the child subvolume as well,
> which would be rather unexpected.
The ro/rw status is a subvolume flag.
So if a subvolume is marked rw (or ro), is writable (not writable) in all
the mount(S)
This flag is not inheritable.
What could be strange is the following:
# mount -o subvolid=5,rw /dev/sda1 /mnt/btrfs-root
# btrfs subvol create /mnt/btrfs-root/subvolname/
then
# touch /mnt/btrfs-root/subvolname/touch-file
succeeds; but
# mount -o subvolid=5,rw /dev/sda1 /mnt/btrfs-root
# btrfs subvol create /mnt/btrfs-root/subvolname/
# mount -o subvol=subvolname,ro /dev/sda1 /mnt/btrfs-subvol
then
# touch /mnt/btrfs-root/subvolname/touch-file2
fails.
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
prev parent reply other threads:[~2014-07-08 4:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 9:30 [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes with different ro/rw options" Qu Wenruo
2014-07-01 15:32 ` David Sterba
2014-07-01 16:36 ` Chris Mason
2014-07-02 7:59 ` Harald Hoyer
2014-07-02 8:28 ` Duncan
2014-07-02 8:58 ` Qu Wenruo
2014-07-03 1:26 ` Chris Mason
2014-07-02 17:48 ` Goffredo Baroncelli
2014-07-03 0:28 ` Qu Wenruo
2014-07-03 8:06 ` Tobias Geerinckx-Rice
2014-07-03 8:33 ` Qu Wenruo
2014-07-03 11:26 ` Tobias Geerinckx-Rice
2014-07-03 17:37 ` Goffredo Baroncelli
2014-07-04 1:28 ` Qu Wenruo
2014-07-04 17:41 ` Goffredo Baroncelli
2014-07-07 1:46 ` Qu Wenruo
2014-07-07 17:37 ` Goffredo Baroncelli
2014-07-08 2:43 ` Duncan
2014-07-08 4:07 ` Goffredo Baroncelli [this message]
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=53BB6E7B.6080205@libero.it \
--to=kreijack@libero.it \
--cc=1i5t5.duncan@cox.net \
--cc=kreijack@inwind.it \
--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.