Re: [OmniOS-discuss] supermicro 3U all-in one storage system

2016-03-21 Thread Kevin Swab
These things work with the ahci driver:

http://www.addonics.com/products/ad4mspx2-a.php

Performance is marginal for use as an l2arc or slog, but they're fine
for installing the OS.  Hot-swapping a failed device is tricky but
possible - I use nylon screws in case I drop one on the MB...

Kevin



On 03/21/2016 04:07 PM, Geoff Nordli wrote:
> On 16-03-19 01:28 PM, Richard Elling wrote:
>>> On Mar 18, 2016, at 4:12 PM, Geoff Nordli  wrote:
>>>
>>> Hi.
>>>
>>> I have had good luck with the SuperStorage 6037R-E1R16L chassis with
>>> the LSI 2308 IT mode HBA.
>> We have several similar servers. The X10DRH is fine. For a non-HA
>> system, single expander backplane
>> is ok (BPN-SAS3-836EL1).
> 
> Any thoughts on how to put 4 SATA drives in that chassis?   2 are easy,
> since they fit in the back of the server, but the other two would need
> to go in the front.
> 
> Is the nvme driver stable enough yet to use as l2arc/slog?
> 
> thanks,
> 
> Geoff
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 
---
Kevin Swab  UNIX Systems Administrator
ACNSColorado State University
Phone: (970)491-6572Email: kevin.s...@colostate.edu
GPG Fingerprint: 7026 3F66 A970 67BD 6F17  8EB8 8A7D 142F 2392 791C
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] supermicro 3U all-in one storage system

2016-03-21 Thread Geoff Nordli

On 16-03-19 01:28 PM, Richard Elling wrote:

On Mar 18, 2016, at 4:12 PM, Geoff Nordli  wrote:

Hi.

I have had good luck with the SuperStorage 6037R-E1R16L chassis with the LSI 
2308 IT mode HBA.

We have several similar servers. The X10DRH is fine. For a non-HA system, 
single expander backplane
is ok (BPN-SAS3-836EL1).


Any thoughts on how to put 4 SATA drives in that chassis?   2 are easy, 
since they fit in the back of the server, but the other two would need 
to go in the front.


Is the nvme driver stable enough yet to use as l2arc/slog?

thanks,

Geoff
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Chris Siebenmann
> > 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.

 This implicitly assumes that the only reason to set ashift=12 is if
you are currently using one or more drives that require it. I strongly
disagree with this view. Since ZFS cannot currently replace a 512n
drive with a 512e one, I feel that you really want to force-create
all pools with ashift=12 even on 512n drives unless you're absolutely
confident that you will be able to obtain replacement 512n drives over
the lifetime of your pool (or unless the impact of using ashift=12 is so
drastic on your usage case that you will need to totally rethink your
pool if you become unable to get 512n replacement drives).

 For many usage cases, somewhat more space usage and perhaps somewhat
slower pools are vastly preferable to a loss of pool redundancy over
time. I feel that OmniOS should at least give you the option here (in
a less crude way than simply telling it that absolutely all of your
drives are 4k drives, partly because such general lies are problematic
in various situations).

- cks
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Richard Elling

> On Mar 21, 2016, at 12:00 PM, Richard Jahnel  wrote:
> 
> Both approaches have their error points.
> 
> FWIW I would very very much like to be able to force my new pools into 
> ashift=12. It would make drive purchasing and replacement a lot more straight 
> forward and future resistant.

The fundamental problem is that this is a vdev-settable, not a pool settable. 
Today, it is very common
for pools to have multiple ashifts active. Recently, per-vdev ZAP objects have 
been proposed and that
code is working its way through the review and integration process.

Meanwhile, use one or more of the dozens of methods documented for doing this.

FWIW, most people with HDDs want space efficiency, because HDDs lost the 
performance race to
SSDs long ago. In general, forcing everything to 4k reduces space efficiency, 
so it is unlikely to be
a good default.
 -- richard

> 
> Regards
> 
> Richard Jahnel
> Network Engineer
> On-Site.com | Ellipse Design
> 866-266-7483 ext. 4408
> Direct: 669-800-6270
> 
> -Original Message-
> From: OmniOS-discuss [mailto:omnios-discuss-boun...@lists.omniti.com] On 
> Behalf Of Richard Elling
> Sent: Monday, March 21, 2016 1:54 PM
> To: Jim Klimov 
> Cc: omnios-discuss@lists.omniti.com
> Subject: Re: [OmniOS-discuss] 4kn or 512e with ashift=12
> 
> 
>> On Mar 21, 2016, at 11:11 AM, Jim Klimov  wrote:
>> 
>> 21 марта 2016 г. 10:02:03 CET, Hanno Hirschberger 
>>  пишет:
>>> 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@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@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Richard Elling

> On Mar 21, 2016, at 12:19 PM, Bob Friesenhahn  
> wrote:
> 
> On Mon, 21 Mar 2016, Richard Elling wrote:
>>> 
>>> 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.
> 
> Does this approach require that Illumos users only use drive hardware much 
> older than the version of Illumos they happen running since outdated 
> whitelist won't know about the new lies?

Forunately, lies are becoming less common. But this raises a good point: if 
your drive doesn't lie,
then you don't need to workaround.

> 
> What if a user is using classic drives but wants to be prepared to install 
> newer drives which require ashift=12?

See the bazillion other posts on this topic.
 -- richard

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

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Bob Friesenhahn

On Mon, 21 Mar 2016, Richard Elling wrote:


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.


Does this approach require that Illumos users only use drive hardware 
much older than the version of Illumos they happen running since 
outdated whitelist won't know about the new lies?


What if a user is using classic drives but wants to be prepared to 
install newer drives which require ashift=12?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Richard Elling

> On Mar 21, 2016, at 11:11 AM, Jim Klimov  wrote:
> 
> 21 марта 2016 г. 10:02:03 CET, Hanno Hirschberger 
>  пишет:
>> 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@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@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Jim Klimov
21 марта 2016 г. 10:02:03 CET, Hanno Hirschberger 
 пишет:
>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@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.

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@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Hanno Hirschberger

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@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] supermicro 3U all-in one storage system

2016-03-21 Thread Jim Klimov
20 марта 2016 г. 21:41:10 CET, Geoff Nordli  пишет:
>
>http://www.newegg.com/Product/Product.aspx?Item=9SIA5EM2KP1657
>
>Also, I created a new thread about the differences with 4kn and 512e.  
>Logically, it would make sense the performance would be the same.   I 
>think it would then depend on which one is cheaper.
>
>thanks,
>
>Geoff
>
>
>On 16-03-20 01:15 AM, Matej Žerovnik wrote:
>> As far as I see, there are no 4Kn 4TB SAS drives, only 6TB.
>>
>>  From performance view, is there any different between 4Kn or 512e
>that is formated with ashift=12?
>>
>> Matej
>>
>>> On 19 Mar 2016, at 19:19, Geoff Nordli  wrote:
>>>
>>> I have had really good luck with the Seagate drives as well.
>>>
>>> I see you are running the ST4000NM0034, any reason why you didn't go
>with the  ST4000NM0014 which is 4Kn?
>>>
>>> thanks,
>>>
>>> Geoff
>>>
>>>
>>> On 16-03-19 04:21 AM, Matej Žerovnik wrote:
 Hey there,

 I’m just about to expand my SAN with LSI 3008 HBA. As far as I
>know, support for 3008 has been in Illumos for about a year if not
>more, so it should be stable. I did have problems with getting sas3ircu
>and sas3flash utils from LSI page working, but in the end, I had to get
>an older version (5.00) for it to work (I got it from nexenta github
>repo).

 As far as HDD goes, I’m currently running around 100 Seagate SAS3
>drives (ST4000NM0034) and none of them died in 4 months that I have
>them. I know it’s not a long era, but so far so good:) I also have
>around 180 Seagate Constellation 4TB SATA drives (ST4000NM0033) for
>over 3 years and only one or two drives died.

 Matej

> On 19 Mar 2016, at 00:12, Geoff Nordli  wrote:
>
> Hi.
>
> I have had good luck with the SuperStorage 6037R-E1R16L chassis
>with the LSI 2308 IT mode HBA.
>
> Thoughts on the
>http://www.supermicro.com/products/system/3U/6038/SSG-6038R-E1CR16L.cfm.
>It has the LSI 3008 HBA and Intel x540 network cards.
>
> I want to get at least 4TB 3.5" SAS drives.  Any suggestions on
>those?
>
> I will be installing the latest version of Ominos.
>
> thanks,
>
> Geoff
>
>
>
>___
>OmniOS-discuss mailing list
>OmniOS-discuss@lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

I'd guess 4kn drives have 4k native sectors and expose them as such. 512e 
drives have 4kn sectors and expose RME ability to write smaller sectors for 
backwards compatibility. 512n drives have 512byte sectors (with ecc for each 
512b, not 4kb as the two above).

Then it depends if alignment etc. do not cause 512e disks to go into rmw - 
otherwise it "should be" same as 4kn for 4k*N writes. Depends on vendor 
firmware from here onwards ;)

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Fred Liu
So that means illumos can handle 512n and 4kn automatically and properly?

Thanks.

Fred

From: Matej Žerovnik [mailto:ma...@zunaj.si]
Sent: 星期一, 三月 21, 2016 14:20
To: Fred Liu
Cc: geo...@gnaa.net; omnios-discuss; zfs-disc...@list.zfsonlinux.org
Subject: Re: [OmniOS-discuss] 4kn or 512e with ashift=12

You can’t do that, but you can force system to recognize hard drive as if it 
was 4Kn. Just like we do it for SSDs: 
http://wiki.illumos.org/display/illumos/List+of+sd-config-list+entries+for+Advanced-Format+drives

lp, Matej


On 21 Mar 2016, at 06:00, Fred Liu 
> wrote:

So, you can “zpool create –o ashift=12” in illumos? I can’t do that in smartos 
at least….

From: Geoff Nordli [mailto:geoff.nor...@gmail.com] On Behalf Of Geoff Nordli
Sent: 星期一, 三月 21, 2016 10:59
To: Fred Liu; omnios-discuss
Cc: zfs-disc...@list.zfsonlinux.org
Subject: Re: [OmniOS-discuss] 4kn or 512e with ashift=12



Hi Fred.

Definitely, the ashift parameter has been around on the illumos for a couple of 
years.

thanks,

Geoff

On 16-03-20 05:21 PM, Fred Liu wrote:
The ashift parameter doesn't apply in illumos if my memory serves me well. It 
was introduced by ZoL.

Thanks.

Fred






On Sun, Mar 20, 2016 at 1:37 PM -0700, "Geoff Nordli" 
> wrote:
Quick, question.

Any performance differences between 4Kn and 512e with ashift=12?

I am thinking there should not be, since they will both write the full
4K block size.

The workload will be virtual machines using a zvol.

thanks,

Geoff
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


Re: [OmniOS-discuss] 4kn or 512e with ashift=12

2016-03-21 Thread Matej Žerovnik
You can’t do that, but you can force system to recognize hard drive as if it 
was 4Kn. Just like we do it for SSDs: 
http://wiki.illumos.org/display/illumos/List+of+sd-config-list+entries+for+Advanced-Format+drives

lp, Matej


> On 21 Mar 2016, at 06:00, Fred Liu  wrote:
> 
> So, you can “zpool create –o ashift=12” in illumos? I can’t do that in 
> smartos at least….
>  
> From: Geoff Nordli [mailto:geoff.nor...@gmail.com 
> ] On Behalf Of Geoff Nordli
> Sent: 星期一, 三月 21, 2016 10:59
> To: Fred Liu; omnios-discuss
> Cc: zfs-disc...@list.zfsonlinux.org 
> Subject: Re: [OmniOS-discuss] 4kn or 512e with ashift=12
>  
> 
> 
> Hi Fred. 
> 
> Definitely, the ashift parameter has been around on the illumos for a couple 
> of years.  
> 
> thanks,
> 
> Geoff 
> 
> On 16-03-20 05:21 PM, Fred Liu wrote:
> The ashift parameter doesn't apply in illumos if my memory serves me well. It 
> was introduced by ZoL.
>  
> Thanks.
>  
> Fred
>  
> 
>  
>  
> 
> 
> 
> On Sun, Mar 20, 2016 at 1:37 PM -0700, "Geoff Nordli"  > wrote:
> 
> Quick, question.
> 
> Any performance differences between 4Kn and 512e with ashift=12?
> 
> I am thinking there should not be, since they will both write the full 
> 4K block size.
> 
> The workload will be virtual machines using a zvol.
> 
> thanks,
> 
> Geoff
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com 
> http://lists.omniti.com/mailman/listinfo/omnios-discuss 
> 
>  
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com 
> http://lists.omniti.com/mailman/listinfo/omnios-discuss 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss