>>>> In a tree-structured filesystem, checksums on everything would
>>>> only cost you space similar to the number of pointers you have.
>>>> Whenever a non-leaf node points to a child, it can hold a checksum
>>>> for that child as well. This gives a very reliable way to spot
>>>> filesystem errors, including corrupt data blocks.
...
>> To have a child is to have a checksum+pointer pair.
...
> I agree that your suggestion will work and that doubling the size
> of the metadata isn't an enormous cost, especially if you'd already
> compressed it using extents. On the other hand, sometimes I just
> feel like trusting the hardware a little. Both atomic-commit and
> journalling strategies take care of normal failure modes, and the
> disk hardware is supposed to flag other failures by ecc'ing each
> sector on disk.
Maybe you should discuss power-loss behavior with Theodore T'so.
For whatever reason, it seems that many drives and/or controllers
like to scribble on random unrelated sectors as power is lost.
For the atomic-commit case, an additional defense against this
sort of problem might be to keep a few extra trees on disk,
using a generation counter to pick the latest one. This does
bring us back to scanning the whole filesystem at boot though,
in order to disregard snapshots that have been damaged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/