Re: [RFC] Union mounts/writable overlays design

[kevin granade]

My apologies to anyone who has received this twice now, re-sending
after gmail added a html rider to the previous email, which was
rejected by lkml.  (A pox on "rich text" emails!)


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?


>    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.
)

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.


>    Thank you for reading!


Thank you for writing!!!

-Kevin Granade
--
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/