>> I don't suppose using a "magic number" head and tail on the
>> superblock is a viable option here? Say 4 bytes at the head
>> and tail of the superblock that would allow for a search for
>> a valid superblock.
> There is a magic number (only one) on the superblock already,
> and that is used by e2fsck to search for the primary superblock.
> It's not used by e2fsck to automatically search from the backup
> superblock under all cases, but that's something that I've been
> thinking of adding.
> It's already the case that if the block group descriptors are
> compromised, e2fsck will automatically go to backup superblocks,
> since it can use the information in the primary superblock to
> find the backup superblocks and block group descriptors.
> What's currently missing today is the code which searches for
> the backup superblock if the primary superblock isn't there to
> give a hint.
One reasonably obvious strategy would be along the lines of the
following pseudocode:
1. Determine integrity of primary superblock. If OK, go to
step 9.
2. Set BLKSZ to 1k.
3. Determine if location of second superblock on filesystem
with blocksize BLKSZ actually contains a superblock. If
so, go to step 8.
4. Set BLKSZ to 2 * BLKSZ.
5. If BLKSZ is not greater than maximum valid blocksize, go
to step 3.
6. No valid second superblock found, so report error and exit.
7. Determine integrity of current superblock. If OK, go to
step 9.
8. Determine location of next superblock for this filesystem
blocksize. If there is one, go to step 7, else go to step
6.
9. Found valid superblock, so use it and exit.
One other point: Presumably if it needs to resort to a superblock
other than the primary one, e2fsck will copy the valid superblock
over the ones that were compromised?
Best wishes from Riley.
PS: The kernel versions page is now back online at the URL below, and
includes separate sublists both for each kernel series, and for
each year of development.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/