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