I've started a project to do something along these lines already. It's called the Enhanced File System project, see http://www.virtual.net.au/~rjc/enh/ for more information. You may wish to join with us to work on such things. You'll note that I have CC'ed this message to the Enhanced File system mailing list.
> The idea is that we can abuse the block_number all over the file
>system and allow the block_number to exceed the number of blocks in a
>single device. We would use the block_number to identify which device
>holds the information at hand.
> So, when a user adds a new disk to an existing file system, the ext2fs
>code will get the number of available blocks on this extra disk and the
>number of block groups, and add this information to the number of
>blocks/block groups he knows about.
> We can even implement this as an optional feature, for example,
>instead of using the ``sb->u.ext2_sb.s_groups_count'' variable directly,
>we should use a macro, lets say EXT2_GROUP_COUNT(sb) which would be
>defined as ``sb->u.ext2_sb.s_groups'' for the regular ext2fs case and as
>some different thing for the case where we have volume management turned
> Of course, we need to take care of recording all of this
>information on the superblocks, enhacing the existing ext2 utilities and
> Comments on this? Is this proposal completely foolish?
It should work. However I think it would probably be better to write a new FS and you can then add other features at the same time. For example Ext2 has no support for logging and adding such support to it would be a significant re-write. Also there's other possibilities to consider such as using an extent-based or tree based file system which can offer significant benefits over the older block-based file system designs. While we're at it using B+ trees for directories as HPFS and NTFS do would be a great win for news servers and other systems with thousands of tiny files.
Another option to consider is implementing the DCE LFS which supports dynamically expandable partitions.