[lkml]   [1998]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectOverlay writable filesystem over r/o partition [long]
    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

    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.

    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 ...


    Richard Jones Tel: +44 171 460 6141 Fax: .. 4461
    ABLE INmEDIA Ltd. 262a Fulham Rd. London SW10 9EL. "you'll write in
    PGP: telegraphic, or you won't write at all" [Céline]
    Warning: Bcc mail messages are *unconditionally* deleted from my inbox!

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