Messages in this thread | | | Date | Thu, 13 Jul 2006 00:04:31 -0700 | Subject | Re: [RFC][PATCH 00/27] Mount writer count and read-only bind mounts (v4) | From | (Ram Pai) |
| |
On Wed, Jul 12, 2006 at 11:17:09AM -0700, Dave Hansen wrote: > Tries to incorporate comments from Al: > http://article.gmane.org/gmane.linux.kernel/421029 > > Al wrote: > > b) figuring out what (if anything) should be done with > > propagation when we have shared subtrees... (not trivial at all) > > Talked with Ram: Shared subtrees are about having identical views > into the filesystem. Changing the mount permissions doesn't affect > the view of the filesystem, so it should not be propagated.
I think shared subtrees propagates mount/unmount events only. This is a case where we are just changing the access permission for a mount instance. So it should not be treated as a propagation event.
Lets say we propagated the event. In that case we would end up with a awkward situation.
1) mount --make-shared /mnt 2) mount --bind /mnt /tmp 3) mount --make-slave /tmp 4) mount -o remount,rw /tmp 5) mount -o remount,ro /mnt
In step (5) all of a sudden the mount at /tmp which was readwrite will be downgraded to read-only. There must have been a reason why /tmp was mounted rw in the first place. Also there would be no way for /mnt to be made 'ro' without effecting /tmp.
Hence I feel the readwrite semantics must be decoupled from the sharedsubtree semantics,
RP
> > The things that probably need the heaviest review in here are the > i_nlink monitoring patch (including the inode state flag patches 03 > and 06) and the new MNT_SB_WRITABLE flag (patch 05). > > --- > > The following series implements read-only bind mounts. This feature > allows a read-only view into a read-write filesystem. In the process > of doing that, it also provides infrastructure for keeping track of > the number of writers to any given mount. In this version, if there > are writers on a superblock, the filesystem may not be remounted > r/o. The same goes for MS_BIND mounts, and writers on a vfsmount. > > This has a number of uses. It allows chroots to have parts of > filesystems writable. It will be useful for containers in the future > and is intended to replace patches that vserver has had out of the > tree for several years. It allows security enhancement by making > sure that parts of your filesystem read-only, when you don't want > to have entire new filesystems mounted, or when you want atime > selectively updated. > > This set makes no attempt to keep the return codes for these > r/o bind mounts the same as for a real r/o filesystem or device. > It would require significantly more code and be quite a bit more > invasive. > > Using this feature requires two steps: > > mount --bind /source /dest > mount -o remount,ro /dest > > Signed-off-by: Dave Hansen <haveblue@us.ibm.com> > - > 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/ - 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/
| |