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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
