Re: Volume management on Linux with the ext2fs.

Stefan Monnier (monnier+/news/lists/linux/kernel@TEQUILA.SYSTEMSZ.CS.YALE.EDU)
23 Apr 1997 14:06:35 -0400

"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> The really hard case happens when you want to remove a disk from the
> *middle* of a logical volume. This is where things get really painful.

Then a user-level tool for RAID-0 allowing to reorder the disks could be handy
(so the e2resize doesn't need to deal with the hole-in-the-middle case). The
problem is to make it work while the RAID-0 device is in use, which might
require help from the RAID-0 driver itself (hence kernel modifications and
potentially heavy ones). But I'd be happy even if I had to umount the device
and do the reorder "off-line" (in which case, it is easy to do).

> a laptop computer, since atime updates would rarely get flushed to disk.

And it gives lots more opportunities to merge them.

> My opinion is that for simple things like adding hashed or B-tree
> directories, or using an extent-based block encoding scheme, we're
> better off simply enahncing the ext2 filesystem. Obviously, the really

Agreed. Actually it recently occured to me that the CacheFS that I'd like Linux
to support could be (to some point) implemented as an extension of e2fs:
create a new type of link (let's call it a copylink). When it is accessed, it
gets replaced by what it points to (and if it was a directory, the directory is
not copied recursively but filled up with copylinks, of course). The thing
could later be improved so as to support copying the inode of a remote file
without the file itself, or even allow to have only some blocks of a remote
file be copied locally. Also some way to "flush the cache" would be needed
(or at least some way to rollback copies of files into copylinks so as to
recover disk space when needed or so as to update remote files that have