[OmniOS-discuss] 4kn or 512e with ashift=12
Richard Elling
richard.elling at richardelling.com
Mon Mar 21 18:53:46 UTC 2016
> On Mar 21, 2016, at 11:11 AM, Jim Klimov <jimklimov at cos.ru> wrote:
>
> 21 марта 2016 г. 10:02:03 CET, Hanno Hirschberger <hannohirschberger at googlemail.com> пишет:
>> On 21.03.2016 08:00, Fred Liu wrote:
>>> So that means illumos can handle 512n and 4kn automatically and
>> properly?
>>
>> Not necessarily as far as I know. Sometime drives are emulating 512
>> blocks and don't properly tell the OS about that and Illumos ZFS is
>> aligning the drives with ashift=9 which leads to enormous performance
>> issues. Also forcing the system to handle drives with a specific sector
>>
>> size with the sd.conf doesn't turn out to be reliable in some cases (at
>>
>> least on my workstations). Here's what I do to ensure ashift=12 values:
>>
>> Reboot the system with a Linux live disk of your choice and install ZoL
>>
>> in the live session. Then create the ZFS pool, export it and reboot the
>>
>> machine. OmniOS / Illumos can import the new pool without problems and
>> the ashift value is correctly set. There was a fixed zpool binary
>> (Solaris 11 binary) flying around the internet which can handle the "-o
>>
>> shift=12" parameter and works with OmniOS but unfortunately I can't
>> find
>> it again right now. This would make the reboot into a live session
>> obsolete.
>>
>> Does anyone know if the "ashift" parameter will be implemented in the
>> OmniOS / Illumos zpool binary in the near future?
>>
>> Best regards
>>
>> Hanno
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> Adding the ashift argument to zpool was discussed every few years and so far was always deemed not enterprisey enough for the Solaris heritage, so the setup to tweak sd driver reports and properly rely on that layer was pushed instead.
The issue is that once a drive model lies, then the Solaris approach is to encode
the lie into a whitelist, so that the lie is always handled properly. The whitelist is in the
sd.conf file.
By contrast, the ZFSonLinux approach requires that the sysadmin knows there is a
lie and manually corrects for every invocation. This is unfortunately a very error-prone
approach.
-- richard
>
> That said, the old tweaked binary came with a blog post detailing the source changes; you're welcome to try a d port and rti it (I'd say there is enough user demand to back the non-enterprisey fix to be on par with other OpenZFS siblings). At worst, you can publish the modernized binary as the original blogger did ;)
>
> Jim
> --
> Typos courtesy of K-9 Mail on my Samsung Android
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
More information about the OmniOS-discuss
mailing list