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