On Sat, Apr 14, 2012 at 09:04:45AM -0400, Edward Ned Harvey wrote:
> Then, about 2 weeks later, the support rep emailed me to say they
> implemented a new feature, which could autoresize +/- some small
> percentage difference, like 1Mb difference or something like that. 

There are two elements to this:
 - the size of actual data on the disk
 - the logical block count, and the resulting LBAs of the labels
   positioned relative to the end of the disk.

The available size of the disk has always been rounded to a whole
number of metaslabs, once the front and back label space is trimmed
off. Combined with the fact that metaslab size is determined
dynamically at vdev creation time based on device size, there can
easily be some amount of unused space at the end, after the last
metaslab and before the end labels. 

It is slop in this space that allows for the small differences you
describe above, even for disks laid out in earlier zpool versions.  
A little poking with zdb and a few calculations will show you just how
much a given disk has. 

However, to make the replacement actually work, the zpool code needed
to not insist on an absoute >= number of blocks (rather to check the
more proper condition, that there was room for all the metaslabs).
There was also testing to ensure that it handled the end labels moving
inwards in absolute position, for a replacement onto slightly smaller
rather than same/larger disks. That was the change that happened at
the time.

(If you somehow had disks that fit exactly a whole number of
metaslabs, you might still have an issue, I suppose. Perhaps that's
likely if you carefully calculated LUN sizes to carve out of some
other storage, in which case you can do the same for replacements.)


Attachment: pgpg1ciooKHti.pgp
Description: PGP signature

zfs-discuss mailing list

Reply via email to