zfs discuss - Jun 2009 - Issues with slightly different sized drives in raidz pool?

Sorry if the question has been discussed before...did a pretty extensive search,
but no luck...

Preparing to build my first raidz pool. Plan to use 4 identical drives in a 3+1
configuration.

My question is -- what happens if one drive dies, and when I replace it, design
has changed slightly and the drive is (very slightly) different sized. Still a
1TB or what have you, but not identical. I''m guessing if it is slightly
larger, no problem, slightly smaller is trouble, but that isn''t always
obvious when you buy a drive. My concern is that in a year when the drive blows,
XYZ brand''s model 1000 will be replaced by XYZ model 1001 that formats
to 1MB less (or worse, I need to replace an XYZ brand 1TB with a similar 1TB ABC
brand)

Is there a best practices suggestion here? Is this a real problem? Can I force
format the drives very slightly less than full capacity before adding them to
the pool to prevent such an issue?

Thanks.
-- 
This message posted from opensolaris.org

On Mon, Jun  8 at 20:28, David Bryan wrote:
>Sorry if the question has been discussed before...did a pretty extensive
search, but no luck...
>
>Preparing to build my first raidz pool. Plan to use 4 identical drives in a
3+1 configuration.
>
>My question is -- what happens if one drive dies, and when I replace it,
design has changed slightly and the drive is (very slightly) different sized.
Still a 1TB or what have you, but not identical. I''m guessing if it is
slightly larger, no problem, slightly smaller is trouble, but that
isn''t always obvious when you buy a drive. My concern is that in a year
when the drive blows, XYZ brand''s model 1000 will be replaced by XYZ
model 1001 that formats to 1MB less (or worse, I need to replace an XYZ brand
1TB with a similar 1TB ABC brand)
>
>Is there a best practices suggestion here? Is this a real problem? Can I
force format the drives very slightly less than full capacity before adding them
to the pool to prevent such an issue?
General consensus is to only buy drives that report even IDEMA
capacities according to their formula.

The formula is documented in their LBA1-02 standard on idema.org, and
works out to:

(LBA count) = 97696368 + (1953504 * (xGB-50.0))

where you replace xGB with the number of gigabyte drive you''re looking
to buy, in your case 1000.0.

The official spec is at idema.org -> LBA standards -> approved
standards

You''ll need to go to each individual manufacturer to confirm that they
sell a SKU of the proper number of sectors, but these days you''re much
safer than you were a few years ago.

Technically it only applies to 2.5" > 80GB and 3.5" > 160GB ATA
drives, but I think most vendors are following this standard for
shipments into the channel.

--eric


-- 
Eric D. Mudama
edmudama at mail.bounceswoosh.org

David Bryan wrote:
> Sorry if the question has been discussed before...did a pretty extensive
search, but no luck...
>
> Preparing to build my first raidz pool. Plan to use 4 identical drives in a
3+1 configuration.
>
> My question is -- what happens if one drive dies, and when I replace it,
design has changed slightly and the drive is (very slightly) different sized.
Still a 1TB or what have you, but not identical. I''m guessing if it is
slightly larger, no problem, slightly smaller is trouble, but that
isn''t always obvious when you buy a drive. My concern is that in a year
when the drive blows, XYZ brand''s model 1000 will be replaced by XYZ
model 1001 that formats to 1MB less (or worse, I need to replace an XYZ brand
1TB with a similar 1TB ABC brand)
>
> Is there a best practices suggestion here? Is this a real problem? Can I
force format the drives very slightly less than full capacity before adding them
to the pool to prevent such an issue?
>
> Thanks.
>   
I just integrated changes which addresses ''6844090 zfs should be able
to
mirror to a smaller disk''. This allows ZFS to deal with slightly 
different sized devices as long as we can create the same number of 
metaslabs. With this change you should be okay.

Thanks,
George