lkml.org 
[lkml]   [2007]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 01/24] Unionfs: Documentation
    > In message <20070109122644.GB1260@atrey.karlin.mff.cuni.cz>, Jan Kara writes:
    > > > In message <20070108111852.ee156a90.akpm@osdl.org>, Andrew Morton writes:
    > > > > On Sun, 7 Jan 2007 23:12:53 -0500
    > > > > "Josef 'Jeff' Sipek" <jsipek@cs.sunysb.edu> wrote:
    > > > >
    > > > > > +Modifying a Unionfs branch directly, while the union is mounted, is
    > > > > > +currently unsupported.
    > > > >
    > > > > Does this mean that if I have /a/b/ and /c/d/ unionised under /mnt/union, I
    > > > > am not allowed to alter anything under /a/b/ and /c/d/? That I may only
    > > > > alter stuff under /mnt/union?
    > > > >
    > > > > If so, that sounds like a significant limitation.
    > > <snip>
    > > > Now, we've discussed a number of possible solutions. Thanks to suggestions
    > > > we got at OLS, we discussed a way to hide the lower namespace, or make it
    > > > readonly, using existing kernel facilities. But my understanding is that
    > > > even it'd work, it'd only address new processes: if an existing process has
    > > > an open fd in a lower branch before we "lock up" the lower branch's name
    > > > space, that process may still be able to make lower-level changes.
    > > > Detecting such processes may not be easy. What to do with them, once
    > > > detected, is also unclear. We welcome suggestions.
    > > Yes, making fs readonly at VFS level would not work for already opened
    > > files. But you if you create new union, you could lock down the
    > > filesystems you are unioning (via s_umount semaphore), go through lists
    > > of all open fd's on those filesystems and check whether they are open
    > > for write or not. If some fd is open for writing, you simply fail to
    > > create the union (and it's upto user to solve the problem). Otherwise
    > > you mark filesystems as RO and safely proceed with creating the union.
    > > I guess you must have come up with this solution. So what is the problem
    > > with it?
    >
    > Jan, all of it is duable: we can downgrade the f/s to readonly, grab various
    > locks, search through various lists looking for open fd's and such, then
    > decide if to allow the mount or not. And hopefully all of that can be done
    > in a non-racy manner. But it feels just rather hacky and ugly to me. If
    > this community will endorse such a solution, we'll be happy to develop it.
    > But right now my impression is that if we posted such patches today, some
    > people will have to wipe the vomit off of their monitors... :-)
    I see :). To me it just sounds as if you want to do remount-read-only
    for source filesystems, which is operation we support perfectly fine,
    and after that create union mount. But I agree you cannot do quite that
    since you need to have write access later from your union mount. So
    maybe it's not so easy as I thought.
    On the other hand, there was some effort to support read-only bind-mounts of
    read-write filesystems (there were even some patches floating around but
    I don't think they got merged) and that should be even closer to what
    you'd need...

    Honza
    --
    Jan Kara <jack@suse.cz>
    SuSE CR Labs
    -
    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/

    \
     
     \ /
      Last update: 2007-01-10 17:43    [W:3.253 / U:0.380 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site