This suggests that getting the size is wrong and using it the way you do is flawed.

The backup GPT is defined to be where the primary GPT says it is, which is not necessarily the last sector(s).

In D10302#213231, @imp wrote:

This suggests that getting the size is wrong and using it the way you do is flawed.

For the pool, yes, we really should get the partition size eventually - assuming we want to get the correct location for the last 2 labels.

The backup GPT is defined to be where the primary GPT says it is, which is not necessarily the last sector(s).

yea, but in this case it is not really even about GPT, as the old sparcs only do support vtoc and GPT support was added for T4 and up. Anyhow, as you do mention GPT, for practical purposes using the GPT backup label location is enough, as it is the last thing *after* the data, and so that will give us good size limit in any case, even if the physical device is larger, it has no data after the backup label.

In D10302#213232, @tsoome wrote:

In D10302#213231, @imp wrote:

This suggests that getting the size is wrong and using it the way you do is flawed.

For the pool, yes, we really should get the partition size eventually - assuming we want to get the correct location for the last 2 labels.

The backup GPT is defined to be where the primary GPT says it is, which is not necessarily the last sector(s).

yea, but in this case it is not really even about GPT, as the old sparcs only do support vtoc and GPT support was added for T4 and up. Anyhow, as you do mention GPT, for practical purposes using the GPT backup label location is enough, as it is the last thing *after* the data, and so that will give us good size limit in any case, even if the physical device is larger, it has no data after the backup label.

True. The reason I mention it is that our mem sticks all have backup labels that aren't at the end of media except for a vanishingly small set of USB sticks...

In D10302#213242, @imp wrote:

In D10302#213232, @tsoome wrote:

In D10302#213231, @imp wrote:

This suggests that getting the size is wrong and using it the way you do is flawed.

For the pool, yes, we really should get the partition size eventually - assuming we want to get the correct location for the last 2 labels.

The backup GPT is defined to be where the primary GPT says it is, which is not necessarily the last sector(s).

yea, but in this case it is not really even about GPT, as the old sparcs only do support vtoc and GPT support was added for T4 and up. Anyhow, as you do mention GPT, for practical purposes using the GPT backup label location is enough, as it is the last thing *after* the data, and so that will give us good size limit in any case, even if the physical device is larger, it has no data after the backup label.

True. The reason I mention it is that our mem sticks all have backup labels that aren't at the end of media except for a vanishingly small set of USB sticks...

Yes, thats exactly the case when this happens - or when you have grown the lun, but not yet adjusted the GPT with new size. Also the GPT "usable" sectors end where the backup label starts:)

This change, or one of the others related to it, breaks the operation of zfsloader on sparc64.

I only got to testing a new zfsloader last night, and ones built from the following snapshots
all fail:
r318502
r317181
r318137

I was able to 'dd' in just the zfsloader from a stable/11 build to the reinstall of r318137 that I
did last night, and that allows the machine to reboot.

The failure message is:

FreeBSD/sparc64 ZFS boot block

Boot path:   /pci@1c,600000/scsi@2/disk@0,0:a

Consoles: Open Firmware console
ERROR: Last Trap: Fast Data Access MMU Miss