Fsck Revisited

[OGAWA Hirofumi]

Daniel Phillips <daniel.raymond.phillips at gmail.com> writes:

>> Copying shadow bitmap to bitmap blocks is not good. It requires to be
>> follow atomic-commit rules (i.e. redirect blocks to modify, and modify
>> pointers to blocks).
>>
>> Instead, we can just use balloc/bfree and log_balloc/log_bfree to fix
>> difference of bitmap. With this, those operations are already following
>> atomic-commit rules (i.e. crash proof), and no need to care about
>> current logblock detail too.
>
> Strongly agree, that is the right place to start. But what about the case
> where a large number of bits differ? For example, suppose an entire block
> of bits were zeroed (which you discover after copying your volume off of
> a failing disk). Then the most efficient strategy is to copy the whole block,
> which would require extra care to make the log consistent. But clearly
> worth it in this case.
>
> Of course, the above is just an optimization. Your suggestion is the best
> to implement at first, and at worst, it might create an unusually large
> number of log blocks, which is worth testing in itself. Note: it is possible
> to construct a case where the volume hits ENOSPC during fsck repair,
> which would be bad. So both approaches may need to be available in a
> production ready fsck.

I guess, then, you can run force_rollup(), instead of force_delta(). So,
logblocks are obsoleted, and bitmap will be flushed instead.

Thanks.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>