lkml.org 
[lkml]   [1998]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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



    \
     
     \ /
      Last update: 2005-03-22 13:41    [W:0.029 / U:0.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site