Isnt it an extreme case of "badblock" ?
No, "badblock" (or rather e2fsck, which handles the assignments of
badblocks) doesn't try to actually move blocks out of the way. Rather,
it assumes that the data on those blocks are already toast, and tries to
clean up the mess afterwards.....
You are assuming you are logging for the purpose of clean recovery from
all cases. The laptop case of logging for power management is a simpler
starting point as you dont care if you have to fsck the disk (and peek
into the log whats left of it anyway).
Yes, I'm assuming that someone has a 20 gigabyte news spool that then
don't want to fsck after a system crash.
Using a simpler starting point is can be a good strategy, as long as
the framework that you put together is actually scalable to the more
general case problem.
We have the libraries for B trees in the kernel hfs module, and they
are extremely clean and thus could be readily transported to ext2.
You mean the Macintosh HFS filesystem? I'll have to take a look at
those....
I'd prefer to see volume management as a part of the RAID stuff, even
down to the idea that a disk is a sort of poor RAID0 array. This
gives us benefits we can apply to other file systems too later on
It would be interesting to set up disk partitions so they always had the
md header, so it would be easier to migrate them to using the md driver
later....
- Ted