Mark Lord wrote:
...
Yeah, that's my suspicion too.. they must have just simply moved
the metadata to near the end instead of sector-8.
...
They write their RAID metadata near-ish to the end of the drive.
On my 320GB drives, it ended up at about -199853 sectors from
the end of the drive. I have no idea what logic leads to them
choosing such a peculiar location for it.
..
Correction: Metadata begins at sector -191192 on my drive.
...
Okay, I figured it out.
The final sector on the drive is at 625142448,
which in hex is sector 0x2542eab0.
The metadata on this drive is at sector 624951296,
which in hex is sector 0x25400000.
Note that this corresponds to a nice round giga-byte value.
So their RAID BIOS is just truncating the drive capacity down
to an even gigabyte, and then putting the metadata right after that.
I don't know what they might do with a drive whose capacity
is exactly some gigabyte value, though --> probably they just
subtract a gigabyte from that, to make room for the metadata.
So.. I do want to make this board usable under Linux.
To do so, requires that we perhaps do a similar capacity truncation
in sata_mv, but only if we see a metadata block at the expected location
(because a "Legacy" mode drive will use the *real* capacity,
placing the metadata in the 9th sector instead.
Jeff / Tejun / Alan:
What do you think we (I) should do here?
0. Initially, we need to further beef-up the recently added boot-time warning
about data-loss. Again, the BIOS will have *already* written metadata to
the drive before we ever get to warn about it. We cannot prevent it,
but we should at least warn the user about this absurdity.
It would also be useful to print the max "usable" capacity as part
of this warning (based on the calculation below).
Now we have a choice as to what else to do:
1. Just clip the drive capacity similar to how the BIOS does it.
clipped_sectors = ((physical_sectors - 1) & ~0x0000000fffff);
OR:
2. Check for the Highpoint BIOS signature at the metadata sector first,
and only clip capacity if we see their signature there.
OR:
3. Don't clip, but printk() WARNINGs whenever a write is performed
to data beyond the theoretical clipped capacity.
OR:
4. Something better (?).
?????????????????????
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
