From a.shvayakov at yahoo.com  Fri Aug  1 12:33:53 2014
From: a.shvayakov at yahoo.com (Shvayakov A.)
Date: Fri, 01 Aug 2014 14:33:53 +0200
Subject: [OmniOS-discuss] After the upgrading (pkg update) I cannot boot the
	system
Message-ID: <53DB8931.3020308@yahoo.com>

Hello all,

I has  OmniOS v11 r151006
I cannot boot the system after the upgrading (pkg update)
I tried to use other BE, but it does not change anything.

If I use the boot parameters -sv,  I see it:

http://i.imgur.com/BWfJL2p.png

Do you have any ideas why this happened?
What else can I do to boot the system?

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140801/ccf6eb97/attachment.html>

From a.shvayakov at yahoo.com  Sat Aug  2 19:24:27 2014
From: a.shvayakov at yahoo.com (Shvayakov A.)
Date: Sat, 02 Aug 2014 21:24:27 +0200
Subject: [OmniOS-discuss] After the upgrading (pkg update) I cannot boot
 the	system
Message-ID: <53DD3AEB.3060604@yahoo.com>

Would be correct to say that the system hangs for about 20 minutes then 
starts
I couldn't find a reason for this delay

Do you have any ideas?

Thanks,

From a.shvayakov at yahoo.com  Sun Aug  3 19:05:09 2014
From: a.shvayakov at yahoo.com (Shvayakov A.)
Date: Sun, 03 Aug 2014 21:05:09 +0200
Subject: [OmniOS-discuss] After the upgrading (pkg update) I cannot boot
 the	system
Message-ID: <53DE87E5.7020808@yahoo.com>

I found the reason in the file /kernel/drv/ixgbe.conf
parameter:
rx_group_number=16;

I used the this recommendations:

http://permalink.gmane.org/gmane.linux.iscsi.iscsi-target.devel/13191

Tuning is Evil :)

From info at houseofancients.nl  Tue Aug  5 06:44:03 2014
From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..)
Date: Tue, 5 Aug 2014 06:44:03 +0000
Subject: [OmniOS-discuss] Status of VAAI
Message-ID: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>

Hi Guys,


Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR

Does anyone know if there's any progress in that area ?



https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg02095.html



best regards,





Floris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140805/90d6a7ff/attachment.html>

From danmcd at omniti.com  Tue Aug  5 16:47:52 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 5 Aug 2014 11:47:52 -0500
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
Message-ID: <B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>

Someone needs to take the time to port the Illumos-nexenta bits upstream.  Nobody has yet stepped up to the plate.  Are you volunteering?  ;)

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Aug 5, 2014, at 1:44 AM, "Floris van Essen ..:: House of Ancients Amstafs ::.." <info at houseofancients.nl> wrote:
> 
> Hi Guys,
>  
> Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR
> Does anyone know if there?s any progress in that area ?
>  
> https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg02095.html
>  
> best regards,
>  
>  
> Floris
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140805/c38d14c3/attachment.html>

From info at houseofancients.nl  Tue Aug  5 17:27:27 2014
From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..)
Date: Tue, 5 Aug 2014 17:27:27 +0000
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
	<B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
Message-ID: <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>

Hi Dan,

Sometimes i wish was a programmer ?
Infra dude here, with plenty of stuff to test thing, but a programmer I am not, however if you need testers?.




Van: Dan McDonald [mailto:danmcd at omniti.com]
Verzonden: dinsdag 5 augustus 2014 18:48
Aan: Floris van Essen ..:: House of Ancients Amstafs ::..
CC: omnios-discuss at lists.omniti.com
Onderwerp: Re: [OmniOS-discuss] Status of VAAI

Someone needs to take the time to port the Illumos-nexenta bits upstream.  Nobody has yet stepped up to the plate.  Are you volunteering?  ;)

Dan

Sent from my iPhone (typos, autocorrect, and all)

On Aug 5, 2014, at 1:44 AM, "Floris van Essen ..:: House of Ancients Amstafs ::.." <info at houseofancients.nl<mailto:info at houseofancients.nl>> wrote:
Hi Guys,


Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR

Does anyone know if there?s any progress in that area ?



https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg02095.html



best regards,





Floris
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com>
http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140805/433f10b1/attachment-0001.html>

From danmcd at omniti.com  Tue Aug  5 17:38:09 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 5 Aug 2014 12:38:09 -0500
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
	<B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
	<356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
Message-ID: <A4F99078-82E9-499E-913B-71ADEDBCEA67@omniti.com>

Pardon the top post.

Testers are ALWAYS appreciated for new things.  I'll remember this.

Thanks,
Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Aug 5, 2014, at 12:27 PM, "Floris van Essen ..:: House of Ancients Amstafs ::.." <info at houseofancients.nl> wrote:
> 
> Hi Dan,
>  
> Sometimes i wish was a programmer J
> Infra dude here, with plenty of stuff to test thing, but a programmer I am not, however if you need testers?.
>  
>  
>  
>  
> Van: Dan McDonald [mailto:danmcd at omniti.com] 
> Verzonden: dinsdag 5 augustus 2014 18:48
> Aan: Floris van Essen ..:: House of Ancients Amstafs ::..
> CC: omnios-discuss at lists.omniti.com
> Onderwerp: Re: [OmniOS-discuss] Status of VAAI
>  
> Someone needs to take the time to port the Illumos-nexenta bits upstream.  Nobody has yet stepped up to the plate.  Are you volunteering?  ;)
>  
> Dan
> 
> Sent from my iPhone (typos, autocorrect, and all)
> 
> On Aug 5, 2014, at 1:44 AM, "Floris van Essen ..:: House of Ancients Amstafs ::.." <info at houseofancients.nl> wrote:
> 
> Hi Guys,
>  
> Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR
> Does anyone know if there?s any progress in that area ?
>  
> https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg02095.html
>  
> best regards,
>  
>  
> Floris
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140805/586ddcfe/attachment.html>

From alka at hfg-gmuend.de  Tue Aug  5 20:43:15 2014
From: alka at hfg-gmuend.de (=?iso-8859-1?Q?G=FCnther_Alka?=)
Date: Tue, 5 Aug 2014 22:43:15 +0200
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
	<B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
	<356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
Message-ID: <A1A7B9EA-80A5-4FB8-9814-8C9BFAB72491@hfg-gmuend.de>

I am a programmer but not for OS development but in the GUI/ usability area
otherwise I would help (can help with testing)

It is really a pity.  Ragarding storage and usability, Solaris and OmniOS is far better than
Linux that I use as well for my ZFS GUI. With the newest features that Nexenta integrates
into NexentaStor (beside VAII this is SMB2 and failure management on slow disks), Illumos
has the ability to be the number 1 storage OS - even in the OpenSource or low-cost  area,
better than BSD or Linux.

If Nexenta would give Illumian more love, it might become the leading free Illumos distribution
but I do not expect that this will happen. The other ?big players? like Delphix, Joyent or
OmniOS seems to have no interest  in such storage features as well as improvements in
encryption (hey we need this)

Gea/ napp-it.org


Am 05.08.2014 um 19:27 schrieb Floris van Essen ..:: House of Ancients Amstafs ::.. <info at houseofancients.nl>:

> Hi Dan,
>  
> Sometimes i wish was a programmer J
> Infra dude here, with plenty of stuff to test thing, but a programmer I am not, however if you need testers?.
>  
>  
>  
>  
> Van: Dan McDonald [mailto:danmcd at omniti.com] 
> Verzonden: dinsdag 5 augustus 2014 18:48
> Aan: Floris van Essen ..:: House of Ancients Amstafs ::..
> CC: omnios-discuss at lists.omniti.com
> Onderwerp: Re: [OmniOS-discuss] Status of VAAI
>  
> Someone needs to take the time to port the Illumos-nexenta bits upstream.  Nobody has yet stepped up to the plate.  Are you volunteering?  ;)
>  
> Dan
> 
> Sent from my iPhone (typos, autocorrect, and all)
> 
> On Aug 5, 2014, at 1:44 AM, "Floris van Essen ..:: House of Ancients Amstafs ::.." <info at houseofancients.nl> wrote:
> 
> Hi Guys,
>  
> Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR
> Does anyone know if there?s any progress in that area ?
>  
> https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg02095.html
>  
> best regards,
>  
>  
> Floris
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140805/e4a8bafb/attachment.html>

From slefevre at indy.rr.com  Tue Aug  5 20:52:39 2014
From: slefevre at indy.rr.com (Scott LeFevre)
Date: Tue, 05 Aug 2014 16:52:39 -0400
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <A1A7B9EA-80A5-4FB8-9814-8C9BFAB72491@hfg-gmuend.de>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
	<B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
	<356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
	<A1A7B9EA-80A5-4FB8-9814-8C9BFAB72491@hfg-gmuend.de>
Message-ID: <1407271959.4138.73.camel@exilis.si-consulting.us>

So what is the skill set needed to help with the development?  If we
have a better understanding of this, it might allow people to understand
if they are capable of helping.

Cheers,
-- 
Scott LeFevre
317-696-1010 

On Tue, 2014-08-05 at 22:43 +0200, G?nther Alka wrote:

> I am a programmer but not for OS development but in the GUI/ usability
> area
> 
> otherwise I would help (can help with testing)
> 
> 
> It is really a pity.  Ragarding storage and usability, Solaris and
> OmniOS is far better than
> Linux that I use as well for my ZFS GUI. With the newest features that
> Nexenta integrates
> into NexentaStor (beside VAII this is SMB2 and failure management on
> slow disks), Illumos
> has the ability to be the number 1 storage OS - even in the OpenSource
> or low-cost  area,
> better than BSD or Linux.
> 
> 
> If Nexenta would give Illumian more love, it might become the leading
> free Illumos distribution
> but I do not expect that this will happen. The other ?big players?
> like Delphix, Joyent or
> OmniOS seems to have no interest  in such storage features as well as
> improvements in
> encryption (hey we need this)
> 
> 
> Gea/ napp-it.org
> 
> 
> 
> 
> Am 05.08.2014 um 19:27 schrieb Floris van Essen ..:: House of Ancients
> Amstafs ::.. <info at houseofancients.nl>:
> 
> 
> 
> > Hi Dan,
> >  
> > Sometimes i wish was a programmer J
> > Infra dude here, with plenty of stuff to test thing, but a
> > programmer I am not, however if you need testers?.
> >  
> >  
> >  
> >  
> > Van: Dan McDonald [mailto:danmcd at omniti.com] 
> > Verzonden: dinsdag 5 augustus 2014 18:48
> > Aan: Floris van Essen ..:: House of Ancients Amstafs ::..
> > CC: omnios-discuss at lists.omniti.com
> > Onderwerp: Re: [OmniOS-discuss] Status of VAAI
> >  
> > Someone needs to take the time to port the Illumos-nexenta bits
> > upstream.  Nobody has yet stepped up to the plate.  Are you
> > volunteering?  ;)
> >  
> > Dan
> > 
> > Sent from my iPhone (typos, autocorrect, and all)
> > 
> > On Aug 5, 2014, at 1:44 AM, "Floris van Essen ..:: House of Ancients
> > Amstafs ::.." <info at houseofancients.nl> wrote:
> > 
> > 
> >         Hi Guys,
> >          
> >         
> >         Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR
> >         Does anyone know if there?s any progress in that area ?
> >          
> >         https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg02095.html
> >          
> >         best regards,
> >          
> >          
> >         Floris
> >         
> >         _______________________________________________
> >         OmniOS-discuss mailing list
> >         OmniOS-discuss at lists.omniti.com
> >         http://lists.omniti.com/mailman/listinfo/omnios-discuss
> > 
> > _______________________________________________
> > OmniOS-discuss mailing list
> > OmniOS-discuss at lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> 
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140805/c288cffd/attachment-0001.html>

From chip at innovates.com  Wed Aug  6 00:38:11 2014
From: chip at innovates.com (Schweiss, Chip)
Date: Tue, 5 Aug 2014 19:38:11 -0500
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <1407271959.4138.73.camel@exilis.si-consulting.us>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
	<B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
	<356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
	<A1A7B9EA-80A5-4FB8-9814-8C9BFAB72491@hfg-gmuend.de>
	<1407271959.4138.73.camel@exilis.si-consulting.us>
Message-ID: <CALeZrrQQ4Gd_nAYMJ9Ab=+N78w=LbM2Jxv9rFF4zDMTE6zoXyQ@mail.gmail.com>

I used to do a lot of Linux kernel work, but haven't jumped in on Illumos,
mostly because the information to get started seems sparse and often
outdated on the few wiki pages that exist.

I'd be a regular at dabbling in the Illumos kernel if it didn't require so
much time just to get started.

One curiosity I have is could a hybrid distribution of OmniOS with a
Nexenta kernel be built and be useable.  Nexenta keeps everything out in
the open on Github.   How hard would it be to build that kernel and utilize
it?

-Chip


On Tue, Aug 5, 2014 at 3:52 PM, Scott LeFevre <slefevre at indy.rr.com> wrote:

>  So what is the skill set needed to help with the development?  If we
> have a better understanding of this, it might allow people to understand if
> they are capable of helping.
>
> Cheers,
>   --
> Scott LeFevre
> 317-696-1010
>
>   On Tue, 2014-08-05 at 22:43 +0200, G?nther Alka wrote:
>
> I am a programmer but not for OS development but in the GUI/ usability
> area
>
>  otherwise I would help (can help with testing)
>
>
>
>  It is really a pity.  Ragarding storage and usability, Solaris and
> OmniOS is far better than
>
>  Linux that I use as well for my ZFS GUI. With the newest features that
> Nexenta integrates
>
>  into NexentaStor (beside VAII this is SMB2 and failure management on slow
> disks), Illumos
>
>  has the ability to be the number 1 storage OS - even in the OpenSource or
> low-cost  area,
>
>  better than BSD or Linux.
>
>
>
>  If Nexenta would give Illumian more love, it might become the leading
> free Illumos distribution
>
>  but I do not expect that this will happen. The other ?big players? like
> Delphix, Joyent or
>
>  OmniOS seems to have no interest  in such storage features as well as
> improvements in
>
>  encryption (hey we need this)
>
>
>
>  Gea/ napp-it.org
>
>
>
>
>  Am 05.08.2014 um 19:27 schrieb Floris van Essen ..:: House of Ancients
> Amstafs ::.. <info at houseofancients.nl>:
>
>
>   Hi Dan,
>
>
>
>   Sometimes i wish was a programmer J
>
>   Infra dude here, with plenty of stuff to test thing, but a programmer I
> am not, however if you need testers?.
>
>
>
>
>
>
>
>
>
>   *Van:* Dan McDonald [mailto:danmcd at omniti.com <danmcd at omniti.com>]
> *Verzonden:* dinsdag 5 augustus 2014 18:48
> *Aan:* Floris van Essen ..:: House of Ancients Amstafs ::..
> *CC:* omnios-discuss at lists.omniti.com
> *Onderwerp:* Re: [OmniOS-discuss] Status of VAAI
>
>
>
>   Someone needs to take the time to port the Illumos-nexenta bits
> upstream.  Nobody has yet stepped up to the plate.  Are you volunteering?
>  ;)
>
>
>
>   Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
>
> On Aug 5, 2014, at 1:44 AM, "Floris van Essen ..:: House of Ancients
> Amstafs ::.." <info at houseofancients.nl> wrote:
>
>
>    Hi Guys,
>
>
>
>    Been waiting now for a long time for VAAI (XCOPY and ATS ) to make it into COMSTAR
> Does anyone know if there?s any progress in that area ?
>  https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg02095.html
>
> best regards,
>
>
> Floris
>
>    _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>   _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
>  _______________________________________________
> OmniOS-discuss mailing listOmniOS-discuss at lists.omniti.comhttp://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140805/80a55e04/attachment.html>

From danmcd at omniti.com  Wed Aug  6 02:21:22 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 5 Aug 2014 22:21:22 -0400
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <A1A7B9EA-80A5-4FB8-9814-8C9BFAB72491@hfg-gmuend.de>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
	<B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
	<356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
	<A1A7B9EA-80A5-4FB8-9814-8C9BFAB72491@hfg-gmuend.de>
Message-ID: <A81CE0BF-BEB8-4D69-AF6D-09135EAAF96D@omniti.com>


On Aug 5, 2014, at 4:43 PM, G?nther Alka <alka at hfg-gmuend.de> wrote:
> 
> If Nexenta would give Illumian more love, it might become the leading free Illumos distribution
> but I do not expect that this will happen.

Many ex-Sun types who aren't Joyent like IPS.  I don't think Illumian, with its Debian-ish-ness, would appeal to them.

> The other ?big players? like Delphix, Joyent or
> OmniOS seems to have no interest  in such storage features

REALLY!?!?  Delphix has been BIG on improvements to storage, specifically in the ZFS realm.  That's an irresponsible use of a broad brush stroke.  And Delphix has fixed some iSCSI stuff that Nexenta didn't catch.  Yes, Nexenta's done the most outside of ZFS improvements to help storage -- it's their jobs (e.g. SMB/CIFS).  Don't blow off the other players, though, please.

OmniTI isn't explicitly in the storage business, so its illumos resources (mostly me) are directed to where they can do the most good for OmniTI and OmniOS.

> as well as improvements in
> encryption (hey we need this)

Nobody, and I mean NOBODY with money to spend has asked any of the major players about on-disk encryption.  I spent just shy of 3 years at Nexenta, and I asked this question repeatedly both inside and out: no paying customers wanted it.

There's also the issue of the ZFS crypto patent - folks are (with good reason) afraid of it. ZFS crypto didn't land in the Oracle Solaris source until AFTER the barn door had been closed.  There's no CDDL grounds to protect people.  The work-in-progress ZFS crypto I've seen kicked around is not complete enough, either.

FYI,
Dan


From danmcd at omniti.com  Wed Aug  6 02:24:02 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 5 Aug 2014 22:24:02 -0400
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <CALeZrrQQ4Gd_nAYMJ9Ab=+N78w=LbM2Jxv9rFF4zDMTE6zoXyQ@mail.gmail.com>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
	<B49D5048-C12E-4BF6-996A-8BC10D3E88E6@omniti.com>
	<356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local>
	<A1A7B9EA-80A5-4FB8-9814-8C9BFAB72491@hfg-gmuend.de>
	<1407271959.4138.73.camel@exilis.si-consulting.us>
	<CALeZrrQQ4Gd_nAYMJ9Ab=+N78w=LbM2Jxv9rFF4zDMTE6zoXyQ@mail.gmail.com>
Message-ID: <D995F51D-A2F3-4315-B020-F8CA817DC9BC@omniti.com>


On Aug 5, 2014, at 8:38 PM, Schweiss, Chip <chip at innovates.com> wrote:

> I used to do a lot of Linux kernel work, but haven't jumped in on Illumos, mostly because the information to get started seems sparse and often outdated on the few wiki pages that exist.    

The wiki isn't bad.  Also look at this old blog post for building small bits:

	http://kebesays.blogspot.com/2011/03/for-illumos-newbies-on-developing-small.html

After our Surge conference this year, we're having an Illumos Day.  Would an intro-to-new-developers talk be useful?

> One curiosity I have is could a hybrid distribution of OmniOS with a Nexenta kernel be built and be useable.  Nexenta keeps everything out in the open on Github.   How hard would it be to build that kernel and utilize it?

You might as well spend the effort to upstream bits of illumos-nexenta that you find interesting.  My next mail on this thread will discuss this.

Dan


From danmcd at omniti.com  Wed Aug  6 03:02:17 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 5 Aug 2014 23:02:17 -0400
Subject: [OmniOS-discuss] Status of VAAI
In-Reply-To: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local>
Message-ID: <7D4C2369-A758-4DE9-AFB5-EE6D1462A627@omniti.com>

Okay.  I'm home (from vacation), and I can answer this a bit more thoroughly.  (Why do you guys pile on while I'm on vacation?!?  :)  )

The best course of action here is to upstream the VAAI bits from illumos-nexenta into illumos-gate.  This would involve:

1.) Scoping out ALL of the VAAI changes in illumos-nexenta - making sure you aren't missing any corner-cases and bugfixes.  (Trust me, I helped with the initial VAAI work, there are bugfixes you need!)

2.) Moving said changes into illumos-gate (illumos-omnios would suffice for this, as we don't diverge from upstream in this department), and making sure they build both as modules, and as a full-world-build nightly.

3.) Testing the hell out of it.  Nexenta tested it, and STILL needed months/years to iron out everything.

4.) Sending it up for review and RTI.

I think I could do #1-2 myself without much effort, but I have OmniTI customers and paying OmniOS customers to serve first. A new-to-illumos person would have two learning curves to climb. It's not untenable, but it's much harder.  Ideally, Nexenta would be working on upstreaming this themselves (as Delphix has with their numerous ZFS changes).  You may wish to ask on illumos community mailing lists about that.

#3 is the hard part.  I knew very little about iSCSI, COMSTAR, and storage in general when I was showed the initial work on VAAI.  After upstreaming UNMAP and WRITE_SAME, Nexenta got a little hamstrung on the other two primitives.  Still, during all of that, TESTING was needed, and sometimes internal testing didn't catch everything. Those of you clamoring for VAAI should be offering to test (like Floris did).  If you can WRITE TESTS for the usr/src/test directory, that would be good (even if they're scripts for other platforms like Linux).  If you have a good hard-and-heavy environment, documenting it, and placing the new code in place would also be good.

#4 is not that tough, especially if whomever did #1-#2 clearly documents what he/she did, and works with (or is) a seasoned illumos developer.

I hope I haven't come across as too harsh.  I think getting this upstreamed is useful and important.  I just wanted to spell out what all needs to happen.

Dan


From danmcd at omniti.com  Wed Aug  6 16:58:13 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 6 Aug 2014 12:58:13 -0400
Subject: [OmniOS-discuss] JOB POST - Illumos System Administrator & Support
	Engineer
Message-ID: <D68FDDC2-501B-4B36-B1B3-3BE5EAA9149B@omniti.com>

From the job posting:

The role of Solaris/Illumos System Administrator is a highly technical role, and requires thorough understanding of all components of a modern web application stack, including front-end, networking, and systems level knowledge. You will be supporting our internal infrastructure and teams, as well as providing managed services support, open source product development, and data center infrastructure support for our customers.

We're actively seeking someone.  I've wired the mail headers to prevent list-followup traffic.  Honor the reply-to field and your name will get to the right people.

Thanks,
Dan


From danmcd at omniti.com  Wed Aug  6 17:00:45 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 6 Aug 2014 13:00:45 -0400
Subject: [OmniOS-discuss] JOB POST - Illumos System Administrator &
	Support Engineer
In-Reply-To: <D68FDDC2-501B-4B36-B1B3-3BE5EAA9149B@omniti.com>
References: <D68FDDC2-501B-4B36-B1B3-3BE5EAA9149B@omniti.com>
Message-ID: <EB03D1B9-D60F-4EA5-86F8-126A2736FE09@omniti.com>


On Aug 6, 2014, at 12:58 PM, Dan McDonald <danmcd at omniti.com> wrote:

> From the job posting:

Forgot the URL, sorry:

	http://www.omniti.com/is/hiring/system-administrator

Pardon the second post,
Dan


From danmcd at omniti.com  Wed Aug  6 21:21:37 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 6 Aug 2014 17:21:37 -0400
Subject: [OmniOS-discuss] Anyone here run Wordpress on OmniOS?
Message-ID: <31D1F961-A2B7-4439-8F94-631D256EC7DC@omniti.com>

I'm contemplating hosting some blogs on the the HDC.  I'd like to use Wordpress.  Anyone here have experience using Wordpress on OmniOS?  If so, I'd LOVE to see your experiences shared here on this thread.

Thanks,
Dan


From zmalone at omniti.com  Wed Aug  6 22:02:45 2014
From: zmalone at omniti.com (Zach Malone)
Date: Wed, 6 Aug 2014 18:02:45 -0400
Subject: [OmniOS-discuss] Anyone here run Wordpress on OmniOS?
In-Reply-To: <31D1F961-A2B7-4439-8F94-631D256EC7DC@omniti.com>
References: <31D1F961-A2B7-4439-8F94-631D256EC7DC@omniti.com>
Message-ID: <CALLZ=vX2v-zL7Ch4JfVPGsdKnefemMcq+rs0yc1+BZjHhdXyEQ@mail.gmail.com>

Hi Dan,
I've run Wordpress on OmniOS in places; I don't remember seeing any
problems out of the platform, although the omniti-ms packages don't
typically include default configs or manifests.  You'll want to add
the omniti-ms repo (information for that is available at
http://omnios.omniti.com/wiki.php/Packaging ), and then you'll want to
install a webserver (our Apache httpd is called apache22), php (php-53
/ php-54), gd, and mysql (mysql55).

Configuring it all together will get you into the standard Apache /
MySQL config files, which probably need to be written from scratch,
and writing service manifests for both.  When that's done, and you
have MySQL and Apache running, you can throw the standard Wordpress
tarball into your document root, configure wp-config.php, and you
should be finished.
--Zach

On Wed, Aug 6, 2014 at 5:21 PM, Dan McDonald <danmcd at omniti.com> wrote:
> I'm contemplating hosting some blogs on the the HDC.  I'd like to use Wordpress.  Anyone here have experience using Wordpress on OmniOS?  If so, I'd LOVE to see your experiences shared here on this thread.
>
> Thanks,
> Dan
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From sk at kram.io  Thu Aug  7 09:38:16 2014
From: sk at kram.io (Steffen Kram)
Date: Thu, 7 Aug 2014 11:38:16 +0200
Subject: [OmniOS-discuss] Anyone here run Wordpress on OmniOS?
In-Reply-To: <31D1F961-A2B7-4439-8F94-631D256EC7DC@omniti.com>
References: <31D1F961-A2B7-4439-8F94-631D256EC7DC@omniti.com>
Message-ID: <65FD43C3-9F13-4E97-A336-A11BF0778B6C@kram.io>

Hi Dan,

I?m running a couple of Wordpress installations on OmniOS using my packages from scott.mathematik.uni-ulm.de. They are all running MySQL, nginx, PHP 5.5.x, PHP-FPM. If you?re interested, I?m glad to provide you with my configuration files.

Cheers, Steffen


Am 06.08.2014 um 23:21 schrieb Dan McDonald <danmcd at omniti.com>:

> I'm contemplating hosting some blogs on the the HDC.  I'd like to use Wordpress.  Anyone here have experience using Wordpress on OmniOS?  If so, I'd LOVE to see your experiences shared here on this thread.
> 
> Thanks,
> Dan
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140807/0f39342f/attachment.bin>

From a.shvayakov at yahoo.com  Thu Aug  7 09:49:52 2014
From: a.shvayakov at yahoo.com (Shvayakov A.)
Date: Thu, 07 Aug 2014 11:49:52 +0200
Subject: [OmniOS-discuss] OmniOS doesn't see FC adapter qla2562
Message-ID: <53E34BC0.7070306@yahoo.com>

Hello,

I wanted to add  the FC card, but  OmniOS doesn't see  My qla2562.
The package driver/network/qlc is installed

modinfo | grep qlc
109 fffffffff81e5000  68978  13   1  qlc (SunFC Qlogic FCA v20100408-3.01)


But....
fcinfo hba-port
No Adapters Found


But If I load OmniOS  Livecd, I can see this device.
http://i.imgur.com/amEu33m.png

Do you have any idea why this is so?

Thanks,

From bfriesen at simple.dallas.tx.us  Thu Aug  7 13:33:16 2014
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Thu, 7 Aug 2014 08:33:16 -0500 (CDT)
Subject: [OmniOS-discuss] OmniOS doesn't see FC adapter qla2562
In-Reply-To: <53E34BC0.7070306@yahoo.com>
References: <53E34BC0.7070306@yahoo.com>
Message-ID: <alpine.GSO.2.01.1408070830240.18732@freddy.simplesystems.org>

On Thu, 7 Aug 2014, Shvayakov A. wrote:

> Hello,
>
> I wanted to add  the FC card, but  OmniOS doesn't see  My qla2562.
> The package driver/network/qlc is installed
>
> modinfo | grep qlc
> 109 fffffffff81e5000  68978  13   1  qlc (SunFC Qlogic FCA v20100408-3.01)
>
>
> But....
> fcinfo hba-port
> No Adapters Found

Did you run the above with 'pfexec' or under an account with 
sufficient privileges?  The "No Adapters Found." message is reported 
if the command is run as an ordinary user.

% fcinfo hba-port
No Adapters Found.
% pfexec fcinfo hba-port
HBA Port WWN: 50014380062d4dd8
 	Port Mode: Initiator
 	Port ID: 0
 	OS Device Name: /dev/cfg/c4
 	Manufacturer: QLogic Corp.
 	Model: AJ764A or AH401A
.
.
.

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

From danmcd at omniti.com  Thu Aug  7 14:46:27 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 7 Aug 2014 10:46:27 -0400
Subject: [OmniOS-discuss] Please "pkg update" for OpenSSL 1.0.1i
Message-ID: <9BE47AD3-0FD6-482A-9C5F-AEF9A3B2F221@omniti.com>

OpenSSL issued an update last night to address some issues, documented here:

	https://www.openssl.org/news/secadv_20140806.txt

The repo servers for Long-Term Support and Stable should be updated.  If you're on Long Term Support (r151006) or the current active Stable (r151010) you'll also be getting a bugfix for a tricky inter-zone/intra-node socket problem (Illumos 5026) an OmniOS customer found.  If you're still on r151008, you're only getting the OpenSSL fix, and you should update to r151010.

The bloody release is NOT fixed yet, but as that's going out in the next 12-36 hours ANYWAY, those fixes will be landing soon enough.

Thank you!
Dan McD. -- OmniOS Engineering


From henson at acm.org  Thu Aug  7 19:41:29 2014
From: henson at acm.org (Paul B. Henson)
Date: Thu, 7 Aug 2014 12:41:29 -0700
Subject: [OmniOS-discuss] Please "pkg update" for OpenSSL 1.0.1i
In-Reply-To: <9BE47AD3-0FD6-482A-9C5F-AEF9A3B2F221@omniti.com>
References: <9BE47AD3-0FD6-482A-9C5F-AEF9A3B2F221@omniti.com>
Message-ID: <014701cfb277$971f7fb0$c55e7f10$@acm.org>

Cool. I see the release notes
(http://omnios.omniti.com/wiki.php/ReleaseNotes/r151010) haven't been
updated? It looks like there was also a perl update
(runtime/perl/module/sun-solaris 0.5.11,5.11-0.151010:20140428T192845Z ->
0.5.11,5.11-.151010:20140806T221302Z) and I was just curious what it
included. 5026 doesn't impact my use case, so I updated just the perl and
openssl packages to avoid an extraneous reboot :).

Thanks.

> -----Original Message-----
> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com]
> On Behalf Of Dan McDonald
> Sent: Thursday, August 07, 2014 7:46 AM
> To: omnios-discuss
> Subject: [OmniOS-discuss] Please "pkg update" for OpenSSL 1.0.1i
> 
> OpenSSL issued an update last night to address some issues, documented
> here:
> 
> 	https://www.openssl.org/news/secadv_20140806.txt
> 
> The repo servers for Long-Term Support and Stable should be updated.  If
> you're on Long Term Support (r151006) or the current active Stable
(r151010)
> you'll also be getting a bugfix for a tricky inter-zone/intra-node socket
> problem (Illumos 5026) an OmniOS customer found.  If you're still on
> r151008, you're only getting the OpenSSL fix, and you should update to
> r151010.
> 
> The bloody release is NOT fixed yet, but as that's going out in the next
12-36
> hours ANYWAY, those fixes will be landing soon enough.
> 
> Thank you!
> Dan McD. -- OmniOS Engineering
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From henson at acm.org  Thu Aug  7 19:46:10 2014
From: henson at acm.org (Paul B. Henson)
Date: Thu, 7 Aug 2014 12:46:10 -0700
Subject: [OmniOS-discuss] deleting zfs filesystems with holds in place
Message-ID: <014b01cfb278$3eaf28c0$bc0d7a40$@acm.org>

I was wondering if anybody knew of a better way to delete a file system that
might have snapshots with holds other than enumerating all of the snapshots
of the file system, checking them for holds, and explicitly releasing them?
I was hoping that -f would do the trick, but that still fails if a snapshot
exists with a hold on it.

Thanks.


From slefevre at indy.rr.com  Thu Aug  7 19:51:39 2014
From: slefevre at indy.rr.com (Scott LeFevre)
Date: Thu, 07 Aug 2014 15:51:39 -0400
Subject: [OmniOS-discuss] deleting zfs filesystems with holds in place
In-Reply-To: <014b01cfb278$3eaf28c0$bc0d7a40$@acm.org>
References: <014b01cfb278$3eaf28c0$bc0d7a40$@acm.org>
Message-ID: <1407441099.20827.3.camel@exilis.si-consulting.us>

Try zfs destroy -R poolname/filesystem

Read the man pages first to ensure this is what you want to do in your
situation.  The -r option might work for you as well.

-- 
Scott LeFevre
317-696-1010 

On Thu, 2014-08-07 at 12:46 -0700, Paul B. Henson wrote:

> I was wondering if anybody knew of a better way to delete a file system that
> might have snapshots with holds other than enumerating all of the snapshots
> of the file system, checking them for holds, and explicitly releasing them?
> I was hoping that -f would do the trick, but that still fails if a snapshot
> exists with a hold on it.
> 
> Thanks.
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140807/8aa6c956/attachment-0001.html>

From danmcd at omniti.com  Thu Aug  7 19:52:40 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 7 Aug 2014 15:52:40 -0400
Subject: [OmniOS-discuss] Please "pkg update" for OpenSSL 1.0.1i
In-Reply-To: <014701cfb277$971f7fb0$c55e7f10$@acm.org>
References: <9BE47AD3-0FD6-482A-9C5F-AEF9A3B2F221@omniti.com>
	<014701cfb277$971f7fb0$c55e7f10$@acm.org>
Message-ID: <FC5A8541-B33D-440C-8DA9-0CFCC7F1C1FD@omniti.com>


On Aug 7, 2014, at 3:41 PM, Paul B. Henson <henson at acm.org> wrote:

> Cool. I see the release notes
> (http://omnios.omniti.com/wiki.php/ReleaseNotes/r151010) haven't been
> updated? It looks like there was also a perl update
> (runtime/perl/module/sun-solaris 0.5.11,5.11-0.151010:20140428T192845Z ->
> 0.5.11,5.11-.151010:20140806T221302Z) and I was just curious what it
> included. 5026 doesn't impact my use case, so I updated just the perl and
> openssl packages to avoid an extraneous reboot :).

Sorry about that.  Fixed. (Someone else had been doing those.)

The Perl update was done because (and I'm shocked we didn't discover this sooner), building all of illumos-omnios's r151010 branch ON r151010 would fail.  It had to do with very strange Perl interactions.  I chose to backport the perl updates from upstream (and tested in bloody) into r151010.  I wanted to build the world because the sockfs fix was in system/kernel, which is a lot of stuff.

Dan


From danmcd at omniti.com  Fri Aug  8 01:48:29 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 7 Aug 2014 21:48:29 -0400
Subject: [OmniOS-discuss] August 7th OmniOS "bloody" repo update
Message-ID: <E5BFFB39-0FE9-4B93-9F23-19984343DF57@omniti.com>

This would've been done sooner, but with the supported repos needing OpenSSL updates, this one got pushed out a bit later.

This one is a small amount of changes, relative to the last one.  Obviously the OpenSSL update is here.  The list of what's new is:

	- OpenSSL updated to 1.0.1i
	- Various man-page updates, including modern man-page tools
	- ZFS bugfixes and performance improvments:
	  - Including improved UNMAP performance for large datasets
	- ztest now uses larger device sizes by default
	- intra-node/inter-zone packets now deliver SIGPOLL to the receiver.
	- Localhost connections choke less in TCP's TIME_WAIT state.

NOTE:  This update does not change the "uname -v" string (omnios-8e364a8), but its default /etc/motd contains omnios-faf4446, which reflects the git commit in illumos-omnios that built this update.  This was because there were no updates in system/kernel/platform, which contains "unix", and the "uname -v" string.

Happy updating!
Dan


From danmcd at omniti.com  Fri Aug  8 04:50:19 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 8 Aug 2014 00:50:19 -0400
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
Message-ID: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>

If you follow Illumos bug 5069 (https://illumos.org/issues/5069), you'll see that the FTP server (based on wuftpd) is being removed from illumos-gate, and subsequently, illumos-omnios.

I'd like to put a replacement FTP server into omnios-build, so it can still be there.  I can stick with the identical version that's being ripped out, but I'd rather, if possible, put something newer in its place.  We may lose some of the PAM and other integration features, unless that's a show-stopper for anyone (esp. paying customers) out here.

If you have suggestions, please let me know.  I'm leaning toward being lazy for now and just moving the source to be ripped out into something consumable by omnios-build.  I can be convinced otherwise without much effort, though.

I'd appreciate it if you speak up on this thread with your suggestions.

Thanks,
Dan McD. -- OmniOS Engineering


From tobi at oetiker.ch  Fri Aug  8 06:43:44 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Fri, 8 Aug 2014 08:43:44 +0200 (CEST)
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
 suggestions?
In-Reply-To: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
Message-ID: <alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>

Hi Dan,

Today Dan McDonald wrote:

> If you follow Illumos bug 5069 (https://illumos.org/issues/5069),
> you'll see that the FTP server (based on wuftpd) is being removed
> from illumos-gate, and subsequently, illumos-omnios.
>
> I'd like to put a replacement FTP server into omnios-build, so it
> can still be there.  I can stick with the identical version
> that's being ripped out, but I'd rather, if possible, put
> something newer in its place.  We may lose some of the PAM and
> other integration features, unless that's a show-stopper for
> anyone (esp.  paying customers) out here.
>
> If you have suggestions, please let me know.  I'm leaning toward
> being lazy for now and just moving the source to be ripped out
> into something consumable by omnios-build.  I can be convinced
> otherwise without much effort, though.

It seems that http://www.proftpd.org/ is well maintained and does
know about solaris and was already considered as a replacement for
wuftpd anyway ...

PSARC 2011/088

cheers
tobi
>
> I'd appreciate it if you speak up on this thread with your suggestions.
>
> Thanks,
> Dan McD. -- OmniOS Engineering
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902


From bfriesen at simple.dallas.tx.us  Fri Aug  8 13:53:15 2014
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 8 Aug 2014 08:53:15 -0500 (CDT)
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
 suggestions?
In-Reply-To: <alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
Message-ID: <alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>

On Fri, 8 Aug 2014, Tobias Oetiker wrote:
>
> It seems that http://www.proftpd.org/ is well maintained and does
> know about solaris and was already considered as a replacement for
> wuftpd anyway ...

My own experience with ProFTPd is that it requires a configuration 
file.  Does it have an equivalent default operating mode to wuftpd or 
will the switch inflict a need to reconfigure existing ftp service due 
to the update?

If it is not a true drop-in replacement, then I suggest supporting 
wuftpd as it is today but also offering (and recommending) use of 
ProFTPd as a non-conflicting installation.

ProFTPd does have an active mailing list and reasonably frequent 
releases.

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

From esproul at omniti.com  Fri Aug  8 14:06:50 2014
From: esproul at omniti.com (Eric Sproul)
Date: Fri, 8 Aug 2014 10:06:50 -0400
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
In-Reply-To: <alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
Message-ID: <CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>

IMHO the existence of an FTP daemon in the base OS runs counter to the
OmniOS minimalist philosophy.  We don't ship any httpd servers in the
base OS, for example, even though many other OSes and illumos distros
do.  in.ftpd there now because it's part of illumos but I don't feel a
strong need to put a replacement in, "just to have one".  Is FTP still
*that* important to people?  I'd argue that if it is, you would be
using your own modern daemon rather than using the decades-old WU
version in -gate, and therefore dropping it causes no harm.

And, since a change to something like ProFTPd or vsftpd is likely
going to require reconfiguration anyway, would having something in a
commonly-used but non-base repo like ms.omniti.com be acceptable?

Eric

From stephen at atalanta-systems.com  Fri Aug  8 14:10:02 2014
From: stephen at atalanta-systems.com (Stephen Nelson-Smith)
Date: Fri, 8 Aug 2014 15:10:02 +0100
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
In-Reply-To: <CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
	<CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
Message-ID: <CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>

Hi,

On 8 August 2014 15:06, Eric Sproul <esproul at omniti.com> wrote:
> IMHO the existence of an FTP daemon in the base OS runs counter to the
> OmniOS minimalist philosophy.

+1 for me.

> And, since a change to something like ProFTPd or vsftpd is likely
> going to require reconfiguration anyway, would having something in a
> commonly-used but non-base repo like ms.omniti.com be acceptable?

I think so.

S.

From danmcd at omniti.com  Fri Aug  8 14:33:15 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 8 Aug 2014 10:33:15 -0400
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
In-Reply-To: <CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
	<CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
	<CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>
Message-ID: <A0C6CD1B-3CFC-4D25-8830-BC9E0239B125@omniti.com>


On Aug 8, 2014, at 10:10 AM, Stephen Nelson-Smith <stephen at atalanta-systems.com> wrote:

> Hi,
> 
> On 8 August 2014 15:06, Eric Sproul <esproul at omniti.com> wrote:
>> IMHO the existence of an FTP daemon in the base OS runs counter to the
>> OmniOS minimalist philosophy.
> 
> +1 for me.

<SNIP!>

This is a valid perspective.  I do believe, however, that we need to have SOMETHING available once the illumos rip-out happens.  I suppose it can live in omnti-ms, but I do think it needs to live somewhere.

Dan


From richard.elling at richardelling.com  Fri Aug  8 14:43:20 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Fri, 8 Aug 2014 07:43:20 -0700
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
In-Reply-To: <A0C6CD1B-3CFC-4D25-8830-BC9E0239B125@omniti.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
	<CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
	<CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>
	<A0C6CD1B-3CFC-4D25-8830-BC9E0239B125@omniti.com>
Message-ID: <E98DCDED-1282-46C9-B1D8-C1369E68B484@RichardElling.com>


> On Aug 8, 2014, at 7:33 AM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Aug 8, 2014, at 10:10 AM, Stephen Nelson-Smith <stephen at atalanta-systems.com> wrote:
>> 
>> Hi,
>> 
>>> On 8 August 2014 15:06, Eric Sproul <esproul at omniti.com> wrote:
>>> IMHO the existence of an FTP daemon in the base OS runs counter to the
>>> OmniOS minimalist philosophy.
>> 
>> +1 for me.
> 
> <SNIP!>
> 
> This is a valid perspective.  I do believe, however, that we need to have SOMETHING available once the illumos rip-out happens.  I suppose it can live in omnti-ms, but I do think it needs to live somewhere.

sftp is there

  -- richard


From esproul at omniti.com  Fri Aug  8 15:08:53 2014
From: esproul at omniti.com (Eric Sproul)
Date: Fri, 8 Aug 2014 11:08:53 -0400
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
In-Reply-To: <E98DCDED-1282-46C9-B1D8-C1369E68B484@RichardElling.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
	<CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
	<CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>
	<A0C6CD1B-3CFC-4D25-8830-BC9E0239B125@omniti.com>
	<E98DCDED-1282-46C9-B1D8-C1369E68B484@RichardElling.com>
Message-ID: <CA+QY2RTj6Xkr-fA6X2pt=y_UEtGdsdG_bF_jdAAcrTt8dDJhFQ@mail.gmail.com>

On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling
<richard.elling at richardelling.com> wrote:
> sftp is there

+1.  FTP is more and more a legacy/niche service.  The world has moved
on and there are better ways of distributing files, like sftp or even
http/https.

From danmcd at omniti.com  Fri Aug  8 15:09:05 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 8 Aug 2014 11:09:05 -0400
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
In-Reply-To: <CA+QY2RTj6Xkr-fA6X2pt=y_UEtGdsdG_bF_jdAAcrTt8dDJhFQ@mail.gmail.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
	<CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
	<CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>
	<A0C6CD1B-3CFC-4D25-8830-BC9E0239B125@omniti.com>
	<E98DCDED-1282-46C9-B1D8-C1369E68B484@RichardElling.com>
	<CA+QY2RTj6Xkr-fA6X2pt=y_UEtGdsdG_bF_jdAAcrTt8dDJhFQ@mail.gmail.com>
Message-ID: <94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com>


On Aug 8, 2014, at 11:08 AM, Eric Sproul <esproul at omniti.com> wrote:

> On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling
> <richard.elling at richardelling.com> wrote:
>> sftp is there
> 
> +1.  FTP is more and more a legacy/niche service.  The world has moved
> on and there are better ways of distributing files, like sftp or even
> http/https.


Then let me rephrase my question, given my possibly faulty assumptions:

	DO WE NEED TO SCRAMBLE TO REPLACE in.ftpd IF IT'S YANKED OUT?

Given Eric's arguments, the answer is no.  I can be convinced of "yes", but it'll take more convincing now.  ("No" is less work for me, so I'm biased.  :) )

Thanks,
Dan


From dswartz at druber.com  Fri Aug  8 15:13:48 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Fri, 8 Aug 2014 11:13:48 -0400
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
 suggestions?
In-Reply-To: <94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
	<CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
	<CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>
	<A0C6CD1B-3CFC-4D25-8830-BC9E0239B125@omniti.com>
	<E98DCDED-1282-46C9-B1D8-C1369E68B484@RichardElling.com>
	<CA+QY2RTj6Xkr-fA6X2pt=y_UEtGdsdG_bF_jdAAcrTt8dDJhFQ@mail.gmail.com>
	<94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com>
Message-ID: <3bf380759ffc0c416700107b3f1525c5.squirrel@webmail.druber.com>

>
> On Aug 8, 2014, at 11:08 AM, Eric Sproul <esproul at omniti.com> wrote:
>
>> On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling
>> <richard.elling at richardelling.com> wrote:
>>> sftp is there
>>
>> +1.  FTP is more and more a legacy/niche service.  The world has moved
>> on and there are better ways of distributing files, like sftp or even
>> http/https.
>
>
> Then let me rephrase my question, given my possibly faulty assumptions:
>
> 	DO WE NEED TO SCRAMBLE TO REPLACE in.ftpd IF IT'S YANKED OUT?
>
> Given Eric's arguments, the answer is no.  I can be convinced of "yes",
> but it'll take more convincing now.  ("No" is less work for me, so I'm
> biased.  :) )

I would agree also...


From peter.tribble at gmail.com  Sat Aug  9 16:36:01 2014
From: peter.tribble at gmail.com (Peter Tribble)
Date: Sat, 9 Aug 2014 17:36:01 +0100
Subject: [OmniOS-discuss] FTP server leaving illumos. Replacement
	suggestions?
In-Reply-To: <94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com>
References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com>
	<alpine.DEB.2.02.1408080842170.11611@froburg.oetiker.ch>
	<alpine.GSO.2.01.1408080847290.18732@freddy.simplesystems.org>
	<CA+QY2RRRaUAfbHOfQdCXzVVFPNbVET5YxKHyv_ZXZR-iq==mBA@mail.gmail.com>
	<CAOq1yR5AP=-=fMZG5HgaHyrJPBRaGF5XsbVBHoB_bru1X6cPNQ@mail.gmail.com>
	<A0C6CD1B-3CFC-4D25-8830-BC9E0239B125@omniti.com>
	<E98DCDED-1282-46C9-B1D8-C1369E68B484@RichardElling.com>
	<CA+QY2RTj6Xkr-fA6X2pt=y_UEtGdsdG_bF_jdAAcrTt8dDJhFQ@mail.gmail.com>
	<94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com>
Message-ID: <CAEgYsbGHH8ZcTRVz0u00fSwvchwjnZ=tPjvqF_3MJh0AfR4L8Q@mail.gmail.com>

On Fri, Aug 8, 2014 at 4:09 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> On Aug 8, 2014, at 11:08 AM, Eric Sproul <esproul at omniti.com> wrote:
>
> > On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling
> > <richard.elling at richardelling.com> wrote:
> >> sftp is there
>

Which is a completely different protocol.


> > +1.  FTP is more and more a legacy/niche service.  The world has moved
> > on and there are better ways of distributing files, like sftp or even
> > http/https.
>

My experience is that most of the world hasn't moved on, much
as we would like it to progress. Personally, I'm often asked to enable
file uploads for average users, and the client capabilities usually
force the use of ftp. And fortunately, enabling basic ftp service
is currently trivial.

(Note that I'm talking about use inside the organization. For proper
customer-facing service, you would always run a dedicated server.
Again, the real world makes extensive use of ftp.)


> Then let me rephrase my question, given my possibly faulty assumptions:
>
>         DO WE NEED TO SCRAMBLE TO REPLACE in.ftpd IF IT'S YANKED OUT?
>
> Given Eric's arguments, the answer is no.  I can be convinced of "yes",
> but it'll take more convincing now.  ("No" is less work for me, so I'm
> biased.  :) )


-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140809/9d0cf837/attachment.html>

From rafibeyli at gmail.com  Mon Aug 11 08:06:42 2014
From: rafibeyli at gmail.com (Hafiz Rafibeyli)
Date: Mon, 11 Aug 2014 11:06:42 +0300 (EEST)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
Message-ID: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>

Tobias thank you for great job,it was missing backup  part for zfs on omnios,

I think ssh will slow for bigger datasets,as you mention znapzend 0.11 supporting use of mbuffer.

I could not find mbuffer package for omnios,could you explain how to setup/use mbuffer on omnios please?

regards



----- Original Message -----
From: omnios-discuss-request at lists.omniti.com
To: omnios-discuss at lists.omniti.com
Sent: Tuesday, 29 July, 2014 10:29:42 PM
Subject: OmniOS-discuss Digest, Vol 28, Issue 8

Send OmniOS-discuss mailing list submissions to
	omnios-discuss at lists.omniti.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.omniti.com/mailman/listinfo/omnios-discuss
or, via email, send a message with subject or body 'help' to
	omnios-discuss-request at lists.omniti.com

You can reach the person managing the list at
	omnios-discuss-owner at lists.omniti.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OmniOS-discuss digest..."


Today's Topics:

   1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
   2. Re: announcement znapzend a new zfs backup tool
      (Theo Schlossnagle)
   3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
   4. Re: Slow scrub performance (wuffers)


----------------------------------------------------------------------

Message: 1
Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
From: Tobias Oetiker <tobi at oetiker.ch>
To: omnios-discuss at lists.omniti.com
Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Just out:

 ZnapZend a Multilevel Backuptool for ZFS

It is on Github. Check out

 http://www.znapzend.org

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902



------------------------------

Message: 2
Date: Tue, 29 Jul 2014 11:54:07 -0400
From: Theo Schlossnagle <jesus at omniti.com>
To: "OmniOS-discuss at lists.omniti.com"
	<omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
	tool
Message-ID:
	<CACLsAptC_wDb+Stkw2-jZkgp7oQZ4OwEUWG_Nnrm_xkaoOkGRg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Awesome!


On Tue, Jul 29, 2014 at 11:50 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:

> Just out:
>
>  ZnapZend a Multilevel Backuptool for ZFS
>
> It is on Github. Check out
>
>  http://www.znapzend.org
>
> cheers
> tobi
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140729/f8adbbf5/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 29 Jul 2014 17:59:18 +0200
From: Saso Kiselkov <skiselkov.ml at gmail.com>
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
	tool
Message-ID: <53D7C4D6.5060308 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 7/29/14, 5:50 PM, Tobias Oetiker wrote:
> Just out:
> 
>  ZnapZend a Multilevel Backuptool for ZFS
> 
> It is on Github. Check out
> 
>  http://www.znapzend.org

Neat, especially the feature that the backup config is part of a
dataset's properties. Very cool.

-- 
Saso



------------------------------

Message: 4
Date: Tue, 29 Jul 2014 15:29:38 -0400
From: wuffers <moo at wuffers.net>
To: Richard Elling <richard.elling at richardelling.com>
Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] Slow scrub performance
Message-ID:
	<CA+tR_KwX_1HN4tVa+-ZOFJk2mN7RE-nFh31sMcTNo7TJJjfyLg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Going to try to answer both responses in one message..

Short answer, yes. ? Keep in mind that
>
> 1. a scrub runs in the background (so as not to impact production I/O,
> this was not always the case and caused serious issues in the past with a
> pool being unresponsive due to a scrub)
>
> 2. a scrub essentially walks the zpool examining every transaction in
> order (as does a resilver)
>
> So the time to complete a scrub depends on how many write transactions
> since the pool was created (which is generally related to the amount of
> data but not always). You are limited by the random I/O capability of the
> disks involved. With VMs I assume this is a file server, so the I/O size
> will also affect performance.


I haven't noticed any slowdowns in our virtual environments, so I guess
that's a good thing it's so low priority that it doesn't impact workloads.

Run the numbers? you are scanning 24.2TB at about 5.5MB/sec ? 4,613,734
> seconds or 54 days. And that assumes the same rate for all of the scan. The
> rate will change as other I/O competes for resources.
>

The number was fluctuating when I started the scrub, and I had seen it go
as high as 35MB/s at one point. I am certain that our Hyper-V workload has
increased since the last scrub, so this does make sense.


> Looks like you have a fair bit of activity going on (almost 1MB/sec of
> writes per spindle).
>

As Richard correctly states below, this is the aggregate since boot (uptime
~56 days). I have another output from iostat as per his instructions below.


> Since this is storage for VMs, I assume this is the storage server for
> separate compute servers? Have you tuned the block size for the file share
> you are using? That can make a huge difference in performance.
>

Both the Hyper-V and VMware LUNs are created with 64K block sizes. From
what I've read of other performance and tuning articles, that is the
optimal block size (I did some limited testing when first configuring the
SAN, but results were somewhat inconclusive). Hyper-V hosts our testing
environment (we integrate with TFS, a MS product, so we have no choice
here) and probably make up the bulk of the workload (~300+ test VMs with
various OSes). VMware hosts our production servers (Exchange, file servers,
SQL, AD, etc - ~50+ VMs).

I also noted that you only have a single LOG device. Best Practice is to
> mirror log devices so you do not lose any data in flight if hit by a power
> outage (of course, if this server has more UPS runtime that all the clients
> that may not matter).
>

Actually, I do have a mirror ZIL device, it's just disabled at this time
(my ZIL devices are ZeusRAMs). At some point, I was troubleshooting some
kernel panics (turned out to be a faulty SSD on the rpool), and hadn't
re-enabled it yet. Thanks for the reminder (and yes, we do have a UPS as
well).

And oops.. re-attaching the ZIL as a mirror triggered a resilver now,
suspending or canceling the scrub? Will monitor this and restart the scrub
if it doesn't by itself.

  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Jul 29 14:48:48 2014
    3.89T scanned out of 24.5T at 3.06G/s, 1h55m to go
    0 resilvered, 15.84% done

At least it's going very fast. EDIT: Now about 67% done as I finish writing
this, speed dropping to ~1.3G/s.

maybe, maybe not
>>
>> this is slower than most, surely slower than desired
>>
>
Unfortunately reattaching the mirror to my log device triggered a resilver.
Not sure if this is desired behavior, but yes, 5.5MB/s seems quite slow.
Hopefully after the resilver the scrub will progress where it left off.


> The estimate is often very wrong, especially for busy systems.
>> If this is an older ZFS implementation, this pool is likely getting
>> pounded by the
>> ZFS write throttle. There are some tunings that can be applied, but the
>> old write
>> throttle is not a stable control system, so it will always be a little
>> bit unpredictable.
>>
>
The system is on r151008 (my BE states that I upgraded back in February,
putting me in r151008j or so), with all the pools upgraded for the new
enhancements as well as activating the new L2ARC compression feature.
Reading the release notes, the ZFS write throttle enhancements were in
since r151008e so I should be good there.


> # iostat -xnze
>>
>>
>> Unfortunately, this is the performance since boot and is not suitable for
>> performance
>> analysis unless the system has been rebooted in the past 10 minutes or
>> so. You'll need
>> to post the second batch from "iostat -zxCn 60 2"
>>
>
Ah yes, that was my mistake. Output from second count (before re-attaching
log mirror):

# iostat -zxCn 60 2

                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
  255.7 1077.7 6294.0 41335.1  0.0  1.9    0.0    1.4   0 153 c1
    5.3   23.9  118.5  811.9  0.0  0.0    0.0    1.1   0   3
c1t5000C50055F8723Bd0
    5.9   14.5  110.0  834.3  0.0  0.0    0.0    1.3   0   2
c1t5000C50055E66B63d0
    5.6   16.6  123.8  822.7  0.0  0.0    0.0    1.3   0   2
c1t5000C50055F87E73d0
    4.7   27.8  118.6  796.6  0.0  0.0    0.0    1.3   0   3
c1t5000C50055F8BFA3d0
    5.6   14.5  139.7  833.8  0.0  0.0    0.0    1.6   0   3
c1t5000C50055F9E123d0
    4.4   27.1  112.3  825.2  0.0  0.0    0.0    0.8   0   2
c1t5000C50055F9F0B3d0
    5.0   20.2  121.7  803.4  0.0  0.0    0.0    1.2   0   3
c1t5000C50055F9D3B3d0
    5.4   26.4  137.0  857.3  0.0  0.0    0.0    1.4   0   4
c1t5000C50055E4FDE7d0
    4.7   12.3  123.7  832.7  0.0  0.0    0.0    2.0   0   3
c1t5000C50055F9A607d0
    5.0   23.9  125.9  830.9  0.0  0.0    0.0    1.3   0   3
c1t5000C50055F8CDA7d0
    4.5   31.4  112.2  814.6  0.0  0.0    0.0    1.1   0   3
c1t5000C50055E65877d0
    5.2   24.4  130.6  872.5  0.0  0.0    0.0    1.2   0   3
c1t5000C50055F9E7D7d0
    4.1   21.8  103.7  797.2  0.0  0.0    0.0    1.1   0   3
c1t5000C50055FA0AF7d0
    5.5   24.8  129.8  802.8  0.0  0.0    0.0    1.5   0   4
c1t5000C50055F9FE87d0
    5.7   17.7  137.2  797.6  0.0  0.0    0.0    1.4   0   3
c1t5000C50055F9F91Bd0
    6.0   30.6  139.1  852.0  0.0  0.1    0.0    1.5   0   4
c1t5000C50055F9FEABd0
    6.1   34.1  137.8  929.2  0.0  0.1    0.0    1.9   0   6
c1t5000C50055F9F63Bd0
    4.1   15.9  101.8  791.4  0.0  0.0    0.0    1.6   0   3
c1t5000C50055F9F3EBd0
    6.4   23.2  155.2  878.6  0.0  0.0    0.0    1.1   0   3
c1t5000C50055F9F80Bd0
    4.5   23.5  106.2  825.4  0.0  0.0    0.0    1.1   0   3
c1t5000C50055F9FB8Bd0
    4.0   23.2  101.1  788.9  0.0  0.0    0.0    1.3   0   3
c1t5000C50055F9F92Bd0
    4.4   11.3  125.7  782.3  0.0  0.0    0.0    1.9   0   3
c1t5000C50055F8905Fd0
    4.6   20.4  129.2  823.0  0.0  0.0    0.0    1.5   0   3
c1t5000C50055F8D48Fd0
    5.1   19.7  142.9  887.2  0.0  0.0    0.0    1.7   0   3
c1t5000C50055F9F89Fd0
    5.6   11.4  129.1  776.0  0.0  0.0    0.0    1.9   0   3
c1t5000C50055F9EF2Fd0
    5.6   23.7  137.4  811.9  0.0  0.0    0.0    1.2   0   3
c1t5000C50055F8C3ABd0
    6.8   13.9  132.4  834.3  0.0  0.0    0.0    1.8   0   3
c1t5000C50055E66053d0
    5.2   26.7  126.9  857.3  0.0  0.0    0.0    1.2   0   3
c1t5000C50055E66503d0
    4.2   27.1  104.6  825.2  0.0  0.0    0.0    1.0   0   3
c1t5000C50055F9D3E3d0
    5.2   30.7  140.9  852.0  0.0  0.1    0.0    1.5   0   4
c1t5000C50055F84FB7d0
    5.4   16.1  124.3  791.4  0.0  0.0    0.0    1.7   0   3
c1t5000C50055F8E017d0
    3.8   31.4   89.7  814.6  0.0  0.0    0.0    1.1   0   4
c1t5000C50055E579F7d0
    4.6   27.5  116.0  796.6  0.0  0.1    0.0    1.6   0   4
c1t5000C50055E65807d0
    4.0   21.5   99.7  797.2  0.0  0.0    0.0    1.1   0   3
c1t5000C50055F84A97d0
    4.7   20.2  116.3  803.4  0.0  0.0    0.0    1.4   0   3
c1t5000C50055F87D97d0
    5.0   11.5  121.5  776.0  0.0  0.0    0.0    2.0   0   3
c1t5000C50055F9F637d0
    4.9   11.3  112.4  782.3  0.0  0.0    0.0    2.3   0   3
c1t5000C50055E65ABBd0
    5.3   11.8  142.5  832.7  0.0  0.0    0.0    2.4   0   3
c1t5000C50055F8BF9Bd0
    5.0   20.3  121.4  823.0  0.0  0.0    0.0    1.7   0   3
c1t5000C50055F8A22Bd0
    6.6   24.3  170.3  872.5  0.0  0.0    0.0    1.3   0   3
c1t5000C50055F9379Bd0
    5.8   16.3  121.7  822.7  0.0  0.0    0.0    1.3   0   2
c1t5000C50055E57A5Fd0
    5.3   17.7  146.5  797.6  0.0  0.0    0.0    1.4   0   3
c1t5000C50055F8CCAFd0
    5.7   34.1  141.5  929.2  0.0  0.1    0.0    1.7   0   5
c1t5000C50055F8B80Fd0
    5.5   23.8  125.7  830.9  0.0  0.0    0.0    1.2   0   3
c1t5000C50055F9FA1Fd0
    5.0   23.2  127.9  878.6  0.0  0.0    0.0    1.1   0   3
c1t5000C50055E65F0Fd0
    5.2   14.0  163.7  833.8  0.0  0.0    0.0    2.0   0   3
c1t5000C50055F8BE3Fd0
    4.6   18.9  122.8  887.2  0.0  0.0    0.0    1.6   0   3
c1t5000C50055F8B21Fd0
    5.5   23.6  137.4  825.4  0.0  0.0    0.0    1.5   0   3
c1t5000C50055F8A46Fd0
    4.9   24.6  116.7  802.8  0.0  0.0    0.0    1.4   0   4
c1t5000C50055F856CFd0
    4.9   23.4  120.8  788.9  0.0  0.0    0.0    1.4   0   3
c1t5000C50055E6606Fd0
  234.9  170.1 4079.9 11127.8  0.0  0.2    0.0    0.5   0   9 c2
  119.0   28.9 2083.8  670.8  0.0  0.0    0.0    0.3   0   3
c2t500117310015D579d0
  115.9   27.4 1996.1  634.2  0.0  0.0    0.0    0.3   0   3
c2t50011731001631FDd0
    0.0  113.8    0.0 9822.8  0.0  0.1    0.0    1.0   0   2
c2t5000A72A3007811Dd0
    0.1   18.5    0.0   64.8  0.0  0.0    0.0    0.0   0   0 c4
    0.1    9.2    0.0   32.4  0.0  0.0    0.0    0.0   0   0 c4t0d0
    0.0    9.2    0.0   32.4  0.0  0.0    0.0    0.0   0   0 c4t1d0
  229.8   58.1 3987.4 1308.0  0.0  0.1    0.0    0.3   0   6 c12
  114.2   27.7 1994.8  626.0  0.0  0.0    0.0    0.3   0   3
c12t500117310015D59Ed0
  115.5   30.4 1992.6  682.0  0.0  0.0    0.0    0.3   0   3
c12t500117310015D54Ed0
    0.1   17.1    0.0   64.8  0.0  0.0    0.6    0.1   0   0 rpool
  720.3 1298.4 14361.2 53770.8 18.7  2.3    9.3    1.1   6  68 tank

Is 153% busy correct on c1? Seems to me that disks are quite "busy", but
are handling the workload just fine (wait at 6% and asvc_t at 1.1ms)

Interestingly, this is the same output now that the resilver is running:

                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
 2876.9 1041.1 25400.7 38189.1  0.0 37.9    0.0    9.7   0 2011 c1
   60.8   26.1  540.1  845.2  0.0  0.7    0.0    8.3   0  39
c1t5000C50055F8723Bd0
   58.4   14.2  511.6  740.7  0.0  0.7    0.0   10.1   0  39
c1t5000C50055E66B63d0
   60.2   16.3  529.3  756.1  0.0  0.8    0.0   10.1   0  41
c1t5000C50055F87E73d0
   57.5   24.9  527.6  841.7  0.0  0.7    0.0    9.0   0  40
c1t5000C50055F8BFA3d0
   57.9   14.5  543.5  765.1  0.0  0.7    0.0    9.8   0  38
c1t5000C50055F9E123d0
   57.9   23.9  516.6  806.9  0.0  0.8    0.0    9.3   0  40
c1t5000C50055F9F0B3d0
   59.8   24.6  554.1  857.5  0.0  0.8    0.0    9.6   0  42
c1t5000C50055F9D3B3d0
   56.5   21.0  480.4  715.7  0.0  0.7    0.0    8.9   0  37
c1t5000C50055E4FDE7d0
   54.8    9.7  473.5  737.9  0.0  0.7    0.0   11.2   0  39
c1t5000C50055F9A607d0
   55.8   20.2  457.3  708.7  0.0  0.7    0.0    9.9   0  40
c1t5000C50055F8CDA7d0
   57.8   28.6  487.0  796.1  0.0  0.9    0.0    9.9   0  45
c1t5000C50055E65877d0
   60.8   27.1  572.6  823.7  0.0  0.8    0.0    8.8   0  41
c1t5000C50055F9E7D7d0
   55.8   21.1  478.2  766.6  0.0  0.7    0.0    9.7   0  40
c1t5000C50055FA0AF7d0
   57.0   22.8  528.3  724.5  0.0  0.8    0.0    9.6   0  41
c1t5000C50055F9FE87d0
   56.2   10.8  465.2  715.6  0.0  0.7    0.0   10.4   0  38
c1t5000C50055F9F91Bd0
   59.2   29.4  524.6  740.9  0.0  0.8    0.0    8.9   0  41
c1t5000C50055F9FEABd0
   57.3   30.7  496.7  788.3  0.0  0.8    0.0    9.1   0  42
c1t5000C50055F9F63Bd0
   55.5   16.3  461.9  652.9  0.0  0.7    0.0   10.1   0  39
c1t5000C50055F9F3EBd0
   57.2   22.1  495.1  701.1  0.0  0.8    0.0    9.8   0  41
c1t5000C50055F9F80Bd0
   59.5   30.2  543.1  741.8  0.0  0.9    0.0    9.6   0  45
c1t5000C50055F9FB8Bd0
   56.5   25.1  515.4  786.9  0.0  0.7    0.0    8.6   0  38
c1t5000C50055F9F92Bd0
   61.8   12.5  540.6  790.9  0.0  0.8    0.0   10.3   0  41
c1t5000C50055F8905Fd0
   57.0   19.8  521.0  774.3  0.0  0.7    0.0    9.6   0  39
c1t5000C50055F8D48Fd0
   56.3   16.3  517.7  724.7  0.0  0.7    0.0    9.9   0  38
c1t5000C50055F9F89Fd0
   57.0   13.4  504.5  790.5  0.0  0.8    0.0   10.7   0  40
c1t5000C50055F9EF2Fd0
   55.0   26.1  477.6  845.2  0.0  0.7    0.0    8.3   0  36
c1t5000C50055F8C3ABd0
   57.8   14.1  518.7  740.7  0.0  0.8    0.0   10.8   0  41
c1t5000C50055E66053d0
   55.9   20.8  490.2  715.7  0.0  0.7    0.0    9.0   0  37
c1t5000C50055E66503d0
   57.0   24.1  509.7  806.9  0.0  0.8    0.0   10.0   0  41
c1t5000C50055F9D3E3d0
   59.1   29.2  504.1  740.9  0.0  0.8    0.0    9.3   0  44
c1t5000C50055F84FB7d0
   54.4   16.3  449.5  652.9  0.0  0.7    0.0   10.4   0  39
c1t5000C50055F8E017d0
   57.8   28.4  503.3  796.1  0.0  0.9    0.0   10.1   0  45
c1t5000C50055E579F7d0
   58.2   24.9  502.0  841.7  0.0  0.8    0.0    9.2   0  40
c1t5000C50055E65807d0
   58.2   20.7  513.4  766.6  0.0  0.8    0.0    9.8   0  41
c1t5000C50055F84A97d0
   56.5   24.9  508.0  857.5  0.0  0.8    0.0    9.2   0  40
c1t5000C50055F87D97d0
   53.4   13.5  449.9  790.5  0.0  0.7    0.0   10.7   0  38
c1t5000C50055F9F637d0
   57.0   11.8  503.0  790.9  0.0  0.7    0.0   10.6   0  39
c1t5000C50055E65ABBd0
   55.4    9.6  461.1  737.9  0.0  0.8    0.0   11.6   0  40
c1t5000C50055F8BF9Bd0
   55.7   19.7  484.6  774.3  0.0  0.7    0.0    9.9   0  40
c1t5000C50055F8A22Bd0
   57.6   27.1  518.2  823.7  0.0  0.8    0.0    8.9   0  40
c1t5000C50055F9379Bd0
   59.6   17.0  528.0  756.1  0.0  0.8    0.0   10.1   0  41
c1t5000C50055E57A5Fd0
   61.2   10.8  530.0  715.6  0.0  0.8    0.0   10.7   0  40
c1t5000C50055F8CCAFd0
   58.0   30.8  493.3  788.3  0.0  0.8    0.0    9.4   0  43
c1t5000C50055F8B80Fd0
   56.5   19.9  490.7  708.7  0.0  0.8    0.0   10.0   0  40
c1t5000C50055F9FA1Fd0
   56.1   22.4  484.2  701.1  0.0  0.7    0.0    9.5   0  39
c1t5000C50055E65F0Fd0
   59.2   14.6  560.9  765.1  0.0  0.7    0.0    9.8   0  39
c1t5000C50055F8BE3Fd0
   57.9   16.2  546.0  724.7  0.0  0.7    0.0   10.1   0  40
c1t5000C50055F8B21Fd0
   59.5   30.0  553.2  741.8  0.0  0.9    0.0    9.8   0  45
c1t5000C50055F8A46Fd0
   57.4   22.5  504.0  724.5  0.0  0.8    0.0    9.6   0  41
c1t5000C50055F856CFd0
   58.4   24.6  531.4  786.9  0.0  0.7    0.0    8.4   0  38
c1t5000C50055E6606Fd0
  511.0  161.4 7572.1 11260.1  0.0  0.3    0.0    0.4   0  14 c2
  252.3   20.1 3776.3  458.9  0.0  0.1    0.0    0.2   0   6
c2t500117310015D579d0
  258.8   18.0 3795.7  350.0  0.0  0.1    0.0    0.2   0   6
c2t50011731001631FDd0
    0.0  123.4    0.0 10451.1  0.0  0.1    0.0    1.0   0   3
c2t5000A72A3007811Dd0
    0.2   16.1    1.9   56.7  0.0  0.0    0.0    0.0   0   0 c4
    0.2    8.1    1.6   28.3  0.0  0.0    0.0    0.0   0   0 c4t0d0
    0.0    8.1    0.3   28.3  0.0  0.0    0.0    0.0   0   0 c4t1d0
  495.6  163.6 7168.9 11290.3  0.0  0.2    0.0    0.4   0  14 c12
    0.0  123.4    0.0 10451.1  0.0  0.1    0.0    1.0   0   3
c12t5000A72B300780FFd0
  248.2   18.1 3645.8  323.0  0.0  0.1    0.0    0.2   0   5
c12t500117310015D59Ed0
  247.4   22.1 3523.1  516.2  0.0  0.1    0.0    0.2   0   6
c12t500117310015D54Ed0
    0.2   14.8    1.9   56.7  0.0  0.0    0.6    0.1   0   0 rpool
 3883.5 1357.7 40141.6 60739.5 22.8 38.6    4.4    7.4  54 100 tank

It is very busy with alot of wait % and higher asvc_t (2011% busy on c1?!).
I'm assuming resilvers are alot more aggressive than scrubs.

There are many variables here, the biggest of which is the current
>> non-scrub load.
>>
>
I might have lost 2 weeks of scrub time, depending on whether the scrub
will resume where it left off. I'll update when I can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140729/1b53a492/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss


------------------------------

End of OmniOS-discuss Digest, Vol 28, Issue 8
*********************************************

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From tobi at oetiker.ch  Mon Aug 11 08:44:21 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Mon, 11 Aug 2014 10:44:21 +0200 (CEST)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
Message-ID: <alpine.DEB.2.02.1408111040150.11611@froburg.oetiker.ch>

Hi Hafiz,

Today Hafiz Rafibeyli wrote:

> Tobias thank you for great job,it was missing backup  part for zfs on omnios,
>
> I think ssh will slow for bigger datasets,as you mention znapzend 0.11 supporting use of mbuffer.
>
> I could not find mbuffer package for omnios,could you explain how to setup/use mbuffer on omnios please?

mbuffer is in the omniti repo

# pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
# pkg install mbuffer

cheers
tobi

>
> regards
>
>
>
> ----- Original Message -----
> From: omnios-discuss-request at lists.omniti.com
> To: omnios-discuss at lists.omniti.com
> Sent: Tuesday, 29 July, 2014 10:29:42 PM
> Subject: OmniOS-discuss Digest, Vol 28, Issue 8
>
> Send OmniOS-discuss mailing list submissions to
> 	omnios-discuss at lists.omniti.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.omniti.com/mailman/listinfo/omnios-discuss
> or, via email, send a message with subject or body 'help' to
> 	omnios-discuss-request at lists.omniti.com
>
> You can reach the person managing the list at
> 	omnios-discuss-owner at lists.omniti.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OmniOS-discuss digest..."
>
>
> Today's Topics:
>
>    1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
>    2. Re: announcement znapzend a new zfs backup tool
>       (Theo Schlossnagle)
>    3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
>    4. Re: Slow scrub performance (wuffers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> From: Tobias Oetiker <tobi at oetiker.ch>
> To: omnios-discuss at lists.omniti.com
> Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Just out:
>
>  ZnapZend a Multilevel Backuptool for ZFS
>
> It is on Github. Check out
>
>  http://www.znapzend.org
>
> cheers
> tobi
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902


From filip.marvan at aira.cz  Mon Aug 11 13:43:07 2014
From: filip.marvan at aira.cz (Filip Marvan)
Date: Mon, 11 Aug 2014 15:43:07 +0200
Subject: [OmniOS-discuss] More detailed logs
Message-ID: <3BE0DEED8863E5429BAE4CAEDF624565036504804F59@AIRA-SRV.aira.local>

Hello,

 

is there any way, how to get more detailed logs on OmniOS server? 

Time to time we have some problems with short disconnection of iSCSI disks
and there is no any information about that on our Storage server with OmniOS
installed (and we know, that there is some problem on storage server,
because disconnection are on multiple client servers at the same time).

 

There is nothing in /var/log/syslog or /var/adm/messages or even
/var/svc/log/*    (network-iscsi-target:default.log for example).
Informations in that log files are useless. 

Is there any way, how to change that? How to get some informations if iscsi
target have some problem?

 

Thank you very much for any help.

 

Filip Marvan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140811/a2c1601f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6247 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140811/a2c1601f/attachment.bin>

From bfriesen at simple.dallas.tx.us  Mon Aug 11 14:06:15 2014
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Mon, 11 Aug 2014 09:06:15 -0500 (CDT)
Subject: [OmniOS-discuss] More detailed logs
In-Reply-To: <3BE0DEED8863E5429BAE4CAEDF624565036504804F59@AIRA-SRV.aira.local>
References: <3BE0DEED8863E5429BAE4CAEDF624565036504804F59@AIRA-SRV.aira.local>
Message-ID: <alpine.GSO.2.01.1408110903450.18732@freddy.simplesystems.org>

On Mon, 11 Aug 2014, Filip Marvan wrote:
> 
> There is nothing in /var/log/syslog or /var/adm/messages or even /var/svc/log/*???
> (network-iscsi-target:default.log for example). Informations in that log files are useless.
> 
> Is there any way, how to change that? How to get some informations if iscsi target have some problem?

Try 'fmdump -v' and 'fmdump -ev'.  Detailed fault information is sent 
to the fault manager, which maintains a detailed history.

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

From filip.marvan at aira.cz  Mon Aug 11 14:34:17 2014
From: filip.marvan at aira.cz (Filip Marvan)
Date: Mon, 11 Aug 2014 16:34:17 +0200
Subject: [OmniOS-discuss] More detailed logs
In-Reply-To: <alpine.GSO.2.01.1408110903450.18732@freddy.simplesystems.org>
References: <3BE0DEED8863E5429BAE4CAEDF624565036504804F59@AIRA-SRV.aira.local>
	<alpine.GSO.2.01.1408110903450.18732@freddy.simplesystems.org>
Message-ID: <3BE0DEED8863E5429BAE4CAEDF624565036504804F6A@AIRA-SRV.aira.local>

Hello,

that is much better, thank you!

Filip


-----Original Message-----
From: Bob Friesenhahn [mailto:bfriesen at simple.dallas.tx.us] 
Sent: Monday, August 11, 2014 4:06 PM
To: Filip Marvan
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] More detailed logs

On Mon, 11 Aug 2014, Filip Marvan wrote:
> 
> There is nothing in /var/log/syslog or /var/adm/messages or even 
> /var/svc/log/* (network-iscsi-target:default.log for example).
Informations in that log files are useless.
> 
> Is there any way, how to change that? How to get some informations if
iscsi target have some problem?

Try 'fmdump -v' and 'fmdump -ev'.  Detailed fault information is sent to the
fault manager, which maintains a detailed history.

Bob
--
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6247 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140811/5305f380/attachment-0001.bin>

From rafibeyli at gmail.com  Mon Aug 11 15:16:32 2014
From: rafibeyli at gmail.com (Hafiz Rafibeyli)
Date: Mon, 11 Aug 2014 18:16:32 +0300 (EEST)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <alpine.DEB.2.02.1408111040150.11611@froburg.oetiker.ch>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
	<alpine.DEB.2.02.1408111040150.11611@froburg.oetiker.ch>
Message-ID: <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr>

Thanks for quick answer Tobi,

could you please share info about  znapsend via mbuffer only(without ssh) syntax?


is this something like this?

znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer \
       --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
SRC '7d=>1h,30d=>4h,90d=>1d' tank/home \
DST:a '7d=>1h,30d=>4h,90d=>1d,1y=>1w,10y=>1month' -O 10.0.0.1:9090


----- Original Message -----
From: "Tobias Oetiker" <tobi at oetiker.ch>
To: "Hafiz Rafibeyli" <rafibeyli at gmail.com>
Cc: omnios-discuss at lists.omniti.com
Sent: Monday, 11 August, 2014 11:44:21 AM
Subject: Re: [OmniOS-discuss] announcement znapzend

Hi Hafiz,

Today Hafiz Rafibeyli wrote:

> Tobias thank you for great job,it was missing backup  part for zfs on omnios,
>
> I think ssh will slow for bigger datasets,as you mention znapzend 0.11 supporting use of mbuffer.
>
> I could not find mbuffer package for omnios,could you explain how to setup/use mbuffer on omnios please?

mbuffer is in the omniti repo

# pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
# pkg install mbuffer

cheers
tobi

>
> regards
>
>
>
> ----- Original Message -----
> From: omnios-discuss-request at lists.omniti.com
> To: omnios-discuss at lists.omniti.com
> Sent: Tuesday, 29 July, 2014 10:29:42 PM
> Subject: OmniOS-discuss Digest, Vol 28, Issue 8
>
> Send OmniOS-discuss mailing list submissions to
> 	omnios-discuss at lists.omniti.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.omniti.com/mailman/listinfo/omnios-discuss
> or, via email, send a message with subject or body 'help' to
> 	omnios-discuss-request at lists.omniti.com
>
> You can reach the person managing the list at
> 	omnios-discuss-owner at lists.omniti.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OmniOS-discuss digest..."
>
>
> Today's Topics:
>
>    1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
>    2. Re: announcement znapzend a new zfs backup tool
>       (Theo Schlossnagle)
>    3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
>    4. Re: Slow scrub performance (wuffers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> From: Tobias Oetiker <tobi at oetiker.ch>
> To: omnios-discuss at lists.omniti.com
> Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Just out:
>
>  ZnapZend a Multilevel Backuptool for ZFS
>
> It is on Github. Check out
>
>  http://www.znapzend.org
>
> cheers
> tobi
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From brogyi at gmail.com  Mon Aug 11 18:07:17 2014
From: brogyi at gmail.com (=?ISO-8859-2?Q?Brogy=E1nyi_J=F3zsef?=)
Date: Mon, 11 Aug 2014 20:07:17 +0200
Subject: [OmniOS-discuss] collectd compiling error
Message-ID: <53E90655.1020901@gmail.com>

Hi

I'd like to use collectd but the make command is stuck. I tried with 
gmake too. Is there any idea? Here is the error message:

*** Error code 1
The following command caused the error:
echo "  CC    " libcollectdclient_la-network_buffer.lo;/bin/sh 
../../libtool --silent --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../src    -I../../src/libcollectdclient/collectd -I../../src   
-Wall -Werror -g -O2 -c -o libcollectdclient_la-network_buffer.lo `test 
-f 'network_buffer.c' || echo './'`network_buffer.c
make: Fatal error: Command failed for target 
`libcollectdclient_la-network_buffer.lo'
Current working directory /home/brogyi/collectd-5.4.1/src/libcollectdclient
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory /home/brogyi/collectd-5.4.1/src/libcollectdclient
*** Error code 1
The following command caused the error:
fail= failcom='exit 1'; \
for f in x $MAKEFLAGS; do \
   case $f in \
     *=* | --[!k]*);; \
     *k*) failcom='fail=yes';; \
   esac; \
done; \
dot_seen=no; \
target=`echo all-recursive | sed s/-recursive//`; \
list='libcollectdclient liboconfig'; for subdir in $list; do \
   echo "Making $target in $subdir"; \
   if test "$subdir" = "."; then \
     dot_seen=yes; \
     local_target="$target-am"; \
   else \
     local_target="$target"; \
   fi; \
   (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \
   || eval $failcom; \
done; \
if test "$dot_seen" = "no"; then \
   make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `all-recursive'
Current working directory /home/brogyi/collectd-5.4.1/src
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory /home/brogyi/collectd-5.4.1/src
*** Error code 1
The following command caused the error:
fail= failcom='exit 1'; \
for f in x $MAKEFLAGS; do \
   case $f in \
     *=* | --[!k]*);; \
     *k*) failcom='fail=yes';; \
   esac; \
done; \
dot_seen=no; \
target=`echo all-recursive | sed s/-recursive//`; \
list='libltdl src bindings .'; for subdir in $list; do \
   echo "Making $target in $subdir"; \
   if test "$subdir" = "."; then \
     dot_seen=yes; \
     local_target="$target-am"; \
   else \
     local_target="$target"; \
   fi; \
   (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \
   || eval $failcom; \
done; \
if test "$dot_seen" = "no"; then \
   make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `all-recursive'


From jesus at omniti.com  Mon Aug 11 23:27:55 2014
From: jesus at omniti.com (Theo Schlossnagle)
Date: Mon, 11 Aug 2014 17:27:55 -0600
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
Message-ID: <CACLsAptKLs-BDAwbZqQWWpzfVNcmVx08oce0AT+7979Kq8OJ8w@mail.gmail.com>

OmniOS ships with pipeviewer (pv), if you use pv -s <several megs>, it
would have close to the same effect as using mbuffer.


On Mon, Aug 11, 2014 at 2:06 AM, Hafiz Rafibeyli <rafibeyli at gmail.com>
wrote:

> Tobias thank you for great job,it was missing backup  part for zfs on
> omnios,
>
> I think ssh will slow for bigger datasets,as you mention znapzend 0.11
> supporting use of mbuffer.
>
> I could not find mbuffer package for omnios,could you explain how to
> setup/use mbuffer on omnios please?
>
> regards
>
>
>
> ----- Original Message -----
> From: omnios-discuss-request at lists.omniti.com
> To: omnios-discuss at lists.omniti.com
> Sent: Tuesday, 29 July, 2014 10:29:42 PM
> Subject: OmniOS-discuss Digest, Vol 28, Issue 8
>
> Send OmniOS-discuss mailing list submissions to
>         omnios-discuss at lists.omniti.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.omniti.com/mailman/listinfo/omnios-discuss
> or, via email, send a message with subject or body 'help' to
>         omnios-discuss-request at lists.omniti.com
>
> You can reach the person managing the list at
>         omnios-discuss-owner at lists.omniti.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OmniOS-discuss digest..."
>
>
> Today's Topics:
>
>    1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
>    2. Re: announcement znapzend a new zfs backup tool
>       (Theo Schlossnagle)
>    3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
>    4. Re: Slow scrub performance (wuffers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> From: Tobias Oetiker <tobi at oetiker.ch>
> To: omnios-discuss at lists.omniti.com
> Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Just out:
>
>  ZnapZend a Multilevel Backuptool for ZFS
>
> It is on Github. Check out
>
>  http://www.znapzend.org
>
> cheers
> tobi
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 29 Jul 2014 11:54:07 -0400
> From: Theo Schlossnagle <jesus at omniti.com>
> To: "OmniOS-discuss at lists.omniti.com"
>         <omnios-discuss at lists.omniti.com>
> Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
>         tool
> Message-ID:
>         <
> CACLsAptC_wDb+Stkw2-jZkgp7oQZ4OwEUWG_Nnrm_xkaoOkGRg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Awesome!
>
>
> On Tue, Jul 29, 2014 at 11:50 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
>
> > Just out:
> >
> >  ZnapZend a Multilevel Backuptool for ZFS
> >
> > It is on Github. Check out
> >
> >  http://www.znapzend.org
> >
> > cheers
> > tobi
> >
> > --
> > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> > www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
> >
> > _______________________________________________
> > OmniOS-discuss mailing list
> > OmniOS-discuss at lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >
>
>
>
> --
>
> Theo Schlossnagle
>
> http://omniti.com/is/theo-schlossnagle
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140729/f8adbbf5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 29 Jul 2014 17:59:18 +0200
> From: Saso Kiselkov <skiselkov.ml at gmail.com>
> To: omnios-discuss at lists.omniti.com
> Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
>         tool
> Message-ID: <53D7C4D6.5060308 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 7/29/14, 5:50 PM, Tobias Oetiker wrote:
> > Just out:
> >
> >  ZnapZend a Multilevel Backuptool for ZFS
> >
> > It is on Github. Check out
> >
> >  http://www.znapzend.org
>
> Neat, especially the feature that the backup config is part of a
> dataset's properties. Very cool.
>
> --
> Saso
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 29 Jul 2014 15:29:38 -0400
> From: wuffers <moo at wuffers.net>
> To: Richard Elling <richard.elling at richardelling.com>
> Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
> Subject: Re: [OmniOS-discuss] Slow scrub performance
> Message-ID:
>         <
> CA+tR_KwX_1HN4tVa+-ZOFJk2mN7RE-nFh31sMcTNo7TJJjfyLg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Going to try to answer both responses in one message..
>
> Short answer, yes. ? Keep in mind that
> >
> > 1. a scrub runs in the background (so as not to impact production I/O,
> > this was not always the case and caused serious issues in the past with a
> > pool being unresponsive due to a scrub)
> >
> > 2. a scrub essentially walks the zpool examining every transaction in
> > order (as does a resilver)
> >
> > So the time to complete a scrub depends on how many write transactions
> > since the pool was created (which is generally related to the amount of
> > data but not always). You are limited by the random I/O capability of the
> > disks involved. With VMs I assume this is a file server, so the I/O size
> > will also affect performance.
>
>
> I haven't noticed any slowdowns in our virtual environments, so I guess
> that's a good thing it's so low priority that it doesn't impact workloads.
>
> Run the numbers? you are scanning 24.2TB at about 5.5MB/sec ? 4,613,734
> > seconds or 54 days. And that assumes the same rate for all of the scan.
> The
> > rate will change as other I/O competes for resources.
> >
>
> The number was fluctuating when I started the scrub, and I had seen it go
> as high as 35MB/s at one point. I am certain that our Hyper-V workload has
> increased since the last scrub, so this does make sense.
>
>
> > Looks like you have a fair bit of activity going on (almost 1MB/sec of
> > writes per spindle).
> >
>
> As Richard correctly states below, this is the aggregate since boot (uptime
> ~56 days). I have another output from iostat as per his instructions below.
>
>
> > Since this is storage for VMs, I assume this is the storage server for
> > separate compute servers? Have you tuned the block size for the file
> share
> > you are using? That can make a huge difference in performance.
> >
>
> Both the Hyper-V and VMware LUNs are created with 64K block sizes. From
> what I've read of other performance and tuning articles, that is the
> optimal block size (I did some limited testing when first configuring the
> SAN, but results were somewhat inconclusive). Hyper-V hosts our testing
> environment (we integrate with TFS, a MS product, so we have no choice
> here) and probably make up the bulk of the workload (~300+ test VMs with
> various OSes). VMware hosts our production servers (Exchange, file servers,
> SQL, AD, etc - ~50+ VMs).
>
> I also noted that you only have a single LOG device. Best Practice is to
> > mirror log devices so you do not lose any data in flight if hit by a
> power
> > outage (of course, if this server has more UPS runtime that all the
> clients
> > that may not matter).
> >
>
> Actually, I do have a mirror ZIL device, it's just disabled at this time
> (my ZIL devices are ZeusRAMs). At some point, I was troubleshooting some
> kernel panics (turned out to be a faulty SSD on the rpool), and hadn't
> re-enabled it yet. Thanks for the reminder (and yes, we do have a UPS as
> well).
>
> And oops.. re-attaching the ZIL as a mirror triggered a resilver now,
> suspending or canceling the scrub? Will monitor this and restart the scrub
> if it doesn't by itself.
>
>   pool: tank
>  state: ONLINE
> status: One or more devices is currently being resilvered.  The pool will
>         continue to function, possibly in a degraded state.
> action: Wait for the resilver to complete.
>   scan: resilver in progress since Tue Jul 29 14:48:48 2014
>     3.89T scanned out of 24.5T at 3.06G/s, 1h55m to go
>     0 resilvered, 15.84% done
>
> At least it's going very fast. EDIT: Now about 67% done as I finish writing
> this, speed dropping to ~1.3G/s.
>
> maybe, maybe not
> >>
> >> this is slower than most, surely slower than desired
> >>
> >
> Unfortunately reattaching the mirror to my log device triggered a resilver.
> Not sure if this is desired behavior, but yes, 5.5MB/s seems quite slow.
> Hopefully after the resilver the scrub will progress where it left off.
>
>
> > The estimate is often very wrong, especially for busy systems.
> >> If this is an older ZFS implementation, this pool is likely getting
> >> pounded by the
> >> ZFS write throttle. There are some tunings that can be applied, but the
> >> old write
> >> throttle is not a stable control system, so it will always be a little
> >> bit unpredictable.
> >>
> >
> The system is on r151008 (my BE states that I upgraded back in February,
> putting me in r151008j or so), with all the pools upgraded for the new
> enhancements as well as activating the new L2ARC compression feature.
> Reading the release notes, the ZFS write throttle enhancements were in
> since r151008e so I should be good there.
>
>
> > # iostat -xnze
> >>
> >>
> >> Unfortunately, this is the performance since boot and is not suitable
> for
> >> performance
> >> analysis unless the system has been rebooted in the past 10 minutes or
> >> so. You'll need
> >> to post the second batch from "iostat -zxCn 60 2"
> >>
> >
> Ah yes, that was my mistake. Output from second count (before re-attaching
> log mirror):
>
> # iostat -zxCn 60 2
>
>                     extended device statistics
>     r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
>   255.7 1077.7 6294.0 41335.1  0.0  1.9    0.0    1.4   0 153 c1
>     5.3   23.9  118.5  811.9  0.0  0.0    0.0    1.1   0   3
> c1t5000C50055F8723Bd0
>     5.9   14.5  110.0  834.3  0.0  0.0    0.0    1.3   0   2
> c1t5000C50055E66B63d0
>     5.6   16.6  123.8  822.7  0.0  0.0    0.0    1.3   0   2
> c1t5000C50055F87E73d0
>     4.7   27.8  118.6  796.6  0.0  0.0    0.0    1.3   0   3
> c1t5000C50055F8BFA3d0
>     5.6   14.5  139.7  833.8  0.0  0.0    0.0    1.6   0   3
> c1t5000C50055F9E123d0
>     4.4   27.1  112.3  825.2  0.0  0.0    0.0    0.8   0   2
> c1t5000C50055F9F0B3d0
>     5.0   20.2  121.7  803.4  0.0  0.0    0.0    1.2   0   3
> c1t5000C50055F9D3B3d0
>     5.4   26.4  137.0  857.3  0.0  0.0    0.0    1.4   0   4
> c1t5000C50055E4FDE7d0
>     4.7   12.3  123.7  832.7  0.0  0.0    0.0    2.0   0   3
> c1t5000C50055F9A607d0
>     5.0   23.9  125.9  830.9  0.0  0.0    0.0    1.3   0   3
> c1t5000C50055F8CDA7d0
>     4.5   31.4  112.2  814.6  0.0  0.0    0.0    1.1   0   3
> c1t5000C50055E65877d0
>     5.2   24.4  130.6  872.5  0.0  0.0    0.0    1.2   0   3
> c1t5000C50055F9E7D7d0
>     4.1   21.8  103.7  797.2  0.0  0.0    0.0    1.1   0   3
> c1t5000C50055FA0AF7d0
>     5.5   24.8  129.8  802.8  0.0  0.0    0.0    1.5   0   4
> c1t5000C50055F9FE87d0
>     5.7   17.7  137.2  797.6  0.0  0.0    0.0    1.4   0   3
> c1t5000C50055F9F91Bd0
>     6.0   30.6  139.1  852.0  0.0  0.1    0.0    1.5   0   4
> c1t5000C50055F9FEABd0
>     6.1   34.1  137.8  929.2  0.0  0.1    0.0    1.9   0   6
> c1t5000C50055F9F63Bd0
>     4.1   15.9  101.8  791.4  0.0  0.0    0.0    1.6   0   3
> c1t5000C50055F9F3EBd0
>     6.4   23.2  155.2  878.6  0.0  0.0    0.0    1.1   0   3
> c1t5000C50055F9F80Bd0
>     4.5   23.5  106.2  825.4  0.0  0.0    0.0    1.1   0   3
> c1t5000C50055F9FB8Bd0
>     4.0   23.2  101.1  788.9  0.0  0.0    0.0    1.3   0   3
> c1t5000C50055F9F92Bd0
>     4.4   11.3  125.7  782.3  0.0  0.0    0.0    1.9   0   3
> c1t5000C50055F8905Fd0
>     4.6   20.4  129.2  823.0  0.0  0.0    0.0    1.5   0   3
> c1t5000C50055F8D48Fd0
>     5.1   19.7  142.9  887.2  0.0  0.0    0.0    1.7   0   3
> c1t5000C50055F9F89Fd0
>     5.6   11.4  129.1  776.0  0.0  0.0    0.0    1.9   0   3
> c1t5000C50055F9EF2Fd0
>     5.6   23.7  137.4  811.9  0.0  0.0    0.0    1.2   0   3
> c1t5000C50055F8C3ABd0
>     6.8   13.9  132.4  834.3  0.0  0.0    0.0    1.8   0   3
> c1t5000C50055E66053d0
>     5.2   26.7  126.9  857.3  0.0  0.0    0.0    1.2   0   3
> c1t5000C50055E66503d0
>     4.2   27.1  104.6  825.2  0.0  0.0    0.0    1.0   0   3
> c1t5000C50055F9D3E3d0
>     5.2   30.7  140.9  852.0  0.0  0.1    0.0    1.5   0   4
> c1t5000C50055F84FB7d0
>     5.4   16.1  124.3  791.4  0.0  0.0    0.0    1.7   0   3
> c1t5000C50055F8E017d0
>     3.8   31.4   89.7  814.6  0.0  0.0    0.0    1.1   0   4
> c1t5000C50055E579F7d0
>     4.6   27.5  116.0  796.6  0.0  0.1    0.0    1.6   0   4
> c1t5000C50055E65807d0
>     4.0   21.5   99.7  797.2  0.0  0.0    0.0    1.1   0   3
> c1t5000C50055F84A97d0
>     4.7   20.2  116.3  803.4  0.0  0.0    0.0    1.4   0   3
> c1t5000C50055F87D97d0
>     5.0   11.5  121.5  776.0  0.0  0.0    0.0    2.0   0   3
> c1t5000C50055F9F637d0
>     4.9   11.3  112.4  782.3  0.0  0.0    0.0    2.3   0   3
> c1t5000C50055E65ABBd0
>     5.3   11.8  142.5  832.7  0.0  0.0    0.0    2.4   0   3
> c1t5000C50055F8BF9Bd0
>     5.0   20.3  121.4  823.0  0.0  0.0    0.0    1.7   0   3
> c1t5000C50055F8A22Bd0
>     6.6   24.3  170.3  872.5  0.0  0.0    0.0    1.3   0   3
> c1t5000C50055F9379Bd0
>     5.8   16.3  121.7  822.7  0.0  0.0    0.0    1.3   0   2
> c1t5000C50055E57A5Fd0
>     5.3   17.7  146.5  797.6  0.0  0.0    0.0    1.4   0   3
> c1t5000C50055F8CCAFd0
>     5.7   34.1  141.5  929.2  0.0  0.1    0.0    1.7   0   5
> c1t5000C50055F8B80Fd0
>     5.5   23.8  125.7  830.9  0.0  0.0    0.0    1.2   0   3
> c1t5000C50055F9FA1Fd0
>     5.0   23.2  127.9  878.6  0.0  0.0    0.0    1.1   0   3
> c1t5000C50055E65F0Fd0
>     5.2   14.0  163.7  833.8  0.0  0.0    0.0    2.0   0   3
> c1t5000C50055F8BE3Fd0
>     4.6   18.9  122.8  887.2  0.0  0.0    0.0    1.6   0   3
> c1t5000C50055F8B21Fd0
>     5.5   23.6  137.4  825.4  0.0  0.0    0.0    1.5   0   3
> c1t5000C50055F8A46Fd0
>     4.9   24.6  116.7  802.8  0.0  0.0    0.0    1.4   0   4
> c1t5000C50055F856CFd0
>     4.9   23.4  120.8  788.9  0.0  0.0    0.0    1.4   0   3
> c1t5000C50055E6606Fd0
>   234.9  170.1 4079.9 11127.8  0.0  0.2    0.0    0.5   0   9 c2
>   119.0   28.9 2083.8  670.8  0.0  0.0    0.0    0.3   0   3
> c2t500117310015D579d0
>   115.9   27.4 1996.1  634.2  0.0  0.0    0.0    0.3   0   3
> c2t50011731001631FDd0
>     0.0  113.8    0.0 9822.8  0.0  0.1    0.0    1.0   0   2
> c2t5000A72A3007811Dd0
>     0.1   18.5    0.0   64.8  0.0  0.0    0.0    0.0   0   0 c4
>     0.1    9.2    0.0   32.4  0.0  0.0    0.0    0.0   0   0 c4t0d0
>     0.0    9.2    0.0   32.4  0.0  0.0    0.0    0.0   0   0 c4t1d0
>   229.8   58.1 3987.4 1308.0  0.0  0.1    0.0    0.3   0   6 c12
>   114.2   27.7 1994.8  626.0  0.0  0.0    0.0    0.3   0   3
> c12t500117310015D59Ed0
>   115.5   30.4 1992.6  682.0  0.0  0.0    0.0    0.3   0   3
> c12t500117310015D54Ed0
>     0.1   17.1    0.0   64.8  0.0  0.0    0.6    0.1   0   0 rpool
>   720.3 1298.4 14361.2 53770.8 18.7  2.3    9.3    1.1   6  68 tank
>
> Is 153% busy correct on c1? Seems to me that disks are quite "busy", but
> are handling the workload just fine (wait at 6% and asvc_t at 1.1ms)
>
> Interestingly, this is the same output now that the resilver is running:
>
>                     extended device statistics
>     r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
>  2876.9 1041.1 25400.7 38189.1  0.0 37.9    0.0    9.7   0 2011 c1
>    60.8   26.1  540.1  845.2  0.0  0.7    0.0    8.3   0  39
> c1t5000C50055F8723Bd0
>    58.4   14.2  511.6  740.7  0.0  0.7    0.0   10.1   0  39
> c1t5000C50055E66B63d0
>    60.2   16.3  529.3  756.1  0.0  0.8    0.0   10.1   0  41
> c1t5000C50055F87E73d0
>    57.5   24.9  527.6  841.7  0.0  0.7    0.0    9.0   0  40
> c1t5000C50055F8BFA3d0
>    57.9   14.5  543.5  765.1  0.0  0.7    0.0    9.8   0  38
> c1t5000C50055F9E123d0
>    57.9   23.9  516.6  806.9  0.0  0.8    0.0    9.3   0  40
> c1t5000C50055F9F0B3d0
>    59.8   24.6  554.1  857.5  0.0  0.8    0.0    9.6   0  42
> c1t5000C50055F9D3B3d0
>    56.5   21.0  480.4  715.7  0.0  0.7    0.0    8.9   0  37
> c1t5000C50055E4FDE7d0
>    54.8    9.7  473.5  737.9  0.0  0.7    0.0   11.2   0  39
> c1t5000C50055F9A607d0
>    55.8   20.2  457.3  708.7  0.0  0.7    0.0    9.9   0  40
> c1t5000C50055F8CDA7d0
>    57.8   28.6  487.0  796.1  0.0  0.9    0.0    9.9   0  45
> c1t5000C50055E65877d0
>    60.8   27.1  572.6  823.7  0.0  0.8    0.0    8.8   0  41
> c1t5000C50055F9E7D7d0
>    55.8   21.1  478.2  766.6  0.0  0.7    0.0    9.7   0  40
> c1t5000C50055FA0AF7d0
>    57.0   22.8  528.3  724.5  0.0  0.8    0.0    9.6   0  41
> c1t5000C50055F9FE87d0
>    56.2   10.8  465.2  715.6  0.0  0.7    0.0   10.4   0  38
> c1t5000C50055F9F91Bd0
>    59.2   29.4  524.6  740.9  0.0  0.8    0.0    8.9   0  41
> c1t5000C50055F9FEABd0
>    57.3   30.7  496.7  788.3  0.0  0.8    0.0    9.1   0  42
> c1t5000C50055F9F63Bd0
>    55.5   16.3  461.9  652.9  0.0  0.7    0.0   10.1   0  39
> c1t5000C50055F9F3EBd0
>    57.2   22.1  495.1  701.1  0.0  0.8    0.0    9.8   0  41
> c1t5000C50055F9F80Bd0
>    59.5   30.2  543.1  741.8  0.0  0.9    0.0    9.6   0  45
> c1t5000C50055F9FB8Bd0
>    56.5   25.1  515.4  786.9  0.0  0.7    0.0    8.6   0  38
> c1t5000C50055F9F92Bd0
>    61.8   12.5  540.6  790.9  0.0  0.8    0.0   10.3   0  41
> c1t5000C50055F8905Fd0
>    57.0   19.8  521.0  774.3  0.0  0.7    0.0    9.6   0  39
> c1t5000C50055F8D48Fd0
>    56.3   16.3  517.7  724.7  0.0  0.7    0.0    9.9   0  38
> c1t5000C50055F9F89Fd0
>    57.0   13.4  504.5  790.5  0.0  0.8    0.0   10.7   0  40
> c1t5000C50055F9EF2Fd0
>    55.0   26.1  477.6  845.2  0.0  0.7    0.0    8.3   0  36
> c1t5000C50055F8C3ABd0
>    57.8   14.1  518.7  740.7  0.0  0.8    0.0   10.8   0  41
> c1t5000C50055E66053d0
>    55.9   20.8  490.2  715.7  0.0  0.7    0.0    9.0   0  37
> c1t5000C50055E66503d0
>    57.0   24.1  509.7  806.9  0.0  0.8    0.0   10.0   0  41
> c1t5000C50055F9D3E3d0
>    59.1   29.2  504.1  740.9  0.0  0.8    0.0    9.3   0  44
> c1t5000C50055F84FB7d0
>    54.4   16.3  449.5  652.9  0.0  0.7    0.0   10.4   0  39
> c1t5000C50055F8E017d0
>    57.8   28.4  503.3  796.1  0.0  0.9    0.0   10.1   0  45
> c1t5000C50055E579F7d0
>    58.2   24.9  502.0  841.7  0.0  0.8    0.0    9.2   0  40
> c1t5000C50055E65807d0
>    58.2   20.7  513.4  766.6  0.0  0.8    0.0    9.8   0  41
> c1t5000C50055F84A97d0
>    56.5   24.9  508.0  857.5  0.0  0.8    0.0    9.2   0  40
> c1t5000C50055F87D97d0
>    53.4   13.5  449.9  790.5  0.0  0.7    0.0   10.7   0  38
> c1t5000C50055F9F637d0
>    57.0   11.8  503.0  790.9  0.0  0.7    0.0   10.6   0  39
> c1t5000C50055E65ABBd0
>    55.4    9.6  461.1  737.9  0.0  0.8    0.0   11.6   0  40
> c1t5000C50055F8BF9Bd0
>    55.7   19.7  484.6  774.3  0.0  0.7    0.0    9.9   0  40
> c1t5000C50055F8A22Bd0
>    57.6   27.1  518.2  823.7  0.0  0.8    0.0    8.9   0  40
> c1t5000C50055F9379Bd0
>    59.6   17.0  528.0  756.1  0.0  0.8    0.0   10.1   0  41
> c1t5000C50055E57A5Fd0
>    61.2   10.8  530.0  715.6  0.0  0.8    0.0   10.7   0  40
> c1t5000C50055F8CCAFd0
>    58.0   30.8  493.3  788.3  0.0  0.8    0.0    9.4   0  43
> c1t5000C50055F8B80Fd0
>    56.5   19.9  490.7  708.7  0.0  0.8    0.0   10.0   0  40
> c1t5000C50055F9FA1Fd0
>    56.1   22.4  484.2  701.1  0.0  0.7    0.0    9.5   0  39
> c1t5000C50055E65F0Fd0
>    59.2   14.6  560.9  765.1  0.0  0.7    0.0    9.8   0  39
> c1t5000C50055F8BE3Fd0
>    57.9   16.2  546.0  724.7  0.0  0.7    0.0   10.1   0  40
> c1t5000C50055F8B21Fd0
>    59.5   30.0  553.2  741.8  0.0  0.9    0.0    9.8   0  45
> c1t5000C50055F8A46Fd0
>    57.4   22.5  504.0  724.5  0.0  0.8    0.0    9.6   0  41
> c1t5000C50055F856CFd0
>    58.4   24.6  531.4  786.9  0.0  0.7    0.0    8.4   0  38
> c1t5000C50055E6606Fd0
>   511.0  161.4 7572.1 11260.1  0.0  0.3    0.0    0.4   0  14 c2
>   252.3   20.1 3776.3  458.9  0.0  0.1    0.0    0.2   0   6
> c2t500117310015D579d0
>   258.8   18.0 3795.7  350.0  0.0  0.1    0.0    0.2   0   6
> c2t50011731001631FDd0
>     0.0  123.4    0.0 10451.1  0.0  0.1    0.0    1.0   0   3
> c2t5000A72A3007811Dd0
>     0.2   16.1    1.9   56.7  0.0  0.0    0.0    0.0   0   0 c4
>     0.2    8.1    1.6   28.3  0.0  0.0    0.0    0.0   0   0 c4t0d0
>     0.0    8.1    0.3   28.3  0.0  0.0    0.0    0.0   0   0 c4t1d0
>   495.6  163.6 7168.9 11290.3  0.0  0.2    0.0    0.4   0  14 c12
>     0.0  123.4    0.0 10451.1  0.0  0.1    0.0    1.0   0   3
> c12t5000A72B300780FFd0
>   248.2   18.1 3645.8  323.0  0.0  0.1    0.0    0.2   0   5
> c12t500117310015D59Ed0
>   247.4   22.1 3523.1  516.2  0.0  0.1    0.0    0.2   0   6
> c12t500117310015D54Ed0
>     0.2   14.8    1.9   56.7  0.0  0.0    0.6    0.1   0   0 rpool
>  3883.5 1357.7 40141.6 60739.5 22.8 38.6    4.4    7.4  54 100 tank
>
> It is very busy with alot of wait % and higher asvc_t (2011% busy on c1?!).
> I'm assuming resilvers are alot more aggressive than scrubs.
>
> There are many variables here, the biggest of which is the current
> >> non-scrub load.
> >>
> >
> I might have lost 2 weeks of scrub time, depending on whether the scrub
> will resume where it left off. I'll update when I can.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140729/1b53a492/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
> ------------------------------
>
> End of OmniOS-discuss Digest, Vol 28, Issue 8
> *********************************************
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 

Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140811/7e6d7951/attachment-0001.html>

From cks at cs.toronto.edu  Tue Aug 12 03:49:22 2014
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Mon, 11 Aug 2014 23:49:22 -0400
Subject: [OmniOS-discuss] Getting detailed NFS lock information on an OmniOS
	NFS server
Message-ID: <20140812034922.2F6075A00A8@testapps.cs.toronto.edu>

 Here's a question: does anyone know of a good way to get detailed NFS
lock information on an OmniOS NFS server, especially information like
which client has a lock on a particular file?

 'mdb -k' can be used to extract basic lock information, like the full
paths of all files that have active locks against them[*], but my old
Solaris mdb commands for getting more detailed NFS information don't
work in the OmniOS mdb any more.

 Thanks in advance.

(I'll happily take pointers to where to look in the kernel implementation
to follow struct pointers by hand with mdb's ::print and so on. From what
I've found so far, I'm looking at usr/src/uts/common/klm to start with; is
this right?)

	- cks
[*: via mdb's ::lminfo and '::walk lock_graph', see eg
    http://utcc.utoronto.ca/~cks/space/blog/solaris/ListingFileLocks

    Solaris 10 also had ::nlm_lockson, which is still present in mdb
    but doesn't seem to work any more, presumably because the actual
    NFS locking implementation changed.
]

From tobi at oetiker.ch  Tue Aug 12 05:54:08 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 12 Aug 2014 07:54:08 +0200 (CEST)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <CACLsAptKLs-BDAwbZqQWWpzfVNcmVx08oce0AT+7979Kq8OJ8w@mail.gmail.com>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
	<CACLsAptKLs-BDAwbZqQWWpzfVNcmVx08oce0AT+7979Kq8OJ8w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1408120752090.11611@froburg.oetiker.ch>

Hi Theo,

znapzend can use mbuffers ability to do a direct tcp connection to another
mbuffer instance ...

didn't know about pv though ... neat tool!

cheers
tobi

http://www.znapzend.org

Yesterday Theo Schlossnagle wrote:

> OmniOS ships with pipeviewer (pv), if you use pv -s <several megs>, it
> would have close to the same effect as using mbuffer.
>
>
> On Mon, Aug 11, 2014 at 2:06 AM, Hafiz Rafibeyli <rafibeyli at gmail.com>
> wrote:
>
> > Tobias thank you for great job,it was missing backup  part for zfs on
> > omnios,
> >
> > I think ssh will slow for bigger datasets,as you mention znapzend 0.11
> > supporting use of mbuffer.
> >
> > I could not find mbuffer package for omnios,could you explain how to
> > setup/use mbuffer on omnios please?
> >
> > regards
> >
> >
> >
> > ----- Original Message -----
> > From: omnios-discuss-request at lists.omniti.com
> > To: omnios-discuss at lists.omniti.com
> > Sent: Tuesday, 29 July, 2014 10:29:42 PM
> > Subject: OmniOS-discuss Digest, Vol 28, Issue 8
> >
> > Send OmniOS-discuss mailing list submissions to
> >         omnios-discuss at lists.omniti.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         http://lists.omniti.com/mailman/listinfo/omnios-discuss
> > or, via email, send a message with subject or body 'help' to
> >         omnios-discuss-request at lists.omniti.com
> >
> > You can reach the person managing the list at
> >         omnios-discuss-owner at lists.omniti.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of OmniOS-discuss digest..."
> >
> >
> > Today's Topics:
> >
> >    1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
> >    2. Re: announcement znapzend a new zfs backup tool
> >       (Theo Schlossnagle)
> >    3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
> >    4. Re: Slow scrub performance (wuffers)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> > From: Tobias Oetiker <tobi at oetiker.ch>
> > To: omnios-discuss at lists.omniti.com
> > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> > Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > Just out:
> >
> >  ZnapZend a Multilevel Backuptool for ZFS
> >
> > It is on Github. Check out
> >
> >  http://www.znapzend.org
> >
> > cheers
> > tobi
> >
> > --
> > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> > www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 29 Jul 2014 11:54:07 -0400
> > From: Theo Schlossnagle <jesus at omniti.com>
> > To: "OmniOS-discuss at lists.omniti.com"
> >         <omnios-discuss at lists.omniti.com>
> > Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
> >         tool
> > Message-ID:
> >         <
> > CACLsAptC_wDb+Stkw2-jZkgp7oQZ4OwEUWG_Nnrm_xkaoOkGRg at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Awesome!
> >
> >
> > On Tue, Jul 29, 2014 at 11:50 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> >
> > > Just out:
> > >
> > >  ZnapZend a Multilevel Backuptool for ZFS
> > >
> > > It is on Github. Check out
> > >
> > >  http://www.znapzend.org
> > >
> > > cheers
> > > tobi
> > >
> > > --
> > > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> > > www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
> > >
> > > _______________________________________________
> > > OmniOS-discuss mailing list
> > > OmniOS-discuss at lists.omniti.com
> > > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> > >
> >
> >
> >
> > --
> >
> > Theo Schlossnagle
> >
> > http://omniti.com/is/theo-schlossnagle
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140729/f8adbbf5/attachment-0001.html
> > >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 29 Jul 2014 17:59:18 +0200
> > From: Saso Kiselkov <skiselkov.ml at gmail.com>
> > To: omnios-discuss at lists.omniti.com
> > Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
> >         tool
> > Message-ID: <53D7C4D6.5060308 at gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On 7/29/14, 5:50 PM, Tobias Oetiker wrote:
> > > Just out:
> > >
> > >  ZnapZend a Multilevel Backuptool for ZFS
> > >
> > > It is on Github. Check out
> > >
> > >  http://www.znapzend.org
> >
> > Neat, especially the feature that the backup config is part of a
> > dataset's properties. Very cool.
> >
> > --
> > Saso
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 29 Jul 2014 15:29:38 -0400
> > From: wuffers <moo at wuffers.net>
> > To: Richard Elling <richard.elling at richardelling.com>
> > Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
> > Subject: Re: [OmniOS-discuss] Slow scrub performance
> > Message-ID:
> >         <
> > CA+tR_KwX_1HN4tVa+-ZOFJk2mN7RE-nFh31sMcTNo7TJJjfyLg at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Going to try to answer both responses in one message..
> >
> > Short answer, yes. ? Keep in mind that
> > >
> > > 1. a scrub runs in the background (so as not to impact production I/O,
> > > this was not always the case and caused serious issues in the past with a
> > > pool being unresponsive due to a scrub)
> > >
> > > 2. a scrub essentially walks the zpool examining every transaction in
> > > order (as does a resilver)
> > >
> > > So the time to complete a scrub depends on how many write transactions
> > > since the pool was created (which is generally related to the amount of
> > > data but not always). You are limited by the random I/O capability of the
> > > disks involved. With VMs I assume this is a file server, so the I/O size
> > > will also affect performance.
> >
> >
> > I haven't noticed any slowdowns in our virtual environments, so I guess
> > that's a good thing it's so low priority that it doesn't impact workloads.
> >
> > Run the numbers? you are scanning 24.2TB at about 5.5MB/sec ? 4,613,734
> > > seconds or 54 days. And that assumes the same rate for all of the scan.
> > The
> > > rate will change as other I/O competes for resources.
> > >
> >
> > The number was fluctuating when I started the scrub, and I had seen it go
> > as high as 35MB/s at one point. I am certain that our Hyper-V workload has
> > increased since the last scrub, so this does make sense.
> >
> >
> > > Looks like you have a fair bit of activity going on (almost 1MB/sec of
> > > writes per spindle).
> > >
> >
> > As Richard correctly states below, this is the aggregate since boot (uptime
> > ~56 days). I have another output from iostat as per his instructions below.
> >
> >
> > > Since this is storage for VMs, I assume this is the storage server for
> > > separate compute servers? Have you tuned the block size for the file
> > share
> > > you are using? That can make a huge difference in performance.
> > >
> >
> > Both the Hyper-V and VMware LUNs are created with 64K block sizes. From
> > what I've read of other performance and tuning articles, that is the
> > optimal block size (I did some limited testing when first configuring the
> > SAN, but results were somewhat inconclusive). Hyper-V hosts our testing
> > environment (we integrate with TFS, a MS product, so we have no choice
> > here) and probably make up the bulk of the workload (~300+ test VMs with
> > various OSes). VMware hosts our production servers (Exchange, file servers,
> > SQL, AD, etc - ~50+ VMs).
> >
> > I also noted that you only have a single LOG device. Best Practice is to
> > > mirror log devices so you do not lose any data in flight if hit by a
> > power
> > > outage (of course, if this server has more UPS runtime that all the
> > clients
> > > that may not matter).
> > >
> >
> > Actually, I do have a mirror ZIL device, it's just disabled at this time
> > (my ZIL devices are ZeusRAMs). At some point, I was troubleshooting some
> > kernel panics (turned out to be a faulty SSD on the rpool), and hadn't
> > re-enabled it yet. Thanks for the reminder (and yes, we do have a UPS as
> > well).
> >
> > And oops.. re-attaching the ZIL as a mirror triggered a resilver now,
> > suspending or canceling the scrub? Will monitor this and restart the scrub
> > if it doesn't by itself.
> >
> >   pool: tank
> >  state: ONLINE
> > status: One or more devices is currently being resilvered.  The pool will
> >         continue to function, possibly in a degraded state.
> > action: Wait for the resilver to complete.
> >   scan: resilver in progress since Tue Jul 29 14:48:48 2014
> >     3.89T scanned out of 24.5T at 3.06G/s, 1h55m to go
> >     0 resilvered, 15.84% done
> >
> > At least it's going very fast. EDIT: Now about 67% done as I finish writing
> > this, speed dropping to ~1.3G/s.
> >
> > maybe, maybe not
> > >>
> > >> this is slower than most, surely slower than desired
> > >>
> > >
> > Unfortunately reattaching the mirror to my log device triggered a resilver.
> > Not sure if this is desired behavior, but yes, 5.5MB/s seems quite slow.
> > Hopefully after the resilver the scrub will progress where it left off.
> >
> >
> > > The estimate is often very wrong, especially for busy systems.
> > >> If this is an older ZFS implementation, this pool is likely getting
> > >> pounded by the
> > >> ZFS write throttle. There are some tunings that can be applied, but the
> > >> old write
> > >> throttle is not a stable control system, so it will always be a little
> > >> bit unpredictable.
> > >>
> > >
> > The system is on r151008 (my BE states that I upgraded back in February,
> > putting me in r151008j or so), with all the pools upgraded for the new
> > enhancements as well as activating the new L2ARC compression feature.
> > Reading the release notes, the ZFS write throttle enhancements were in
> > since r151008e so I should be good there.
> >
> >
> > > # iostat -xnze
> > >>
> > >>
> > >> Unfortunately, this is the performance since boot and is not suitable
> > for
> > >> performance
> > >> analysis unless the system has been rebooted in the past 10 minutes or
> > >> so. You'll need
> > >> to post the second batch from "iostat -zxCn 60 2"
> > >>
> > >
> > Ah yes, that was my mistake. Output from second count (before re-attaching
> > log mirror):
> >
> > # iostat -zxCn 60 2
> >
> >                     extended device statistics
> >     r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
> >   255.7 1077.7 6294.0 41335.1  0.0  1.9    0.0    1.4   0 153 c1
> >     5.3   23.9  118.5  811.9  0.0  0.0    0.0    1.1   0   3
> > c1t5000C50055F8723Bd0
> >     5.9   14.5  110.0  834.3  0.0  0.0    0.0    1.3   0   2
> > c1t5000C50055E66B63d0
> >     5.6   16.6  123.8  822.7  0.0  0.0    0.0    1.3   0   2
> > c1t5000C50055F87E73d0
> >     4.7   27.8  118.6  796.6  0.0  0.0    0.0    1.3   0   3
> > c1t5000C50055F8BFA3d0
> >     5.6   14.5  139.7  833.8  0.0  0.0    0.0    1.6   0   3
> > c1t5000C50055F9E123d0
> >     4.4   27.1  112.3  825.2  0.0  0.0    0.0    0.8   0   2
> > c1t5000C50055F9F0B3d0
> >     5.0   20.2  121.7  803.4  0.0  0.0    0.0    1.2   0   3
> > c1t5000C50055F9D3B3d0
> >     5.4   26.4  137.0  857.3  0.0  0.0    0.0    1.4   0   4
> > c1t5000C50055E4FDE7d0
> >     4.7   12.3  123.7  832.7  0.0  0.0    0.0    2.0   0   3
> > c1t5000C50055F9A607d0
> >     5.0   23.9  125.9  830.9  0.0  0.0    0.0    1.3   0   3
> > c1t5000C50055F8CDA7d0
> >     4.5   31.4  112.2  814.6  0.0  0.0    0.0    1.1   0   3
> > c1t5000C50055E65877d0
> >     5.2   24.4  130.6  872.5  0.0  0.0    0.0    1.2   0   3
> > c1t5000C50055F9E7D7d0
> >     4.1   21.8  103.7  797.2  0.0  0.0    0.0    1.1   0   3
> > c1t5000C50055FA0AF7d0
> >     5.5   24.8  129.8  802.8  0.0  0.0    0.0    1.5   0   4
> > c1t5000C50055F9FE87d0
> >     5.7   17.7  137.2  797.6  0.0  0.0    0.0    1.4   0   3
> > c1t5000C50055F9F91Bd0
> >     6.0   30.6  139.1  852.0  0.0  0.1    0.0    1.5   0   4
> > c1t5000C50055F9FEABd0
> >     6.1   34.1  137.8  929.2  0.0  0.1    0.0    1.9   0   6
> > c1t5000C50055F9F63Bd0
> >     4.1   15.9  101.8  791.4  0.0  0.0    0.0    1.6   0   3
> > c1t5000C50055F9F3EBd0
> >     6.4   23.2  155.2  878.6  0.0  0.0    0.0    1.1   0   3
> > c1t5000C50055F9F80Bd0
> >     4.5   23.5  106.2  825.4  0.0  0.0    0.0    1.1   0   3
> > c1t5000C50055F9FB8Bd0
> >     4.0   23.2  101.1  788.9  0.0  0.0    0.0    1.3   0   3
> > c1t5000C50055F9F92Bd0
> >     4.4   11.3  125.7  782.3  0.0  0.0    0.0    1.9   0   3
> > c1t5000C50055F8905Fd0
> >     4.6   20.4  129.2  823.0  0.0  0.0    0.0    1.5   0   3
> > c1t5000C50055F8D48Fd0
> >     5.1   19.7  142.9  887.2  0.0  0.0    0.0    1.7   0   3
> > c1t5000C50055F9F89Fd0
> >     5.6   11.4  129.1  776.0  0.0  0.0    0.0    1.9   0   3
> > c1t5000C50055F9EF2Fd0
> >     5.6   23.7  137.4  811.9  0.0  0.0    0.0    1.2   0   3
> > c1t5000C50055F8C3ABd0
> >     6.8   13.9  132.4  834.3  0.0  0.0    0.0    1.8   0   3
> > c1t5000C50055E66053d0
> >     5.2   26.7  126.9  857.3  0.0  0.0    0.0    1.2   0   3
> > c1t5000C50055E66503d0
> >     4.2   27.1  104.6  825.2  0.0  0.0    0.0    1.0   0   3
> > c1t5000C50055F9D3E3d0
> >     5.2   30.7  140.9  852.0  0.0  0.1    0.0    1.5   0   4
> > c1t5000C50055F84FB7d0
> >     5.4   16.1  124.3  791.4  0.0  0.0    0.0    1.7   0   3
> > c1t5000C50055F8E017d0
> >     3.8   31.4   89.7  814.6  0.0  0.0    0.0    1.1   0   4
> > c1t5000C50055E579F7d0
> >     4.6   27.5  116.0  796.6  0.0  0.1    0.0    1.6   0   4
> > c1t5000C50055E65807d0
> >     4.0   21.5   99.7  797.2  0.0  0.0    0.0    1.1   0   3
> > c1t5000C50055F84A97d0
> >     4.7   20.2  116.3  803.4  0.0  0.0    0.0    1.4   0   3
> > c1t5000C50055F87D97d0
> >     5.0   11.5  121.5  776.0  0.0  0.0    0.0    2.0   0   3
> > c1t5000C50055F9F637d0
> >     4.9   11.3  112.4  782.3  0.0  0.0    0.0    2.3   0   3
> > c1t5000C50055E65ABBd0
> >     5.3   11.8  142.5  832.7  0.0  0.0    0.0    2.4   0   3
> > c1t5000C50055F8BF9Bd0
> >     5.0   20.3  121.4  823.0  0.0  0.0    0.0    1.7   0   3
> > c1t5000C50055F8A22Bd0
> >     6.6   24.3  170.3  872.5  0.0  0.0    0.0    1.3   0   3
> > c1t5000C50055F9379Bd0
> >     5.8   16.3  121.7  822.7  0.0  0.0    0.0    1.3   0   2
> > c1t5000C50055E57A5Fd0
> >     5.3   17.7  146.5  797.6  0.0  0.0    0.0    1.4   0   3
> > c1t5000C50055F8CCAFd0
> >     5.7   34.1  141.5  929.2  0.0  0.1    0.0    1.7   0   5
> > c1t5000C50055F8B80Fd0
> >     5.5   23.8  125.7  830.9  0.0  0.0    0.0    1.2   0   3
> > c1t5000C50055F9FA1Fd0
> >     5.0   23.2  127.9  878.6  0.0  0.0    0.0    1.1   0   3
> > c1t5000C50055E65F0Fd0
> >     5.2   14.0  163.7  833.8  0.0  0.0    0.0    2.0   0   3
> > c1t5000C50055F8BE3Fd0
> >     4.6   18.9  122.8  887.2  0.0  0.0    0.0    1.6   0   3
> > c1t5000C50055F8B21Fd0
> >     5.5   23.6  137.4  825.4  0.0  0.0    0.0    1.5   0   3
> > c1t5000C50055F8A46Fd0
> >     4.9   24.6  116.7  802.8  0.0  0.0    0.0    1.4   0   4
> > c1t5000C50055F856CFd0
> >     4.9   23.4  120.8  788.9  0.0  0.0    0.0    1.4   0   3
> > c1t5000C50055E6606Fd0
> >   234.9  170.1 4079.9 11127.8  0.0  0.2    0.0    0.5   0   9 c2
> >   119.0   28.9 2083.8  670.8  0.0  0.0    0.0    0.3   0   3
> > c2t500117310015D579d0
> >   115.9   27.4 1996.1  634.2  0.0  0.0    0.0    0.3   0   3
> > c2t50011731001631FDd0
> >     0.0  113.8    0.0 9822.8  0.0  0.1    0.0    1.0   0   2
> > c2t5000A72A3007811Dd0
> >     0.1   18.5    0.0   64.8  0.0  0.0    0.0    0.0   0   0 c4
> >     0.1    9.2    0.0   32.4  0.0  0.0    0.0    0.0   0   0 c4t0d0
> >     0.0    9.2    0.0   32.4  0.0  0.0    0.0    0.0   0   0 c4t1d0
> >   229.8   58.1 3987.4 1308.0  0.0  0.1    0.0    0.3   0   6 c12
> >   114.2   27.7 1994.8  626.0  0.0  0.0    0.0    0.3   0   3
> > c12t500117310015D59Ed0
> >   115.5   30.4 1992.6  682.0  0.0  0.0    0.0    0.3   0   3
> > c12t500117310015D54Ed0
> >     0.1   17.1    0.0   64.8  0.0  0.0    0.6    0.1   0   0 rpool
> >   720.3 1298.4 14361.2 53770.8 18.7  2.3    9.3    1.1   6  68 tank
> >
> > Is 153% busy correct on c1? Seems to me that disks are quite "busy", but
> > are handling the workload just fine (wait at 6% and asvc_t at 1.1ms)
> >
> > Interestingly, this is the same output now that the resilver is running:
> >
> >                     extended device statistics
> >     r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
> >  2876.9 1041.1 25400.7 38189.1  0.0 37.9    0.0    9.7   0 2011 c1
> >    60.8   26.1  540.1  845.2  0.0  0.7    0.0    8.3   0  39
> > c1t5000C50055F8723Bd0
> >    58.4   14.2  511.6  740.7  0.0  0.7    0.0   10.1   0  39
> > c1t5000C50055E66B63d0
> >    60.2   16.3  529.3  756.1  0.0  0.8    0.0   10.1   0  41
> > c1t5000C50055F87E73d0
> >    57.5   24.9  527.6  841.7  0.0  0.7    0.0    9.0   0  40
> > c1t5000C50055F8BFA3d0
> >    57.9   14.5  543.5  765.1  0.0  0.7    0.0    9.8   0  38
> > c1t5000C50055F9E123d0
> >    57.9   23.9  516.6  806.9  0.0  0.8    0.0    9.3   0  40
> > c1t5000C50055F9F0B3d0
> >    59.8   24.6  554.1  857.5  0.0  0.8    0.0    9.6   0  42
> > c1t5000C50055F9D3B3d0
> >    56.5   21.0  480.4  715.7  0.0  0.7    0.0    8.9   0  37
> > c1t5000C50055E4FDE7d0
> >    54.8    9.7  473.5  737.9  0.0  0.7    0.0   11.2   0  39
> > c1t5000C50055F9A607d0
> >    55.8   20.2  457.3  708.7  0.0  0.7    0.0    9.9   0  40
> > c1t5000C50055F8CDA7d0
> >    57.8   28.6  487.0  796.1  0.0  0.9    0.0    9.9   0  45
> > c1t5000C50055E65877d0
> >    60.8   27.1  572.6  823.7  0.0  0.8    0.0    8.8   0  41
> > c1t5000C50055F9E7D7d0
> >    55.8   21.1  478.2  766.6  0.0  0.7    0.0    9.7   0  40
> > c1t5000C50055FA0AF7d0
> >    57.0   22.8  528.3  724.5  0.0  0.8    0.0    9.6   0  41
> > c1t5000C50055F9FE87d0
> >    56.2   10.8  465.2  715.6  0.0  0.7    0.0   10.4   0  38
> > c1t5000C50055F9F91Bd0
> >    59.2   29.4  524.6  740.9  0.0  0.8    0.0    8.9   0  41
> > c1t5000C50055F9FEABd0
> >    57.3   30.7  496.7  788.3  0.0  0.8    0.0    9.1   0  42
> > c1t5000C50055F9F63Bd0
> >    55.5   16.3  461.9  652.9  0.0  0.7    0.0   10.1   0  39
> > c1t5000C50055F9F3EBd0
> >    57.2   22.1  495.1  701.1  0.0  0.8    0.0    9.8   0  41
> > c1t5000C50055F9F80Bd0
> >    59.5   30.2  543.1  741.8  0.0  0.9    0.0    9.6   0  45
> > c1t5000C50055F9FB8Bd0
> >    56.5   25.1  515.4  786.9  0.0  0.7    0.0    8.6   0  38
> > c1t5000C50055F9F92Bd0
> >    61.8   12.5  540.6  790.9  0.0  0.8    0.0   10.3   0  41
> > c1t5000C50055F8905Fd0
> >    57.0   19.8  521.0  774.3  0.0  0.7    0.0    9.6   0  39
> > c1t5000C50055F8D48Fd0
> >    56.3   16.3  517.7  724.7  0.0  0.7    0.0    9.9   0  38
> > c1t5000C50055F9F89Fd0
> >    57.0   13.4  504.5  790.5  0.0  0.8    0.0   10.7   0  40
> > c1t5000C50055F9EF2Fd0
> >    55.0   26.1  477.6  845.2  0.0  0.7    0.0    8.3   0  36
> > c1t5000C50055F8C3ABd0
> >    57.8   14.1  518.7  740.7  0.0  0.8    0.0   10.8   0  41
> > c1t5000C50055E66053d0
> >    55.9   20.8  490.2  715.7  0.0  0.7    0.0    9.0   0  37
> > c1t5000C50055E66503d0
> >    57.0   24.1  509.7  806.9  0.0  0.8    0.0   10.0   0  41
> > c1t5000C50055F9D3E3d0
> >    59.1   29.2  504.1  740.9  0.0  0.8    0.0    9.3   0  44
> > c1t5000C50055F84FB7d0
> >    54.4   16.3  449.5  652.9  0.0  0.7    0.0   10.4   0  39
> > c1t5000C50055F8E017d0
> >    57.8   28.4  503.3  796.1  0.0  0.9    0.0   10.1   0  45
> > c1t5000C50055E579F7d0
> >    58.2   24.9  502.0  841.7  0.0  0.8    0.0    9.2   0  40
> > c1t5000C50055E65807d0
> >    58.2   20.7  513.4  766.6  0.0  0.8    0.0    9.8   0  41
> > c1t5000C50055F84A97d0
> >    56.5   24.9  508.0  857.5  0.0  0.8    0.0    9.2   0  40
> > c1t5000C50055F87D97d0
> >    53.4   13.5  449.9  790.5  0.0  0.7    0.0   10.7   0  38
> > c1t5000C50055F9F637d0
> >    57.0   11.8  503.0  790.9  0.0  0.7    0.0   10.6   0  39
> > c1t5000C50055E65ABBd0
> >    55.4    9.6  461.1  737.9  0.0  0.8    0.0   11.6   0  40
> > c1t5000C50055F8BF9Bd0
> >    55.7   19.7  484.6  774.3  0.0  0.7    0.0    9.9   0  40
> > c1t5000C50055F8A22Bd0
> >    57.6   27.1  518.2  823.7  0.0  0.8    0.0    8.9   0  40
> > c1t5000C50055F9379Bd0
> >    59.6   17.0  528.0  756.1  0.0  0.8    0.0   10.1   0  41
> > c1t5000C50055E57A5Fd0
> >    61.2   10.8  530.0  715.6  0.0  0.8    0.0   10.7   0  40
> > c1t5000C50055F8CCAFd0
> >    58.0   30.8  493.3  788.3  0.0  0.8    0.0    9.4   0  43
> > c1t5000C50055F8B80Fd0
> >    56.5   19.9  490.7  708.7  0.0  0.8    0.0   10.0   0  40
> > c1t5000C50055F9FA1Fd0
> >    56.1   22.4  484.2  701.1  0.0  0.7    0.0    9.5   0  39
> > c1t5000C50055E65F0Fd0
> >    59.2   14.6  560.9  765.1  0.0  0.7    0.0    9.8   0  39
> > c1t5000C50055F8BE3Fd0
> >    57.9   16.2  546.0  724.7  0.0  0.7    0.0   10.1   0  40
> > c1t5000C50055F8B21Fd0
> >    59.5   30.0  553.2  741.8  0.0  0.9    0.0    9.8   0  45
> > c1t5000C50055F8A46Fd0
> >    57.4   22.5  504.0  724.5  0.0  0.8    0.0    9.6   0  41
> > c1t5000C50055F856CFd0
> >    58.4   24.6  531.4  786.9  0.0  0.7    0.0    8.4   0  38
> > c1t5000C50055E6606Fd0
> >   511.0  161.4 7572.1 11260.1  0.0  0.3    0.0    0.4   0  14 c2
> >   252.3   20.1 3776.3  458.9  0.0  0.1    0.0    0.2   0   6
> > c2t500117310015D579d0
> >   258.8   18.0 3795.7  350.0  0.0  0.1    0.0    0.2   0   6
> > c2t50011731001631FDd0
> >     0.0  123.4    0.0 10451.1  0.0  0.1    0.0    1.0   0   3
> > c2t5000A72A3007811Dd0
> >     0.2   16.1    1.9   56.7  0.0  0.0    0.0    0.0   0   0 c4
> >     0.2    8.1    1.6   28.3  0.0  0.0    0.0    0.0   0   0 c4t0d0
> >     0.0    8.1    0.3   28.3  0.0  0.0    0.0    0.0   0   0 c4t1d0
> >   495.6  163.6 7168.9 11290.3  0.0  0.2    0.0    0.4   0  14 c12
> >     0.0  123.4    0.0 10451.1  0.0  0.1    0.0    1.0   0   3
> > c12t5000A72B300780FFd0
> >   248.2   18.1 3645.8  323.0  0.0  0.1    0.0    0.2   0   5
> > c12t500117310015D59Ed0
> >   247.4   22.1 3523.1  516.2  0.0  0.1    0.0    0.2   0   6
> > c12t500117310015D54Ed0
> >     0.2   14.8    1.9   56.7  0.0  0.0    0.6    0.1   0   0 rpool
> >  3883.5 1357.7 40141.6 60739.5 22.8 38.6    4.4    7.4  54 100 tank
> >
> > It is very busy with alot of wait % and higher asvc_t (2011% busy on c1?!).
> > I'm assuming resilvers are alot more aggressive than scrubs.
> >
> > There are many variables here, the biggest of which is the current
> > >> non-scrub load.
> > >>
> > >
> > I might have lost 2 weeks of scrub time, depending on whether the scrub
> > will resume where it left off. I'll update when I can.
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140729/1b53a492/attachment.html
> > >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > OmniOS-discuss mailing list
> > OmniOS-discuss at lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >
> >
> > ------------------------------
> >
> > End of OmniOS-discuss Digest, Vol 28, Issue 8
> > *********************************************
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> > _______________________________________________
> > OmniOS-discuss mailing list
> > OmniOS-discuss at lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >
>
>
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902


From tobi at oetiker.ch  Tue Aug 12 06:12:01 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 12 Aug 2014 08:12:01 +0200 (CEST)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
	<alpine.DEB.2.02.1408111040150.11611@froburg.oetiker.ch>
	<352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr>
Message-ID: <alpine.DEB.2.02.1408120810530.11611@froburg.oetiker.ch>

Hi Hafiz

sure ... from the manpage :)

--mbuffer=/usr/bin/mbuffer:31337

Specifiy the path to your copy of the mbuffer utility and the port
used on the destination. Caution: znapzend will send the data
directly from source mbuffer to destination mbuffer, thus data
stream is not encrypted.


note this has only been added recently

cheers
tobi


Yesterday Hafiz Rafibeyli wrote:

> Thanks for quick answer Tobi,
>
> could you please share info about  znapsend via mbuffer only(without ssh) syntax?
>
>
> is this something like this?
>
> znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer \
>        --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
> SRC '7d=>1h,30d=>4h,90d=>1d' tank/home \
> DST:a '7d=>1h,30d=>4h,90d=>1d,1y=>1w,10y=>1month' -O 10.0.0.1:9090
>
>
> ----- Original Message -----
> From: "Tobias Oetiker" <tobi at oetiker.ch>
> To: "Hafiz Rafibeyli" <rafibeyli at gmail.com>
> Cc: omnios-discuss at lists.omniti.com
> Sent: Monday, 11 August, 2014 11:44:21 AM
> Subject: Re: [OmniOS-discuss] announcement znapzend
>
> Hi Hafiz,
>
> Today Hafiz Rafibeyli wrote:
>
> > Tobias thank you for great job,it was missing backup  part for zfs on omnios,
> >
> > I think ssh will slow for bigger datasets,as you mention znapzend 0.11 supporting use of mbuffer.
> >
> > I could not find mbuffer package for omnios,could you explain how to setup/use mbuffer on omnios please?
>
> mbuffer is in the omniti repo
>
> # pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
> # pkg install mbuffer
>
> cheers
> tobi
>
> >
> > regards
> >
> >
> >
> > ----- Original Message -----
> > From: omnios-discuss-request at lists.omniti.com
> > To: omnios-discuss at lists.omniti.com
> > Sent: Tuesday, 29 July, 2014 10:29:42 PM
> > Subject: OmniOS-discuss Digest, Vol 28, Issue 8
> >
> > Send OmniOS-discuss mailing list submissions to
> > 	omnios-discuss at lists.omniti.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 	http://lists.omniti.com/mailman/listinfo/omnios-discuss
> > or, via email, send a message with subject or body 'help' to
> > 	omnios-discuss-request at lists.omniti.com
> >
> > You can reach the person managing the list at
> > 	omnios-discuss-owner at lists.omniti.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of OmniOS-discuss digest..."
> >
> >
> > Today's Topics:
> >
> >    1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
> >    2. Re: announcement znapzend a new zfs backup tool
> >       (Theo Schlossnagle)
> >    3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
> >    4. Re: Slow scrub performance (wuffers)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> > From: Tobias Oetiker <tobi at oetiker.ch>
> > To: omnios-discuss at lists.omniti.com
> > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> > Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > Just out:
> >
> >  ZnapZend a Multilevel Backuptool for ZFS
> >
> > It is on Github. Check out
> >
> >  http://www.znapzend.org
> >
> > cheers
> > tobi
> >
> >
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902


From rafibeyli at gmail.com  Tue Aug 12 06:39:15 2014
From: rafibeyli at gmail.com (Hafiz Rafibeyli)
Date: Tue, 12 Aug 2014 09:39:15 +0300 (EEST)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <alpine.DEB.2.02.1408120810530.11611@froburg.oetiker.ch>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
	<alpine.DEB.2.02.1408111040150.11611@froburg.oetiker.ch>
	<352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr>
	<alpine.DEB.2.02.1408120810530.11611@froburg.oetiker.ch>
Message-ID: <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr>

Hi Tobi,

but where to specify destination itself?is this syntax correct?

 znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer:9090 \
        --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
 SRC '7d=>1h,30d=>4h,90d=>1d' tank/home \
 DST:a '7d=>1h,30d=>4h,90d=>1d,1y=>1w,10y=>1month' -O 10.0.0.1:9090


----- Original Message -----
From: "Tobias Oetiker" <tobi at oetiker.ch>
To: "Hafiz Rafibeyli" <rafibeyli at gmail.com>
Cc: omnios-discuss at lists.omniti.com
Sent: Tuesday, 12 August, 2014 9:12:01 AM
Subject: Re: [OmniOS-discuss] announcement znapzend

Hi Hafiz

sure ... from the manpage :)

--mbuffer=/usr/bin/mbuffer:31337

Specifiy the path to your copy of the mbuffer utility and the port
used on the destination. Caution: znapzend will send the data
directly from source mbuffer to destination mbuffer, thus data
stream is not encrypted.


note this has only been added recently

cheers
tobi


Yesterday Hafiz Rafibeyli wrote:

> Thanks for quick answer Tobi,
>
> could you please share info about  znapsend via mbuffer only(without ssh) syntax?
>
>
> is this something like this?
>
> znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer \
>        --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
> SRC '7d=>1h,30d=>4h,90d=>1d' tank/home \
> DST:a '7d=>1h,30d=>4h,90d=>1d,1y=>1w,10y=>1month' -O 10.0.0.1:9090
>
>
> ----- Original Message -----
> From: "Tobias Oetiker" <tobi at oetiker.ch>
> To: "Hafiz Rafibeyli" <rafibeyli at gmail.com>
> Cc: omnios-discuss at lists.omniti.com
> Sent: Monday, 11 August, 2014 11:44:21 AM
> Subject: Re: [OmniOS-discuss] announcement znapzend
>
> Hi Hafiz,
>
> Today Hafiz Rafibeyli wrote:
>
> > Tobias thank you for great job,it was missing backup  part for zfs on omnios,
> >
> > I think ssh will slow for bigger datasets,as you mention znapzend 0.11 supporting use of mbuffer.
> >
> > I could not find mbuffer package for omnios,could you explain how to setup/use mbuffer on omnios please?
>
> mbuffer is in the omniti repo
>
> # pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
> # pkg install mbuffer
>
> cheers
> tobi
>
> >
> > regards
> >
> >
> >
> > ----- Original Message -----
> > From: omnios-discuss-request at lists.omniti.com
> > To: omnios-discuss at lists.omniti.com
> > Sent: Tuesday, 29 July, 2014 10:29:42 PM
> > Subject: OmniOS-discuss Digest, Vol 28, Issue 8
> >
> > Send OmniOS-discuss mailing list submissions to
> > 	omnios-discuss at lists.omniti.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 	http://lists.omniti.com/mailman/listinfo/omnios-discuss
> > or, via email, send a message with subject or body 'help' to
> > 	omnios-discuss-request at lists.omniti.com
> >
> > You can reach the person managing the list at
> > 	omnios-discuss-owner at lists.omniti.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of OmniOS-discuss digest..."
> >
> >
> > Today's Topics:
> >
> >    1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
> >    2. Re: announcement znapzend a new zfs backup tool
> >       (Theo Schlossnagle)
> >    3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
> >    4. Re: Slow scrub performance (wuffers)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> > From: Tobias Oetiker <tobi at oetiker.ch>
> > To: omnios-discuss at lists.omniti.com
> > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> > Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > Just out:
> >
> >  ZnapZend a Multilevel Backuptool for ZFS
> >
> > It is on Github. Check out
> >
> >  http://www.znapzend.org
> >
> > cheers
> > tobi
> >
> >
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From tobi at oetiker.ch  Tue Aug 12 07:58:50 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 12 Aug 2014 09:58:50 +0200 (CEST)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
	<alpine.DEB.2.02.1408111040150.11611@froburg.oetiker.ch>
	<352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr>
	<alpine.DEB.2.02.1408120810530.11611@froburg.oetiker.ch>
	<573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr>
Message-ID: <alpine.DEB.2.02.1408120955490.11611@froburg.oetiker.ch>

Hi Hafiz,

Today Hafiz Rafibeyli wrote:

> Hi Tobi,
>
> but where to specify destination itself?is this syntax correct?
>
>  znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer:9090 \
>         --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
>  SRC '7d=>1h,30d=>4h,90d=>1d' tank/home \
>  DST:a '7d=>1h,30d=>4h,90d=>1d,1y=>1w,10y=>1month' -O 10.0.0.1:9090

the destination is the same as if you were using ssh only ...
znapzend still uses ssh to discover the snapshots present at the
remote end, and to launch the mbuffer command at the receiving end
....

    znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer:13872 \
       --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
       SRC '7d=>1h,30d=>4h,90d=>1d' tank/home \
       DST:a '7d=>1h,30d=>4h,90d=>1d,1y=>1w,10y=>1month' root at bserv:backup/home

cheers
tobi

>
>
> ----- Original Message -----
> From: "Tobias Oetiker" <tobi at oetiker.ch>
> To: "Hafiz Rafibeyli" <rafibeyli at gmail.com>
> Cc: omnios-discuss at lists.omniti.com
> Sent: Tuesday, 12 August, 2014 9:12:01 AM
> Subject: Re: [OmniOS-discuss] announcement znapzend
>
> Hi Hafiz
>
> sure ... from the manpage :)
>
> --mbuffer=/usr/bin/mbuffer:31337
>
> Specifiy the path to your copy of the mbuffer utility and the port
> used on the destination. Caution: znapzend will send the data
> directly from source mbuffer to destination mbuffer, thus data
> stream is not encrypted.
>
>
> note this has only been added recently
>
> cheers
> tobi
>
>
> Yesterday Hafiz Rafibeyli wrote:
>
> > Thanks for quick answer Tobi,
> >
> > could you please share info about  znapsend via mbuffer only(without ssh) syntax?
> >
> >
> > is this something like this?
> >
> > znapzendzetup create --recursive --mbuffer=/opt/omni/bin/mbuffer \
> >        --mbuffersize=1G --tsformat='%Y-%m-%d-%H%M%S' \
> > SRC '7d=>1h,30d=>4h,90d=>1d' tank/home \
> > DST:a '7d=>1h,30d=>4h,90d=>1d,1y=>1w,10y=>1month' -O 10.0.0.1:9090
> >
> >
> > ----- Original Message -----
> > From: "Tobias Oetiker" <tobi at oetiker.ch>
> > To: "Hafiz Rafibeyli" <rafibeyli at gmail.com>
> > Cc: omnios-discuss at lists.omniti.com
> > Sent: Monday, 11 August, 2014 11:44:21 AM
> > Subject: Re: [OmniOS-discuss] announcement znapzend
> >
> > Hi Hafiz,
> >
> > Today Hafiz Rafibeyli wrote:
> >
> > > Tobias thank you for great job,it was missing backup  part for zfs on omnios,
> > >
> > > I think ssh will slow for bigger datasets,as you mention znapzend 0.11 supporting use of mbuffer.
> > >
> > > I could not find mbuffer package for omnios,could you explain how to setup/use mbuffer on omnios please?
> >
> > mbuffer is in the omniti repo
> >
> > # pkg set-publisher -g http://pkg.omniti.com/omniti-ms/  ms.omniti.com
> > # pkg install mbuffer
> >
> > cheers
> > tobi
> >
> > >
> > > regards
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: omnios-discuss-request at lists.omniti.com
> > > To: omnios-discuss at lists.omniti.com
> > > Sent: Tuesday, 29 July, 2014 10:29:42 PM
> > > Subject: OmniOS-discuss Digest, Vol 28, Issue 8
> > >
> > > Send OmniOS-discuss mailing list submissions to
> > > 	omnios-discuss at lists.omniti.com
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > 	http://lists.omniti.com/mailman/listinfo/omnios-discuss
> > > or, via email, send a message with subject or body 'help' to
> > > 	omnios-discuss-request at lists.omniti.com
> > >
> > > You can reach the person managing the list at
> > > 	omnios-discuss-owner at lists.omniti.com
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of OmniOS-discuss digest..."
> > >
> > >
> > > Today's Topics:
> > >
> > >    1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
> > >    2. Re: announcement znapzend a new zfs backup tool
> > >       (Theo Schlossnagle)
> > >    3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
> > >    4. Re: Slow scrub performance (wuffers)
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> > > From: Tobias Oetiker <tobi at oetiker.ch>
> > > To: omnios-discuss at lists.omniti.com
> > > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> > > Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> > > Content-Type: TEXT/PLAIN; charset=US-ASCII
> > >
> > > Just out:
> > >
> > >  ZnapZend a Multilevel Backuptool for ZFS
> > >
> > > It is on Github. Check out
> > >
> > >  http://www.znapzend.org
> > >
> > > cheers
> > > tobi
> > >
> > >
> >
> >
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902


From bfriesen at simple.dallas.tx.us  Tue Aug 12 22:45:55 2014
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Tue, 12 Aug 2014 17:45:55 -0500 (CDT)
Subject: [OmniOS-discuss] announcement znapzend
In-Reply-To: <CACLsAptKLs-BDAwbZqQWWpzfVNcmVx08oce0AT+7979Kq8OJ8w@mail.gmail.com>
References: <mailman.40.1406662182.8821.omnios-discuss@lists.omniti.com>
	<1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr>
	<CACLsAptKLs-BDAwbZqQWWpzfVNcmVx08oce0AT+7979Kq8OJ8w@mail.gmail.com>
Message-ID: <alpine.GSO.2.01.1408121743170.27062@freddy.simplesystems.org>

On Mon, 11 Aug 2014, Theo Schlossnagle wrote:

> OmniOS ships with pipeviewer (pv), if you use pv -s <several megs>, it would have close to the same effect as using mbuffer.

According to the 'pv' manual page (read on a Ubuntu installation), I 
assume that you mean -B (or --buffer-size) rather than -s?

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

From slefevre at indy.rr.com  Tue Aug 12 23:38:46 2014
From: slefevre at indy.rr.com (Scott LeFevre)
Date: Tue, 12 Aug 2014 19:38:46 -0400
Subject: [OmniOS-discuss] Getting detailed NFS lock information on an
 OmniOS NFS server
In-Reply-To: <20140812034922.2F6075A00A8@testapps.cs.toronto.edu>
References: <20140812034922.2F6075A00A8@testapps.cs.toronto.edu>
Message-ID: <1407886726.14159.27.camel@exilis.si-consulting.us>

This may help (or may not).  I presume this will work on OmniOS as it
works on other Illumos variants.

You can enable logging on an nfs share by adding 'log' to the sharenfs
property of a zfs file system.  For example, on one of my systems I have

$ zfs get sharenfs pool0/media
NAME           PROPERTY  VALUE                           SOURCE
pool0/example  sharenfs  sec=sys,log,rw=@10.1.1.0/24:... local


After this change, svc:/network/nfs/log:default is enabled automatically
and a log file 'nfslog' (and other related files) can be found
int /var/nfs.  I don't know if this records the locks but it will at
least show who/what is accessing files under an nfs share.  BTW, the
nfs/log service collects information for a bit before it drops it into
the nfslog file.

-- 
Scott LeFevre
317-696-1010 

On Mon, 2014-08-11 at 23:49 -0400, Chris Siebenmann wrote:

> Here's a question: does anyone know of a good way to get detailed NFS
> lock information on an OmniOS NFS server, especially information like
> which client has a lock on a particular file?
> 
>  'mdb -k' can be used to extract basic lock information, like the full
> paths of all files that have active locks against them[*], but my old
> Solaris mdb commands for getting more detailed NFS information don't
> work in the OmniOS mdb any more.
> 
>  Thanks in advance.
> 
> (I'll happily take pointers to where to look in the kernel implementation
> to follow struct pointers by hand with mdb's ::print and so on. From what
> I've found so far, I'm looking at usr/src/uts/common/klm to start with; is
> this right?)
> 
> 	- cks
> [*: via mdb's ::lminfo and '::walk lock_graph', see eg
>     http://utcc.utoronto.ca/~cks/space/blog/solaris/ListingFileLocks
> 
>     Solaris 10 also had ::nlm_lockson, which is still present in mdb
>     but doesn't seem to work any more, presumably because the actual
>     NFS locking implementation changed.
> ]
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140812/1093ad87/attachment.html>

From richard.elling at richardelling.com  Wed Aug 13 00:22:36 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Tue, 12 Aug 2014 17:22:36 -0700
Subject: [OmniOS-discuss] Getting detailed NFS lock information on an
	OmniOS NFS server
In-Reply-To: <1407886726.14159.27.camel@exilis.si-consulting.us>
References: <20140812034922.2F6075A00A8@testapps.cs.toronto.edu>
	<1407886726.14159.27.camel@exilis.si-consulting.us>
Message-ID: <143B66A8-1978-4DBF-9531-4683D446534E@richardelling.com>


On Aug 12, 2014, at 4:38 PM, Scott LeFevre <slefevre at indy.rr.com> wrote:

> This may help (or may not).  I presume this will work on OmniOS as it works on other Illumos variants.

NFS logging is a perfect way to destroy performance. It is very serial and will not scale well.
One important Sun customer had the misfortune of wiring it into their app and when they had
their "big event" and the systems were in production, performance was 15% of what they 
expected. The only solution was to disable logging, but they required it for their app. Needless
to say, the app was rewritten, but they had lots of pain during the "big event"
 -- richard

> 
> You can enable logging on an nfs share by adding 'log' to the sharenfs property of a zfs file system.  For example, on one of my systems I have
> $ zfs get sharenfs pool0/media
> NAME           PROPERTY  VALUE                           SOURCE
> pool0/example  sharenfs  sec=sys,log,rw=@10.1.1.0/24:... local
> 
> After this change, svc:/network/nfs/log:default is enabled automatically and a log file 'nfslog' (and other related files) can be found int /var/nfs.  I don't know if this records the locks but it will at least show who/what is accessing files under an nfs share.  BTW, the nfs/log service collects information for a bit before it drops it into the nfslog file.
> 
> -- 
> Scott LeFevre
> 317-696-1010 
> 
> On Mon, 2014-08-11 at 23:49 -0400, Chris Siebenmann wrote:
>> 
>> Here's a question: does anyone know of a good way to get detailed NFS
>> lock information on an OmniOS NFS server, especially information like
>> which client has a lock on a particular file?
>> 
>>  'mdb -k' can be used to extract basic lock information, like the full
>> paths of all files that have active locks against them[*], but my old
>> Solaris mdb commands for getting more detailed NFS information don't
>> work in the OmniOS mdb any more.
>> 
>>  Thanks in advance.
>> 
>> (I'll happily take pointers to where to look in the kernel implementation
>> to follow struct pointers by hand with mdb's ::print and so on. From what
>> I've found so far, I'm looking at usr/src/uts/common/klm to start with; is
>> this right?)
>> 
>> 	- cks
>> [*: via mdb's ::lminfo and '::walk lock_graph', see eg
>>     http://utcc.utoronto.ca/~cks/space/blog/solaris/ListingFileLocks
>> 
>>     Solaris 10 also had ::nlm_lockson, which is still present in mdb
>>     but doesn't seem to work any more, presumably because the actual
>>     NFS locking implementation changed.
>> ]
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140812/1168afb9/attachment-0001.html>

From slefevre at indy.rr.com  Wed Aug 13 01:22:37 2014
From: slefevre at indy.rr.com (Scott LeFevre)
Date: Tue, 12 Aug 2014 21:22:37 -0400
Subject: [OmniOS-discuss] Getting detailed NFS lock information on an
 OmniOS NFS server
In-Reply-To: <143B66A8-1978-4DBF-9531-4683D446534E@richardelling.com>
References: <20140812034922.2F6075A00A8@testapps.cs.toronto.edu>
	<1407886726.14159.27.camel@exilis.si-consulting.us>
	<143B66A8-1978-4DBF-9531-4683D446534E@richardelling.com>
Message-ID: <1407892957.14159.43.camel@exilis.si-consulting.us>



> NFS logging is a perfect way to destroy performance. It is very serial
> and will not scale well.
> One important Sun customer had the misfortune of wiring it into their
> app and when they had
> their "big event" and the systems were in production, performance was
> 15% of what they 
> expected. The only solution was to disable logging, but they required
> it for their app. Needless
> to say, the app was rewritten, but they had lots of pain during the
> "big event"
>  -- richard

Thanks Richard! Good info. I guess everything has a price.
-- 
Scott LeFevre
317-696-1010 

On Tue, 2014-08-12 at 17:22 -0700, Richard Elling wrote:

> 
> 
> On Aug 12, 2014, at 4:38 PM, Scott LeFevre <slefevre at indy.rr.com>
> wrote:
> 
> 
> 
> > This may help (or may not).  I presume this will work on OmniOS as
> > it works on other Illumos variants.
> > 
> 
> 
> NFS logging is a perfect way to destroy performance. It is very serial
> and will not scale well.
> One important Sun customer had the misfortune of wiring it into their
> app and when they had
> their "big event" and the systems were in production, performance was
> 15% of what they 
> expected. The only solution was to disable logging, but they required
> it for their app. Needless
> to say, the app was rewritten, but they had lots of pain during the
> "big event"
>  -- richard
> 
> 
> 
> > 
> > You can enable logging on an nfs share by adding 'log' to the
> > sharenfs property of a zfs file system.  For example, on one of my
> > systems I have 
> > 
> > $ zfs get sharenfs pool0/media
> > NAME           PROPERTY  VALUE                           SOURCE
> > pool0/example  sharenfs  sec=sys,log,rw=@10.1.1.0/24:... local
> > 
> > 
> > After this change, svc:/network/nfs/log:default is enabled
> > automatically and a log file 'nfslog' (and other related files) can
> > be found int /var/nfs.  I don't know if this records the locks but
> > it will at least show who/what is accessing files under an nfs
> > share.  BTW, the nfs/log service collects information for a bit
> > before it drops it into the nfslog file.
> > 
> > -- 
> > Scott LeFevre
> > 317-696-1010 
> > 
> > 
> > On Mon, 2014-08-11 at 23:49 -0400, Chris Siebenmann wrote: 
> > 
> > > Here's a question: does anyone know of a good way to get detailed NFS
> > > lock information on an OmniOS NFS server, especially information like
> > > which client has a lock on a particular file?
> > > 
> > >  'mdb -k' can be used to extract basic lock information, like the full
> > > paths of all files that have active locks against them[*], but my old
> > > Solaris mdb commands for getting more detailed NFS information don't
> > > work in the OmniOS mdb any more.
> > > 
> > >  Thanks in advance.
> > > 
> > > (I'll happily take pointers to where to look in the kernel implementation
> > > to follow struct pointers by hand with mdb's ::print and so on. From what
> > > I've found so far, I'm looking at usr/src/uts/common/klm to start with; is
> > > this right?)
> > > 
> > > 	- cks
> > > [*: via mdb's ::lminfo and '::walk lock_graph', see eg
> > >     http://utcc.utoronto.ca/~cks/space/blog/solaris/ListingFileLocks
> > > 
> > >     Solaris 10 also had ::nlm_lockson, which is still present in mdb
> > >     but doesn't seem to work any more, presumably because the actual
> > >     NFS locking implementation changed.
> > > ]
> > > _______________________________________________
> > > OmniOS-discuss mailing list
> > > OmniOS-discuss at lists.omniti.com
> > > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> > 
> > _______________________________________________
> > OmniOS-discuss mailing list
> > OmniOS-discuss at lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140812/eb9259ef/attachment.html>

From henson at acm.org  Wed Aug 13 02:27:03 2014
From: henson at acm.org (Paul B. Henson)
Date: Tue, 12 Aug 2014 19:27:03 -0700
Subject: [OmniOS-discuss] deleting zfs filesystems with holds in place
In-Reply-To: <1407441099.20827.3.camel@exilis.si-consulting.us>
References: <014b01cfb278$3eaf28c0$bc0d7a40$@acm.org>
	<1407441099.20827.3.camel@exilis.si-consulting.us>
Message-ID: <06af01cfb69e$141915b0$3c4b4110$@acm.org>

> From: Scott LeFevre
> Sent: Thursday, August 07, 2014 12:52 PM
> 
> Try zfs destroy -R poolname/filesystem
> 
> Read the man pages first to ensure this is what you want to do in your
> situation.  The -r option might work for you as well.

I had already confirmed -r didn't work, neither does -R:

# zfs create export/user/testit
# zfs snap export/user/testit at testsnap
# zfs hold testhold export/user/testit at testsnap
# zfs destroy -r export/user/testit
cannot destroy snapshot export/user/testit at testsnap: dataset is busy
# zfs destroy -R export/user/testit
cannot destroy snapshot export/user/testit at testsnap: dataset is busy

Matt confirmed on the ZFS mailing list that there's currently no way to delete a file system with held snapshots other than enumerate the holds and explicitly releasing them :(.

Thanks...



From tobi at oetiker.ch  Wed Aug 13 07:12:27 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Wed, 13 Aug 2014 09:12:27 +0200 (CEST)
Subject: [OmniOS-discuss] how to see the real process arguments
Message-ID: <alpine.DEB.2.02.1408130912160.11611@froburg.oetiker.ch>

Have you ever tried this:

 % sh -c 'true xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx no one sees me && sleep 1000' &
 [1] 13070
 % pargs 13070
 13070:  sh -c true xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 argv[0]: sh
 argv[1]: -c
 argv[2]: sh

I thought pargs was going to show me the arguments

tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902


From lotheac at iki.fi  Wed Aug 13 07:25:30 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Wed, 13 Aug 2014 10:25:30 +0300
Subject: [OmniOS-discuss] how to see the real process arguments
In-Reply-To: <alpine.DEB.2.02.1408130912160.11611@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1408130912160.11611@froburg.oetiker.ch>
Message-ID: <20140813072530.GB1876@gutsman.lotheac.fi>

On Wed, Aug 13 2014 09:12:27 +0200, Tobias Oetiker wrote:
> I thought pargs was going to show me the arguments

It prints the contents of argv, but the program may have modified it.

-- 
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet

From marc.fournier at camptocamp.com  Wed Aug 13 07:36:33 2014
From: marc.fournier at camptocamp.com (Marc Fournier)
Date: Wed, 13 Aug 2014 09:36:33 +0200
Subject: [OmniOS-discuss] collectd compiling error
In-Reply-To: <53E90655.1020901@gmail.com>
References: <53E90655.1020901@gmail.com>
Message-ID: <1407914494-sup-1383@lonquimay.wrk.lsn.camptocamp.com>

Excerpts from Brogy?nyi J?zsef's message of 2014-08-11 20:07:17 +0200:
> Hi
> 
> I'd like to use collectd but the make command is stuck. I tried with 
> gmake too. Is there any idea? Here is the error message:
> 
> *** Error code 1
> The following command caused the error:
> echo "  CC    " libcollectdclient_la-network_buffer.lo;/bin/sh 
> ../../libtool --silent --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I../../src    -I../../src/libcollectdclient/collectd -I../../src   
> -Wall -Werror -g -O2 -c -o libcollectdclient_la-network_buffer.lo `test 
> -f 'network_buffer.c' || echo './'`network_buffer.c
> make: Fatal error: Command failed for target 
> `libcollectdclient_la-network_buffer.lo'
> [...]

Folks are reporting build problems on this exact file on other OSes too:
https://github.com/collectd/collectd/issues/632

I see no mention of gcrypt in your error messages, are you able to
increase the verbosity to get the exact error message from the compiler ?

If it's indeed the same issue "./configure --without-libgcrypt" or
building without -Werror should allow you to work around it until the
problem is fixed in collectd.

Marc

From fabio at fabiorabelo.wiki.br  Wed Aug 13 20:09:30 2014
From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=)
Date: Wed, 13 Aug 2014 17:09:30 -0300
Subject: [OmniOS-discuss] LSI 3041e
Message-ID: <CAEekY67xQfgy-Rcq2NcDoJMQtQWJ1HaEX34AHZgFMAyBDxv4Zg@mail.gmail.com>

Hi to all

Quick question about a 4 port Sata card :

I have an HP branded LSI 3041 card with 4 Sata ports on it .

I need to reflash it, or it are supported by OmniOS Out of the Box ?

Thanks in advance ....


F?bio Rabelo

From matthew.lagoe at subrigo.net  Wed Aug 13 20:23:24 2014
From: matthew.lagoe at subrigo.net (Matthew Lagoe)
Date: Wed, 13 Aug 2014 13:23:24 -0700
Subject: [OmniOS-discuss] LSI 3041e
In-Reply-To: <CAEekY67xQfgy-Rcq2NcDoJMQtQWJ1HaEX34AHZgFMAyBDxv4Zg@mail.gmail.com>
References: <CAEekY67xQfgy-Rcq2NcDoJMQtQWJ1HaEX34AHZgFMAyBDxv4Zg@mail.gmail.com>
Message-ID: <00be01cfb734$719b4fa0$54d1eee0$@subrigo.net>

It should work out of the box

That said if you can stick lsi firmware on it do it, as HP has a bad habit of using really old firmware with issues in it

-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of F?bio Rabelo
Sent: Wednesday, August 13, 2014 01:10 PM
To: omnios-discuss at lists.omniti.com
Subject: [OmniOS-discuss] LSI 3041e

Hi to all

Quick question about a 4 port Sata card :

I have an HP branded LSI 3041 card with 4 Sata ports on it .

I need to reflash it, or it are supported by OmniOS Out of the Box ?

Thanks in advance ....


F?bio Rabelo
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss



From mmabis at vmware.com  Wed Aug 13 20:43:31 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Wed, 13 Aug 2014 20:43:31 +0000
Subject: [OmniOS-discuss] SuperMicro Board Reboot Hang
Message-ID: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>

Hey all,

I looked at some of the past notes on this but it looked like the discussion tiered off and stopped.  I was wondering if there was ever a resolution to the Reboot hang issues with OMNI.

Running a SuperMicro Board 16GB Ram soon to be updated... my first thought is it has something to do with SMB but i have also seen this happen when its Core Dumped b/c SMB crapped itself.
Basically the server will just sit at the Rebooting words and do nothing it requires physical intervention to reboot the box.
Haven't Tried shutdown honestly cause i keep it up all the time!  Was there any incite to what is causing this like fast boot or something?    I do have LSI SAS-2008 Controllers (Multiple) in this box!
Matt Mabis
Sr. Consultant PSO (End User Computing)
VCA-DCV/WM,VCP-DCV/DT,VCAP-DCA/DCD/DTD
mmabis at vmware.com
3401 Hillview Avenue, Palo Alto, CA 94304
530.481.5405 Mobile

[VMware]<http://www.vmware.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140813/d722fd36/attachment-0001.html>

From danmcd at omniti.com  Wed Aug 13 20:46:36 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 13 Aug 2014 16:46:36 -0400
Subject: [OmniOS-discuss] SuperMicro Board Reboot Hang
In-Reply-To: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>
References: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>
Message-ID: <36DF2034-31A4-4074-BD3C-9C934C1B0734@omniti.com>


On Aug 13, 2014, at 4:43 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> Hey all,
> 
> I looked at some of the past notes on this but it looked like the discussion tiered off and stopped.  I was wondering if there was ever a resolution to the Reboot hang issues with OMNI. 
> 
> Running a SuperMicro Board 16GB Ram soon to be updated... my first thought is it has something to do with SMB but i have also seen this happen when its Core Dumped b/c SMB crapped itself.  
> Basically the server will just sit at the Rebooting words and do nothing it requires physical intervention to reboot the box.  
> Haven't Tried shutdown honestly cause i keep it up all the time!  Was there any incite to what is causing this like fast boot or something? 

To eliminate fast reboot, utter "reboot -p".  That's how you force reboot into the BIOS again.

Dan


From mmabis at vmware.com  Wed Aug 13 20:54:38 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Wed, 13 Aug 2014 20:54:38 +0000
Subject: [OmniOS-discuss] SuperMicro Board Reboot Hang
In-Reply-To: <36DF2034-31A4-4074-BD3C-9C934C1B0734@omniti.com>
References: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>,
	<36DF2034-31A4-4074-BD3C-9C934C1B0734@omniti.com>
Message-ID: <4e0fe9aa876449d5a9f593f9e840c7d1@EX13-MBX-001.vmware.com>

Is it assumed that the fastboot could be causing these hangs?

Is there a longer term solution a better way as it were to get this to just be the default?


Matt Mabis
________________________________________
From: Dan McDonald <danmcd at omniti.com>
Sent: Wednesday, August 13, 2014 1:46 PM
To: Matthew Mabis
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] SuperMicro Board Reboot Hang

On Aug 13, 2014, at 4:43 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> Hey all,
>
> I looked at some of the past notes on this but it looked like the discussion tiered off and stopped.  I was wondering if there was ever a resolution to the Reboot hang issues with OMNI.
>
> Running a SuperMicro Board 16GB Ram soon to be updated... my first thought is it has something to do with SMB but i have also seen this happen when its Core Dumped b/c SMB crapped itself.
> Basically the server will just sit at the Rebooting words and do nothing it requires physical intervention to reboot the box.
> Haven't Tried shutdown honestly cause i keep it up all the time!  Was there any incite to what is causing this like fast boot or something?

To eliminate fast reboot, utter "reboot -p".  That's how you force reboot into the BIOS again.

Dan

From danmcd at omniti.com  Wed Aug 13 20:57:15 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Wed, 13 Aug 2014 16:57:15 -0400
Subject: [OmniOS-discuss] SuperMicro Board Reboot Hang
In-Reply-To: <4e0fe9aa876449d5a9f593f9e840c7d1@EX13-MBX-001.vmware.com>
References: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>,
	<36DF2034-31A4-4074-BD3C-9C934C1B0734@omniti.com>
	<4e0fe9aa876449d5a9f593f9e840c7d1@EX13-MBX-001.vmware.com>
Message-ID: <42E39D6A-0B0A-4C9E-BE05-9829C2A699E6@omniti.com>


On Aug 13, 2014, at 4:54 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> Is it assumed that the fastboot could be causing these hangs?

It is not assumed, but running that simple experiment can confirm/deny things.

As for the default, there's an SMF way to do it (which escapes me at the moment, but it's documented in the reboot(1M) man page).

Dan


From henson at acm.org  Wed Aug 13 21:00:56 2014
From: henson at acm.org (Paul B. Henson)
Date: Wed, 13 Aug 2014 14:00:56 -0700
Subject: [OmniOS-discuss] SuperMicro Board Reboot Hang
In-Reply-To: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>
References: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>
Message-ID: <20140813210056.GB31192@bender.unx.csupomona.edu>

On Wed, Aug 13, 2014 at 08:43:31PM +0000, Matthew Mabis wrote:

> Running a SuperMicro Board 16GB Ram soon to be updated... my first
> thought is it has something to do with SMB but i have also seen this
> happen when its Core Dumped b/c SMB crapped itself.  Basically the
> server will just sit at the Rebooting words and do nothing it requires
> physical intervention to reboot the box.

Did you try disabling fast reboot? I have a similar supermicro box that
wedges at reboot if fast reboot is enabled. Disabling fast reboot makes
it work, albeit at the cost of ripping through BIOS POST each reboot.
Seems a decent trade off ;).

# svccfg -s "system/boot-config:default" setprop config/fastreboot_default=false
# svccfg -s "system/boot-config:default" setprop config/fastreboot_onpanic=false
# svcadm refresh svc:/system/boot-config:default

From mmabis at vmware.com  Wed Aug 13 21:23:30 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Wed, 13 Aug 2014 21:23:30 +0000
Subject: [OmniOS-discuss] SuperMicro Board Reboot Hang
In-Reply-To: <20140813210056.GB31192@bender.unx.csupomona.edu>
References: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>,
	<20140813210056.GB31192@bender.unx.csupomona.edu>
Message-ID: <db7b44a383b543a4b9caef0f156f871d@EX13-MBX-001.vmware.com>

I have not tried yet, 

I was hoping there was a nicer way to do it in omni now i saw an older method which looked nasty I will change those settings and hopefully get that issue cleared! 

I could care less if it runs through the bios again heck i prefer it just incase the ECC RAM goes on the fritz... 

Thanks!

Matt Mabis



________________________________________
From: Paul Henson <paul.b.henson at gmail.com> on behalf of Paul B. Henson <henson at acm.org>
Sent: Wednesday, August 13, 2014 2:00 PM
To: Matthew Mabis
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] SuperMicro Board Reboot Hang

On Wed, Aug 13, 2014 at 08:43:31PM +0000, Matthew Mabis wrote:

> Running a SuperMicro Board 16GB Ram soon to be updated... my first
> thought is it has something to do with SMB but i have also seen this
> happen when its Core Dumped b/c SMB crapped itself.  Basically the
> server will just sit at the Rebooting words and do nothing it requires
> physical intervention to reboot the box.

Did you try disabling fast reboot? I have a similar supermicro box that
wedges at reboot if fast reboot is enabled. Disabling fast reboot makes
it work, albeit at the cost of ripping through BIOS POST each reboot.
Seems a decent trade off ;).

# svccfg -s "system/boot-config:default" setprop config/fastreboot_default=false
# svccfg -s "system/boot-config:default" setprop config/fastreboot_onpanic=false
# svcadm refresh svc:/system/boot-config:default

From richard.elling at richardelling.com  Thu Aug 14 01:33:45 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Wed, 13 Aug 2014 18:33:45 -0700
Subject: [OmniOS-discuss] SuperMicro Board Reboot Hang
In-Reply-To: <36DF2034-31A4-4074-BD3C-9C934C1B0734@omniti.com>
References: <088fbff6b9a54adc8ea5f8f82ba1c426@EX13-MBX-001.vmware.com>
	<36DF2034-31A4-4074-BD3C-9C934C1B0734@omniti.com>
Message-ID: <CB25D49C-9A2D-4952-A17B-EB9A0DCBEEF5@richardelling.com>

Dan,
This causes much angst for x86 systems. Some distros disable fastboot out of the box.
I suggest OmniOS do likewise.
 -- richard

On Aug 13, 2014, at 1:46 PM, Dan McDonald <danmcd at omniti.com> wrote:

> 
> On Aug 13, 2014, at 4:43 PM, Matthew Mabis <mmabis at vmware.com> wrote:
> 
>> Hey all,
>> 
>> I looked at some of the past notes on this but it looked like the discussion tiered off and stopped.  I was wondering if there was ever a resolution to the Reboot hang issues with OMNI. 
>> 
>> Running a SuperMicro Board 16GB Ram soon to be updated... my first thought is it has something to do with SMB but i have also seen this happen when its Core Dumped b/c SMB crapped itself.  
>> Basically the server will just sit at the Rebooting words and do nothing it requires physical intervention to reboot the box.  
>> Haven't Tried shutdown honestly cause i keep it up all the time!  Was there any incite to what is causing this like fast boot or something? 
> 
> To eliminate fast reboot, utter "reboot -p".  That's how you force reboot into the BIOS again.
> 
> Dan
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From helmut.hartl at firmos.at  Thu Aug 14 06:50:40 2014
From: helmut.hartl at firmos.at (Helmut Hartl)
Date: Thu, 14 Aug 2014 08:50:40 +0200
Subject: [OmniOS-discuss] Boot Hang / VMWare Fusion /
	OmniOS_Text_r151010s.iso
Message-ID: <53EC5C40.9060205@firmos.at>

Hi,

Booting OmniOS_Text_r151010s.iso under
VMWare Fusion Version 6.0.4 (1887983)
on my MPB late 2013 @OSX Mavericks 10.9.4
hangs for me.

Some previous/other iso's like the
OmniOS_Text_bloody_20140723.iso
dont show this behaviour and are installable.

I tried to boot with grub kernel -v option.
The last line printed is:
-
PCI Express-device: pic15ad,7a0 at 18,7, pcieb31
pcieb31 is /pci at 0,0/pci15ad,7a0 at 18,7
-
I also attached a screenshot.

Is this just me or a known problem ?

thanks,

  helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omnios_hang.png
Type: image/png
Size: 61607 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140814/be7f20c4/attachment-0001.png>

From sim.ple at live.nl  Thu Aug 14 11:28:42 2014
From: sim.ple at live.nl (Randy S)
Date: Thu, 14 Aug 2014 13:28:42 +0200
Subject: [OmniOS-discuss] trying to build omnios latest
Message-ID: <DUB124-W5201A56C890443F10C7C78E0E80@phx.gbl>

Hi all,

I am trying to build the latest omnios.
First tried the complete system, failed. Then tried to only build the kernel (command used: ./buildctl build illumos-gate), failed.

According to many posts, I downloaded the latest bloody version and then followed the documents on the wiki.
So, using bloody for this (but also failed on the latest stable omnios 151010).
Installed all dependencies during several runs of trial and error.
Even tried it with ROOT_OK to see if I missed any rights issues but still failing.

error in mail.msg:
==== Tools build errors ====

dmake: Warning: Target `install' not remade because of errors
The following command caused the error:
dmake: Warning: Command failed for target `mandoc'
dmake: Warning: Target `install' not remade because of errors
============================

nightly.log contains multiple errors like :
dmake: Warning: Target `def.targ' not remade because of errors

dmake: Warning: Command failed for target `uts'

ld.so.1: perl: fatal: relocation error: file /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64/auto/POSIX/POSIX.so: 
symbol __mb_cur_max: referenced symbol not found

The following command caused the error:
cd intel; pwd; dmake  install.prereq
dmake: Warning: Target `install' not remade because of errors

I have been testing this for the past two days, but before I go any further and ask for specific help, I want to ask if the documents on the wiki are up to date or if anybody knows of any supplemental documents which I must have missed. 
(only looked at the wiki and all additional posts that I could find on the internet).

My point is that by following the wiki, I don't succeed.

the following thread espacially helped a lot to gain insights but handles an older version of omnios:
https://www.mail-archive.com/omnios-discuss at lists.omniti.com/msg00048.html

So if anybody knows of helpful supplemental documents for me to read, I would appreciate it, so I don't have 
to reinvent the wheel unnecessarily.

Thanks
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140814/d3535977/attachment.html>

From danmcd at omniti.com  Thu Aug 14 13:49:34 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 14 Aug 2014 09:49:34 -0400
Subject: [OmniOS-discuss] trying to build omnios latest
In-Reply-To: <DUB124-W5201A56C890443F10C7C78E0E80@phx.gbl>
References: <DUB124-W5201A56C890443F10C7C78E0E80@phx.gbl>
Message-ID: <B2284EE3-21AE-4A27-8D4F-FB2744961493@omniti.com>

So as of this moment, you are:

1.) Running bloody.

2.) Trying to build illumos-omnios

Right?

Let's first try just building illumos-omnios the way illumos developers do:  With nightly.

1.) Clone illumos-omnios somewhere.  Since you're building bloody, make sure it's the "master" branch.

2.) Use the attached illumos-omnios.env.

3.) Edit in the illumos-omnios.env file the GATE (to the name of your clone), the PARENT_WS and CODEMGR_WS (to match the path to the directory containing your GATE), and the ON_CLOSED_BINS (to make sure your closed-binaries are referenced).

4.) Run /opt/onbld/bin/nightly <Your/copy/of/>illumos-omnios.env

Please share the subsequent mail_msg.

Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: illumos-omnios.env
Type: application/octet-stream
Size: 8185 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140814/978e8b96/attachment.obj>

From natxo.asenjo at gmail.com  Sat Aug 16 12:21:52 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sat, 16 Aug 2014 14:21:52 +0200
Subject: [OmniOS-discuss] vnic zone disabled after reboot
Message-ID: <CAHBEJzVVrFOc+NxB0gCKo35potxMkrpLpQHBw_hfF8PO5U6KTg@mail.gmail.com>

hi,

This is bugging me and cannot get it to work properly.

Disclaimer: I am no solaris old timer so all info I have on this is from
the omnios wiki and my own trial and errors.

So I have an omnios real hardware host with just 1 physical nic (bge0):

root at zfstank:~# dladm show-phys
LINK         MEDIA                STATE      SPEED  DUPLEX    DEVICE
bge0         Ethernet             up         1000   full      bge0

To simplify my lab I would very much like to use dhcp for the
hosts/vms/zones. I create vnics like this

# dladm create-vnic -l bge0 vnic1

there it is:

# dladm show-vnic
LINK         OVER         SPEED  MACADDRESS        MACADDRTYPE         VID
vnic1        bge0         1000   2:8:20:ae:f6:c0   random              0

Then I create a zone and assign the vnic1 as a physical nic to it:

global # zonecfg -z zone1
sapacc: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:sapacc> create
zonecfg:sapacc> set zonepath=/tank/zones/zone1
zonecfg:sapacc> set autoboot=false
zonecfg:sapacc> set ip-type=exclusive
zonecfg:sapacc> add net
zonecfg:sapacc:net> set physical=vnic1
zonecfg:sapacc:net> end
zonecfg:sapacc> verify
zonecfg:sapacc> commit
zonecfg:sapacc> exit

Then I install the zone and I see the link:

zone 1# dladm show-link
LINK        CLASS     MTU    STATE    BRIDGE     OVER
vnic1       vnic      1500   up       --         ?

Then I create an inteface and an address:
root at zone1:~# ipadm create-if vnic1
root at zone1:~# ipadm create-addr -T dhcp vnic1/v4
root at zone1:~# ipadm show-addr
ADDROBJ TYPE STATE ADDR
lo0/v4 static ok 127.0.0.1/8
vnic1/v4 dhcp ok 192.168.0.171/24
lo0/v6 static ok ::1/128

And it works. Ok, let's reboot the zone, but now the address is disabled:

# ipadm show-addr
ADDROBJ           TYPE     STATE        ADDR
lo0/v4            static   ok           127.0.0.1/8
lo0/v6            static   ok           ::1/128
vnic1/v4          dhcp     disabled     ?

I cannot enable it either:
# ipadm enable-addr vnic1/v4
ipadm: persistent operation not supported for enable-addr

Not really sure what the PERSISTENT -46 means:
root at zone1:~# ipadm show-if
IFNAME     STATE    CURRENT      PERSISTENT
lo0        ok       -m-v------46 ---
vnic1      ok       bm--------4- -46

Am I doing something wrong or is it just that zones are not supposed
to use dhcp addresses?

Thanks for your help.
--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140816/508ed11f/attachment.html>

From natxo.asenjo at gmail.com  Sat Aug 16 13:59:02 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sat, 16 Aug 2014 15:59:02 +0200
Subject: [OmniOS-discuss] vnic zone disabled after reboot
In-Reply-To: <CAHBEJzVVrFOc+NxB0gCKo35potxMkrpLpQHBw_hfF8PO5U6KTg@mail.gmail.com>
References: <CAHBEJzVVrFOc+NxB0gCKo35potxMkrpLpQHBw_hfF8PO5U6KTg@mail.gmail.com>
Message-ID: <CAHBEJzU85w6=21TbFmJt2Q1a-VJ+_mwmn18jyi8DnVr=9CX8Bg@mail.gmail.com>

hi,

according to this doc:
http://docs.oracle.com/cd/E19455-01/806-5529/6jehkcs2t/index.html

I have create a /etc/dhcp.interface (vnic1) file. Then rebooted and I have
link, but things are a bit strange:

# ipadm show-addr
ADDROBJ           TYPE     STATE        ADDR
lo0/v4            static   ok           127.0.0.1/8
vnic1/?           dhcp     ok           192.168.0.171/24
lo0/v6            static   ok           ::1/128
vnic1/v4          dhcp     disabled     ?

So I deleted the vnic1 interface, recreated it with just ipadm create-if
vnic1 and rebooted with the /etc/dhcp.interface file and now it works:

# ipadm show-addr
ADDROBJ           TYPE     STATE        ADDR
lo0/v4            static   ok           127.0.0.1/8
vnic1/?           dhcp     ok           192.168.0.171/24
lo0/v6            static   ok           ::1/128

Is this the right way to do it?

-- 
groet,
Natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140816/62dd912b/attachment-0001.html>

From zmalone at omniti.com  Mon Aug 18 14:49:28 2014
From: zmalone at omniti.com (Zach Malone)
Date: Mon, 18 Aug 2014 10:49:28 -0400
Subject: [OmniOS-discuss] vnic zone disabled after reboot
In-Reply-To: <CAHBEJzU85w6=21TbFmJt2Q1a-VJ+_mwmn18jyi8DnVr=9CX8Bg@mail.gmail.com>
References: <CAHBEJzVVrFOc+NxB0gCKo35potxMkrpLpQHBw_hfF8PO5U6KTg@mail.gmail.com>
	<CAHBEJzU85w6=21TbFmJt2Q1a-VJ+_mwmn18jyi8DnVr=9CX8Bg@mail.gmail.com>
Message-ID: <CALLZ=vVL1=n==zOgM1kNjP48WQ3X3MuxDHggsEfp2wF-4_0t-w@mail.gmail.com>

Hello Natxo,
If you create /etc/ files to configure an interface, ipadm will no
longer be the primary way to administer them.  ipadm replaces the old
/etc/ and methods of interface creation.  You can still use both, but
they tend to step on each other's toes.

I'd try http://omnios.omniti.com/wiki.php/GeneralAdministration#SettingupdynamicDHCPnetworking
instead, which should leave you with enabled permanent interfaces that
can be managed via ipadm.
--Zach

On Sat, Aug 16, 2014 at 9:59 AM, Natxo Asenjo <natxo.asenjo at gmail.com> wrote:
> hi,
>
> according to this doc:
> http://docs.oracle.com/cd/E19455-01/806-5529/6jehkcs2t/index.html
>
> I have create a /etc/dhcp.interface (vnic1) file. Then rebooted and I have
> link, but things are a bit strange:
>
> # ipadm show-addr
> ADDROBJ           TYPE     STATE        ADDR
> lo0/v4            static   ok           127.0.0.1/8
> vnic1/?           dhcp     ok           192.168.0.171/24
> lo0/v6            static   ok           ::1/128
> vnic1/v4          dhcp     disabled     ?
>
> So I deleted the vnic1 interface, recreated it with just ipadm create-if
> vnic1 and rebooted with the /etc/dhcp.interface file and now it works:
>
> # ipadm show-addr
> ADDROBJ           TYPE     STATE        ADDR
> lo0/v4            static   ok           127.0.0.1/8
> vnic1/?           dhcp     ok           192.168.0.171/24
> lo0/v6            static   ok           ::1/128
>
> Is this the right way to do it?
>
> --
> groet,
> Natxo
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From sim.ple at live.nl  Tue Aug 19 15:42:37 2014
From: sim.ple at live.nl (Randy S)
Date: Tue, 19 Aug 2014 17:42:37 +0200
Subject: [OmniOS-discuss] build erros  omnios r10
Message-ID: <DUB124-W13CF4AECA70CFC369470E2E0D50@phx.gbl>

Hi all,

In addition to my previous post about trying to build the r10  kernel, I succeeded with the help of the script that Dan posted.
Now I'm trying to build all packages and at the moment the build stops while working on the mozilla-nss package.

I am building on the R10 bloody version.

There are several errors in the build.log regarding security modules like:

certdb.c: In function 'CERT_ImportCerts':
certdb.c:2438:15: warning: variable 'rv' set but not used [-Wunused-but-set-variable]
     SECStatus rv;
               ^
certdb.c: In function 'CERT_UnlockCertRefCount':
certdb.c:2888:14: warning: variable 'prstat' set but not used [-Wunused-but-set-variable]
     PRStatus prstat;
              ^
certdb.c: In function 'CERT_UnlockCertTrust':
certdb.c:2968:14: warning: variable 'prstat' set but not used [-Wunused-but-set-variable]
     PRStatus prstat;

Ending with:
cc1: some warnings being treated as errors
gmake[2]: *** [SunOS5.11_i86pc_gcc_OPT.OBJ/ocspsig.o] Error 1
gmake[2]: Leaving directory `/tmp/build_/nss-3.14.3/mozilla/security/nss/lib/certhigh'
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory `/tmp/build_/nss-3.14.3/mozilla/security/nss/lib'
gmake: *** [libs] Error 2
build failed

If somebody knows how to work around this I would appreciate a pointer in the right direction ?

Regards,
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140819/58029cf2/attachment.html>

From KBruene at simmonsperrine.com  Tue Aug 19 19:01:07 2014
From: KBruene at simmonsperrine.com (Kyle Bruene)
Date: Tue, 19 Aug 2014 19:01:07 +0000
Subject: [OmniOS-discuss] Fibre Channel performance on OmniOS
Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local>

Hi everyone,

Last year we built a "SAN" based on OmniOS r151008. Here are the specs:
2 x Xeon 6-core SNB
128GB DDR3 ECC
2 x 4 Port 4gbps Qlogic Fibre Channel cards
2 x 8 port 6gbps SAS controllers
2 x Brocade fibre switches.
5 x 1TB Crucial M550 SSD
5 x 3TB Seagate 7200rpm HDD

My issue is that I am only able to read/write to it at about 400-500MB/s sequential. There is plenty of cache so it seems like I should be able to get more speed with multipathing on. The hosts that are connecting to it are Windows Server 2012, but I've also tried an Ubuntu box with the same result. Is there anything I need to do on the OmniOS box to allow hosts to multipath to it? I've tried both Round Robin, Least Blocks, and Least Queue with no additional speed. It will use all the paths but will not go beyond that 500ish MBps limit. Does anyone have any insight into multipathing best practices?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140819/fed349f5/attachment.html>

From KBruene at simmonsperrine.com  Wed Aug 20 13:36:02 2014
From: KBruene at simmonsperrine.com (Kyle Bruene)
Date: Wed, 20 Aug 2014 13:36:02 +0000
Subject: [OmniOS-discuss] FW:  Fibre Channel performance on OmniOS
In-Reply-To: <DUB124-W2E1B8FEEB77621A3F74E2E0D20@phx.gbl>
References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local>
	<DUB124-W2E1B8FEEB77621A3F74E2E0D20@phx.gbl>
Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33D225B2@SPMAIL1.spae.local>

I've tried different pool configurations. Currently I have two pools: the 5 ssd's in a raidz and the 3TB's in a raidz. I get the same result from both because the cache is so large. With sync off, I get the same speed on both pools because it is just writing/reading to/from ram. I feel like there is enough hardware and was hoping to get better speed than this with more SSD's. I am assuming that if I setup some kind of ramdisk, I would still only get the 400MB/s over FC. Reading and writing to the pool(s) locally produces multiple GB/s.

From: Randy S [mailto:sim.ple at live.nl]
Sent: Wednesday, August 20, 2014 4:57 AM
To: Kyle Bruene
Subject: RE: [OmniOS-discuss] Fibre Channel performance on OmniOS

Hi ,

Indeed some heavy duty hardware but how did you organize your pool ?

________________________________
From: KBruene at simmonsperrine.com<mailto:KBruene at simmonsperrine.com>
To: omnios-discuss at lists.omniti.com<mailto:omnios-discuss at lists.omniti.com>
Date: Tue, 19 Aug 2014 19:01:07 +0000
Subject: [OmniOS-discuss] Fibre Channel performance on OmniOS
Hi everyone,

Last year we built a "SAN" based on OmniOS r151008. Here are the specs:
2 x Xeon 6-core SNB
128GB DDR3 ECC
2 x 4 Port 4gbps Qlogic Fibre Channel cards
2 x 8 port 6gbps SAS controllers
2 x Brocade fibre switches.
5 x 1TB Crucial M550 SSD
5 x 3TB Seagate 7200rpm HDD

My issue is that I am only able to read/write to it at about 400-500MB/s sequential. There is plenty of cache so it seems like I should be able to get more speed with multipathing on. The hosts that are connecting to it are Windows Server 2012, but I've also tried an Ubuntu box with the same result. Is there anything I need to do on the OmniOS box to allow hosts to multipath to it? I've tried both Round Robin, Least Blocks, and Least Queue with no additional speed. It will use all the paths but will not go beyond that 500ish MBps limit. Does anyone have any insight into multipathing best practices?

Thanks.

_______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com<mailto:OmniOS-discuss at lists.omniti.com> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140820/91f2823a/attachment.html>

From bfriesen at simple.dallas.tx.us  Wed Aug 20 13:53:51 2014
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Wed, 20 Aug 2014 08:53:51 -0500 (CDT)
Subject: [OmniOS-discuss] FW:  Fibre Channel performance on OmniOS
In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33D225B2@SPMAIL1.spae.local>
References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local>
	<DUB124-W2E1B8FEEB77621A3F74E2E0D20@phx.gbl>
	<202C92988C5CF249BD3F9F21B2B199CB33D225B2@SPMAIL1.spae.local>
Message-ID: <alpine.GSO.2.01.1408200843020.18732@freddy.simplesystems.org>

On Wed, 20 Aug 2014, Kyle Bruene wrote:

> 
> I?ve tried different pool configurations. Currently I have two pools: the 5 ssd?s in a raidz and the 3TB?s
> in a raidz. I get the same result from both because the cache is so large. With sync off, I get the same
> speed on both pools because it is just writing/reading to/from ram. I feel like there is enough hardware and
> was hoping to get better speed than this with more SSD?s. I am assuming that if I setup some kind of
> ramdisk, I would still only get the 400MB/s over FC. Reading and writing to the pool(s) locally produces
> multiple GB/s.

What method are you using to measure throughput?  It may be that your 
setup will increase throughput with more independent data streams but 
perhaps your benchmark methodology might only be using one data 
stream.

If there is a fixed response latency somewhere (e.g. SSD sync write 
time) then single-app throughput would not likely increase as more 
parallelism is added to the hardware and topology.

Even with zfs zil disabled, the disks/SSDs need to accept writes and 
cache flushes for each transaction group.  Without these cache 
flushes, your pool would likely be toast on the first power loss or 
system panic.

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

From KBruene at simmonsperrine.com  Wed Aug 20 14:25:57 2014
From: KBruene at simmonsperrine.com (Kyle Bruene)
Date: Wed, 20 Aug 2014 14:25:57 +0000
Subject: [OmniOS-discuss] FW:  Fibre Channel performance on OmniOS
In-Reply-To: <alpine.GSO.2.01.1408200843020.18732@freddy.simplesystems.org>
References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local>
	<DUB124-W2E1B8FEEB77621A3F74E2E0D20@phx.gbl>
	<202C92988C5CF249BD3F9F21B2B199CB33D225B2@SPMAIL1.spae.local>
	<alpine.GSO.2.01.1408200843020.18732@freddy.simplesystems.org>
Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33D22718@SPMAIL1.spae.local>

I'm ok with losing data from power loss or panic. I have two of these boxes that are normally run in a mirror configuration at the host level. These are being used VM's. It is indeed a single data steam. The test is being run over a single LUN. Does multipathing not split the stream between two paths? 

Hyper-V connects to these boxes and mirrors them. Maybe it just depends on if the Hypervisor will access the VHD file in multiple streams or just a single one.

-----Original Message-----
From: Bob Friesenhahn [mailto:bfriesen at simple.dallas.tx.us] 
Sent: Wednesday, August 20, 2014 8:54 AM
To: Kyle Bruene
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] FW: Fibre Channel performance on OmniOS

On Wed, 20 Aug 2014, Kyle Bruene wrote:

> 
> I?ve tried different pool configurations. Currently I have two pools: 
> the 5 ssd?s in a raidz and the 3TB?s in a raidz. I get the same result 
> from both because the cache is so large. With sync off, I get the same 
> speed on both pools because it is just writing/reading to/from ram. I 
> feel like there is enough hardware and was hoping to get better speed 
> than this with more SSD?s. I am assuming that if I setup some kind of ramdisk, I would still only get the 400MB/s over FC. Reading and writing to the pool(s) locally produces multiple GB/s.

What method are you using to measure throughput?  It may be that your setup will increase throughput with more independent data streams but perhaps your benchmark methodology might only be using one data stream.

If there is a fixed response latency somewhere (e.g. SSD sync write
time) then single-app throughput would not likely increase as more parallelism is added to the hardware and topology.

Even with zfs zil disabled, the disks/SSDs need to accept writes and cache flushes for each transaction group.  Without these cache flushes, your pool would likely be toast on the first power loss or system panic.

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

From johan.kragsterman at capvert.se  Wed Aug 20 15:23:10 2014
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Wed, 20 Aug 2014 17:23:10 +0200
Subject: [OmniOS-discuss] Ang:  Fibre Channel performance on OmniOS
In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local>
References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local>
Message-ID: <OF45EFBF95.4AAE0CD3-ONC1257D3A.005484F7-C1257D3A.005484F9@inse.com>


-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: "'omnios-discuss at lists.omniti.com'" <omnios-discuss at lists.omniti.com>
Fr?n: Kyle Bruene 
S?nt av: "OmniOS-discuss" 
Datum: 2014-08-19 21:02
?rende: [OmniOS-discuss] Fibre Channel performance on OmniOS

Hi everyone,

?

Last year we built a &#8220;SAN&#8221; based on OmniOS r151008. Here are the specs:

2 x Xeon 6-core SNB

128GB DDR3 ECC

2 x 4 Port 4gbps Qlogic Fibre Channel cards

2 x 8 port 6gbps SAS controllers

2 x Brocade fibre switches.

5 x 1TB Crucial M550 SSD

5 x 3TB Seagate 7200rpm HDD

?

My issue is that I am only able to read/write to it at about 400-500MB/s sequential. There is plenty of cache so it seems like I should be able to get more speed with multipathing on. The hosts that are connecting to it are Windows Server 2012, but I&#8217;ve also tried an Ubuntu box with the same result. Is there anything I need to do on the OmniOS box to allow hosts to multipath to it? I&#8217;ve tried both Round Robin, Least Blocks, and Least Queue with no additional speed. It will use all the paths but will not go beyond that 500ish MBps limit. Does anyone have any insight into multipathing best practices?

?




Hi!

400-500 MegaByte/s is just what you should expect, from 4 Gbit/s fibre channel, IF YOU USE single port HBA's in the host.

Do you?

If you use dual port HBA's you should expect about the double.

You got multipath enabled, but the multipath isn't going to help you with performance, unless you provide more host ports. The only thing the multipath do with host single port is spreading the load over the target ports, but you're still limited at 4 Gbit/s.

Rgrds Johan





Thanks.

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss



From KBruene at simmonsperrine.com  Wed Aug 20 15:29:09 2014
From: KBruene at simmonsperrine.com (Kyle Bruene)
Date: Wed, 20 Aug 2014 15:29:09 +0000
Subject: [OmniOS-discuss] FW:  Fibre Channel performance on OmniOS
In-Reply-To: <OF45EFBF95.4AAE0CD3-ONC1257D3A.005484F7-C1257D3A.005484F9@inse.com>
References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local>
	<OF45EFBF95.4AAE0CD3-ONC1257D3A.005484F7-C1257D3A.005484F9@inse.com>
Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33D227E3@SPMAIL1.spae.local>

Thanks for the responses. I guess I forgot to mention that I have dual port and some quad port cards in the hosts. I am starting to wish I would have just spent some extra and gotten 8gb instead. I feel like most of the access is going to be single application/stream since it is mostly Exchange 2010 accessing the SAN from inside a VM. From what I understand it has been redesigned to be more sequential, combining IO requests. Thanks for your help everyone. I think I've got it figured out now.

-----Original Message-----
From: Johan Kragsterman [mailto:johan.kragsterman at capvert.se] 
Sent: Wednesday, August 20, 2014 10:23 AM
To: Kyle Bruene
Cc: 'omnios-discuss at lists.omniti.com'
Subject: Ang: [OmniOS-discuss] Fibre Channel performance on OmniOS


-----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com> skrev: -----
Till: "'omnios-discuss at lists.omniti.com'" <omnios-discuss at lists.omniti.com>
Fr?n: Kyle Bruene 
S?nt av: "OmniOS-discuss" 
Datum: 2014-08-19 21:02
?rende: [OmniOS-discuss] Fibre Channel performance on OmniOS

Hi everyone,

?

Last year we built a &#8220;SAN&#8221; based on OmniOS r151008. Here are the specs:

2 x Xeon 6-core SNB

128GB DDR3 ECC

2 x 4 Port 4gbps Qlogic Fibre Channel cards

2 x 8 port 6gbps SAS controllers

2 x Brocade fibre switches.

5 x 1TB Crucial M550 SSD

5 x 3TB Seagate 7200rpm HDD

?

My issue is that I am only able to read/write to it at about 400-500MB/s sequential. There is plenty of cache so it seems like I should be able to get more speed with multipathing on. The hosts that are connecting to it are Windows Server 2012, but I&#8217;ve also tried an Ubuntu box with the same result. Is there anything I need to do on the OmniOS box to allow hosts to multipath to it? I&#8217;ve tried both Round Robin, Least Blocks, and Least Queue with no additional speed. It will use all the paths but will not go beyond that 500ish MBps limit. Does anyone have any insight into multipathing best practices?

?




Hi!

400-500 MegaByte/s is just what you should expect, from 4 Gbit/s fibre channel, IF YOU USE single port HBA's in the host.

Do you?

If you use dual port HBA's you should expect about the double.

You got multipath enabled, but the multipath isn't going to help you with performance, unless you provide more host ports. The only thing the multipath do with host single port is spreading the load over the target ports, but you're still limited at 4 Gbit/s.

Rgrds Johan





Thanks.

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss



From sim.ple at live.nl  Wed Aug 20 21:24:01 2014
From: sim.ple at live.nl (Randy S)
Date: Wed, 20 Aug 2014 23:24:01 +0200
Subject: [OmniOS-discuss] Create iso R151010
Message-ID: <DUB124-W4217D1399843FA58F6F139E0D20@phx.gbl>

Tried to create an iso based on the r151010 repo 
Followed the steps on the wiki  and used the standard dc_text_x86.xml
Tried procedure on both standard  r151010 install and on the bloody install to see if that made a difference (since bloody is mostly advised for building stuff)

Distro_const completes successfully (no errors)  but the resulting iso does not boot past the primary screen stating the copyright.

Who knows how to create a working iso successfully and can show the steps to take?

Btw. noticed that the R10 repo contains 
                        616 packages , far less then e.g the R8 repo. 

Regards


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140820/4989d307/attachment.html>

From sim.ple at live.nl  Thu Aug 21 12:01:47 2014
From: sim.ple at live.nl (Randy S)
Date: Thu, 21 Aug 2014 14:01:47 +0200
Subject: [OmniOS-discuss] Create iso R151010
In-Reply-To: <DUB124-W4217D1399843FA58F6F139E0D20@phx.gbl>
References: <DUB124-W4217D1399843FA58F6F139E0D20@phx.gbl>
Message-ID: <DUB124-W38C71BE74F6790EABE295AE0D30@phx.gbl>

Booting the kernel in verbose mode shows that it stops while loading pci express-device pcieb31
pcieb31 is /pci at 0,0/pci15ad,7a0 at 18,7

Any advice?

From: sim.ple at live.nl
To: omnios-discuss at lists.omniti.com
Date: Wed, 20 Aug 2014 23:24:01 +0200
Subject: [OmniOS-discuss] Create iso R151010




Tried to create an iso based on the r151010 repo 
Followed the steps on the wiki  and used the standard dc_text_x86.xml
Tried procedure on both standard  r151010 install and on the bloody install to see if that made a difference (since bloody is mostly advised for building stuff)

Distro_const completes successfully (no errors)  but the resulting iso does not boot past the primary screen stating the copyright.

Who knows how to create a working iso successfully and can show the steps to take?

Btw. noticed that the R10 repo contains 
                        616 packages , far less then e.g the R8 repo. 

Regards


 		 	   		  

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140821/8c020647/attachment.html>

From danmcd at omniti.com  Fri Aug 22 01:57:02 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 21 Aug 2014 21:57:02 -0400
Subject: [OmniOS-discuss] No bloody update this time
Message-ID: <5C259DAE-43DA-4CB8-AA34-A85CAD379079@omniti.com>

If you track the omnios-build git repo, you'll have seen a large number of updates.  Some of these may be causing problems, and may have contributed to the host machine of bloody builds being bricked (pardon the alliteration).

The plan is to update bloody at the next two-week interval, which will be Sep. 10th or 11th.  I hope to have all of the current glitches & bugs worked out.

The illumos-omnios tree seems to be stable - updating that with ONU works out rather well.  I don't, however, want to just push out kernel updates in case there's something more subtle I'm missing with the overall picture.

Thank you for your patience,
Dan


From fabio at fabiorabelo.wiki.br  Sat Aug 23 12:46:00 2014
From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=)
Date: Sat, 23 Aug 2014 09:46:00 -0300
Subject: [OmniOS-discuss] LSI SAS3041e-HP
Message-ID: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>

Hi to all

Finaly I got my hands in this card, an LSI SAS3041e-HP

http://mlb-s1-p.mlstatic.com/lsi-3041e-hp-4-portas-pci-e-3gbs-sas-sata-2-raid-low-prof-16467-MLB20121375810_072014-O.jpg

But Omni are not recognising any disk connected to it !

Linux does .

So the card are working, its bios shows-up during boot .

Must be Bios/firmware related .

But I do not find anything in the "unraid" sites about this card .

Someone knows where I can find bios/firmware for IT mode that can work
on this card ?

Thanks in advance ...


F?bio Rabelo

From mir at miras.org  Sat Aug 23 13:22:13 2014
From: mir at miras.org (Michael Rasmussen)
Date: Sat, 23 Aug 2014 15:22:13 +0200
Subject: [OmniOS-discuss] LSI SAS3041e-HP
In-Reply-To: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>
References: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>
Message-ID: <20140823152213.63df2675@sleipner.datanom.net>

On Sat, 23 Aug 2014 09:46:00 -0300
F?bio Rabelo <fabio at fabiorabelo.wiki.br> wrote:

> Someone knows where I can find bios/firmware for IT mode that can work
> on this card ?
> 
Maybe?
http://www.lsi.com/support/pages/download-results.aspx?component=Storage+Component&productfamily=Legacy+Host+Bus+Adapters&productcode=P00056&assettype=Firmware&productname=LSI+SAS+3041E-R

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Accuracy, n.:
	The vice of being right
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140823/55b8632b/attachment-0001.bin>

From matthew.lagoe at subrigo.net  Sat Aug 23 13:42:24 2014
From: matthew.lagoe at subrigo.net (Matthew Lagoe)
Date: Sat, 23 Aug 2014 06:42:24 -0700
Subject: [OmniOS-discuss] LSI SAS3041e-HP
In-Reply-To: <20140823152213.63df2675@sleipner.datanom.net>
References: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>
	<20140823152213.63df2675@sleipner.datanom.net>
Message-ID: <02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net>

On that page there is SAS3041ER_ Package_P21_IR_IT_Firmware_BIOS_for_MSDOS_Windows

-----Original Message-----
From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Michael Rasmussen
Sent: Saturday, August 23, 2014 06:22 AM
To: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] LSI SAS3041e-HP

On Sat, 23 Aug 2014 09:46:00 -0300
F?bio Rabelo <fabio at fabiorabelo.wiki.br> wrote:

> Someone knows where I can find bios/firmware for IT mode that can work 
> on this card ?
> 
Maybe?
http://www.lsi.com/support/pages/download-results.aspx?component=Storage+Component&productfamily=Legacy+Host+Bus+Adapters&productcode=P00056&assettype=Firmware&productname=LSI+SAS+3041E-R

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Accuracy, n.:
	The vice of being right



From subscriptions at e-snk.me  Sat Aug 23 14:02:26 2014
From: subscriptions at e-snk.me (Suleyman Nazif Kutlu)
Date: Sat, 23 Aug 2014 16:02:26 +0200
Subject: [OmniOS-discuss] OmniOS KVM on AMD Processor
Message-ID: <CAO1DT2ALFNaHdzHsGMbWxQH=GN9kNUfd9uOpa8yQa2bGiYqW5w@mail.gmail.com>

Hi all,

I am brand new to OmniOS. Reading some documentation on Internet I found
out that on Illumos based OSes KVM is only supported on Intel processors.
Is this true for OmniOS as well?

I am planning to use OmniOS on an AMD processor server with ZFS+KVM+Zones
as a virtualization host for some personal Web Servers, databases, Home
Fileserver, Multimedia Streaming, etc..

I started with Ubuntu+KVM several years ago, then migrated to ESXi 5.x...
Now I want to use ZFS as well. This is main reason for me to start thinking
about Illumos based OSes.

Although ZOL is available on Ubuntu, I believe, as many others on Internet,
ZFS on Illumos based OSes are more mature then ZOL.

If this works on AMD processor, I will start migrations as soon as
possible...

Thanks in advance.
-Suleyman Kutlu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140823/60394fe9/attachment.html>

From jeffpc at josefsipek.net  Sat Aug 23 14:35:21 2014
From: jeffpc at josefsipek.net (Josef 'Jeff' Sipek)
Date: Sat, 23 Aug 2014 10:35:21 -0400
Subject: [OmniOS-discuss] OmniOS KVM on AMD Processor
In-Reply-To: <CAO1DT2ALFNaHdzHsGMbWxQH=GN9kNUfd9uOpa8yQa2bGiYqW5w@mail.gmail.com>
References: <CAO1DT2ALFNaHdzHsGMbWxQH=GN9kNUfd9uOpa8yQa2bGiYqW5w@mail.gmail.com>
Message-ID: <20140823143521.GA3300@josefsipek.net>

On Sat, Aug 23, 2014 at 04:02:26PM +0200, Suleyman Nazif Kutlu wrote:
> Hi all,
> 
> I am brand new to OmniOS. Reading some documentation on Internet I found
> out that on Illumos based OSes KVM is only supported on Intel processors.
> Is this true for OmniOS as well?
> 
> I am planning to use OmniOS on an AMD processor server with ZFS+KVM+Zones
> as a virtualization host for some personal Web Servers, databases, Home
> Fileserver, Multimedia Streaming, etc..
> 
> I started with Ubuntu+KVM several years ago, then migrated to ESXi 5.x...
> Now I want to use ZFS as well. This is main reason for me to start thinking
> about Illumos based OSes.
> 
> Although ZOL is available on Ubuntu, I believe, as many others on Internet,
> ZFS on Illumos based OSes are more mature then ZOL.
> 
> If this works on AMD processor, I will start migrations as soon as
> possible...

Unless OmniTI managed to get that working (I haven't heard about anything
like that), the answer is still "no, only Intel is supported".  There have
been attempts at getting AMD support going, but I think everyone involved
gave up.

Jeff.

-- 
Intellectuals solve problems; geniuses prevent them
		- Albert Einstein

From subscriptions at e-snk.me  Sat Aug 23 14:42:04 2014
From: subscriptions at e-snk.me (Suleyman Nazif Kutlu)
Date: Sat, 23 Aug 2014 16:42:04 +0200
Subject: [OmniOS-discuss] OmniOS KVM on AMD Processor
In-Reply-To: <20140823143521.GA3300@josefsipek.net>
References: <CAO1DT2ALFNaHdzHsGMbWxQH=GN9kNUfd9uOpa8yQa2bGiYqW5w@mail.gmail.com>
	<20140823143521.GA3300@josefsipek.net>
Message-ID: <CAO1DT2D-7Q6JKu=cSFTOsxTZqMkUMALLE_62h-WenGzmrXV5kQ@mail.gmail.com>

Thanks Josef, I could not find/hear any positive / negative feedback on
Internet about KVM AMD support on Illumos based OSes (OmniOS, SmartOS, etc)
neither.

So this is what I was afraid of. Now I will switch back to backup plan ZOL
on Ubuntu / Debian :(


On Sat, Aug 23, 2014 at 4:35 PM, Josef 'Jeff' Sipek <jeffpc at josefsipek.net>
wrote:

> On Sat, Aug 23, 2014 at 04:02:26PM +0200, Suleyman Nazif Kutlu wrote:
> > Hi all,
> >
> > I am brand new to OmniOS. Reading some documentation on Internet I found
> > out that on Illumos based OSes KVM is only supported on Intel processors.
> > Is this true for OmniOS as well?
> >
> > I am planning to use OmniOS on an AMD processor server with ZFS+KVM+Zones
> > as a virtualization host for some personal Web Servers, databases, Home
> > Fileserver, Multimedia Streaming, etc..
> >
> > I started with Ubuntu+KVM several years ago, then migrated to ESXi 5.x...
> > Now I want to use ZFS as well. This is main reason for me to start
> thinking
> > about Illumos based OSes.
> >
> > Although ZOL is available on Ubuntu, I believe, as many others on
> Internet,
> > ZFS on Illumos based OSes are more mature then ZOL.
> >
> > If this works on AMD processor, I will start migrations as soon as
> > possible...
>
> Unless OmniTI managed to get that working (I haven't heard about anything
> like that), the answer is still "no, only Intel is supported".  There have
> been attempts at getting AMD support going, but I think everyone involved
> gave up.
>
> Jeff.
>
> --
> Intellectuals solve problems; geniuses prevent them
>                 - Albert Einstein
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140823/81ed859e/attachment.html>

From esproul at omniti.com  Sat Aug 23 15:23:49 2014
From: esproul at omniti.com (Eric Sproul)
Date: Sat, 23 Aug 2014 11:23:49 -0400
Subject: [OmniOS-discuss] LSI SAS3041e-HP
In-Reply-To: <02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net>
References: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>
	<20140823152213.63df2675@sleipner.datanom.net>
	<02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net>
Message-ID: <CA+QY2RRuymoRsKj4fbKmbKddSgsw46bf1afh=f_jb5knBqEYTQ@mail.gmail.com>

That generation of LSI adapters (based on SAS1064/1068 controller
chip) is supported by the legacy, closed-source "mpt" driver.  Is the
mpt driver attaching to the device at all? `modinfo | grep mpt`

If not, you might try adding its PCI ID as another alias for mpt.
You'd do that with update_drv(1M).  Check `prtconf -d` to find the ID.
If it is attaching, but the drives are not, it could well be a
firmware issue.  The "-HP" in the part name makes me suspicious that
it could have a custom HP firmware, so re-flashing it with stock LSI
firmware would be a good first step.

Note that our mpt driver, being closed-source, will never see any
further development.  If you can get your hands on a SAS2 adapter,
those are supported by the open-source (and still-developed)
mpt_sas(7D).  Good choices include those based on the SAS200{4,8} and
SAS230{4,8}, as they can have the IT firmware.  Avoid SAS210x because
they are IR-only.  The IBM M1015 is a popular version, based on the
SAS2008 chip.

Eric

From jimklimov at cos.ru  Sat Aug 23 16:56:02 2014
From: jimklimov at cos.ru (Jim Klimov)
Date: Sat, 23 Aug 2014 18:56:02 +0200
Subject: [OmniOS-discuss] OmniOS KVM on AMD Processor
In-Reply-To: <CAO1DT2D-7Q6JKu=cSFTOsxTZqMkUMALLE_62h-WenGzmrXV5kQ@mail.gmail.com>
References: <CAO1DT2ALFNaHdzHsGMbWxQH=GN9kNUfd9uOpa8yQa2bGiYqW5w@mail.gmail.com>
	<20140823143521.GA3300@josefsipek.net>
	<CAO1DT2D-7Q6JKu=cSFTOsxTZqMkUMALLE_62h-WenGzmrXV5kQ@mail.gmail.com>
Message-ID: <e3cb2083-b412-4154-a0f4-91d6f5852295@email.android.com>

23 ??????? 2014??. 16:42:04 CEST, Suleyman Nazif Kutlu <subscriptions at e-snk.me> ?????:
>Thanks Josef, I could not find/hear any positive / negative feedback on
>Internet about KVM AMD support on Illumos based OSes (OmniOS, SmartOS,
>etc)
>neither.
>
>So this is what I was afraid of. Now I will switch back to backup plan
>ZOL
>on Ubuntu / Debian :(
>
>
>On Sat, Aug 23, 2014 at 4:35 PM, Josef 'Jeff' Sipek
><jeffpc at josefsipek.net>
>wrote:
>
>> On Sat, Aug 23, 2014 at 04:02:26PM +0200, Suleyman Nazif Kutlu wrote:
>> > Hi all,
>> >
>> > I am brand new to OmniOS. Reading some documentation on Internet I
>found
>> > out that on Illumos based OSes KVM is only supported on Intel
>processors.
>> > Is this true for OmniOS as well?
>> >
>> > I am planning to use OmniOS on an AMD processor server with
>ZFS+KVM+Zones
>> > as a virtualization host for some personal Web Servers, databases,
>Home
>> > Fileserver, Multimedia Streaming, etc..
>> >
>> > I started with Ubuntu+KVM several years ago, then migrated to ESXi
>5.x...
>> > Now I want to use ZFS as well. This is main reason for me to start
>> thinking
>> > about Illumos based OSes.
>> >
>> > Although ZOL is available on Ubuntu, I believe, as many others on
>> Internet,
>> > ZFS on Illumos based OSes are more mature then ZOL.
>> >
>> > If this works on AMD processor, I will start migrations as soon as
>> > possible...
>>
>> Unless OmniTI managed to get that working (I haven't heard about
>anything
>> like that), the answer is still "no, only Intel is supported".  There
>have
>> been attempts at getting AMD support going, but I think everyone
>involved
>> gave up.
>>
>> Jeff.
>>
>> --
>> Intellectuals solve problems; geniuses prevent them
>>                 - Albert Einstein
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

Another backup plan worth consideration might be to use another hypervisor over a true illumos core, i.e. VirtualBox?
At the very least, you would also have flexible networking, benefits of ZFS and SMF integration (see http://vboxsvc.sf.net for my shameless plug), as well as ability to group VMs into local zones to run and resource-control whole independent labs, demo clusters in different datacenters, etc.

Reports vary as to whether KVM is better (might be, being a kernel service), but certaintly VBox has its good place in the ecosystem.

HTH, Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From robert at omniti.com  Sat Aug 23 17:33:48 2014
From: robert at omniti.com (Robert Treat)
Date: Sat, 23 Aug 2014 10:33:48 -0700 (PDT)
Subject: [OmniOS-discuss] OmniOS KVM on AMD Processor
In-Reply-To: <CAO1DT2D-7Q6JKu=cSFTOsxTZqMkUMALLE_62h-WenGzmrXV5kQ@mail.gmail.com>
References: <CAO1DT2D-7Q6JKu=cSFTOsxTZqMkUMALLE_62h-WenGzmrXV5kQ@mail.gmail.com>
Message-ID: <1408815227409.1715269a@Nodemailer>

I believe the last serious effort was at?https://github.com/jclulow/illumos-kvm, but as mentioned that's a few years on now (but still probably the best starting point). Personally, I don't really see AMD support coming to illumos KVM anytime soon given the lack of people willing to contribute either effort or funding to it; I can say we have no plans to work on it in the near future (we run on Intel)


Robert Treat

On Sat, Aug 23, 2014 at 10:45 AM, Suleyman Nazif Kutlu
<subscriptions at e-snk.me> wrote:

> Thanks Josef, I could not find/hear any positive / negative feedback on
> Internet about KVM AMD support on Illumos based OSes (OmniOS, SmartOS, etc)
> neither.
> So this is what I was afraid of. Now I will switch back to backup plan ZOL
> on Ubuntu / Debian :(
> On Sat, Aug 23, 2014 at 4:35 PM, Josef 'Jeff' Sipek <jeffpc at josefsipek.net>
> wrote:
>> On Sat, Aug 23, 2014 at 04:02:26PM +0200, Suleyman Nazif Kutlu wrote:
>> > Hi all,
>> >
>> > I am brand new to OmniOS. Reading some documentation on Internet I found
>> > out that on Illumos based OSes KVM is only supported on Intel processors.
>> > Is this true for OmniOS as well?
>> >
>> > I am planning to use OmniOS on an AMD processor server with ZFS+KVM+Zones
>> > as a virtualization host for some personal Web Servers, databases, Home
>> > Fileserver, Multimedia Streaming, etc..
>> >
>> > I started with Ubuntu+KVM several years ago, then migrated to ESXi 5.x...
>> > Now I want to use ZFS as well. This is main reason for me to start
>> thinking
>> > about Illumos based OSes.
>> >
>> > Although ZOL is available on Ubuntu, I believe, as many others on
>> Internet,
>> > ZFS on Illumos based OSes are more mature then ZOL.
>> >
>> > If this works on AMD processor, I will start migrations as soon as
>> > possible...
>>
>> Unless OmniTI managed to get that working (I haven't heard about anything
>> like that), the answer is still "no, only Intel is supported".  There have
>> been attempts at getting AMD support going, but I think everyone involved
>> gave up.
>>
>> Jeff.
>>
>> --
>> Intellectuals solve problems; geniuses prevent them
>>                 - Albert Einstein
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140823/cf227c06/attachment-0001.html>

From slefevre at indy.rr.com  Sun Aug 24 13:04:39 2014
From: slefevre at indy.rr.com (Scott LeFevre)
Date: Sun, 24 Aug 2014 09:04:39 -0400
Subject: [OmniOS-discuss] Install issues
Message-ID: <1408885479.23280.14.camel@exilis.si-consulting.us>

I'm setting up a physical test box and have had a bit of a difficult
time of it.

I downloaded the stable USB image (twice) and dd it to two different USB
sticks.  When I booted to either, it would go so far as showing the
SunOS banner with the copy right but it would go no further.  It showed
a cursor under the banner and I could get it to move down the screen by
pressing enter but no installer.

I then downloaded LTS USB image and dd it to one of the same USB sticks
and was able to get it to boot and install.

I'm now trying to upgrade to r151008 using
http://omnios.omniti.com/wiki.php/Upgrade_r151006_r151008.  Following
the instructions, I get to the bit below and hit a wall.  

# /usr/bin/pkg update --be-name=omnios-r151008 entire at 11,5.11-0.151008
Creating Plan -
pkg update: No matching version of entire can be installed:
  Reject:  pkg://omnios/entire at 11,5.11-0.151008:20131204T230829Z
  Reason:  All versions matching 'require' dependency pkg:/library/python-2/pycurl at 7.19.0.1,5.11-0.151008 are rejected
    Reject:  pkg://omnios/library/python-2/pycurl at 7.19.0.1,5.11-0.151008:20131204T024248Z
    Reason:  All versions matching 'require' dependency pkg:/web/curl are rejected
      Reject:  pkg://omnios/web/curl at 7.24.0,5.11-0.151002:20120401T180628Z
               pkg://omnios/web/curl at 7.24.0,5.11-0.151004:20121015T140346Z
               pkg://omnios/web/curl at 7.30.0,5.11-0.151004:20130416T172742Z
               pkg://omnios/web/curl at 7.30.0,5.11-0.151006:20130506T195707Z
               pkg://omnios/web/curl at 7.31.0,5.11-0.151006:20130703T175442Z
      Reason:  Excluded by proposed incorporation 'incorporation/jeos/omnios-userland'
               Newer version pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z is already installed
      Reject:  pkg://omnios/web/curl at 7.32.0,5.11-0.151008:20131204T025214Z
               pkg://omnios/web/curl at 7.33.0,5.11-0.151008:20131205T191134Z
      Reason:  Newer version pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z is already installed
      Reject:  pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z
               pkg://omnios/web/curl at 7.36.0,5.11-0.151008:20140414T215242Z
      Reason:  Excluded by proposed incorporation 'incorporation/jeos/omnios-userland'
    Reject:  pkg://omnios/library/python-2/pycurl at 7.19.0.1,5.11-0.151008:20131205T191236Z
    Reason:  All versions matching 'require' dependency pkg:/web/curl are rejected
  Reject:  pkg://omnios/entire at 11,5.11-0.151008:20131205T191306Z
  Reason:  All versions matching 'require' dependency pkg:/web/curl at 7.28.0,5.11-0.151008 are rejected
    Reject:  pkg://omnios/web/curl at 7.30.0,5.11-0.151004:20130416T172742Z
             pkg://omnios/web/curl at 7.30.0,5.11-0.151006:20130506T195707Z
             pkg://omnios/web/curl at 7.31.0,5.11-0.151006:20130703T175442Z
    Reason:  Excluded by proposed incorporation 'incorporation/jeos/omnios-userland'
             Newer version pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z is already installed
    Reject:  pkg://omnios/web/curl at 7.32.0,5.11-0.151008:20131204T025214Z
             pkg://omnios/web/curl at 7.33.0,5.11-0.151008:20131205T191134Z
    Reason:  Newer version pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z is already installed
    Reject:  pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z
             pkg://omnios/web/curl at 7.36.0,5.11-0.151008:20140414T215242Z
    Reason:  Excluded by proposed incorporation 'incorporation/jeos/omnios-userland'
  Reject:  pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z
  Reason:  All versions matching 'require' dependency pkg:/library/python-2/pycurl at 7.19.0.1,5.11-0.151008 are rejected
    Reject:  pkg://omnios/library/python-2/pycurl at 7.19.0.1,5.11-0.151008:20131204T024248Z
    Reason:  All versions matching 'require' dependency pkg:/web/curl are rejected
      Reject:  pkg://omnios/web/curl at 7.24.0,5.11-0.151002:20120401T180628Z
               pkg://omnios/web/curl at 7.24.0,5.11-0.151004:20121015T140346Z
               pkg://omnios/web/curl at 7.30.0,5.11-0.151004:20130416T172742Z
               pkg://omnios/web/curl at 7.30.0,5.11-0.151006:20130506T195707Z
               pkg://omnios/web/curl at 7.31.0,5.11-0.151006:20130703T175442Z
      Reason:  Excluded by proposed incorporation 'incorporation/jeos/omnios-userland'
               Newer version pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z is already installed
      Reject:  pkg://omnios/web/curl at 7.32.0,5.11-0.151008:20131204T025214Z
               pkg://omnios/web/curl at 7.33.0,5.11-0.151008:20131205T191134Z
      Reason:  Newer version pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z is already installed
      Reject:  pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z
               pkg://omnios/web/curl at 7.36.0,5.11-0.151008:20140414T215242Z
      Reason:  Excluded by proposed incorporation 'incorporation/jeos/omnios-userland'
    Reject:  pkg://omnios/library/python-2/pycurl at 7.19.0.1,5.11-0.151008:20131205T191236Z
    Reason:  All versions matching 'require' dependency pkg:/web/curl are rejected


Trying to remove the offending packages gets me know where.

# pkg uninstall web/curl library/python-2/pycurl
Creating Planpkg uninstall: Cannot remove 'pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z' due to the following packages that depend on it:
  pkg://omnios/entire at 11,5.11-0.151006:20131210T224515Z


Any suggestions on how to get to r151010 which is where I want to be?

Cheers,
-- 
Scott LeFevre
317-696-1010 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140824/2bc232d3/attachment.html>

From danmcd at omniti.com  Sun Aug 24 13:49:16 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Sun, 24 Aug 2014 09:49:16 -0400
Subject: [OmniOS-discuss] Install issues
In-Reply-To: <1408885479.23280.14.camel@exilis.si-consulting.us>
References: <1408885479.23280.14.camel@exilis.si-consulting.us>
Message-ID: <90CE75C4-DD36-459D-BC13-0964AC2B2E99@omniti.com>

First off, I'm a little surprised the r151010 stick or ISO didn't boot for you.  I've been off in bloody development, so I know THAT ISO works.

> 
> Any suggestions on how to get to r151010 which is where I want to be?

Try this:

1.) Create a new boot environment:  beadm create 010

2.) Mount it:  beadm mount 010 /mnt
    (Assuming /mnt is empty, of course.)

3.) Change the publisher on the new be:
  pkg -R /mnt set-publisher -G http://pkg.omnti.com/omnios/release/ -g http://pkg.omniti.com/omnios/r151010 omnios

4.) Upgrade the new BE:  pkg -R /mnt update

5.) Unmount the new BE:  beadm umount 010

6.) Reboot, but when GRUB shows up, select the "010" BE to test it.

If it works, you can use "beadm activate 010" to make it permanent.

Cheesy, but effective,
Dan

p.s. Technically I'm on vacation, so pardon any high latency in the followup.

From lotheac at iki.fi  Sun Aug 24 14:02:21 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Sun, 24 Aug 2014 17:02:21 +0300
Subject: [OmniOS-discuss] Install issues
In-Reply-To: <1408885479.23280.14.camel@exilis.si-consulting.us>
References: <1408885479.23280.14.camel@exilis.si-consulting.us>
Message-ID: <20140824140221.GA19603@gutsman.lotheac.fi>

On Sun, Aug 24 2014 09:04:39 -0400, Scott LeFevre wrote:
>   Reject:  pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z
>   Reason:  All versions matching 'require' dependency pkg:/library/python-2/pycurl at 7.19.0.1,5.11-0.151008 are rejected
>     Reject:  pkg://omnios/library/python-2/pycurl at 7.19.0.1,5.11-0.151008:20131204T024248Z
>     Reason:  All versions matching 'require' dependency pkg:/web/curl are rejected
>       Reject:  pkg://omnios/web/curl at 7.32.0,5.11-0.151008:20131204T025214Z
>                pkg://omnios/web/curl at 7.33.0,5.11-0.151008:20131205T191134Z
>       Reason:  Newer version pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z is already installed
>       Reject:  pkg://omnios/web/curl at 7.36.0,5.11-0.151006:20140414T214024Z
>                pkg://omnios/web/curl at 7.36.0,5.11-0.151008:20140414T215242Z
>       Reason:  Excluded by proposed incorporation 'incorporation/jeos/omnios-userland'
>     Reject:  pkg://omnios/library/python-2/pycurl at 7.19.0.1,5.11-0.151008:20131205T191236Z
>     Reason:  All versions matching 'require' dependency pkg:/web/curl are rejected

The trouble here is that r151008 does not include curl 7.36, but 151006
does (and you have that version installed, so pkg refuses to downgrade
it without you asking). I think this is a packaging bug in 151008. I
believe I worked around this by 'pkg update curl at 7.33' when I upgraded.

-- 
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet

From slefevre at indy.rr.com  Sun Aug 24 15:25:24 2014
From: slefevre at indy.rr.com (Scott LeFevre)
Date: Sun, 24 Aug 2014 11:25:24 -0400
Subject: [OmniOS-discuss] Install issues
In-Reply-To: <90CE75C4-DD36-459D-BC13-0964AC2B2E99@omniti.com>
References: <1408885479.23280.14.camel@exilis.si-consulting.us>
	<90CE75C4-DD36-459D-BC13-0964AC2B2E99@omniti.com>
Message-ID: <1408893924.23280.18.camel@exilis.si-consulting.us>

Dan,

That did the trick.  I'm up on r151010. Thanks!

BTW, can this approach (with some modification) be used to move to
OmniOS from a running install of OpenIndiana for example?

> p.s. Technically I'm on vacation, so pardon any high latency in the
followup.
I didn't see any latency at all.  Thank you for the quick response.

Cheers,
-- 
Scott LeFevre
317-696-1010 

On Sun, 2014-08-24 at 09:49 -0400, Dan McDonald wrote:

> First off, I'm a little surprised the r151010 stick or ISO didn't boot for you.  I've been off in bloody development, so I know THAT ISO works.
> 
> > 
> > Any suggestions on how to get to r151010 which is where I want to be?
> 
> Try this:
> 
> 1.) Create a new boot environment:  beadm create 010
> 
> 2.) Mount it:  beadm mount 010 /mnt
>     (Assuming /mnt is empty, of course.)
> 
> 3.) Change the publisher on the new be:
>   pkg -R /mnt set-publisher -G http://pkg.omnti.com/omnios/release/ -g http://pkg.omniti.com/omnios/r151010 omnios
> 
> 4.) Upgrade the new BE:  pkg -R /mnt update
> 
> 5.) Unmount the new BE:  beadm umount 010
> 
> 6.) Reboot, but when GRUB shows up, select the "010" BE to test it.
> 
> If it works, you can use "beadm activate 010" to make it permanent.
> 
> Cheesy, but effective,
> Dan
> 
> p.s. Technically I'm on vacation, so pardon any high latency in the followup.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140824/7a9a2023/attachment.html>

From danmcd at omniti.com  Sun Aug 24 17:59:43 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Sun, 24 Aug 2014 13:59:43 -0400
Subject: [OmniOS-discuss] Install issues
In-Reply-To: <1408893924.23280.18.camel@exilis.si-consulting.us>
References: <1408885479.23280.14.camel@exilis.si-consulting.us>
	<90CE75C4-DD36-459D-BC13-0964AC2B2E99@omniti.com>
	<1408893924.23280.18.camel@exilis.si-consulting.us>
Message-ID: <FA87FFAB-48BB-4577-9F90-EA9E38692A6B@omniti.com>


On Aug 24, 2014, at 11:25 AM, Scott LeFevre <slefevre at indy.rr.com> wrote:

> Dan,
> 
> That did the trick.  I'm up on r151010. Thanks!

That's how I bootstrap new bloody releases (e.g. 151011 from 151010).  Never done it officially moving 006/008 up to 010.

> BTW, can this approach (with some modification) be used to move to OmniOS from a running install of OpenIndiana for example?

I don't think so, because:

	1.) OI uses a different package name, numbering, and possibly even contents in some corner cases.

	2.) I've never tried anything even close to it.

I moved my home server from OI to OmniOS when I started work here (see http://kebesays.blogspot.com/2014/06/home-data-center-20-dogfooding-again.html), and I just exported the data pool, reinstalled the system, took config files by hand from the OI rpool, and moved forward.

I'm VERY glad the alt-BE approach worked out okay.  I also use that approach to upgrade my zones.  The downside to that is if you have operational data in the rpool/BE, it won't all move over when you upgrade.  The OmniOS wiki recommendation for upgrading zones mitigates operational amnesia, at the cost of downtime.

Dan


From jeffpc at josefsipek.net  Mon Aug 25 14:06:22 2014
From: jeffpc at josefsipek.net (Josef 'Jeff' Sipek)
Date: Mon, 25 Aug 2014 10:06:22 -0400
Subject: [OmniOS-discuss] Install issues
In-Reply-To: <FA87FFAB-48BB-4577-9F90-EA9E38692A6B@omniti.com>
References: <1408885479.23280.14.camel@exilis.si-consulting.us>
	<90CE75C4-DD36-459D-BC13-0964AC2B2E99@omniti.com>
	<1408893924.23280.18.camel@exilis.si-consulting.us>
	<FA87FFAB-48BB-4577-9F90-EA9E38692A6B@omniti.com>
Message-ID: <20140825140622.GB997@meili>

On Sun, Aug 24, 2014 at 01:59:43PM -0400, Dan McDonald wrote:
> 
> On Aug 24, 2014, at 11:25 AM, Scott LeFevre <slefevre at indy.rr.com> wrote:
> 
> > Dan,
> > 
> > That did the trick.  I'm up on r151010. Thanks!
> 
> That's how I bootstrap new bloody releases (e.g. 151011 from 151010).
> Never done it officially moving 006/008 up to 010.
> 
> > BTW, can this approach (with some modification) be used to move to
> > OmniOS from a running install of OpenIndiana for example?
> 
> I don't think so, because:
> 
> 	1.) OI uses a different package name, numbering, and possibly even
> 	contents in some corner cases.
> 
> 	2.) I've never tried anything even close to it.

The closest to anything like that I've done was going from OpenIndiana to
OpenIndiana Hipster in a clean-slate way.

It basically consisted of:

(1) create a new be

(2) zfs destroy it

(3) zfs create the same-named dataset and set org.opensolaris.libbe:uuid to
    the same value as before

(4) beadm mount hipster

(5) pkg -R /tmp/XYZ image-create

(6) pkg -R /tmp/XYZ install slim_install

(7) bootadm update-archive -R /tmp/XYZ

(8) modify a bunch of config files in /tmp/XYZ/etc  (hostname, passwd,
    shadow, etc.)

(9) do a symlink dance in /tmp/XYZ/etc/svc

(10) reboot

Ok, I actually had to boot into the old BE a couple of times because I kept
forgetting to set some things (like root password - oops!).  If you dig up
the omnios install scripts, you can get enough of an idea how to make smf
happy enough to start.

I did this instead of a plain ol' reinstall because I didn't want to lose a
working system.  With this complicated way, I could always go back to my OI
BE.  I did not have to repartition or recreate the rpool - that was the
other goal.

Jeff

-- 
Computer Science is no more about computers than astronomy is about
telescopes.
		- Edsger Dijkstra

From keith at paskett.org  Tue Aug 26 00:38:27 2014
From: keith at paskett.org (Keith Paskett)
Date: Mon, 25 Aug 2014 18:38:27 -0600
Subject: [OmniOS-discuss] Install issues
In-Reply-To: <1408885479.23280.14.camel@exilis.si-consulting.us>
References: <1408885479.23280.14.camel@exilis.si-consulting.us>
Message-ID: <8DAA06AB-8D4E-45F0-91D1-06332D954BFB@paskett.org>

Just a note, that I have had the same issue with r151010 hanging after the copyright notice.
I have the issue when booting from CD on several different SunFIre servers. They are X4150s and X4250s.
I have not yet tried on other systems. 
----
Keith Paskett

On Aug 24, 2014, at 7:04 AM, Scott LeFevre <slefevre at indy.rr.com> wrote:

> I'm setting up a physical test box and have had a bit of a difficult time of it.
> 
> I downloaded the stable USB image (twice) and dd it to two different USB sticks.  When I booted to either, it would go so far as showing the SunOS banner with the copy right but it would go no further.  It showed a cursor under the banner and I could get it to move down the screen by pressing enter but no installer.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140825/08293db7/attachment.bin>

From fabio at fabiorabelo.wiki.br  Tue Aug 26 22:23:18 2014
From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=)
Date: Tue, 26 Aug 2014 19:23:18 -0300
Subject: [OmniOS-discuss] LSI SAS3041e-HP
In-Reply-To: <CA+QY2RRuymoRsKj4fbKmbKddSgsw46bf1afh=f_jb5knBqEYTQ@mail.gmail.com>
References: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>
	<20140823152213.63df2675@sleipner.datanom.net>
	<02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net>
	<CA+QY2RRuymoRsKj4fbKmbKddSgsw46bf1afh=f_jb5knBqEYTQ@mail.gmail.com>
Message-ID: <CAEekY64ws9mY61aB3otSXduDtrYC3DYjfJ17Zg1SaLxicqrFOw@mail.gmail.com>

Ok, some things I did not see at first .

After a long day trying to flash this card, I entered in it's own
utility, and ti identifies itself as SAS1064E-IR, even if all printed
ithe board says is is a 3041 .

So it is probably my issue ....

So, how I can flash a 1064E-IR to became a 1064E-IT ?

Thanks in advance all the tips and info ....


F?bio Rabelo



2014-08-23 12:23 GMT-03:00 Eric Sproul <esproul at omniti.com>:
> That generation of LSI adapters (based on SAS1064/1068 controller
> chip) is supported by the legacy, closed-source "mpt" driver.  Is the
> mpt driver attaching to the device at all? `modinfo | grep mpt`
>
> If not, you might try adding its PCI ID as another alias for mpt.
> You'd do that with update_drv(1M).  Check `prtconf -d` to find the ID.
> If it is attaching, but the drives are not, it could well be a
> firmware issue.  The "-HP" in the part name makes me suspicious that
> it could have a custom HP firmware, so re-flashing it with stock LSI
> firmware would be a good first step.
>
> Note that our mpt driver, being closed-source, will never see any
> further development.  If you can get your hands on a SAS2 adapter,
> those are supported by the open-source (and still-developed)
> mpt_sas(7D).  Good choices include those based on the SAS200{4,8} and
> SAS230{4,8}, as they can have the IT firmware.  Avoid SAS210x because
> they are IR-only.  The IBM M1015 is a popular version, based on the
> SAS2008 chip.
>
> Eric
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From rafibeyli at gmail.com  Wed Aug 27 11:25:44 2014
From: rafibeyli at gmail.com (Hafiz Rafibeyli)
Date: Wed, 27 Aug 2014 14:25:44 +0300 (EEST)
Subject: [OmniOS-discuss] Micron P420M 700GB L2ARC
In-Reply-To: <1787416942.522537.1409138523998.JavaMail.zimbra@cantekstil.com.tr>
Message-ID: <1165423980.522633.1409138744764.JavaMail.zimbra@cantekstil.com.tr>

Hello,

anyone have experience with  Micron P420M 700GB(MTFDGAR700MAX-1AG1Z) as a L2ARC device?

is it supported by illumos or omnios?


regards

Hafiz.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From esproul at omniti.com  Wed Aug 27 13:49:50 2014
From: esproul at omniti.com (Eric Sproul)
Date: Wed, 27 Aug 2014 09:49:50 -0400
Subject: [OmniOS-discuss] LSI SAS3041e-HP
In-Reply-To: <CAEekY64ws9mY61aB3otSXduDtrYC3DYjfJ17Zg1SaLxicqrFOw@mail.gmail.com>
References: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>
	<20140823152213.63df2675@sleipner.datanom.net>
	<02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net>
	<CA+QY2RRuymoRsKj4fbKmbKddSgsw46bf1afh=f_jb5knBqEYTQ@mail.gmail.com>
	<CAEekY64ws9mY61aB3otSXduDtrYC3DYjfJ17Zg1SaLxicqrFOw@mail.gmail.com>
Message-ID: <CA+QY2RRp_YrJ-R58yweSxgH3xdVJ5MHMLRqD4LC1c7PU8xj=WQ@mail.gmail.com>

On Tue, Aug 26, 2014 at 6:23 PM, F?bio Rabelo <fabio at fabiorabelo.wiki.br> wrote:
> Ok, some things I did not see at first .
>
> After a long day trying to flash this card, I entered in it's own
> utility, and ti identifies itself as SAS1064E-IR, even if all printed
> ithe board says is is a 3041 .

You are confusing a product model with the controller chip it
contains.  The LSI 3041 HBA uses the SAS1064E controller chip.  I have
a stock LSI-branded version of this card.  It is printed with "LSI
3041E-R" but the controller chip itself is "SAS1064E".

>
> So it is probably my issue ....
>
> So, how I can flash a 1064E-IR to became a 1064E-IT ?

The download link that Michael posted earlier in this thread shows
"SAS3041ER_ Package_P21_IR_IT_Firmware_BIOS_for_MSDOS_Windows" which
should contain both the IR and IT firmware images.  The "SASFlash
Quick Reference Guide" also on that page should have the instructions,
if they are not included with the firmware.  This all assumes that
your HP-branded card is identical hardware to a stock LSI-branded
part, and simply has custom firmware on it, which should be able to be
replaced with the stock firmware.  None of us know if that is actually
the case, though, so the best we can say is "try it and find out".

Eric

From groups at tierarzt-mueller.de  Wed Aug 27 17:47:55 2014
From: groups at tierarzt-mueller.de (Alexander Lesle)
Date: Wed, 27 Aug 2014 19:47:55 +0200
Subject: [OmniOS-discuss] LSI SAS3041e-HP
In-Reply-To: <CAEekY64ws9mY61aB3otSXduDtrYC3DYjfJ17Zg1SaLxicqrFOw@mail.gmail.com>
References: <CAEekY66=sS-6gtMtgGNdDMeBCrisR_V00WpUzi7+=iuXL2fMCQ@mail.gmail.com>
	<20140823152213.63df2675@sleipner.datanom.net>
	<02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net>
	<CA+QY2RRuymoRsKj4fbKmbKddSgsw46bf1afh=f_jb5knBqEYTQ@mail.gmail.com>
	<CAEekY64ws9mY61aB3otSXduDtrYC3DYjfJ17Zg1SaLxicqrFOw@mail.gmail.com>
Message-ID: <1113899755.20140827194755@tierarzt-mueller.de>

Hello F?bio,

first download on the LSI website:
http://www.lsi.com/support/pages/download-results.aspx?component=Storage+Component&productfamily=Legacy+Host+Bus+Adapters&productcode=P00056&assettype=Firmware&productname=LSI+SAS+3041E-R
this two files:

SAS3041ER_ Package_P21_IR_IT_Firmware_BIOS_for_MSDOS_Windows
http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapters%20Common%20Files/SAS_SATA_3G_P21/SAS3041ER_%20Package_P21_IR_IT_Firmware_BIOS_for_MSDOS_Windows.zip
SASFlash Quick Reference Guide
http://www.lsi.com/downloads/Public/Obsolete/Obsolete%20Common%20Files/SASFlash_Ref_Guide.zip

Unzip the first file and copy all the files not the folders on your
USB-Stick - in a new folder e.g. named "sas3041" not more than 8
letters.
Boot to DOS, switch to c:\sas3041 and first I recommend to do
'sasflash -list' and write down all infos about the card first.
You know now the Chip Version and the SAS Address.

Now you can run the 'hbaFlash.bat', select CardType, PCIType, IT-Mode
and Chipversion.
The batch first flash the Firmware and here you get maybe a message that
the ProduktID an VendorID does not match. Type Y to flash anyway.
After flashing Firmware you MUST get the message "Firmware Flash
Successful"
the same with the second flash BIOS you MUST get the successfull
message too and "Finished Processing Commands Successfully".
You have done your card is now in IT-Mode and reflashed to LSI.

When sasflash breaks and you cant flash the card because it is
branded to HP - you have to erase the card first.
Reboot than 'sasflash -o -e X' X=Parameter
I always use Parameter=6 when I want to reflash to a LSI card.
Do NOT reboot after erase - run the batch file and than set the
SAS Address with 'sasflash -o -sasadd 500x' (x= numbers for SAS address)
You have done.

Check the driver - see Eric Sproul's recommendation yesterday.
If OmniOS use the driver mpt I would check it out
Parameter=7 to change to mpt_sas.

Good luck. :)

am Mittwoch, 27. August 2014 um 00:23 hat <F?bio Rabelo> u.a.
in mid:CAEekY64ws9mY61aB3otSXduDtrYC3DYjfJ17Zg1SaLxicqrFOw at mail.gmail.com geschrieben:

> So, how I can flash a 1064E-IR to became a 1064E-IT ?
-- 
Mit freundlichem Gruss
Alexander
mailto:groups at tierarzt-mueller.de
eMail geschrieben mit: The Bat! 5.8.8
unter Windows 7 Pro Service Pack 1



From piiv at zhaw.ch  Thu Aug 28 08:43:24 2014
From: piiv at zhaw.ch (Vincenzo Pii)
Date: Thu, 28 Aug 2014 10:43:24 +0200
Subject: [OmniOS-discuss]  High Availability and clustering on OmniOS
Message-ID: <CALOiZS2_sF5Vreo+E1tp4_PQ9VZXBo91qJXpxu=dafbENUXTgQ@mail.gmail.com>

Hello,

What software/technologies can be used on OmniOS to get an active/passive
setup between two (OmniOS) nodes?

Basically, one node should be up and running all the time and, in case of
failures, the second one should take over transparently.

Is the IHAC project (https://www.illumos.org/projects/ihac) still alive or
forked and maintained somewhere else? When trying to access the Repository
I get a 404...

Many thanks,
Vincenzo.

-- 
Vincenzo Pii
Researcher, InIT Cloud Computing Lab
Zurich University of Applied Sciences (ZHAW)
http://www.cloudcomp.ch/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140828/65fbb7ce/attachment.html>

From jesus at omniti.com  Thu Aug 28 10:24:17 2014
From: jesus at omniti.com (Theo Schlossnagle)
Date: Thu, 28 Aug 2014 06:24:17 -0400
Subject: [OmniOS-discuss] High Availability and clustering on OmniOS
In-Reply-To: <CALOiZS2_sF5Vreo+E1tp4_PQ9VZXBo91qJXpxu=dafbENUXTgQ@mail.gmail.com>
References: <CALOiZS2_sF5Vreo+E1tp4_PQ9VZXBo91qJXpxu=dafbENUXTgQ@mail.gmail.com>
Message-ID: <CACLsAptVZ5kSU3FdBQLbL-ez6gWC0WHX85kuwJyeUadPQK+yCQ@mail.gmail.com>

It depends on what services you are intending to make highly available. We
do this got load balancing, http acceleration and nat using vippy. It is
not really suited toward making services like NFS fail over.
On Aug 28, 2014 4:47 AM, "Vincenzo Pii" <piiv at zhaw.ch> wrote:

> Hello,
>
> What software/technologies can be used on OmniOS to get an active/passive
> setup between two (OmniOS) nodes?
>
> Basically, one node should be up and running all the time and, in case of
> failures, the second one should take over transparently.
>
> Is the IHAC project (https://www.illumos.org/projects/ihac) still alive
> or forked and maintained somewhere else? When trying to access the
> Repository I get a 404...
>
> Many thanks,
> Vincenzo.
>
> --
> Vincenzo Pii
> Researcher, InIT Cloud Computing Lab
> Zurich University of Applied Sciences (ZHAW)
> http://www.cloudcomp.ch/
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140828/7c54eb79/attachment-0001.html>

From jimklimov at cos.ru  Thu Aug 28 11:26:31 2014
From: jimklimov at cos.ru (Jim Klimov)
Date: Thu, 28 Aug 2014 13:26:31 +0200
Subject: [OmniOS-discuss] High Availability and clustering on OmniOS
In-Reply-To: <CACLsAptVZ5kSU3FdBQLbL-ez6gWC0WHX85kuwJyeUadPQK+yCQ@mail.gmail.com>
References: <CALOiZS2_sF5Vreo+E1tp4_PQ9VZXBo91qJXpxu=dafbENUXTgQ@mail.gmail.com>
	<CACLsAptVZ5kSU3FdBQLbL-ez6gWC0WHX85kuwJyeUadPQK+yCQ@mail.gmail.com>
Message-ID: <5ef7d23c-3ab5-4cd8-a2af-32fd05f95f65@email.android.com>

28 ??????? 2014??. 12:24:17 CEST, Theo Schlossnagle <jesus at omniti.com> ?????:
>It depends on what services you are intending to make highly available.
>We
>do this got load balancing, http acceleration and nat using vippy. It
>is
>not really suited toward making services like NFS fail over.
>On Aug 28, 2014 4:47 AM, "Vincenzo Pii" <piiv at zhaw.ch> wrote:
>
>> Hello,
>>
>> What software/technologies can be used on OmniOS to get an
>active/passive
>> setup between two (OmniOS) nodes?
>>
>> Basically, one node should be up and running all the time and, in
>case of
>> failures, the second one should take over transparently.
>>
>> Is the IHAC project (https://www.illumos.org/projects/ihac) still
>alive
>> or forked and maintained somewhere else? When trying to access the
>> Repository I get a 404...
>>
>> Many thanks,
>> Vincenzo.
>>
>> --
>> Vincenzo Pii
>> Researcher, InIT Cloud Computing Lab
>> Zurich University of Applied Sciences (ZHAW)
>> http://www.cloudcomp.ch/
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OmniOS-discuss mailing list
>OmniOS-discuss at lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss

Probably, something of the kind might be done by serving the applications/databases/etc. from local zones, hosted along with HA data on storage equally available to two head-nodes.

Then the failover is about grabbing the pool, and starting the zones. Securely mastering the zfs pool, as well as STONITH and fencing is the tricky part. 

Firing up the services (pool and zones and maybe VMs) is simple and can be SMFized to do in proper order as dependencies are met, I blogged on that with code snippets in OI/illumos wikis somewhere ;)

HTH, Jim
--
Typos courtesy of K-9 Mail on my Samsung Android

From piiv at zhaw.ch  Thu Aug 28 12:03:09 2014
From: piiv at zhaw.ch (Vincenzo Pii)
Date: Thu, 28 Aug 2014 14:03:09 +0200
Subject: [OmniOS-discuss] High Availability and clustering on OmniOS
In-Reply-To: <afdd285066144ed9b94a500a64806a9d@SRV-MAIL-001.zhaw.ch>
References: <CALOiZS2_sF5Vreo+E1tp4_PQ9VZXBo91qJXpxu=dafbENUXTgQ@mail.gmail.com>
	<CACLsAptVZ5kSU3FdBQLbL-ez6gWC0WHX85kuwJyeUadPQK+yCQ@mail.gmail.com>
	<afdd285066144ed9b94a500a64806a9d@SRV-MAIL-001.zhaw.ch>
Message-ID: <CALOiZS24iKiE1O9QGLEgXD79G1B0wq8h-FKENrD-ruWNx_YwMw@mail.gmail.com>

2014-08-28 13:26 GMT+02:00 Jim Klimov <jimklimov at cos.ru>:

> 28 ??????? 2014 ?. 12:24:17 CEST, Theo Schlossnagle <jesus at omniti.com>
> ?????:
> >It depends on what services you are intending to make highly available.
> >We
> >do this got load balancing, http acceleration and nat using vippy. It
> >is
> >not really suited toward making services like NFS fail over.
> >On Aug 28, 2014 4:47 AM, "Vincenzo Pii" <piiv at zhaw.ch> wrote:
> >
> >> Hello,
> >>
> >> What software/technologies can be used on OmniOS to get an
> >active/passive
> >> setup between two (OmniOS) nodes?
> >>
> >> Basically, one node should be up and running all the time and, in
> >case of
> >> failures, the second one should take over transparently.
> >>
> >> Is the IHAC project (https://www.illumos.org/projects/ihac) still
> >alive
> >> or forked and maintained somewhere else? When trying to access the
> >> Repository I get a 404...
> >>
> >> Many thanks,
> >> Vincenzo.
> >>
> >> --
> >> Vincenzo Pii
> >> Researcher, InIT Cloud Computing Lab
> >> Zurich University of Applied Sciences (ZHAW)
> >> http://www.cloudcomp.ch/
> >>
> >> _______________________________________________
> >> OmniOS-discuss mailing list
> >> OmniOS-discuss at lists.omniti.com
> >> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >>
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >OmniOS-discuss mailing list
> >OmniOS-discuss at lists.omniti.com
> >http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
> Probably, something of the kind might be done by serving the
> applications/databases/etc. from local zones, hosted along with HA data on
> storage equally available to two head-nodes.
>
> Then the failover is about grabbing the pool, and starting the zones.
> Securely mastering the zfs pool, as well as STONITH and fencing is the
> tricky part.
>
> Firing up the services (pool and zones and maybe VMs) is simple and can be
> SMFized to do in proper order as dependencies are met, I blogged on that
> with code snippets in OI/illumos wikis somewhere ;)
>
> HTH, Jim
> --
> Typos courtesy of K-9 Mail on my Samsung Android
>


How would you detect a failure in this case?
I mean, which clustering software would you use for this scenario?

Many thanks!

-- 
Vincenzo Pii
Researcher, InIT Cloud Computing Lab
Zurich University of Applied Sciences (ZHAW)
http://www.cloudcomp.ch/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140828/915c73bb/attachment.html>

From richard.elling at richardelling.com  Thu Aug 28 17:13:37 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Thu, 28 Aug 2014 10:13:37 -0700
Subject: [OmniOS-discuss] High Availability and clustering on OmniOS
In-Reply-To: <CALOiZS2_sF5Vreo+E1tp4_PQ9VZXBo91qJXpxu=dafbENUXTgQ@mail.gmail.com>
References: <CALOiZS2_sF5Vreo+E1tp4_PQ9VZXBo91qJXpxu=dafbENUXTgQ@mail.gmail.com>
Message-ID: <B540D186-E122-4474-AB2D-560B10DBDCA7@richardelling.com>

On Aug 28, 2014, at 1:43 AM, Vincenzo Pii <piiv at zhaw.ch> wrote:

> Hello,
> 
> What software/technologies can be used on OmniOS to get an active/passive setup between two (OmniOS) nodes?
> 
> Basically, one node should be up and running all the time and, in case of failures, the second one should take over transparently.
> 
> Is the IHAC project (https://www.illumos.org/projects/ihac) still alive or forked and maintained somewhere else? When trying to access the Repository I get a 404...

The old project  was Open[Solaris] High Availability Cluster (OHAC). It isn't worth thinkering
with: too complex and overkill for just HA failover (I know, I wrote the book on SunCluster 3, way
back when...)

For a commercially supported product, take a look at High Availability Computing's RSF-1,
www.high-availability.com. 

For DIY, Saso wrote up a how-to using pacemaker and blogged about it.
http://zfs-create.blogspot.com/2013/06/building-zfs-storage-appliance-part-1.html

Be aware that there are a lot of alligators in the waters around building HA systems, many
of which are not in the OS software, but the OS has to deal with the "anomalies, lies, and
damn lies" from the hardware/firmware/BIOS/cables/drives/NICs/etc. If downtime costs you
money, then it is worth getting involved with domain experts -- those who know the idiosyncracies
of the environments.
 -- richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140828/76d43b67/attachment.html>

From lotheac at iki.fi  Fri Aug 29 06:55:11 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Fri, 29 Aug 2014 09:55:11 +0300
Subject: [OmniOS-discuss] user_attr.d directory shipped, but not functional
Message-ID: <20140829065511.GA17957@gutsman.lotheac.fi>

I don't know whether this is a distribution bug or exists in upstream
illumos so I'm reporting it here.

I assumed since the base install, ie. pkg:/SUNWcs, ships
{auth,exec,prof,user}_attr.d directories and a file in them, that you
could drop a file in one of them and have it function similarly to
appending to the _attr file. This is, however, not the case for at least
user_attr:

gutsman /etc # useradd foo
gutsman /etc # auths foo                          
solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
gutsman /etc # echo 'foo::::type=normal;auths=bar' > user_attr.d/foo
gutsman /etc # auths foo
solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
gutsman /etc # cat user_attr.d/foo >> user_attr
gutsman /etc # auths foo                       
bar,solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read

A quick look also didn't turn up any code that would handle these
directories (but I can be wrong). I think that these directories should
not be shipped at all -- it could lead to security problems in the worst
case (think shipping a setuid binary and a file in exec_attr.d to set
Forced Privilege on it; I actually did this in one of our packages but I
guess it's probably not limiting privileges at all).

The .d directories are not referenced in any manual pages, though, but
it's still a bad idea to ship files which serve no purpose (as far as I
can tell :) and may confuse users.

-- 
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet

From peter.tribble at gmail.com  Fri Aug 29 07:52:41 2014
From: peter.tribble at gmail.com (Peter Tribble)
Date: Fri, 29 Aug 2014 08:52:41 +0100
Subject: [OmniOS-discuss] user_attr.d directory shipped,
	but not functional
In-Reply-To: <20140829065511.GA17957@gutsman.lotheac.fi>
References: <20140829065511.GA17957@gutsman.lotheac.fi>
Message-ID: <CAEgYsbHVJypg8dhPofUWA=c1Pg2SO-3cWA17o=3rF80sMAY7DQ@mail.gmail.com>

On Fri, Aug 29, 2014 at 7:55 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:

> I don't know whether this is a distribution bug or exists in upstream
> illumos so I'm reporting it here.
>
> I assumed since the base install, ie. pkg:/SUNWcs, ships
> {auth,exec,prof,user}_attr.d directories and a file in them, that you
> could drop a file in one of them and have it function similarly to
> appending to the _attr file. This is, however, not the case for at least
> user_attr:
>

The directories contains fragments that are used as part of self
assembly to construct the resulting file (and it's the file such as
/etc/user_attr that is actually used by the system).

So, if you add additional files into these directories, you need to
trigger self-assembly. Normally, packages delivering additional
fragments to these .d directories will do so automatically, but
otherwise you can force the update yourself:

svcadm restart rbac


> gutsman /etc # useradd foo
> gutsman /etc # auths foo
>
> solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
> gutsman /etc # echo 'foo::::type=normal;auths=bar' > user_attr.d/foo
> gutsman /etc # auths foo
>
> solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
> gutsman /etc # cat user_attr.d/foo >> user_attr
> gutsman /etc # auths foo
>
> bar,solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
>
> A quick look also didn't turn up any code that would handle these
> directories (but I can be wrong). I think that these directories should
> not be shipped at all -- it could lead to security problems in the worst
> case (think shipping a setuid binary and a file in exec_attr.d to set
> Forced Privilege on it; I actually did this in one of our packages but I
> guess it's probably not limiting privileges at all).
>
> The .d directories are not referenced in any manual pages, though, but
> it's still a bad idea to ship files which serve no purpose (as far as I
> can tell :) and may confuse users.
>
> --
> Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140829/a8803b6e/attachment-0001.html>

From lotheac at iki.fi  Fri Aug 29 12:52:36 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Fri, 29 Aug 2014 15:52:36 +0300
Subject: [OmniOS-discuss] user_attr.d directory shipped,
 but not functional
In-Reply-To: <CAEgYsbHVJypg8dhPofUWA=c1Pg2SO-3cWA17o=3rF80sMAY7DQ@mail.gmail.com>
References: <20140829065511.GA17957@gutsman.lotheac.fi>
	<CAEgYsbHVJypg8dhPofUWA=c1Pg2SO-3cWA17o=3rF80sMAY7DQ@mail.gmail.com>
Message-ID: <20140829125236.GB17957@gutsman.lotheac.fi>

On Fri, Aug 29 2014 08:52:41 +0100, Peter Tribble wrote:
> The directories contains fragments that are used as part of self
> assembly to construct the resulting file (and it's the file such as
> /etc/user_attr that is actually used by the system).
> 
> So, if you add additional files into these directories, you need to
> trigger self-assembly. Normally, packages delivering additional
> fragments to these .d directories will do so automatically, but
> otherwise you can force the update yourself:
> 
> svcadm restart rbac

Ah, thanks, that makes sense! Maybe this just needs documentation
then? :)

-- 
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet

