Re: Proposal for variable length extents

tytso wrote:

> Sure, but the solution to that isn't to use inefficient encodings, but
> rather to add checksums.  The reason why I didn't make that part of
> the proposal is because my current thinking is we should be adding a
> CRC-16 to cover the entire inode, and a CRC-32 to cover the entire
> leaf block in an extent tree.  So I agree, but I would handle it
> outside of the extent encoding proposal.

I would suggest using a 64 bit checksum.  CRC is very expensive to calculate 
on most CPUs as the inner loop has a data dependant load from a lookup table, 
while checksums are much easier to update for partial block changes.  Given 
that we're trying to catch the most obvious corruption, a checksum is probably 
enough.  Sorry for not commenting sooner.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[email protected]>.