Date: Mon, 1 May 2000 21:29:42 +0200 (MEST)
From: Lennert Buytenhek <[EMAIL PROTECTED]>
Eeeeh..... not quite.
Because we reserve the first 1024 bytes of an ext2 fs for putting the boot
loader, we put the superblock at offset 1024. For 1k blocks, this means
the superblock ends up in block #1. For 2k/4k block sizes, this means the
superblock ends up in block #0 (albeit at offset 1024). So for 1k block
fs'es, s_first_data_block is 1. For 2k/4k blocks fs'es, s_first_data_block
is 0. So this field is actually being used.
Yup, that's right. In order to make this work, we'd need to make a
certain number of blocks as "in use" so that the kernel doesn't allocate
into them, and then somehow signal to e2fsck to not to release those
blocks when it is doing the check.
The answer to that is pretty simple --- you create a compatible
filesystem feature, and indicate the number of "extra" saved blocks in
the superblock. Old e2fsck's who don't know about the compatible
filesystem features will refuse to touch the filesystem, so they won't
clear the extra bits in the block bitmap. However, since it's a
compatible filesystem feature, the kernel will happily mount such a
filesystem --- since it trusts the accuracy of the block allocation
bitmaps, it won't try to allocate any of the reserved blocks.
So this can be done using a pure e2fsprogs enhancement..... maybe I'll
just code it up, and see what happens. :-)
- Ted
P.S. The e2fsprogs 1.19 will have support for off-line resizing, even
without this feature. It just simply moves the inode table if necessary
(with very paranoid, very carefully written code). (Yes, that's right,
the GPL timeout on resize2fs finally timed out.) If you want an early
peek at it, the 1.19 pre-release snapshot at e2fsprogs.sourceforge.net
already has it. I just need to get a couple of final bug
fixes/enhancements before I release 1.19 for real.
(I'm currently debapting whether or not to code this above idea before
or after the 1.19 release. :-)
