Messages in this thread | | | Date | Sun, 04 Jan 1998 05:28:36 +0000 | From | Steve Logue <> | Subject | Re: Overlay writable filesystem over r/o partition [long] |
| |
Richard Jones wrote:
> Dear all, > > I've been thinking about a number of ways to implement > an ``overlay'' filesystem for Linux -- a filesystem > that you could mount over ordinary r/o media like CD-ROMs > and NFS r/o partitions, which would allow you to write > and just store the diffs to the original data. Useful > for live CD-ROM-based filesystems and NFS root mounts. > I hope this hasn't been done already. If so, ignore what > I've got to say below and quietly point me in the right > direction. > > The schemes I thought up for this: > > 1. At the block-device level. > > The overlay block device handles read operations by > passing them on to the underlying block device. However, > if you write to a block, we store the block written in > our own disk partition, which looks like this: > > +-------+-------------------+-----------------------------+ > | super | index of blocks | modified blocks | > | block | | | > +-------+-------------------+-----------------------------+ > > This works quite nicely for CD-ROM overlays, but would > be no use for other filesystems, particularly NFS mounts. > [Did I say, we really need this so we can have a single > shared NFS root partition for a bunch of diskless clients]. > > 2. At the filesystem level. > > Next scheme: We overlay an EXT2 filesystem over any other > VFS filesystem. Calls which read inodes or data are passed > through to the underlying filesystem. Calls which write > an inode/file cause the inode + data blocks to be copied > into the EXT2 filesystem overlay. The EXT2 filesystem > overlay would end up looking like this: > > index # maps underlying inodes -> inodes > # in the overlay filesystem > i3511 # stores modified inode #3511 on > # underlying filesystem > i47711 # modified inode #47711 > i48212 # etc. > i48213 > > Works with NFS r/o partitions, but it's not particularly > efficient, since a single write copies a whole file. > > 3. Quick hack: modify EXT2 (and VFS?) > > Third attempt. Modify EXT2 to add a ``copy-on-write'' link. > This looks a lot like a symbolic link, but has slightly > different semantics. If the COW link points to a non-directory > entry, and the operation is a read, then the link acts like > a symbolic link that has been followed (even for ``readlink''). > If the COW link points to a directory entry and the operation > is a read, then the link changes into a directory inode, and > we populate it with new COW links pointing to files in the > subdirectory. For any sort of write operation on a COW link, > we actually copy the inode locally first and then execute the > write operation on the local copy. > > So, if ``ln -c'' creates such a link, then we could make a > copy-on-write copy of an entire filesystem just by doing: > > % ln -c /mnt/data /tmp/copy > % ls /tmp/copy > [ read on directory: /tmp/copy is populated ] > file1 file2 dir1 > % touch /tmp/copy/file1 > [ write on file: /tmp/copy/file1 is copied ] > % ll /tmp/copy/file1 > -rw-rw-r-- 1 rjones rjones 474 Jan 4 22:24 /tmp/copy/file1 > > Hmm. Seems like a nice idea, but can anyone think of any > problems with this? > > Thanks for your time ... I'm quite prepared to implement > one of these schemes, but I need some input, coz there's > no entirely obvious solution I can see ... > > Rich. > > -- > Richard Jones rjones@imcl.com Tel: +44 171 460 6141 Fax: .. 4461 > ABLE INmEDIA Ltd. 262a Fulham Rd. London SW10 9EL. "you'll write in > PGP: www.four11.com telegraphic, or you won't write at all" [Céline] > Warning: Bcc mail messages are *unconditionally* deleted from my inbox!
Would BSD Union filesystem code help?
-STEVEl
| |