From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Waychison Subject: Re: [RFC] shared subtrees Date: Mon, 31 Jan 2005 12:19:03 -0500 Message-ID: <41FE6887.3090006@sun.com> References: <20050113221851.GI26051@parcelfarce.linux.theplanet.co.uk> <41FABD4E.6050701@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Cc: Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: Received: from brmea-mail-4.Sun.COM ([192.18.98.36]:42472 "EHLO brmea-mail-4.sun.com") by vger.kernel.org with ESMTP id S261260AbVAaRUA (ORCPT ); Mon, 31 Jan 2005 12:20:00 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0VHJxdx026127 for ; Mon, 31 Jan 2005 10:19:59 -0700 (MST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IB600B01YM4MV@mpk-mail1.sfbay.sun.com> (original mail from Michael.Waychison@Sun.COM) for linux-fsdevel@vger.kernel.org; Mon, 31 Jan 2005 09:19:59 -0800 (PST) In-reply-to: To: raven@themaw.net Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for the bad quoting below: raven@themaw.net wrote: > On Fri, 28 Jan 2005, Mike Waychison wrote: > > Al Viro wrote: > >>>> OK, here comes the first draft of proposed semantics for subtree >>>> sharing. What we want is being able to propagate events between >>>> the parts of mount trees. Below is a description of what I think >>>> might be a workable semantics; it does *NOT* describe the data >>>> structures I would consider final and there are considerable >>>> areas where we still need to figure out the right behaviour. >>>> > > Okay, I'm not convinced that shared subtrees as proposed will work well > with autofs. > > >> OK. I've read the thread but haven't digested it so you'll have to put >> up with some stupid questions. > > > The idea discussed off-line was this: > > When you install an autofs mountpoint, on say /home, a daemon is started > to service the requests. As far as the admin is concerned, an fs is > mounted in the current namespace, call it namespaceA. The daemon > actually runs in it's one private namespace: call it namespaceB. > namespaceB receives a new autofs filesystem: call it autofsB. autofsB > is in it's own p-node. namespaceA gets an autofsA on /home as well, and > autofsA is 'owned' by autofsB's p-node. > > So: > > autofsB -> autofsB > and > autofsB -> autofsA > > Effectively, namespaceA has a private instance of autofsB in its tree. > > The problem is this: > > Assume /home/mikew is accessed in namespaceA. The daemon running in > namespaceB gets the event, and mounts an nfs vfsmount on autofsB. This > event is propagated back to autofsA. > > >> Which condition (or action) in the definition implies > >> autofsB -> autofsA > autofsB -> autofsA indicates that mount events are propagated from autofsB to autofsA. Eg: if you have two mounts (A, B) in the same p-node, then A -> B and B -> A By definition, a mountpoint (A) alone in a one element p-node has the property: A -> A Which doesn't mean much, other than to show that A is in a p-node. If you have a p-node p' owned by p-node p, then all mountpoints i' in p' will have the following relationship with all mountpoints i in p: i -> i' but not the reverse (one-way relationship). > > (Problem 1: how do you block access to /home/mikew in namespaceA?) > > Next, a CLONE_NS is done in namespaceA, creating namespaceA'. the > homedir on /home/mikew is also copied. > > Now, in namespaceA', what happens when a user umount's /home/mikew? We > haven't yet determined how to handle umount event propagation, but it > appears likely that it will be *a hard thing to do*. > > >> No I haven't spent enough time on the RFC buy into this one. >> So I'll just say it looks like something is missing in this argument. > >> Perhaps the later is namespaceC? > Sure, it doesn't matter, namespaceA' is an arbitrary name. HTH, - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB/miHdQs4kOxk3/MRArCsAJ9PxyxE7crSRk4R0OMB4yppH10wpQCfeQO8 qk6kcExaN7rzJOi4KoRyXoY= =VvFb -----END PGP SIGNATURE-----