zfs discuss - Apr 2012 - Seagate Constellation vs. Hitachi Ultrastar

Happy Friday, List!

I''m spec''ing out a Thumper-esque solution and having trouble
finding my favorite Hitachi Ultrastar 2TB drives at a reasonable post-flood
price. The Seagate Constellations seem pretty reasonable given the market
circumstances but I don''t have any experience with them. Anybody using
these in their ZFS systems and have you had good luck?

Also, if anyone has a line on a used/refurbished/reconditioned X4540 (Thor),
I''d love to hear from you.

Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120406/1ca66fac/attachment.html>

anh at blackandcode.com said:
> I''m spec''ing out a Thumper-esque solution and having
trouble finding my
> favorite Hitachi Ultrastar 2TB drives at a reasonable post-flood price. The
> Seagate Constellations seem pretty reasonable given the market
circumstances
> but I don''t have any experience with them. Anybody using these in
their ZFS
> systems and have you had good luck?? 
We have a lot of 2TB and 3TB Seagates here, they work fine.  Most of
ours are the Nearline-SAS variety, in Dell MD1200 enclosures, used on
Windows & Linux behind PERC H800 RAID cards, and on Solaris-10 and
OpenIndiana behind LSI SAS HBA''s.  We do have one new server with a
pile of 2TB SATA Seagate''s as well, so far working fine.

The only caveat I''ve found is that the Nearline SAS Seagates go really
slow with the Solaris default multipath load-balancing setting
(round-robin).  Set it to "none" or some large block value and they go
fast.  This issue doesn''t appear when used with the PERC
H800''s.

Regards,

Marion

On Fri, 6 Apr 2012, Marion Hakanson wrote:
>
> The only caveat I''ve found is that the Nearline SAS Seagates go
really
> slow with the Solaris default multipath load-balancing setting
> (round-robin).  Set it to "none" or some large block value and
they go
> fast.  This issue doesn''t appear when used with the PERC
H800''s.
If the drives are exposed as individual LUNs, then it may be possible 
to arrange things so that 1/2 the drives are accessed (by default) 
down one path, and the other 1/2 down the other.  That way you get the 
effect of load-balancing without the churn which might be caused by 
dynamic load-balancing.  That is what I did for my storage here, but 
the preferences needed to be configured on the remote end.

It is likely possible to configure everything on the host end but 
Solaris has special support for my drive array so it used the drive 
array''s preferences.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

I''ve seen a couple sources that suggest prices should be dropping by
the end of April -- apparently not as low as pre flood prices due in
part to a rise in manufacturing costs but about 10% lower than they''re
priced today.

-Gary

On Apr 6, 2012, at 4:58 PM, Marion Hakanson wrote:
> anh at blackandcode.com said:
>> I''m spec''ing out a Thumper-esque solution and having
trouble finding my
>> favorite Hitachi Ultrastar 2TB drives at a reasonable post-flood price.
The
>> Seagate Constellations seem pretty reasonable given the market
circumstances
>> but I don''t have any experience with them. Anybody using these
in their ZFS
>> systems and have you had good luck?  
> 
> We have a lot of 2TB and 3TB Seagates here, they work fine.  Most of
> ours are the Nearline-SAS variety, in Dell MD1200 enclosures, used on
> Windows & Linux behind PERC H800 RAID cards, and on Solaris-10 and
> OpenIndiana behind LSI SAS HBA''s.  We do have one new server with
a
> pile of 2TB SATA Seagate''s as well, so far working fine.
> 
> The only caveat I''ve found is that the Nearline SAS Seagates go
really
> slow with the Solaris default multipath load-balancing setting
> (round-robin).  Set it to "none" or some large block value and
they go
> fast.  This issue doesn''t appear when used with the PERC
H800''s.
We are starting to see a number of SAS HDDs that prefer logical-block to
round-robin. I see this with late model Seagate and Toshiba HDDs.

There is another, similar issue with recognition of multipathing by the
scsi_vhci
driver. Both of these are being tracked as https://www.illumos.org/issues/644
and
there is an alternate scsi_vhci.conf file posted in that bugid.

We''re considering making logical-block the default (as in above bugid)
and we
have not discovered a reason to keep round-robin. If you know of any reason why
round-robin is useful, please add to the bugid.
 -- richard


--
ZFS Performance and Training
Richard.Elling at RichardElling.com
+1-760-896-4422






-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120407/9eec7a0a/attachment.html>

richard.elling at richardelling.com said:
> We are starting to see a number of SAS HDDs that prefer logical-block to
> round-robin. I see this with late model Seagate and Toshiba HDDs.
> 
> There is another, similar issue with recognition of multipathing by the
> scsi_vhci driver. Both of these are being tracked
as?https://www.illumos.org/
> issues/644?and there is an alternate scsi_vhci.conf file posted in that
> bugid.
Interesting, I just last week had a Toshiba come from Dell as a replacement
for a Seagate 2TB SAS drive;  On Solaris-10, the Toshiba insisted on showing
up as 2 drives, so mpxio was not recognizing it.  Fortunately I was able to
swap the drive for a Seagate, but I''ll stash away a copy of the
scsi_vhci.conf
entry for the future.

> We''re considering making logical-block the default (as in above
bugid) and we
> have not discovered a reason to keep round-robin. If you know of any reason
> why round-robin is useful, please add to the bugid. 
Should be fine.  When I first ran into this a couple years ago, I did a
lot of tests and found logical-block to be slower than "none" (with
those
Seagate 2TB SAS drives in Dell MD1200''s), but not a whole lot slower.
I vaguely recall that round-robin was better for highly random, small I/O 
(IOPS-intensive) workloads.

I got the best results by manually load-balancing half the drives to one
path and half the drives to the other path.  But I decided it was not
worth the effort.  Maybe if there was a way to automatically do that
(with a relatively static result)....  Of course, this was all tested
on Solaris-10, so your mileage may vary.

Regards,

Marion

Are these issues something to watch out for on Solaris 11 as well? Thx in
advance?

-Anh


On Apr 9, 2012, at 12:43 PM, Marion Hakanson wrote:
> richard.elling at richardelling.com said:
>> We are starting to see a number of SAS HDDs that prefer logical-block
to
>> round-robin. I see this with late model Seagate and Toshiba HDDs.
>> 
>> There is another, similar issue with recognition of multipathing by the
>> scsi_vhci driver. Both of these are being tracked as
https://www.illumos.org/
>> issues/644 and there is an alternate scsi_vhci.conf file posted in that
>> bugid.
> 
> Interesting, I just last week had a Toshiba come from Dell as a replacement
> for a Seagate 2TB SAS drive;  On Solaris-10, the Toshiba insisted on
showing
> up as 2 drives, so mpxio was not recognizing it.  Fortunately I was able to
> swap the drive for a Seagate, but I''ll stash away a copy of the
scsi_vhci.conf
> entry for the future.
> 
> 
>> We''re considering making logical-block the default (as in
above bugid) and we
>> have not discovered a reason to keep round-robin. If you know of any
reason
>> why round-robin is useful, please add to the bugid. 
> 
> Should be fine.  When I first ran into this a couple years ago, I did a
> lot of tests and found logical-block to be slower than "none"
(with those
> Seagate 2TB SAS drives in Dell MD1200''s), but not a whole lot
slower.
> I vaguely recall that round-robin was better for highly random, small I/O 
> (IOPS-intensive) workloads.
> 
> I got the best results by manually load-balancing half the drives to one
> path and half the drives to the other path.  But I decided it was not
> worth the effort.  Maybe if there was a way to automatically do that
> (with a relatively static result)....  Of course, this was all tested
> on Solaris-10, so your mileage may vary.
> 
> Regards,
> 
> Marion
> 
>