Re: Block-level CRC checks

* Greg Stark <gsstark(at)mit(dot)edu> [091201 20:14]:

> I'm not sure we're on the same page. As I understand it there are
> three proposals on the table now:
>
> 1) set aside a section of the page to contain only non-checksummed
> hint bits. That section has to be relocatable so the crc check would
> have to read the start and end address of it from the page header.
>
> 2) store the hint bits in the line pointers and skip checking the line
> pointers. In that case the crc check would skip any bytes between the
> start of the line pointer array and pd_lower (or pd_upper? no point in
> crc checking unused bytes is there?)
>
> 3) store the hint bits in the line pointers and apply a mask which
> masks out the 4 hint bits in each 32-bit word in the region between
> the start of the line pointers and pd_lower (or pd_upper again)

I'm not intimately familiar with the innards of the pages, but I had
*thought* that the original suggestion of moving the hint bits was
purely to make sure that they are in the same filesystem block/disk
sector as the CRC. That may not be possible, but *if* that's the case,
you avoid the torn-page problem, with only 1 minimal assumption:
- the FS-block/disk-sector will write whole "blocks" at a time, or
likely be corrupt anyways

With my understanding of disks and platters, I'ld assume that if you got
a partial sector written, and something prevented it from being
completely written, I'ld guess the part missing would be smeared with
corruption.... And that would seem to hold with flash/SSD's too...

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.