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: 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: 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: 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 ::.." 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: 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: References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local> 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 ::.." > 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: 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> <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local> Message-ID: 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 ::.." 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 ::.." 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: 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> <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local> Message-ID: 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 ::.. : > 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 ::.." 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: 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: References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local> <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local> 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 ::.. : > > > > > 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 ::.." 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: 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> <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local> <1407271959.4138.73.camel@exilis.si-consulting.us> Message-ID: 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 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 ::.. : > > > 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 ::.." 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: 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: References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local> <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local> Message-ID: On Aug 5, 2014, at 4:43 PM, G?nther Alka 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: References: <356582D1FC91784992ABB4265A16ED4856EE93E2@vEX01.mindstorm-internet.local> <356582D1FC91784992ABB4265A16ED4856EEA595@vEX01.mindstorm-internet.local> <1407271959.4138.73.camel@exilis.si-consulting.us> Message-ID: On Aug 5, 2014, at 8:38 PM, Schweiss, Chip 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: 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: References: Message-ID: On Aug 6, 2014, at 12:58 PM, Dan McDonald 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: 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 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 : > 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: 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: 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: 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: On Aug 7, 2014, at 3:41 PM, Paul B. Henson 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: 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: 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: References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com> Message-ID: 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: References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com> Message-ID: 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: References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com> Message-ID: Hi, On 8 August 2014 15:06, Eric Sproul 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: References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com> Message-ID: On Aug 8, 2014, at 10:10 AM, Stephen Nelson-Smith wrote: > Hi, > > On 8 August 2014 15:06, Eric Sproul wrote: >> IMHO the existence of an FTP daemon in the base OS runs counter to the >> OmniOS minimalist philosophy. > > +1 for me. 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: References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com> Message-ID: > On Aug 8, 2014, at 7:33 AM, Dan McDonald wrote: > > >> On Aug 8, 2014, at 10:10 AM, Stephen Nelson-Smith wrote: >> >> Hi, >> >>> On 8 August 2014 15:06, Eric Sproul wrote: >>> IMHO the existence of an FTP daemon in the base OS runs counter to the >>> OmniOS minimalist philosophy. >> >> +1 for me. > > > > 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: References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com> Message-ID: On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling 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: References: <93BA3994-B937-4594-B3B6-8D20A6EF4D08@omniti.com> Message-ID: <94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com> On Aug 8, 2014, at 11:08 AM, Eric Sproul wrote: > On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling > 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> <94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com> Message-ID: <3bf380759ffc0c416700107b3f1525c5.squirrel@webmail.druber.com> > > On Aug 8, 2014, at 11:08 AM, Eric Sproul wrote: > >> On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling >> 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> <94B78A7B-4DDB-4FAA-8584-7B6232CF0F40@omniti.com> Message-ID: On Fri, Aug 8, 2014 at 4:09 PM, Dan McDonald wrote: > > On Aug 8, 2014, at 11:08 AM, Eric Sproul wrote: > > > On Fri, Aug 8, 2014 at 10:43 AM, Richard Elling > > 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: 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: References: 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 To: omnios-discuss at lists.omniti.com Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool Message-ID: 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 To: "OmniOS-discuss at lists.omniti.com" Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup tool Message-ID: Content-Type: text/plain; charset="utf-8" Awesome! On Tue, Jul 29, 2014 at 11:50 AM, Tobias Oetiker 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: ------------------------------ Message: 3 Date: Tue, 29 Jul 2014 17:59:18 +0200 From: Saso Kiselkov 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 To: Richard Elling Cc: omnios-discuss Subject: Re: [OmniOS-discuss] Slow scrub performance Message-ID: 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: ------------------------------ 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: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> Message-ID: 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 > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool > Message-ID: > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6247 bytes Desc: not available URL: 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: 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: References: <3BE0DEED8863E5429BAE4CAEDF624565036504804F59@AIRA-SRV.aira.local> 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: 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: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> 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" To: "Hafiz Rafibeyli" 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 > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool > Message-ID: > 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: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> Message-ID: OmniOS ships with pipeviewer (pv), if you use pv -s , it would have close to the same effect as using mbuffer. On Mon, Aug 11, 2014 at 2:06 AM, 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? > > 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 > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool > Message-ID: > 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 > To: "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 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: < > https://omniosce.org/ml-archive/attachments/20140729/f8adbbf5/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 29 Jul 2014 17:59:18 +0200 > From: Saso Kiselkov > 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 > To: Richard Elling > Cc: omnios-discuss > 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: < > https://omniosce.org/ml-archive/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: 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: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> Message-ID: 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 , it > would have close to the same effect as using mbuffer. > > > On Mon, Aug 11, 2014 at 2:06 AM, 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? > > > > 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 > > To: omnios-discuss at lists.omniti.com > > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool > > Message-ID: > > 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 > > To: "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 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: < > > https://omniosce.org/ml-archive/attachments/20140729/f8adbbf5/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 29 Jul 2014 17:59:18 +0200 > > From: Saso Kiselkov > > 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 > > To: Richard Elling > > Cc: omnios-discuss > > 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: < > > https://omniosce.org/ml-archive/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: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> Message-ID: 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" > To: "Hafiz Rafibeyli" > 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 > > To: omnios-discuss at lists.omniti.com > > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool > > Message-ID: > > 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: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> 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" To: "Hafiz Rafibeyli" 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" > To: "Hafiz Rafibeyli" > 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 > > To: omnios-discuss at lists.omniti.com > > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool > > Message-ID: > > 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: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> Message-ID: 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" > To: "Hafiz Rafibeyli" > 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" > > To: "Hafiz Rafibeyli" > > 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 > > > To: omnios-discuss at lists.omniti.com > > > Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool > > > Message-ID: > > > 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: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> Message-ID: On Mon, 11 Aug 2014, Theo Schlossnagle wrote: > OmniOS ships with pipeviewer (pv), if you use pv -s , 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: 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 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: 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 > 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: 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: 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: References: 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: 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: References: 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 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 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 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 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: 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 on behalf of Paul B. Henson 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: 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 wrote: > > On Aug 13, 2014, at 4:43 PM, Matthew Mabis 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: 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: 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: 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: References: Message-ID: 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 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: 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: 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: 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: References: Message-ID: 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: 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: References: Message-ID: 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 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: 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: 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: 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: References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local> 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 To: 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 http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: 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> <202C92988C5CF249BD3F9F21B2B199CB33D225B2@SPMAIL1.spae.local> Message-ID: 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: References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local> <202C92988C5CF249BD3F9F21B2B199CB33D225B2@SPMAIL1.spae.local> 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: -----"OmniOS-discuss" skrev: ----- Till: "'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 “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? ? 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: References: <202C92988C5CF249BD3F9F21B2B199CB33D21079@SPMAIL1.spae.local> 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" skrev: ----- Till: "'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 “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? ? 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: 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: 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: References: Message-ID: 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: 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: 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: References: Message-ID: <20140823152213.63df2675@sleipner.datanom.net> On Sat, 23 Aug 2014 09:46:00 -0300 F?bio Rabelo 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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: <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 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 rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras 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: 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: 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: References: 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: <20140823143521.GA3300@josefsipek.net> Message-ID: 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 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: 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: <20140823152213.63df2675@sleipner.datanom.net> <02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net> Message-ID: 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: References: <20140823143521.GA3300@josefsipek.net> Message-ID: 23 ??????? 2014??. 16:42:04 CEST, Suleyman Nazif Kutlu ?????: >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 > >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: References: 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 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 > 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: 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: 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: 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: On Aug 24, 2014, at 11:25 AM, Scott LeFevre 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: 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: <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 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 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: 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: References: <20140823152213.63df2675@sleipner.datanom.net> <02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net> Message-ID: 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 : > 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: References: <20140823152213.63df2675@sleipner.datanom.net> <02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net> Message-ID: On Tue, Aug 26, 2014 at 6:23 PM, F?bio Rabelo 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: References: <20140823152213.63df2675@sleipner.datanom.net> <02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net> 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 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: 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: 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: References: Message-ID: 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" 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: 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: References: Message-ID: <5ef7d23c-3ab5-4cd8-a2af-32fd05f95f65@email.android.com> 28 ??????? 2014??. 12:24:17 CEST, Theo Schlossnagle ?????: >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" 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: References: Message-ID: 2014-08-28 13:26 GMT+02:00 Jim Klimov : > 28 ??????? 2014 ?. 12:24:17 CEST, Theo Schlossnagle > ?????: > >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" 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: 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: References: Message-ID: On Aug 28, 2014, at 1:43 AM, Vincenzo Pii 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: 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: On Fri, Aug 29, 2014 at 7:55 AM, Lauri Tirkkonen 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: 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: References: <20140829065511.GA17957@gutsman.lotheac.fi> 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