Messages in this thread | | | Date | Thu, 26 Feb 1998 23:51:45 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: VFS 64-bit clean |
| |
Hi,
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
| |