* Greg Stark <gsst...@mit.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,
ai...@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
