[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101006173141.GB18479@shell>
Date: Wed, 6 Oct 2010 13:31:41 -0400
From: Valerie Aurora <vaurora@...hat.com>
To: Andreas Gruenbacher <agruen@...e.de>,
Michal Suchanek <hramrach@...trum.cz>,
Andy Whitcroft <apw@...onical.com>,
Scott James Remnant <scott@...onical.com>,
Vladimir Dronnikov <dronnikov@...il.com>,
Felix Fietkau <nbd@...nwrt.org>
Cc: Miklos Szeredi <miklos@...redi.hu>, linuxram@...ibm.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
neilb@...e.de, viro@...iv.linux.org.uk
Subject: Re: [PATCH 6/7 v3] overlay: hybrid overlay filesystem prototype
On Fri, Oct 01, 2010 at 11:34:57AM +0200, Andreas Gruenbacher wrote:
> On Thursday 30 September 2010 23:51:15 Valerie Aurora wrote:
> >
> > Hm, this was a pretty basic assumption for me - that you'd want to
> > construct a topmost image offline that would be "merged" with the
> > lower layers. So, for example:
> >
> > Topmost layer contains:
> >
> > /etc/hostname
> >
> > Lower layers contain everything else in /etc/. So /etc/ would exist
> > on the topmost layer at the time of union mount, but we would want it
> > to be transparent. But if we created a new dir *during* the union
> > mount, it would be opaque.
> >
> > What was your model?
>
> The prevalent use case probably is to start out with an empty topmost layer on
> top of an existing file system. When things are modified, changes obviously
> go into the topmost layer. Additional layers can later be stacked on top of
> that, turning the previous topmost layer into a read-only lower layer.
>
> Overlaying preexisting file systems doesn't seem that important; users
> commonly should be able to start out with an empty topmost layer instead. To
Okay, that surprises me. Let me check my assumptions. I cc'd several
people who seem to be actively using unionfs or aufs in ways that we
want union mounts to replace. Do you start out with an empty topmost
file system in most cases? Or do you prepopulate with some files in
dirs you want to be transparent?
> also cover the less common cases, there should be a way to convert directories
> in a union from opaque to transparent and back though, just like there should
> be a way to get rid of a whiteout.
Conversion is a requirement, yes.
-VAL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists