Comment 9 for bug 556621

On Apr 10, 2010, at 10:45 PM, Phillip Susi wrote:

> Oh dear, so the kernel and fsck never update the backup copies? Seems
> to defeat the purpose doesn't it? I mean if they are never updated,
> why have them? Their initial content could be regenerated by mkfs -n
> couldn't it?

*If* you remember exactly all of the command-line parameters you gave to mkfs, *and* if you have exactly the same contents in /etc/mke2fs.conf, and *if* you've never resized the file system, and *if* you are using exactly the same version of mke2fs ---- then why yes, you could find these parameters by using mkfs -n. (Or if you are really brave, you could try restoring the world using mke2fs -S

> So if fsck finds the main bg descriptor corrupt and isn't sure if the
> inode table was zeroed or not, and happens to find old data that looks
> like inodes in the uninitialized table, wouldn't it be highly likely
> that such inodes would claim blocks that are either marked as free, or
> allocated by other inodes? And these inodes would not have any
> directory entries pointing to them, so wouldn't the worst case then be
> that fsck places copies of garbage in lost+found, but no actual data
> would be lost?
>
> If the worst case scenario in the unlikely event of the bg descriptors
> being corrupted is that fsck finds garbage data and puts it in
> lost+found, then I don't see a downside to enabling this option.

Ah, if only it would be so simple. The other problem is that these inodes may point at blocks used by the current '"real" inodes in the file system. This means that invoking pass 1b/1c/1d processing, which is slow, takes a long time, and requires asking the user if they would like to clone or delete the multiply-claimed blocks. For very large disks, if users don't have enough memory or who don't have enough swap enabled, e2fsck could run out of memory during the pass 1b/1c/1d passes.

So again, I really do not recommend enabling lazy_itable_init at this time.

-- Ted