"Kevin P. Neal" sez:
[much deleted]
# 
# It's a rather long document, and it gets into much detail in some places.
# 
# Neat stuff. Resizable partitions, easy mirroring of individual partitions,
# reorganizing of partitions with ease. Stability in the event of hardware
# going bad in run time. Imagine taking a system down, hooking up a drive,
# then booting multi-user mode. In multi-user mode, add partitions and 
# filesystems as you like. Rearrange as you like. Minimized down time.
# 
# "Help! My home directory partition is full!"
# 
# "Hold on a sec.....How's that?"
# 
# "Wow! Thanks!"

Yes, this is cool, I agree.

Now, one thing that none of the other filesystems deal with is how to
*shrink* a partition, should it become necessary.

I agree that it would be a cool thing to grow/shrink/move filesystems.

Someone wrote that an extensible filesystem would be difficult because
of the overhead of layout, as well as the problem of fragmentation.

I note that fsck has a '-d' option for 'debug'; perhaps we should
implement a -D option for "defragment".

I know defragmenters can take a LOT of time, but if extensible filesystems
can't avoid fragmentation easily, perhaps a FS_FRAGMENT flag should be
set in the filesystem superblock, and fsck would pick it up and attempt
to defrag the filesystem at the next reboot (really fsck -p).

But I still have my reservations about keeping lots of arcane metadata
in obscure locations.

If this could all be made to work with a maximum of transparency,
I'll probably shut up and not bitch too much (not that it matters
as my technical contributions have been minimal:-).

[It's frustrating being able to half-grasp the concepts being bandied
about and not being able to a) find time to write code and b) understand
the code to be written.]

		(stream_t *) (--*greywolf)->u_thought = 0;