union-mount: Support for mounting union mount file systems
in [Kernel]
|
Prev: [GIT PULL] Important ocfs2 fixes for 2.6.35
Next: Reminder: Linux Plumber's Conference Call for Papers
From: Valerie Aurora on 16 Jul 2010 17:10 On Tue, Jul 13, 2010 at 12:47:02PM +0800, Ian Kent wrote: > On Tue, Jun 15, 2010 at 11:39:51AM -0700, Valerie Aurora wrote: > > + > > +static int > > +check_mnt_union(struct path *mntpnt, struct vfsmount *topmost_mnt, int mnt_flags) > > +{ > > + struct vfsmount *lower_mnt = mntpnt->mnt; > > + > > + if (!(mnt_flags & MNT_UNION)) > > + return 0; > > + > > +#ifndef CONFIG_UNION_MOUNT > > + return -EINVAL; > > +#endif > > + if (!(lower_mnt->mnt_sb->s_flags & MS_RDONLY)) > > + return -EBUSY; > > + > > + if (!list_empty(&lower_mnt->mnt_mounts)) > > + return -EBUSY; > > + > > + if (!IS_ROOT(mntpnt->dentry)) > > + return -EINVAL; > > + > > + if (mnt_flags & MNT_READONLY) > > + return -EROFS; > > + > > + if (!(topmost_mnt->mnt_sb->s_flags & MS_WHITEOUT)) > > + return -EINVAL; > > + > > Is there a need to check fallthru, umm ... that probably doesn't > apply for the ROOT(), right? Actually, that's on my todo list - right now I'm assuming MS_WHITEOUT implies fallthru support as well. But it doesn't. We're a little short on MS_* flags. I'm thinking of just checking ->whiteout and ->fallthru for non-NULL on the root dir and getting rid of MS_WHITEOUT entirely. Thoughts? -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Miklos Szeredi on 4 Aug 2010 11:00 On Tue, 15 Jun 2010, Valerie Aurora wrote: > Create and tear down union mount structures on mount. Check > requirements for union mounts. This version clones the read-only > mounts and puts them in an array hanging off the superblock of the > topmost layer. If I do mount -r fs1 /mnt mount -r fs2 /mnt mount -ounion fs3 /mnt then only fs2 and fs3 will be unioned. Or how are multiple read-only layers supposed to work? Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valerie Aurora on 4 Aug 2010 16:00 On Wed, Aug 04, 2010 at 04:55:39PM +0200, Miklos Szeredi wrote: > On Tue, 15 Jun 2010, Valerie Aurora wrote: > > Create and tear down union mount structures on mount. Check > > requirements for union mounts. This version clones the read-only > > mounts and puts them in an array hanging off the superblock of the > > topmost layer. > > If I do > > mount -r fs1 /mnt > mount -r fs2 /mnt > mount -ounion fs3 /mnt > > then only fs2 and fs3 will be unioned. > > Or how are multiple read-only layers supposed to work? You have it right, this is a bug in lookup in the last version I sent out. I had commented out the part of my test suite that actually tested three layer mounts so I didn't notice when I broke it. :/ I'll post a new version with the fix today. -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valerie Aurora on 4 Aug 2010 18:10 On Tue, Jul 20, 2010 at 11:12:17AM +0800, Ian Kent wrote: > On Fri, 2010-07-16 at 17:02 -0400, Valerie Aurora wrote: > > On Tue, Jul 13, 2010 at 12:47:02PM +0800, Ian Kent wrote: > > > On Tue, Jun 15, 2010 at 11:39:51AM -0700, Valerie Aurora wrote: > > > > + > > > > +static int > > > > +check_mnt_union(struct path *mntpnt, struct vfsmount *topmost_mnt, int mnt_flags) > > > > +{ > > > > + struct vfsmount *lower_mnt = mntpnt->mnt; > > > > + > > > > + if (!(mnt_flags & MNT_UNION)) > > > > + return 0; > > > > + > > > > +#ifndef CONFIG_UNION_MOUNT > > > > + return -EINVAL; > > > > +#endif > > > > + if (!(lower_mnt->mnt_sb->s_flags & MS_RDONLY)) > > > > + return -EBUSY; > > > > + > > > > + if (!list_empty(&lower_mnt->mnt_mounts)) > > > > + return -EBUSY; > > > > + > > > > + if (!IS_ROOT(mntpnt->dentry)) > > > > + return -EINVAL; > > > > + > > > > + if (mnt_flags & MNT_READONLY) > > > > + return -EROFS; > > > > + > > > > + if (!(topmost_mnt->mnt_sb->s_flags & MS_WHITEOUT)) > > > > + return -EINVAL; > > > > + > > > > > > Is there a need to check fallthru, umm ... that probably doesn't > > > apply for the ROOT(), right? > > > > Actually, that's on my todo list - right now I'm assuming MS_WHITEOUT > > implies fallthru support as well. But it doesn't. > > > > We're a little short on MS_* flags. I'm thinking of just checking > > ->whiteout and ->fallthru for non-NULL on the root dir and getting rid > > of MS_WHITEOUT entirely. Thoughts? > > Checking for the methods is a good idea I think, since they are assumed > to be present by the code, at least in some places. > > Although it shouldn't happen, it is possible for a file system to create > the root dentry with these methods defined but other dentrys without > them defined, so a file system implementation error could cause some > unpleasant crashes. Maybe requiring the flags to indicate support would > help avoid unpleasant implementation problems like this, not sure > really. > > Also not sure if a method existence check should always be made prior to > use, regardless. I went for MS_WHITEOUT and MS_FALLTHRU, and added the checks for the ops being non-null. -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valerie Aurora on 5 Aug 2010 00:30
On Wed, Aug 04, 2010 at 03:50:08PM -0400, Valerie Aurora wrote: > On Wed, Aug 04, 2010 at 04:55:39PM +0200, Miklos Szeredi wrote: > > On Tue, 15 Jun 2010, Valerie Aurora wrote: > > > Create and tear down union mount structures on mount. Check > > > requirements for union mounts. This version clones the read-only > > > mounts and puts them in an array hanging off the superblock of the > > > topmost layer. > > > > If I do > > > > mount -r fs1 /mnt > > mount -r fs2 /mnt > > mount -ounion fs3 /mnt > > > > then only fs2 and fs3 will be unioned. > > > > Or how are multiple read-only layers supposed to work? > > You have it right, this is a bug in lookup in the last version I sent > out. I had commented out the part of my test suite that actually > tested three layer mounts so I didn't notice when I broke it. :/ I'll > post a new version with the fix today. Try branch "for_miklos" in: git://git.kernel.org/pub/scm/linux/kernel/git/val/linux-2.6.git It's against 2.6.34, I'm rebasing against 2.6.35 tomorrow. -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |