On Wed, 25 Feb 1998 14:23:31 +0100 (MET), Rik van Riel
<H.H.vanRiel@fys.ruu.nl> said:
> While we're at it, we really should support DvD-FS like
> filesystem-over-multiple-media support.
> We can simply do this by using the first 8 (or 16) of
> our 64 bits to indicate what volume the data block is
> on. Then we can use the next 32-40 bits to indicate
> the block group and the final bits to indicate what
> block to take inside the group.
Already done, thanks to Miguel. I hope we can integrate this stuff
before 2.2.
> The major advantage of doing this, is that we now
> have an easy way to expand/shrink a filesystem,
> even when it's up and running. All we need to do
> to shrink an fs is to have a kernel daemon:
> mark the to-be-removed volume as such, so blocks won't
> be allocated under us when we're migrating data
> walk all inodes on the fs
> relocate all inodes and blocks off of the to-be-removed volume
Relocating inodes is hard, since there is no cheap way to determine
which dirents refer to a given inode. Relocating blocks is not much
easier, since there's no lookup from block to inode either, but at least
there's only one owner inode for every block.
>> Like you said, filesystems must be rock-solid. Any change to ext2
>> (outside of bugfixes) would introduce bugs that would need to be worked
>> out.
> I'd like to second this. There's no better testing ground for a new fs
> than an OS which is already running without problems. Creating new
> ext2 bugs will definately hinder development of new fs features.
But we can easily maintain a separate, parallel "ext2dev" tree with the
latest features, and migrate those features into the solid ext2 tree as
they prove themselves.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu