Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755922AbZJARQV (ORCPT ); Thu, 1 Oct 2009 13:16:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755866AbZJARQU (ORCPT ); Thu, 1 Oct 2009 13:16:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754657AbZJARQU (ORCPT ); Thu, 1 Oct 2009 13:16:20 -0400 Date: Thu, 1 Oct 2009 13:15:47 -0400 From: Valerie Aurora To: kevin granade Cc: Jan Blunck , Alexander Viro , Christoph Hellwig , Andy Whitcroft , Scott James Remnant , Sandu Popa Marius , Jan Rekorajski , "J. R. Okajima" , Arnd Bergmann , Vladimir Dronnikov , Felix Fietkau , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] Union mounts/writable overlays design Message-ID: <20091001171547.GE29152@shell> References: <20091001145547.GA29152@shell> <7004b08e0910010838i6d0a5f5xeed699be686f6906@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7004b08e0910010838i6d0a5f5xeed699be686f6906@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3543 Lines: 78 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. > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/