Re: [RFC] Union mounts/writable overlays design

[Jan Blunck]

Am 01.10.2009 um 19:15 schrieb Valerie Aurora <vaurora@xxxxxxxxxx>:

> On Thu, Oct 01, 2009 at 10:38:27AM -0500, kevin granade wrote:
> > Wow, amazingly thorough writeup, was a very interesting read and  
> > I'm looking
> > forward to trying this out.
> >
> > Examples
> > > ========
> > >
> > > What happens when I...
> > >
> > > - creat() /newfile -> creates on top layer
> > > - unlink() /oldfile -> creates a whiteout on top layer
> > > - Edit /existingfile -> copies up to top layer at open(O_WR) time
> > > - truncate /existingfile -> copies up to top layer + N bytes if  
> > > specified
> > > - touch()/chmod()/chown()/etc. -> copies up to top layer
> > > - mkdir() /newdir -> creates on top layer
> > > - rmdir() /olddir -> creates a whiteout on top layer
> > > - mkdir() /olddir after above -> creates on top layer w/ opaque flag
> > > - readdir() /shareddir -> copies up entries from bottom layer as  
> > > fallthrus
> > > - link() /oldfile /newlink -> copies up /oldfile, creates /newlink  
> > > on top
> > > layer
> > > - symlink() /oldfile /symlink -> nothing special
> > > - rename() /oldfile /newfile -> copies up /oldfile to /newfile on  
> > > top layer
> >
> > Minor quibble here, rename should also whiteout /oldfile, of course  
> > you have
> > it explained correctly in the detailed description of rename() below.
> > Or am I misunderstanding and the above is what it does now and the  
> > detailed
> > description is what it will do once implemented properly?
>
> Hi Kevin,
>
> You are correct, it whiteouts the original name.  Thanks for pointing
> that out!
>
> > > Non-features
> > > ------------
> > >
> > > Features we do not currently plan to support as part of writable
> > > overlays:
> > >
> > > Online upgrade: E.g., installing software on a file system NFS
> > > exported to clients while the clients are still up and running.
> > > Allowing the read-only bottom layer to change while the writable
> > > overlay file system is mounted invalidates our locking strategy.
> >
> > So as long as the RO filesystem is NOT mounted as part of an  
> > overlay, you
> > could modify it and then re-construct the previous overlay and  
> > things will
> > work as expected?
> > For example could one create a hard drive over CD overlay, then  
> > periodically
> > (requiring a reboot probably) replace the underlying CD with a new  
> > version
> > and automagically have new versions of software available?   
> > ( obviously
> > there are additional complexities in packaging to make this work,  
> > but having
> > support in the kernel is the first step. )
>
> This could theoretically work, but the main problem is resolving
> differences between files (always the big problem in upgrade).  Say
> you have /etc/passwd, you add a new user and write to it on the top
> layer, and then the next upgrade adds a new user to the read-only
> version.  You're not going to see the new user.

No. Scripts that come with updated packages still need to run on the  
union. Otherwise this is just asking for problems. Probably you could  
come up with a clever merger if the update and the base image is still  
available.

> > One last thing, I don't see this in either the "features" or the
> > "non-features".  Will there be a way to "revert" a file to the RO  
> > version
> > once it has been copied up, either by just removing the overlay  
> > entry or by
> > somehow forcing the open of the underlying file when it has an  
> > overlay?  Now
> > that I think of it, one could just mount the underlying filesystem  
> > elsewhere
> > and copy the file, but I'd still be interested to know if there is  
> > any
> > desire to provide the more "direct" operation.
>
> I think that people are calling this "punch-through."  I don't see a
> problem with it, other than slightly more kernel support.
>
> -VAL
--
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/