-----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----- _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss