Re: [RFC] Union mounts/writable overlays design

[kevin granade <kevin.granade@gmail.com>]

On Thu, Oct 1, 2009 at 12:55 PM, Jan Blunck <jblunck@suse.de> wrote:
> Am 01.10.2009 um 19:15 schrieb Valerie Aurora <vaurora@redhat.com>:
>
>> On Thu, Oct 01, 2009 at 10:38:27AM -0500, kevin granade wrote:


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

Yes, that sort of thing is what I meant by "additional complexities in
packaging", and I understand that they are in no way trivial, but I
was mostly interested in whether that kind of behavior would be
supported at the kernel level at all.

For example a simpler use, once again with the HD-over-CD distro, is
one could build in an option to "flatten" the entire contents of the
overlay onto a new CD, at which point the CD itself contains the
logical contents of the overlay at that point in time.  The user could
then wipe the HD (or ramdrive in some scenarios) and continue with all
their customizations in place, but no space being used on the RW
filesystem.

Puppy Linux did this in one installation mode by using Unionfs to
progressively "flatten" the user's additions onto successive tracks on
the DVD being used as the RO device.  When the disk ran out of room
the logical "top layer" could be copied to a new disk and the process
restarted.  Obviously this system won't support the iterative addition
of filesystem changes, but it could support more occasional
"flattening" of the overlay onto a new RO media.

Another scenario would be a liveCD that allows the user to make
(potentially extensive) customizations on a ramdrive, then burn a new
liveCD with all the user's customizations included on the disc.

-Kevin Granade