Messages in this thread | | | From | Stefan Monnier <monnier+/news/lists/linux/> | Subject | Re: Volume management on Linux with the ext2fs. | Date | 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 changed)
Stefan
| |