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.128 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site