[OpenIndiana-discuss] Harddisk > 2TB

[Sašo Kiselkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/20/2013 05:52 PM, Ulrich Hagen wrote:
> Sašo Kiselkov wrote:
> 
>> It indeed appears to be a hard limit of the LSI SAS 1068e chip,
>> no newer firmware appears to fix this issue (which is bizarre,
>> but I suppose LSI also knows how to force customers to upgrade).
>> I suggest you pick up any one of the widely available LSI SAS
>> 2008-based cards out there - in general, OEM cards tend to be
>> cheaper than LSI-original ones, despite running the same hardware
>> and being reflashable to LSI firmware. See 
>> http://www.servethehome.com/lsi-sas-2008-raid-controller-hba-information/
>> for a list of suitable candidates. I personally prefer Dell's
>> PERC H200 - essentially a pure LSI 9211-8i, no reflashing needed,
>> JBOD support and runs like a champ under OI.
> 
> As I wrote in my original e-mail, that is exactly my plan. Not
> with the PERC H200, but with an IBM ServeRAID M1015, which is
> mentioned in the page you sent the link to. My question was, if
> this controller will accept the disks as my current Intel
> controller left them, and keep the data intact. Then I would rely
> on the autoexpand property of the pool to use the additional
> space.

It should, without any trouble.

>>>> 2) Is it possible that for some reason these disks use an
>>>> MBR partitioning table instead of GPT? The former would max
>>>> out at 2Tb.
>>> 
>>> They were and are not partitioned. I took them out of their
>>> boxes, connected them to the controller, started OI and created
>>> the pool using entire disks.
>>> 
>>> And, to reply to Sašo Kiselkov: ashift is 9, these disk lie
>>> about their native sector size. So my pool will never be as
>>> fast as it could.
>> 
>> Nope, they don't. What you're hitting is a bug in ZFS which
>> incorrectly handles Advanced Format drives. I have the same kind
>> of drive with the same formatting and my pools are ashift=13,
>> because I created them with the patched zpool command from
>> Illumos source. If possible, I recommend you re-create your pool
>> with the correct ashift - it is possible.
> 
> Hm, as far as I recollect the discussions about this topic, the 
> statement was: If only these disks would not lie about their 
> blocksize, OI (or rather ZFS) would do the correct thing and set
> up the ashift to 12 automatically.
> 
> But anyway, recreating the pool is currently out of the question
> for me. I will just have to live with ashift=9.

Okay, it's your prerogative.

> BTW: If someone comes up with a tool that can change ashift on the 
> fly, I would be most interested. Not that I expect that to happen
> ...

Highly unlikely. ashift is intimately tied with the pool geometry and
changing it is quite dangerous.

- --
Saso
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlD8Lj8ACgkQle4gLqwmJMfWbACfUHFOwIoH324zoMUcnLeRbNKV
xTkAn2H8+MtWDZD6lMU1lLGv5IUJAdCz
=EcxW
-----END PGP SIGNATURE-----