Re: [PATCH 0/5] hybrid union filesystem prototype

[Neil Brown]

On Tue, 31 Aug 2010 13:00:45 +0200
Miklos Szeredi <miklos@xxxxxxxxxx> wrote:

> On Tue, 31 Aug 2010, Neil Brown wrote:
> > So: is this a problem?  It may seem a bit confusing to someone who doesn't
> > understand what is happening, but we define that as not being a problem (to
> > avoid confusion: don't change U or L).
> > The important questions are:  Can it cause corruption, and can it cause a
> > deadlock?
> 
> No, I don't think this design will do that.  So it might be enough
> just to document that online modification of upper or lower
> filesystems results in undefined behavior.
> 
> But to prevent accidental damage, it's prudent (at least by default)
> to enforce the no-modification policy.
> 
> Why do you think this feature of allowing modification is important?
> Lets take some typical use cases:
> 
>  - live cd: lower layer is hard r/o, upper layer makes no sense to
>    modify online
> 
>  - thin client: lower layer is static except upgrades, which need
>    special tools to support and is done offline, upper layer makes no
>    sense to modify online
> 
> Do you have some cases in mind where it makes at least a little sense
> to allow online modification of the underlying filesystems?

No, I don't have a particular use case in mind that would take advantage of
the layers being directly modifiable.  But I know that sys-admins can be very
ingenious and may well come up with something clever.

My point is more that I don't think that is it *possible* to prevent changes
to the underlying filesystem (NFS being the prime example) so if there are
easy steps we can take to make the behaviour of overlayfs more predictable in
those cases, we should.

Further I think that insisting that the underlying filesystems remain
unchangeable is overly restrictive.  If I were not allowed to perform an
overlay mount on a read/write lower filesystem, that would make it
significantly harder to explore the possibilities of overlayfs and experiment
with it.

I certainly don't think we should put a lot of work or a lot of code into
making it work "perfectly" in any sense at all.  But if there are *easy*
things to do that allow us to avoid some weird behaviours, then I think it is
worth that effort to do it.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/