From: Arnd Bergmann Subject: Re: [RFC 0/7] [RFC] cramfs: fake write support Date: Mon, 2 Jun 2008 09:51:26 +0200 Message-ID: <200806020951.26868.arnd@arndb.de> References: <200806020325.m523Pqsq025740@agora.fsl.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jamie Lokier , Phillip Lougher , David Newall , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hch@lst.de To: Erez Zadok Return-path: In-Reply-To: <200806020325.m523Pqsq025740@agora.fsl.cs.sunysb.edu> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Monday 02 June 2008, Erez Zadok wrote: > Correction: Unionfs doesn't make additional copies in the page cache. Ok, I must have misunderstood something there. Sorry about that. > Arnd, I favor a more generic approach, one that will work with the va= st > majority of file systems that people use w/ unioning, preferably all = of > them. =A0Supporting copy-on-write in cramfs will only help a small su= bset of > users. =A0Yes, it might be simple, but I fear it won't be useful enou= gh to > convince existing users of unioning to switch over. =A0And I don't th= ink we > should add CoW support in every file system -- the complexity will be= much > more than using unionfs or some other VFS-based solution. My idea was to have it in cramfs, squashfs and iso9660 at most, I agree that doing it in even a single writable file system would add far too much complexity. I did not mean to start a fundamental discussion about how to do it the right way, just noticed that there are half a dozen implementations that have been around for years without getting close t= o inclusion in the mainline kernel, while a much simpler approach gives you sane semantics for a subset of users. > I can see some advantages (re: cache coherency) by hacking CoW suppor= t > directly into a f/s. =A0If you want to use a filesystem-specific solu= tion, > then I suggest you don't modify a file system used as a source in a u= nion, > but one used as a destination. =A0You'll have better overage that way= =2E =A0The > vast majority of times, unionfs users will either write to tmpfs or e= xt2; > but the source readonly f/s can be a lot of different ones (most popu= lar are > ext*, nfs*, isofs, and cramfs/squashfs). Yes, that absolutely makes sense. I don't care much about a persistant storage for the overlay, so tmpfs (if not ramfs) should be the only pla= ce to do it in. It does introduce some of the same old problems though, because you could still write to a bind mounted copy of the underlying file system (unlike cramfs, which is guaranteed to be read-only), which forces you to either to a full copy-up, or can result in inconsistent file contents. Also, stacking multiple union-tmpfs copies on top of eac= h other would be hard to do without the potential to overflow the kernel stack. I'll probably try implementing a '-o union' option tmpfs anyway, just to see how hard it is and what the problems are. > I find it somewhat ironic to hear the argument that "union mounts isn= 't > stable yet, so lets come up with a new solution inside cramfs." =A0Wh= y should > your solution become stable much faster than union mounts (which also= had > patches floating around for a long time already). Because the patches are not trying to solve any of the hard problems at= all: Persistent storage of overlays, readdir traversal through more than two layers, stable inode numbers, opening a file through two different over= lays, copyup, and so on. I'm sure you know more about these problems that I d= o, but as long as I don't have to care about them, I don't see a problem with my patches (other than the bugs I already described). > If you have cycles to spare, why not help Bharata and Jan? I spent a lot of time on discussing the initial implementation with Jan years ago, and will keep reviewing their patches, but I have neither th= e time nor the brains to really contribute much to them. As you mentioned in your reply to Jan E., it's on an entirely different scale than doing a small hack to cramfs or tmpfs. Arnd <><