> In that case, please at least leave ext2 alone - copy all that code over
> to a ext3 development tree or something or other and then start your
> modifications (64-bit, larger blocksizes, whatever you or others feel is
> necessary).
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.
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
- update the superblock info to reflect the new disk size and
layout
And since the first n bits are used to point to the volume,
we need to insert a 0-sized volume in place of the removed
volume, so the other block numbers will remain consistent.
Now we can expand/shrink filesystems without having to
renumber every block number, and the only remaining problem
is to remove the first volume... But I'm sure somebody comes
up with a solution for this.
> 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.
Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
| ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu