[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <56A500B5-DEC5-4B4E-A224-6F5F2D702D2B@suse.de>
Date: Thu, 1 Oct 2009 19:55:14 +0200
From: Jan Blunck <jblunck@...e.de>
To: Valerie Aurora <vaurora@...hat.com>
Cc: kevin granade <kevin.granade@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christoph Hellwig <hch@...radead.org>,
Andy Whitcroft <apw@...onical.com>,
Scott James Remnant <scott@...onical.com>,
Sandu Popa Marius <sandupopamarius@...il.com>,
Jan Rekorajski <baggins@...h.mimuw.edu.pl>,
"J. R. Okajima" <hooanon05@...oo.co.jp>,
Arnd Bergmann <arnd@...db.de>,
Vladimir Dronnikov <dronnikov@...il.com>,
Felix Fietkau <nbd@...nwrt.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Union mounts/writable overlays design
Am 01.10.2009 um 19:15 schrieb Valerie Aurora <vaurora@...hat.com>:
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists