From henson at acm.org Sun Feb 2 01:46:07 2014 From: henson at acm.org (Paul B. Henson) Date: Sat, 1 Feb 2014 17:46:07 -0800 Subject: [OmniOS-discuss] overriding serial port IRQ Message-ID: <20140202014607.GS5681@bender.unx.csupomona.edu> So I updated the BIOS on my storage box, which has a supermicro X9SRi-F, from 2.0a to 3.0a, and my IPMI SOL console stopped working :(. After an annoying investigation, I discovered that the new BIOS misconfigures ttyc/COM3, the BIOS says it's using irq 4, when in actuality it's using irq 10. Under linux, when I override the bios config and force the driver to use irq 10, it works fine. How do I get an illumos/omnios box to override the bios serial port config and use an explicitly configured irq rather than the BIOS provided one? It looks like I need to tweak something in /kernel/drv/asy.conf, but I'm not really clear on exactly what. Thanks for any pointers, and ay, supermicro, fix one thing and break another ... From henson at acm.org Sun Feb 2 21:37:19 2014 From: henson at acm.org (Paul B. Henson) Date: Sun, 2 Feb 2014 13:37:19 -0800 Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ In-Reply-To: References: <20140202014607.GS5681@bender.unx.csupomona.edu> Message-ID: <20140202213719.GX5681@bender.unx.csupomona.edu> On Sun, Feb 02, 2014 at 11:10:35AM -0500, Albert Lee wrote: > To introduce this info to the devinfo tree, append to /kernel/drv/asy.conf: > name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10; Thanks for the tip. I updated my asy.conf, it looks like this now: ----- interrupt-priorities=12; # temporarily hardcode serial config due to broken BIOS name="asy" parent="isa" reg=1,0x3f8,8 interrupts=4; name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3; name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10; ----- I then did a 'bootadm update-archive' (under the assumption this config needed to be pulled into it), and rebooted, but unfortunately, the serial console is still misbehaving :(. I have verbose boot enabled, and all I see is: SunOS Release 5.11 Version omnios-6de5e81 64-bit Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. [ network/ip-inter and then it stops, like it did before I tweaked asy.conf. I don't see any mention of serial, or asy, or tty/console in dmesg, is there any way to confirm what irq the os is using to make sure it picked up the hardcoded config? Hmm, looks like prtconf -v shows it: asy, instance #2 System properties: name='interrupts' type=int items=1 value=0000000a name='reg' type=int items=3 value=00000001.000003e8.00000008 name='interrupt-priorities' type=int items=1 value=0000000c Looks like it picked up irq 10 (0xa)? The other two ports say "not attached", not sure why, maybe because nothing's using them: asy, instance #0 (driver not attached) asy, instance #1 (driver not attached) Hmm, darn it. I tested it under linux while I was trying to figure out what broke, linux barfed on the bad bios config too, but when I hardcoded the irq to 10 linux worked fine on the SOL port, so I know it can work. Any other thoughts? Or maybe I'm SOL on the SOL port pending a supermicro bios update . Thanks much... From trisk at nexenta.com Sun Feb 2 16:10:35 2014 From: trisk at nexenta.com (Albert Lee) Date: Sun, 2 Feb 2014 11:10:35 -0500 Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ In-Reply-To: <20140202014607.GS5681@bender.unx.csupomona.edu> References: <20140202014607.GS5681@bender.unx.csupomona.edu> Message-ID: On Sat, Feb 1, 2014 at 8:46 PM, Paul B. Henson wrote: > So I updated the BIOS on my storage box, which has a supermicro X9SRi-F, > from 2.0a to 3.0a, and my IPMI SOL console stopped working :(. After an > annoying investigation, I discovered that the new BIOS misconfigures > ttyc/COM3, the BIOS says it's using irq 4, when in actuality it's using > irq 10. Under linux, when I override the bios config and force the > driver to use irq 10, it works fine. > > How do I get an illumos/omnios box to override the bios serial port > config and use an explicitly configured irq rather than the BIOS > provided one? It looks like I need to tweak something in > /kernel/drv/asy.conf, but I'm not really clear on exactly what. > > Thanks for any pointers, and ay, supermicro, fix one thing and break > another ... > > To introduce this info to the devinfo tree, append to /kernel/drv/asy.conf: name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10; If the first two serial ports don't keep working, also prepend name="asy" parent="isa" reg=1,0x3f8,8 interrupts=4; name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3; -Albert > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175801-8cd47afa > Modify Your Subscription: https://www.listbox.com/member/?member_id=21175801&id_secret=21175801-f1323306 > Powered by Listbox: http://www.listbox.com -- Albert Lee Nexenta Systems, Inc. From tobi at oetiker.ch Mon Feb 3 10:51:59 2014 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 3 Feb 2014 11:51:59 +0100 (CET) Subject: [OmniOS-discuss] iscsi timeouts In-Reply-To: References: <52DEF033.7010107@gmail.com> <52DEF1AB.9030305@gmail.com> <52DEF24B.7070806@gmail.com> Message-ID: a short update on the matter for anyone browsing the ML archives: The affected system runs on an S2600CP motherboard with RMM4 remote management. RMM comes with the ability to use any of the existing Ethernet ports on the MB for its communication needs ... we have configured it with a separate hw port, but it seems that this ability the access the other ports can interfere with omnios operation. 10 days ago, we have upgraded the bios to version SE5C600.86B.02.01.0002.082220131453 08/22/2013 since then we have not seen any issues ... I am not 100% sure that this is the solution to the problem, as we only found the behaviour after several weeks of uptime ... in any event, for now things look good. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From skiselkov.ml at gmail.com Mon Feb 3 11:48:09 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 03 Feb 2014 11:48:09 +0000 Subject: [OmniOS-discuss] iscsi timeouts In-Reply-To: References: <52DEF033.7010107@gmail.com> <52DEF1AB.9030305@gmail.com> <52DEF24B.7070806@gmail.com> Message-ID: <52EF81F9.8010204@gmail.com> On 2/3/14, 10:51 AM, Tobias Oetiker wrote: > a short update on the matter for anyone browsing the ML archives: > > The affected system runs on an S2600CP motherboard with RMM4 remote > management. RMM comes with the ability to use any of the existing > Ethernet ports on the MB for its communication needs ... we have > configured it with a separate hw port, but it seems that this > ability the access the other ports can interfere with omnios > operation. > > 10 days ago, we have upgraded the bios to > version SE5C600.86B.02.01.0002.082220131453 08/22/2013 > > since then we have not seen any issues ... > > I am not 100% sure that this is the solution to the problem, as we > only found the behaviour after several weeks of uptime ... in any > event, for now things look good. Interesting observation, thanks for keeping the list updated! Best wishes, -- Saso From kai at meder.info Mon Feb 3 12:19:33 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 13:19:33 +0100 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints Message-ID: Hello, running 'pkg update' I get the following result: pkg update: No solution was found to satisfy constraints Plan Creation: Package solver has not found a solution to update to latest available versions. This may indicate an overly constrained set of packages are installed. latest incorporations: pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151008:20131204T022427Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z Dependency analysis is unable to determine exact cause. Try specifying expected results to obtain more detailed error messages. Is this simply a matter of waiting until something in the repository is fixed or am I supposed to do anything? Thanks a lot, Kai From esproul at omniti.com Mon Feb 3 14:46:06 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 09:46:06 -0500 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: Message-ID: On Mon, Feb 3, 2014 at 7:19 AM, Kai Meder wrote: > Dependency analysis is unable to determine exact cause. > Try specifying expected results to obtain more detailed error messages. > > > Is this simply a matter of waiting until something in the repository is > fixed or am I supposed to do anything? What version of OmniOS are you currently on (see /etc/release)? Are you using packages from any publishers other than omnios? Others that have run into this were using packages from ms.omniti.com that require r151006. The errors from pkg(1) are, it's safe to say, less than helpful here. Eric From trisk at nexenta.com Sun Feb 2 22:26:36 2014 From: trisk at nexenta.com (Albert Lee) Date: Sun, 2 Feb 2014 17:26:36 -0500 Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ In-Reply-To: <20140202213719.GX5681@bender.unx.csupomona.edu> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> Message-ID: On Sun, Feb 2, 2014 at 4:37 PM, Paul B. Henson wrote: > On Sun, Feb 02, 2014 at 11:10:35AM -0500, Albert Lee wrote: > >> To introduce this info to the devinfo tree, append to /kernel/drv/asy.conf: >> name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10; > > Thanks for the tip. I updated my asy.conf, it looks like this now: > > ----- > interrupt-priorities=12; > > # temporarily hardcode serial config due to broken BIOS > name="asy" parent="isa" reg=1,0x3f8,8 interrupts=4; > name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3; > name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10; > ----- > > I then did a 'bootadm update-archive' (under the assumption this config > needed to be pulled into it), and rebooted, but unfortunately, the > serial console is still misbehaving :(. I have verbose boot enabled, and > all I see is: > > SunOS Release 5.11 Version omnios-6de5e81 64-bit > Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights > reserved. > [ network/ip-inter > > and then it stops, like it did before I tweaked asy.conf. I don't see > any mention of serial, or asy, or tty/console in dmesg, is there any way > to confirm what irq the os is using to make sure it picked up the > hardcoded config? Hmm, looks like prtconf -v shows it: > > asy, instance #2 > System properties: > name='interrupts' type=int items=1 > value=0000000a > name='reg' type=int items=3 > value=00000001.000003e8.00000008 > name='interrupt-priorities' type=int items=1 > value=0000000c > > Looks like it picked up irq 10 (0xa)? The other two ports say "not attached", > not sure why, maybe because nothing's using them: > > asy, instance #0 (driver not attached) > > asy, instance #1 (driver not attached) > > Hmm, darn it. I tested it under linux while I was trying to figure out > what broke, linux barfed on the bad bios config too, but when I hardcoded > the irq to 10 linux worked fine on the SOL port, so I know it can work. > > Any other thoughts? Or maybe I'm SOL on the SOL port pending a supermicro > bios update . > > Thanks much... > Are you sure it's still ttyc/COM3? asy should pick up the device name from the I/O address, which is why I used 0x3e8. Also, echo ::interrupts | mdb -k should show the current assignments. -Albert From kai at meder.info Mon Feb 3 15:05:55 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 16:05:55 +0100 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: Message-ID: Eric Sproul schrieb: > On Mon, Feb 3, 2014 at 7:19 AM, Kai Meder wrote: >> Dependency analysis is unable to determine exact cause. >> Try specifying expected results to obtain more detailed error messages. >> >> >> Is this simply a matter of waiting until something in the repository is >> fixed or am I supposed to do anything? > > What version of OmniOS are you currently on (see /etc/release)? Are > you using packages from any publishers other than omnios? Others that > have run into this were using packages from ms.omniti.com that require > r151006. The errors from pkg(1) are, it's safe to say, less than > helpful here. I am on OmniOS v11 r151006. I am indeed using php and lighttpd from ms.omniti.com, how would I resolve this error? Thank you very much, Kai From mmabis at vmware.com Mon Feb 3 15:06:59 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Mon, 3 Feb 2014 07:06:59 -0800 (PST) Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> Message-ID: <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> Hello, I have a few questions about a project that i am trying to work on, needless to say i have 1 80GB SSD Drive that i can fit in this case, the rest of the drives are a RaidZ2 configuration and there cannot be anymore added Disks to this system period! My goal is to make the SSD capable of making NFS run better (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere! My Questions are 1) Splitting the SSD into partitions and running is that bad i always heard it was my question is why? 2) Can Omni be run from say a 32GB USB3 key directly? 3) What options do i have here outside of adding a drive. I have SATA Slots on the mobo just no place to add an additional drive! From dswartz at druber.com Mon Feb 3 15:12:20 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Mon, 3 Feb 2014 10:12:20 -0500 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> Message-ID: > > Hello, > > I have a few questions about a project that i am trying to work on, > needless to say i have 1 80GB SSD Drive that i can fit in this case, the > rest of the drives are a RaidZ2 configuration and there cannot be anymore > added Disks to this system period! > > My goal is to make the SSD capable of making NFS run better > (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere! > > My Questions are > > 1) Splitting the SSD into partitions and running is that bad i always > heard it was my question is why? > 2) Can Omni be run from say a 32GB USB3 key directly? > 3) What options do i have here outside of adding a drive. > > I have SATA Slots on the mobo just no place to add an additional drive! Given how small and flat ssd drives are, you can't tape one to the inside of the case out of the way somewhere? From fabio at fabiorabelo.wiki.br Mon Feb 3 15:12:54 2014 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Mon, 3 Feb 2014 13:12:54 -0200 Subject: [OmniOS-discuss] industrial usb flash Message-ID: Hi to all People are talking about "industrial grade" usb flash storage to use as boot device for Omni and napp-it . Exactly witch brand build this kind of device ? I just can not find anything like that on amazon .... F?bio Rabelo From skiselkov.ml at gmail.com Mon Feb 3 15:23:05 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 03 Feb 2014 15:23:05 +0000 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> Message-ID: <52EFB459.9050504@gmail.com> On 2/3/14, 3:06 PM, Matthew Mabis wrote: > > Hello, > > I have a few questions about a project that i am trying to work on, needless to say i have 1 80GB SSD Drive that i can fit in this case, the rest of the drives are a RaidZ2 configuration and there cannot be anymore added Disks to this system period! > > My goal is to make the SSD capable of making NFS run better (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere! > > My Questions are > > 1) Splitting the SSD into partitions and running is that bad i always heard it was my question is why? > 2) Can Omni be run from say a 32GB USB3 key directly? > 3) What options do i have here outside of adding a drive. > > I have SATA Slots on the mobo just no place to add an additional drive! Yes, you can partition the SSD and it works okay. For the OS, set aside something like 10GB and turn on compression. Although the standard installer doesn't let you set compression on the root pool before starting installation, there's a trick to doing it. Before firing up the installation, get a shell from the installer menu and run the following commands: # screen # while ! zpool set compress=lz4 rpool; do sleep 1; done (after this hit 'Ctrl-A' + 'D' and type 'exit' to return to the installer menu and leave the loop running) The loop will try to set compression on the newly created root pool as soon as the installer creates it, so that the OS's data itself will be installed compressed. For slog (aka ZIL) you don't need much - usually around 1-2GB is more than enough, since it only needs to hold the sync write data from the last transaction (by default: the last 5 seconds). Use the rest of the SSD for L2ARC. Depending on the SSD type you may also want to keep around 10-20% of the SSD unallocated, so that the garbage collector on the controller always has blocks available it can pre-erase - this can boost long-term slog performance quite a bit. YMMV Cheers, -- Saso From doug at will.to Mon Feb 3 15:34:29 2014 From: doug at will.to (Doug Hughes) Date: Mon, 03 Feb 2014 10:34:29 -0500 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> Message-ID: <52EFB705.2030300@will.to> On 2/3/2014 10:12 AM, Dan Swartzendruber wrote: >> >> Hello, >> >> I have a few questions about a project that i am trying to work on, >> needless to say i have 1 80GB SSD Drive that i can fit in this case, the >> rest of the drives are a RaidZ2 configuration and there cannot be anymore >> added Disks to this system period! >> >> My goal is to make the SSD capable of making NFS run better >> (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere! >> >> My Questions are >> >> 1) Splitting the SSD into partitions and running is that bad i always >> heard it was my question is why? >> 2) Can Omni be run from say a 32GB USB3 key directly? >> 3) What options do i have here outside of adding a drive. >> >> I have SATA Slots on the mobo just no place to add an additional drive! > Yes, we do this all the time. The OS image doesn't take that much space. Just carve off 8GB partition on your SSD for the ZIL, and you are set. It vastly improves NFS synchronous operations such as deletes, metadata changes, and small file writes. What kind of SSD is it? I wouldn't recommend on an X-25M because there's no cap to write it out on power failure, but the Intel-320 line is a very good choice in general. From kai at meder.info Mon Feb 3 15:45:32 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 16:45:32 +0100 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: Message-ID: Kai Meder schrieb: > Eric Sproul schrieb: >> On Mon, Feb 3, 2014 at 7:19 AM, Kai >> Meder wrote: >>> Dependency analysis is unable to determine exact cause. >>> Try specifying expected results to obtain more detailed error messages. >>> >>> >>> Is this simply a matter of waiting until something in the repository is >>> fixed or am I supposed to do anything? >> >> What version of OmniOS are you currently on (see /etc/release)? Are >> you using packages from any publishers other than omnios? Others that >> have run into this were using packages from ms.omniti.com that require >> r151006. The errors from pkg(1) are, it's safe to say, less than >> helpful here. > I am on OmniOS v11 r151006. > > I am indeed using php and lighttpd from ms.omniti.com, > how would I resolve this error? I have installed those packages: pkg list | grep ms.omniti.com omniti/database/mysql-55 (ms.omniti.com) 5.5.31-0.151004 i-- omniti/database/mysql-55/library (ms.omniti.com) 5.5.31-0.151004 i-- omniti/editor/nano (ms.omniti.com) 2.2.6-0.151002 i-- omniti/library/freetype2 (ms.omniti.com) 2.4.10-0.151002 i-- omniti/library/gd (ms.omniti.com) 2.0.35-0.151002 i-- omniti/library/libjpeg (ms.omniti.com) 8.4-0.151002 i-- omniti/library/libmcrypt (ms.omniti.com) 2.5.7-0.151002 i-- omniti/library/libpng (ms.omniti.com) 1.5.12-0.151002 i-- omniti/library/libpq5 (ms.omniti.com) 9.2.0-0.151002 i-- omniti/library/libssh2 (ms.omniti.com) 1.4.2-0.151002 i-- omniti/library/mhash (ms.omniti.com) 0.9.9.9-0.151002 i-- omniti/runtime/php-54 (ms.omniti.com) 5.4.19-0.151006 i-- omniti/server/lighttpd (ms.omniti.com) 1.4.32-0.151004 i-- omniti/system/storage/smartmontools (ms.omniti.com) 6.0-0.151004 i-- How do I find out which one breaks the update? Thanks! From mmabis at vmware.com Mon Feb 3 15:52:37 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Mon, 3 Feb 2014 07:52:37 -0800 (PST) Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <52EFB705.2030300@will.to> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> <52EFB705.2030300@will.to> Message-ID: <413332433.2630440.1391442757714.JavaMail.root@vmware.com> Its an Intel 320 80GB Drive I ensured to buy SSDs for my lab that have the power Caps didnt want to make that mistake! Matt ----- Original Message ----- From: "Doug Hughes" To: omnios-discuss at lists.omniti.com Sent: Monday, February 3, 2014 7:34:29 AM Subject: Re: [OmniOS-discuss] Where to Run Omni On 2/3/2014 10:12 AM, Dan Swartzendruber wrote: >> >> Hello, >> >> I have a few questions about a project that i am trying to work on, >> needless to say i have 1 80GB SSD Drive that i can fit in this case, the >> rest of the drives are a RaidZ2 configuration and there cannot be anymore >> added Disks to this system period! >> >> My goal is to make the SSD capable of making NFS run better >> (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere! >> >> My Questions are >> >> 1) Splitting the SSD into partitions and running is that bad i always >> heard it was my question is why? >> 2) Can Omni be run from say a 32GB USB3 key directly? >> 3) What options do i have here outside of adding a drive. >> >> I have SATA Slots on the mobo just no place to add an additional drive! > Yes, we do this all the time. The OS image doesn't take that much space. Just carve off 8GB partition on your SSD for the ZIL, and you are set. It vastly improves NFS synchronous operations such as deletes, metadata changes, and small file writes. What kind of SSD is it? I wouldn't recommend on an X-25M because there's no cap to write it out on power failure, but the Intel-320 line is a very good choice in general. _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com https://urldefense.proofpoint.com/v1/url?u=http://lists.omniti.com/mailman/listinfo/omnios-discuss&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yqgQ6LhGnfWMd79QvLrmWsnr%2FlpWj5c0oy4MpT8%2Bgik%3D%0A&m=jbXB0E2AdHLBwrLyWlAxJtx7ZA5Rg7gTJaePeKew70Y%3D%0A&s=b5c7784a65fcfa3c44e8f9f89d910678eda6fe717feb159eba020e2d1bab7582 From mmabis at vmware.com Mon Feb 3 15:53:57 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Mon, 3 Feb 2014 07:53:57 -0800 (PST) Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <52EFB459.9050504@gmail.com> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> <52EFB459.9050504@gmail.com> Message-ID: <1221717239.2630686.1391442837397.JavaMail.root@vmware.com> This is perfect, I was reading on Hardforum from a user named GEA saying that its unsupported and not recommended about a year ago so i figured why not bring the question to the forum and get the answer to Why! This information will get things rolling! Thanks! Matt Mabis ----- Original Message ----- From: "Saso Kiselkov" To: omnios-discuss at lists.omniti.com Sent: Monday, February 3, 2014 7:23:05 AM Subject: Re: [OmniOS-discuss] Where to Run Omni On 2/3/14, 3:06 PM, Matthew Mabis wrote: > > Hello, > > I have a few questions about a project that i am trying to work on, needless to say i have 1 80GB SSD Drive that i can fit in this case, the rest of the drives are a RaidZ2 configuration and there cannot be anymore added Disks to this system period! > > My goal is to make the SSD capable of making NFS run better (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere! > > My Questions are > > 1) Splitting the SSD into partitions and running is that bad i always heard it was my question is why? > 2) Can Omni be run from say a 32GB USB3 key directly? > 3) What options do i have here outside of adding a drive. > > I have SATA Slots on the mobo just no place to add an additional drive! Yes, you can partition the SSD and it works okay. For the OS, set aside something like 10GB and turn on compression. Although the standard installer doesn't let you set compression on the root pool before starting installation, there's a trick to doing it. Before firing up the installation, get a shell from the installer menu and run the following commands: # screen # while ! zpool set compress=lz4 rpool; do sleep 1; done (after this hit 'Ctrl-A' + 'D' and type 'exit' to return to the installer menu and leave the loop running) The loop will try to set compression on the newly created root pool as soon as the installer creates it, so that the OS's data itself will be installed compressed. For slog (aka ZIL) you don't need much - usually around 1-2GB is more than enough, since it only needs to hold the sync write data from the last transaction (by default: the last 5 seconds). Use the rest of the SSD for L2ARC. Depending on the SSD type you may also want to keep around 10-20% of the SSD unallocated, so that the garbage collector on the controller always has blocks available it can pre-erase - this can boost long-term slog performance quite a bit. YMMV Cheers, -- Saso _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com https://urldefense.proofpoint.com/v1/url?u=http://lists.omniti.com/mailman/listinfo/omnios-discuss&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yqgQ6LhGnfWMd79QvLrmWsnr%2FlpWj5c0oy4MpT8%2Bgik%3D%0A&m=SIl8BuMbKpDSpCGhnR41LKGpg8kFruHNVH1eJ2FH%2BGE%3D%0A&s=c03620d2a0c94f3a2b271e1c23f59d4e9b986a1c1dadcc8744a1ca51a20fc7af From dswartz at druber.com Mon Feb 3 16:01:34 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Mon, 3 Feb 2014 11:01:34 -0500 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <1221717239.2630686.1391442837397.JavaMail.root@vmware.com> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> <52EFB459.9050504@gmail.com> <1221717239.2630686.1391442837397.JavaMail.root@vmware.com> Message-ID: <8dc163b35c20fb4496e0e226b7e6196b.squirrel@webmail.druber.com> > This is perfect, I was reading on Hardforum from a user named GEA saying > that its unsupported and not recommended about a year ago so i figured why > not bring the question to the forum and get the answer to Why! I seem to recall there being sound reasons not to share the same device between SLOG and L2ARC (or anything else, for that matter...) From esproul at omniti.com Mon Feb 3 16:16:55 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 11:16:55 -0500 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: Message-ID: On Mon, Feb 3, 2014 at 10:45 AM, Kai Meder wrote: > I have installed those packages: > > pkg list | grep ms.omniti.com > omniti/database/mysql-55 (ms.omniti.com) 5.5.31-0.151004 i-- > omniti/database/mysql-55/library (ms.omniti.com) 5.5.31-0.151004 i-- > omniti/editor/nano (ms.omniti.com) 2.2.6-0.151002 i-- > omniti/library/freetype2 (ms.omniti.com) 2.4.10-0.151002 i-- > omniti/library/gd (ms.omniti.com) 2.0.35-0.151002 i-- > omniti/library/libjpeg (ms.omniti.com) 8.4-0.151002 i-- > omniti/library/libmcrypt (ms.omniti.com) 2.5.7-0.151002 i-- > omniti/library/libpng (ms.omniti.com) 1.5.12-0.151002 i-- > omniti/library/libpq5 (ms.omniti.com) 9.2.0-0.151002 i-- > omniti/library/libssh2 (ms.omniti.com) 1.4.2-0.151002 i-- > omniti/library/mhash (ms.omniti.com) 0.9.9.9-0.151002 i-- > omniti/runtime/php-54 (ms.omniti.com) 5.4.19-0.151006 i-- > omniti/server/lighttpd (ms.omniti.com) 1.4.32-0.151004 i-- > omniti/system/storage/smartmontools (ms.omniti.com) 6.0-0.151004 i-- > > How do I find out which one breaks the update? I'm going to surmise that it is php-54. More recent builds in ms.omniti.com began incorporating on the 'entire' package of the version they were built on, because we could not know whether they would work properly on future versions of the OS. You can try this to confirm my suspicion: pkg search -H -l -o pkg.name 'depend:incorporate:entire' That generates a list of pkg.name values (from pkg metadata) of locally installed (-l) packages that have a dependency of type incorporate on entire. The -H eliminates the header line in output. Eric From doug at will.to Mon Feb 3 16:26:56 2014 From: doug at will.to (Doug Hughes) Date: Mon, 03 Feb 2014 11:26:56 -0500 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <1221717239.2630686.1391442837397.JavaMail.root@vmware.com> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> <52EFB459.9050504@gmail.com> <1221717239.2630686.1391442837397.JavaMail.root@vmware.com> Message-ID: <52EFC350.20306@will.to> On 2/3/2014 10:53 AM, Matthew Mabis wrote: > This is perfect, I was reading on Hardforum from a user named GEA saying that its unsupported and not recommended about a year ago so i figured why not bring the question to the forum and get the answer to Why! > > This information will get things rolling! Thanks! > > Matt Mabis On a normal spinning disk this has the potential to be questionable because the head has to seek to get to the zil, and then back again, especially if you have swap enabled and in use. The OS, though, really doesn't do much disk activity after being loaded (unless you have a lot of logging going on), and SSD has no seek penalty, per se. From esproul at omniti.com Mon Feb 3 16:28:50 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 11:28:50 -0500 Subject: [OmniOS-discuss] Fwd: omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: <1E670AA9-9943-49E1-B3E4-BE73596A6402@fluffy.co.uk> Message-ID: Forgot to reply-all ---------- Forwarded message ---------- From: Eric Sproul Date: Mon, Feb 3, 2014 at 11:28 AM Subject: Re: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints To: Ben Summers On Mon, Feb 3, 2014 at 11:20 AM, Ben Summers wrote: > > On 3 Feb 2014, at 16:16, Eric Sproul wrote: > >> I'm going to surmise that it is php-54. More recent builds in >> ms.omniti.com began incorporating on the 'entire' package of the >> version they were built on, because we could not know whether they >> would work properly on future versions of the OS. > > The expectation of someone from the Solaris world is that if it works now, it'll work on any future version of the OS. > > Should OmniOS users expect this to be the case, or should we recompile for new versions of the OS? That's only for libc ABI. Those promises do not extend to userland libraries, which is where we would most likely expect breakage for high-level apps. Eric From kai at meder.info Mon Feb 3 18:57:45 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 19:57:45 +0100 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: Message-ID: <52EFE6A9.8070203@meder.info> Eric Sproul schrieb: > On Mon, Feb 3, 2014 at 10:45 AM, Kai Meder wrote: >> I have installed those packages: >> >> pkg list | grep ms.omniti.com >> omniti/database/mysql-55 (ms.omniti.com) 5.5.31-0.151004 i-- >> omniti/database/mysql-55/library (ms.omniti.com) 5.5.31-0.151004 i-- >> omniti/editor/nano (ms.omniti.com) 2.2.6-0.151002 i-- >> omniti/library/freetype2 (ms.omniti.com) 2.4.10-0.151002 i-- >> omniti/library/gd (ms.omniti.com) 2.0.35-0.151002 i-- >> omniti/library/libjpeg (ms.omniti.com) 8.4-0.151002 i-- >> omniti/library/libmcrypt (ms.omniti.com) 2.5.7-0.151002 i-- >> omniti/library/libpng (ms.omniti.com) 1.5.12-0.151002 i-- >> omniti/library/libpq5 (ms.omniti.com) 9.2.0-0.151002 i-- >> omniti/library/libssh2 (ms.omniti.com) 1.4.2-0.151002 i-- >> omniti/library/mhash (ms.omniti.com) 0.9.9.9-0.151002 i-- >> omniti/runtime/php-54 (ms.omniti.com) 5.4.19-0.151006 i-- >> omniti/server/lighttpd (ms.omniti.com) 1.4.32-0.151004 i-- >> omniti/system/storage/smartmontools (ms.omniti.com) 6.0-0.151004 i-- >> >> How do I find out which one breaks the update? > > I'm going to surmise that it is php-54. More recent builds in > ms.omniti.com began incorporating on the 'entire' package of the > version they were built on, because we could not know whether they > would work properly on future versions of the OS. > > You can try this to confirm my suspicion: pkg search -H -l -o pkg.name > 'depend:incorporate:entire' > > That generates a list of pkg.name values (from pkg metadata) of > locally installed (-l) packages that have a dependency of type > incorporate on entire. The -H eliminates the header line in output. pkg search -H -l -o pkg.name 'depend:incorporate:entire' omniti/runtime/php-54 OK, you hit it. What am I supposed to do now? I did not really understand the 'entire'-incorporation... Thank you From kai at meder.info Mon Feb 3 19:00:32 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 20:00:32 +0100 Subject: [OmniOS-discuss] industrial usb flash In-Reply-To: References: Message-ID: <52EFE750.5040307@meder.info> The SanDisk Extreme USB3.0 32GB is said to be good. http://www.sandisk.com/products/usb/drives/extreme/ But this is still far from "industrial grade" if you're talking about SLC heavy-write-endurance drives... Would be interested too for my next Avoton/Rangeley build using OmniOS. Anyone any advice? F?bio Rabelo schrieb: > Hi to all > > People are talking about "industrial grade" usb flash storage to use > as boot device for Omni and napp-it . > > Exactly witch brand build this kind of device ? > > I just can not find anything like that on amazon .... > > > F?bio Rabelo > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From esproul at omniti.com Mon Feb 3 19:40:04 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 14:40:04 -0500 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: <52EFE6A9.8070203@meder.info> References: <52EFE6A9.8070203@meder.info> Message-ID: On Mon, Feb 3, 2014 at 1:57 PM, Kai Meder wrote: > pkg search -H -l -o pkg.name 'depend:incorporate:entire' > omniti/runtime/php-54 > > OK, you hit it. What am I supposed to do now? > I did not really understand the 'entire'-incorporation... The php-54 package declares that it requires entire at 11-0.151006 and only that version. 'entire' is a package that controls (directly or indirectly) the versions of all the packages available in the omnios publisher, so php-54 uses that as a way to say "I will only run on r151006". You can remove that package and upgrade, or you can stay on r151006 if you want to keep using the php-54 package. Eric From esproul at omniti.com Mon Feb 3 20:29:06 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 15:29:06 -0500 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: <52EFF9E0.5010209@meder.info> References: <52EFE6A9.8070203@meder.info> <52EFF9E0.5010209@meder.info> Message-ID: On Mon, Feb 3, 2014 at 3:19 PM, Kai Meder wrote: > Eric Sproul schrieb: >> You can remove that package and upgrade, or you can stay on r151006 if >> you want to keep using the php-54 package. > > OK, but since there is no php-55, I can't currently use PHP if I want to > stay upgradeable, do I? > My server-WebInterface is based on PHP5, so I need any PHP5-version... There certainly is PHP 5.5 available as source. ;) You cannot use the ms.omniti.com php-54 package on anything except r151006. You can always roll your own. On the other hand, note that r151006 is a long-term support release with security updates through 2016, so unless you have some non-negotiable reason to go to r151008, perhaps you could stay on 006. Eric From esproul at omniti.com Mon Feb 3 21:11:35 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 16:11:35 -0500 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: <52EFFCF3.7070001@meder.info> References: <52EFE6A9.8070203@meder.info> <52EFF9E0.5010209@meder.info> <52EFFCF3.7070001@meder.info> Message-ID: On Mon, Feb 3, 2014 at 3:32 PM, Kai Meder wrote: > Do you actually plan to change php-54's 'entire' incorporation? > I am willing to stay on LTS for the time being but not for the next 3 years > ;) > > Thank you very much for these explanations The ms.omniti.com package set is what OmniTI uses internally for hosting and other production purposes. We prefer the stability of LTS for that, so I can't say if/when there will be builds for r151008. If you really need both php 5.4 *and* always the latest-and-greatest OS every 6 months, then you should invest in rolling your own packages, as you have needs that aren't being met by the available community packages. Eric From esproul at omniti.com Mon Feb 3 21:16:16 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 16:16:16 -0500 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: <52F0068A.9050404@meder.info> References: <52EFE6A9.8070203@meder.info> <52EFF9E0.5010209@meder.info> <52EFFCF3.7070001@meder.info> <52F0068A.9050404@meder.info> Message-ID: On Mon, Feb 3, 2014 at 4:13 PM, Kai Meder wrote: > OK, this is perfectly acceptable. > How do I tell my OmniOS to update anything possible but stop whining about > php's and possible future 'entire'-dependencies? You cannot do that. A package (php-54) has declared that it must have r151006. The only way to upgrade would be to remove that package, and accept that it will not be installable on the upgraded system. From henson at acm.org Mon Feb 3 21:30:03 2014 From: henson at acm.org (Paul B. Henson) Date: Mon, 3 Feb 2014 13:30:03 -0800 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <52EFB459.9050504@gmail.com> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> <52EFB459.9050504@gmail.com> Message-ID: <089c01cf2127$1b4e9650$51ebc2f0$@acm.org> > From: Saso Kiselkov > Sent: Monday, February 03, 2014 7:23 AM > something like 10GB and turn on compression. Although the standard > installer doesn't let you set compression on the root pool before > starting installation, there's a trick to doing it. Before firing up the With a little more effort: http://omnios.omniti.com/wiki.php/ISOrpoolCustomize You can configure the size of the rpool partition, provide arbitrary pool creation options including compression, and also size swap/dump explicitly rather than use the installer defaults. From henson at acm.org Mon Feb 3 21:40:44 2014 From: henson at acm.org (Paul B. Henson) Date: Mon, 3 Feb 2014 13:40:44 -0800 Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ In-Reply-To: References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> Message-ID: <08a001cf2128$995d49f0$cc17ddd0$@acm.org> > From: Albert Lee [mailto:trisk at nexenta.com] > Sent: Sunday, February 02, 2014 2:27 PM > > Are you sure it's still ttyc/COM3? asy should pick up the device name > from the I/O address, which is why I used 0x3e8. Pretty sure. Linux works okay on ttyS2 (COM3) with the irq overridden to 10. I also see the first bit of booting under omnios with the console set to ttyc, and I also see "rebooting" on the serial console when I reboot. The behavior is very similar to a problem I had with openbsd and the SOL console when it was using the wrong irq, it would print out like 16 characters or so until the buffer was full and then hang waiting for an interrupt that never came. > Also, echo ::interrupts | mdb -k should show the current assignments. Arg, looks like it didn't get the override after all: CPU/Vect IRQ IPL Bus Trg Type Share APIC/INT# ISR 10/0x20 3 5 ISA Edg Fixed 1 0x0/0x3 asyintr 11/0x20 4 5 ISA Edg Fixed 2 0x0/0x4 asyintr 11/0x20 4 5 ISA Edg Fixed 2 0x0/0x4 asyintr I've seen some other examples for asy.conf that look more like: name="asy" class="sysbus" interrupts=12,10 reg=0x3e8,0,0 ioaddr=0x3e8; As opposed to the one I have now: name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10; I'm not sure if that was for an older version of Solaris though? From kai at meder.info Mon Feb 3 20:19:44 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 21:19:44 +0100 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: <52EFE6A9.8070203@meder.info> Message-ID: <52EFF9E0.5010209@meder.info> Eric Sproul schrieb: > On Mon, Feb 3, 2014 at 1:57 PM, Kai Meder wrote: >> pkg search -H -l -o pkg.name 'depend:incorporate:entire' >> omniti/runtime/php-54 >> >> OK, you hit it. What am I supposed to do now? >> I did not really understand the 'entire'-incorporation... > > The php-54 package declares that it requires entire at 11-0.151006 and > only that version. 'entire' is a package that controls (directly or > indirectly) the versions of all the packages available in the omnios > publisher, so php-54 uses that as a way to say "I will only run on > r151006". > > You can remove that package and upgrade, or you can stay on r151006 if > you want to keep using the php-54 package. OK, but since there is no php-55, I can't currently use PHP if I want to stay upgradeable, do I? My server-WebInterface is based on PHP5, so I need any PHP5-version... Thanks, Kai From kai at meder.info Mon Feb 3 20:32:51 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 21:32:51 +0100 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: <52EFE6A9.8070203@meder.info> <52EFF9E0.5010209@meder.info> Message-ID: <52EFFCF3.7070001@meder.info> Eric Sproul schrieb: > On Mon, Feb 3, 2014 at 3:19 PM, Kai Meder wrote: >> Eric Sproul schrieb: >>> You can remove that package and upgrade, or you can stay on r151006 if >>> you want to keep using the php-54 package. >> OK, but since there is no php-55, I can't currently use PHP if I want to >> stay upgradeable, do I? >> My server-WebInterface is based on PHP5, so I need any PHP5-version... > > There certainly is PHP 5.5 available as source. ;) > > You cannot use the ms.omniti.com php-54 package on anything except > r151006. You can always roll your own. > > On the other hand, note that r151006 is a long-term support release > with security updates through 2016, so unless you have some > non-negotiable reason to go to r151008, perhaps you could stay on 006. Do you actually plan to change php-54's 'entire' incorporation? I am willing to stay on LTS for the time being but not for the next 3 years ;) Thank you very much for these explanations From kai at meder.info Mon Feb 3 21:13:46 2014 From: kai at meder.info (Kai Meder) Date: Mon, 03 Feb 2014 22:13:46 +0100 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: References: <52EFE6A9.8070203@meder.info> <52EFF9E0.5010209@meder.info> <52EFFCF3.7070001@meder.info> Message-ID: <52F0068A.9050404@meder.info> Eric Sproul schrieb: > On Mon, Feb 3, 2014 at 3:32 PM, Kai Meder wrote: >> Do you actually plan to change php-54's 'entire' incorporation? >> I am willing to stay on LTS for the time being but not for the next 3 years >> ;) >> >> Thank you very much for these explanations > > The ms.omniti.com package set is what OmniTI uses internally for > hosting and other production purposes. We prefer the stability of LTS > for that, so I can't say if/when there will be builds for r151008. If > you really need both php 5.4 *and* always the latest-and-greatest OS > every 6 months, then you should invest in rolling your own packages, > as you have needs that aren't being met by the available community > packages. OK, this is perfectly acceptable. How do I tell my OmniOS to update anything possible but stop whining about php's and possible future 'entire'-dependencies? Thanks, Kai From esproul at omniti.com Mon Feb 3 21:49:15 2014 From: esproul at omniti.com (Eric Sproul) Date: Mon, 3 Feb 2014 16:49:15 -0500 Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy constraints In-Reply-To: <542DB2F3-EAB2-40B3-9782-3C57BCF6355C@marzocchi.net> References: <52EFE6A9.8070203@meder.info> <52EFF9E0.5010209@meder.info> <52EFFCF3.7070001@meder.info> <52F0068A.9050404@meder.info> <542DB2F3-EAB2-40B3-9782-3C57BCF6355C@marzocchi.net> Message-ID: On Mon, Feb 3, 2014 at 4:24 PM, Olaf Marzocchi wrote: > > Il giorno 03/feb/2014, alle ore 22:16, Eric Sproul ha scritto: > >> On Mon, Feb 3, 2014 at 4:13 PM, Kai Meder wrote: >>> OK, this is perfectly acceptable. >>> How do I tell my OmniOS to update anything possible but stop whining about >>> php's and possible future 'entire'-dependencies? >> >> You cannot do that. A package (php-54) has declared that it must have >> r151006. The only way to upgrade would be to remove that package, and >> accept that it will not be installable on the upgraded system. > > Kai, I had the same problem with perl provided by ms.omniti and the suggestion was to take it out and compile my own perl. > It seemed a burden, it took only 10 minutes. Now I also enjoy some advantages I didn't think about. > I think php is about as complex as perl :) It's even easier because there's an existing build you can look at: https://github.com/omniti-labs/omnios-build/tree/omniti-ms/build/php-54 There is a single patch to fix a zlib issue, but otherwise it "just works". From skiselkov.ml at gmail.com Mon Feb 3 22:26:15 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Mon, 03 Feb 2014 22:26:15 +0000 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <089c01cf2127$1b4e9650$51ebc2f0$@acm.org> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> <52EFB459.9050504@gmail.com> <089c01cf2127$1b4e9650$51ebc2f0$@acm.org> Message-ID: <52F01787.7050801@gmail.com> On 2/3/14, 9:30 PM, Paul B. Henson wrote: >> From: Saso Kiselkov >> Sent: Monday, February 03, 2014 7:23 AM >> something like 10GB and turn on compression. Although the standard >> installer doesn't let you set compression on the root pool before >> starting installation, there's a trick to doing it. Before firing up the > > With a little more effort: > > http://omnios.omniti.com/wiki.php/ISOrpoolCustomize > > You can configure the size of the rpool partition, provide arbitrary pool > creation options including compression, and also size swap/dump explicitly > rather than use the installer defaults. Oh wow, configure network, download script, make executable, execute, bootstrap pre-install environment, edit perl script, then cross fingers that it works as expected (be sure to read the log!). I mean I understand that this is more flexible than just running stuff in a screen, but if you were willing to go to such lengths to create this script, what's the problem with fixing the installer to simply prompt for some of these options in the first place? You know, things like swap/dump size, fs options, etc - little things. Doesn't have to be a full installer rewrite. Cheers, -- Saso From henson at acm.org Mon Feb 3 23:34:46 2014 From: henson at acm.org (Paul B. Henson) Date: Mon, 3 Feb 2014 15:34:46 -0800 Subject: [OmniOS-discuss] Where to Run Omni In-Reply-To: <52F01787.7050801@gmail.com> References: <20140202014607.GS5681@bender.unx.csupomona.edu> <20140202213719.GX5681@bender.unx.csupomona.edu> <1834167362.2619679.1391440019290.JavaMail.root@vmware.com> <52EFB459.9050504@gmail.com> <089c01cf2127$1b4e9650$51ebc2f0$@acm.org> <52F01787.7050801@gmail.com> Message-ID: <08a601cf2138$87dc2330$97946990$@acm.org> > From: Saso Kiselkov > Sent: Monday, February 03, 2014 2:26 PM > > Oh wow, configure network, download script, make executable, execute, > bootstrap pre-install environment, edit perl script, then cross fingers > that it works as expected (be sure to read the log!). The omnios installer itself has a log, do you cross your fingers when you use it? I really don't think you can correlate "something creates a log you can look at in case something goes wrong" with "something is likely to go wrong". I haven't had any problems with it, but if somebody doesn't like how it works out for them, they're more than welcome to a full refund ;). > understand that this is more flexible than just running stuff in a > screen, but if you were willing to go to such lengths to create this > script, what's the problem with fixing the installer to simply prompt > for some of these options in the first place? I think you overestimate considerably how much time I put into whipping up this little workaround. I can't imagine it took more than 30 minutes all told. Good luck reengineering the text based installer in that timeframe 8-/. Dunno, it scratched my itch, I know of at least a couple of other people it worked out for, and if somebody gets a good chuckle out of making fun of it, I suppose that's better than nothing. From ask at apache.org Mon Feb 3 23:43:30 2014 From: ask at apache.org (=?windows-1252?Q?Ask_Bj=F8rn_Hansen?=) Date: Mon, 3 Feb 2014 15:43:30 -0800 Subject: [OmniOS-discuss] industrial usb flash In-Reply-To: References: Message-ID: <91A14458-B2EF-42F1-9439-FB1E7A3741A3@apache.org> On Feb 3, 2014, at 7:12 , F?bio Rabelo wrote: > People are talking about "industrial grade" usb flash storage to use > as boot device for Omni and napp-it . I haven?t tried them but Transcend have various SLC flash form factors: http://us.transcend-info.com/industry/products.asp?CatNo=2&LangNo=0&Func1No=1&Func2No=171 Including a USB connected drive: http://us.transcend-info.com/industry/products.asp?CatNo=2&LangNo=0&Func1No=1&Func2No=171 Ask From cks at cs.toronto.edu Tue Feb 4 16:27:27 2014 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 04 Feb 2014 11:27:27 -0500 Subject: [OmniOS-discuss] Are reboots hanging on 'rebooting...' still of interest? Message-ID: <20140204162727.BDA2C1A0A8D@apps0.cs.toronto.edu> Back in October there was a thread about OmniOS systems hanging on reboot (starting at http://lists.omniti.com/pipermail/omnios-discuss/2013-October/001494.html). I now have a OmniOS r151008j install that does this reliably on a SuperMicro X9SRH-7TF motherboard (and the workaround from http://lists.omniti.com/pipermail/omnios-discuss/2013-October/001496.html works for me to work around the issue). Is hardware information or other diagnostics from the machine still of interest to either the list or to individual people? This machine is not in production so I can easily do experiments on it for people, and I'm happy to give configuration dumps or whatever you'd find handy. - cks From mamruoc at gmail.com Tue Feb 4 20:06:41 2014 From: mamruoc at gmail.com (Mam Ruoc) Date: Tue, 4 Feb 2014 21:06:41 +0100 Subject: [OmniOS-discuss] Shutdown/reboot hangs Message-ID: Hello, I have recently moved from ZFSguru to OmniOS and love it. I do have a "problem" though: When I reboot/shutdhown, the system seems to hang due to clients connected to samba and nfs shares. Is it possible to terminate these connects, so the system can shutdown/reboot without me pulling the physical plug? Brgds, Mam From mayuresh at kathe.in Wed Feb 5 13:09:25 2014 From: mayuresh at kathe.in (Mayuresh Kathe) Date: Wed, 05 Feb 2014 18:39:25 +0530 Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not happening! Message-ID: hi, i have been trying to download the r151008 iso since afternoon. fails after downloading around 120mb. this has happened thrice. and inspite of using 'wget -c' it fails to restart. is there any problem with the omniti network connectivity? have successfully downloaded crux linux after that. best, ~mayuresh From skiselkov.ml at gmail.com Wed Feb 5 13:30:40 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Wed, 05 Feb 2014 13:30:40 +0000 Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not happening! In-Reply-To: References: Message-ID: <52F23D00.1030500@gmail.com> On 2/5/14, 1:09 PM, Mayuresh Kathe wrote: > hi, > > i have been trying to download the r151008 iso since afternoon. > fails after downloading around 120mb. > > this has happened thrice. > and inspite of using 'wget -c' it fails to restart. > > is there any problem with the omniti network connectivity? > have successfully downloaded crux linux after that. Works for me. -- Saso From mayuresh at kathe.in Wed Feb 5 14:06:22 2014 From: mayuresh at kathe.in (Mayuresh Kathe) Date: Wed, 5 Feb 2014 14:06:22 +0000 Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not happening! In-Reply-To: <52F23D00.1030500@gmail.com> References: <52F23D00.1030500@gmail.com> Message-ID: <20140205140620.GA11447@SDF.ORG> On Wed, Feb 05, 2014 at 01:30:40PM +0000, Saso Kiselkov wrote: > On 2/5/14, 1:09 PM, Mayuresh Kathe wrote: > > hi, > > > > i have been trying to download the r151008 iso since afternoon. > > fails after downloading around 120mb. > > > > this has happened thrice. > > and inspite of using 'wget -c' it fails to restart. > > > > is there any problem with the omniti network connectivity? > > have successfully downloaded crux linux after that. > > Works for me. yeah, worked at my end too, done in less than 40 minutes. strange... ~mayuresh From skiselkov.ml at gmail.com Wed Feb 5 14:18:36 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Wed, 05 Feb 2014 14:18:36 +0000 Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not happening! In-Reply-To: <20140205140620.GA11447@SDF.ORG> References: <52F23D00.1030500@gmail.com> <20140205140620.GA11447@SDF.ORG> Message-ID: <52F2483C.9040408@gmail.com> On 2/5/14, 2:06 PM, Mayuresh Kathe wrote: > On Wed, Feb 05, 2014 at 01:30:40PM +0000, Saso Kiselkov wrote: >> On 2/5/14, 1:09 PM, Mayuresh Kathe wrote: >>> hi, >>> >>> i have been trying to download the r151008 iso since afternoon. >>> fails after downloading around 120mb. >>> >>> this has happened thrice. >>> and inspite of using 'wget -c' it fails to restart. >>> >>> is there any problem with the omniti network connectivity? >>> have successfully downloaded crux linux after that. >> >> Works for me. > > yeah, worked at my end too, done in less than 40 minutes. > strange... I guess it would be kind of nice if the OmniTI would publish torrents, so that the community can help out with the traffic situation, or at least have it work as a back up. -- Saso From moo at wuffers.net Wed Feb 5 19:59:10 2014 From: moo at wuffers.net (wuffers) Date: Wed, 5 Feb 2014 14:59:10 -0500 Subject: [OmniOS-discuss] Supermicro IPMI based BIOS update In-Reply-To: <03f401cf0e75$faf5d0d0$f0e17270$@acm.org> References: <094801cef550$b5cc58a0$216509e0$@acm.org> <03f401cf0e75$faf5d0d0$f0e17270$@acm.org> Message-ID: On Fri, Jan 10, 2014 at 9:36 PM, Paul B. Henson wrote: > Did you ever get a response? So far I have still been unable to find a > source for purchasing these "IPMI BIOS update" license keys... > Sorry, hadn't gotten a response and had to push my reseller again for some updated information which I finally got, hence the late reply. The part number you are looking for is "SFT-OOB-LIC", which seems to be ~$20 per node (or motherboard). And yes, it's somehow tied to the serial number or BMC MAC of the server, so you can't just buy one activation key and use it on multiple servers. It's all part of their "value-add" Server Management Utilities ( http://www.supermicro.com/products/nfo/files/SSM/SSM_brochure.pdf). I guess in the end, it's up to the vendor to determine what's "essential" or not in their base offerings. I mean, HP charges for "remote graphical access" on their Advanced iLO licenses.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Wed Feb 5 20:23:34 2014 From: henson at acm.org (Paul B. Henson) Date: Wed, 5 Feb 2014 12:23:34 -0800 Subject: [OmniOS-discuss] Supermicro IPMI based BIOS update In-Reply-To: References: <094801cef550$b5cc58a0$216509e0$@acm.org> <03f401cf0e75$faf5d0d0$f0e17270$@acm.org> Message-ID: <0a3a01cf22b0$27f4d920$77de8b60$@acm.org> > From: wuffers> Sent: Wednesday, February 05, 2014 11:59 AM > To: Paul B. Henson > > Sorry, hadn't gotten a response and had to push my reseller again for some > updated information which I finally got, hence the late reply. > > The part number you are looking for is "SFT-OOB-LIC", which seems to be > ~$20 per node (or motherboard). Thanks; I had actually finally gotten the same information out of Supermicro a couple of weeks ago. I tried ordering one of these from CDW, they let me put it in the shopping cart and pay for it, but after two weeks I still hadn't actually gotten an activation key. Multiple voicemail messages and emails to the account representative listed on the invoice yielded nothing, I finally ended up canceling the order after two weeks. Maybe it's just not meant for low volume customers 8-/... From geoffn at gnaa.net Thu Feb 6 00:00:18 2014 From: geoffn at gnaa.net (Geoff Nordli) Date: Wed, 05 Feb 2014 16:00:18 -0800 Subject: [OmniOS-discuss] java can't find libjli.so on OmniOS v11 r151008 -- workaround Message-ID: <52F2D092.5020403@gnaa.net> I know very little about Java, so not sure exactly if there are more things that need to get done in order to fix it, but here is a workaround. I installed the package: pkg install java pkg info java Name: runtime/java Summary: Open-source implementation of the seventh edition of the Java SE Platform State: Installed Publisher: omnios Version: 0.5.11 (jdk7u21-b30) Build Release: 5.11 Branch: 0.151008 Packaging Date: 4 December, 2013 08:10:13 PM Size: 105.29 MB FMRI: pkg://omnios/runtime/java at 0.5.11,5.11-0.151008:20131204T201013Z For whatever reason java couldn't find a library. /usr/bin/java -v ld.so.1: java: fatal: libjli.so: open failed: No such file or directory Killed ldd /usr/bin/java libthread.so.1 => /lib/libthread.so.1 libjli.so => (file not found) libdl.so.1 => /lib/libdl.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 So I ended up doing: cd /usr/lib/ ln -s /usr/java/jre/lib/i386/jli/libjli.so and we are good...... /usr/bin/java -version openjdk version "1.7.0_21" OpenJDK Runtime Environment (build 1.7.0_21-b30) OpenJDK Server VM (build 24.60-b03, mixed mode) Geoff From mayuresh at kathe.in Thu Feb 6 06:30:24 2014 From: mayuresh at kathe.in (Mayuresh Kathe) Date: Thu, 6 Feb 2014 06:30:24 +0000 Subject: [OmniOS-discuss] java can't find libjli.so on OmniOS v11 r151008 -- workaround In-Reply-To: <52F2D092.5020403@gnaa.net> References: <52F2D092.5020403@gnaa.net> Message-ID: <20140206063022.GA22816@SDF.ORG> hey, doesn't java come pre-installed with omnios-r151008j? i just installed jdk and it didn't even touch java packages for installation. ~mayuresh On Wed, Feb 05, 2014 at 04:00:18PM -0800, Geoff Nordli wrote: > I know very little about Java, so not sure exactly if there are more > things that need to get done in order to fix it, but here is a > workaround. > > I installed the package: pkg install java > > pkg info java > Name: runtime/java > Summary: Open-source implementation of the seventh edition of > the Java SE Platform > State: Installed > Publisher: omnios > Version: 0.5.11 (jdk7u21-b30) > Build Release: 5.11 > Branch: 0.151008 > Packaging Date: 4 December, 2013 08:10:13 PM > Size: 105.29 MB > FMRI: > pkg://omnios/runtime/java at 0.5.11,5.11-0.151008:20131204T201013Z > > For whatever reason java couldn't find a library. > > /usr/bin/java -v > ld.so.1: java: fatal: libjli.so: open failed: No such file or directory > Killed > > ldd /usr/bin/java > libthread.so.1 => /lib/libthread.so.1 > libjli.so => (file not found) > libdl.so.1 => /lib/libdl.so.1 > libc.so.1 => /lib/libc.so.1 > libm.so.2 => /lib/libm.so.2 > > So I ended up doing: > > cd /usr/lib/ > > ln -s /usr/java/jre/lib/i386/jli/libjli.so > > > and we are good...... > > /usr/bin/java -version > openjdk version "1.7.0_21" > OpenJDK Runtime Environment (build 1.7.0_21-b30) > OpenJDK Server VM (build 24.60-b03, mixed mode) > > > > > Geoff > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From omniti at familyk.org Fri Feb 7 17:14:07 2014 From: omniti at familyk.org (Willard Korfhage) Date: Fri, 07 Feb 2014 11:14:07 -0600 Subject: [OmniOS-discuss] Warning that partition is too large when mirroring identical disks in root pool Message-ID: <52F5145F.4060005@familyk.org> I just installed OmniOS r151008j last night, and today I wanted to mirror rpool, but have a warning about the disk size. I have 2 Seagate 1TB disks (model ST1000LM024HN), and my OmniOS install is on one of them. I told the install to use the whole disk. Some version of OpenIndiana was previously installed on the disk. The install went without any problem. c2t0d0 is the disk with OmniOS c2t1d0 is supposed to be its mirror To do the mirroring, following the directions in the wiki, I did root at s1:~# pfexec fdisk -B c2t1d0p0 root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s - /dev/rdsk/c2t1d0s2 fmthard: Partition 2 specifies the full disk and is not equal full size of disk. The full disk capacity is 1953407610 sectors. fmthard: Partition 2 specified as 1953471870 sectors starting at 0 does not fit. The full disk contains 1953407610 sectors. fmthard: New volume table of contents now in place. At this point I stopped, and haven't done the mirror. For the disk with the install, format reports Current Disk = c2t0d0 /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0 and further information is root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 * /dev/rdsk/c2t0d0s2 partition map * * Dimensions: * 512 bytes/sector * 126 sectors/track * 255 tracks/cylinder * 32130 sectors/cylinder * 60799 cylinders * 60797 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 0 32130 32129 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 32130 1953375480 1953407609 2 5 01 0 1953471870 1953471869 8 1 01 0 32130 32129 Any idea what is going on? I tried to format the disk without the install (c2t1d0), just to start with a completely fresh disk, but it doesn't work. This appears to be a long-standing (11-month old) Illumos bug (https://www.illumos.org/issues/3610) From protonwrangler at gmail.com Fri Feb 7 17:54:01 2014 From: protonwrangler at gmail.com (Warren Marts) Date: Fri, 7 Feb 2014 10:54:01 -0700 Subject: [OmniOS-discuss] Warning that partition is too large when mirroring identical disks in root pool In-Reply-To: <52F5145F.4060005@familyk.org> References: <52F5145F.4060005@familyk.org> Message-ID: This may be a genuine mismatch between the disks. A few weeks ago I was trying to image between two apparently identical Western Digital RE2 400GB drives. They were produced on the same day and their serial numbers were only ~200 apart, but the disk utility reported block counts that differed by about 20,000 (10 MB) and neither count matched the one on the disk label. I was surprised, to say the least. On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage wrote: > I just installed OmniOS r151008j last night, and today I wanted to mirror > rpool, but have a warning about the disk size. I have 2 Seagate 1TB disks > (model ST1000LM024HN), and my OmniOS install is on one of them. I told the > install to use the whole disk. Some version of OpenIndiana was previously > installed on the disk. The install went without any problem. > > c2t0d0 is the disk with OmniOS > c2t1d0 is supposed to be its mirror > > To do the mirroring, following the directions in the wiki, I did > > root at s1:~# pfexec fdisk -B c2t1d0p0 > root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s - > /dev/rdsk/c2t1d0s2 > fmthard: Partition 2 specifies the full disk and is not equal > full size of disk. The full disk capacity is 1953407610 sectors. > fmthard: Partition 2 specified as 1953471870 sectors starting at 0 > does not fit. The full disk contains 1953407610 sectors. > fmthard: New volume table of contents now in place. > > At this point I stopped, and haven't done the mirror. > > For the disk with the install, format reports > > Current Disk = c2t0d0 > > /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0 > > and further information is > > root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 > * /dev/rdsk/c2t0d0s2 partition map > * > * Dimensions: > * 512 bytes/sector > * 126 sectors/track > * 255 tracks/cylinder > * 32130 sectors/cylinder > * 60799 cylinders > * 60797 accessible cylinders > * > * Flags: > * 1: unmountable > * 10: read-only > * > * Unallocated space: > * First Sector Last > * Sector Count Sector > * 0 32130 32129 > * > * First Sector Last > * Partition Tag Flags Sector Count Sector Mount Directory > 0 2 00 32130 1953375480 1953407609 > 2 5 01 0 1953471870 1953471869 > 8 1 01 0 32130 32129 > > Any idea what is going on? > > I tried to format the disk without the install (c2t1d0), just to start > with a completely fresh disk, but it doesn't work. This appears to be a > long-standing (11-month old) Illumos bug (https://www.illumos.org/ > issues/3610) > > > _______________________________________________ > 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 Sat Feb 8 00:06:38 2014 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Fri, 7 Feb 2014 18:06:38 -0600 (CST) Subject: [OmniOS-discuss] Warning that partition is too large when mirroring identical disks in root pool In-Reply-To: <52F5145F.4060005@familyk.org> References: <52F5145F.4060005@familyk.org> Message-ID: On Fri, 7 Feb 2014, Willard Korfhage wrote: > > At this point I stopped, and haven't done the mirror. There is some possibility that the mirror will still work. Due to problems like this, zfs leaves some spare unused space. This might only apply to the case where zfs does the partitioning though (i.e. not for rpool). You can try initating the mirror and see if there is a failure. Zfs puts a marker toward the end of the partition so it will know if there is a problem. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From omniti at familyk.org Sat Feb 8 06:21:53 2014 From: omniti at familyk.org (Willard Korfhage) Date: Sat, 08 Feb 2014 00:21:53 -0600 Subject: [OmniOS-discuss] Warning that partition is too large when mirroring identical disks in root pool In-Reply-To: References: <52F5145F.4060005@familyk.org> Message-ID: <52F5CD01.9020500@familyk.org> That could happen, depending on how many bad blocks the disk has, but in this case, the numbers it reports, the numbers it says are inconsistent, are from the original OmniOS install. I am surprised that the original install would generate an inconsistent partition arrangement. Now if I could just figure out how to format the disk, I could try starting from scratch. Given the Illumos bug, I suppose I'll have to pull it and format it on another machine. On 2/7/2014 11:54 AM, Warren Marts wrote: > This may be a genuine mismatch between the disks. > > A few weeks ago I was trying to image between two apparently identical > Western Digital RE2 400GB drives. They were produced on the same day > and their serial numbers were only ~200 apart, but the disk utility > reported block counts that differed by about 20,000 (10 MB) and > neither count matched the one on the disk label. > > I was surprised, to say the least. > > > On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage > wrote: > > I just installed OmniOS r151008j last night, and today I wanted to > mirror rpool, but have a warning about the disk size. I have 2 > Seagate 1TB disks (model ST1000LM024HN), and my OmniOS install is > on one of them. I told the install to use the whole disk. Some > version of OpenIndiana was previously installed on the disk. The > install went without any problem. > > c2t0d0 is the disk with OmniOS > c2t1d0 is supposed to be its mirror > > To do the mirroring, following the directions in the wiki, I did > > root at s1:~# pfexec fdisk -B c2t1d0p0 > root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s - > /dev/rdsk/c2t1d0s2 > fmthard: Partition 2 specifies the full disk and is not equal > full size of disk. The full disk capacity is 1953407610 sectors. > fmthard: Partition 2 specified as 1953471870 sectors starting at 0 > does not fit. The full disk contains 1953407610 sectors. > fmthard: New volume table of contents now in place. > > At this point I stopped, and haven't done the mirror. > > For the disk with the install, format reports > > Current Disk = c2t0d0 > > /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0 > > and further information is > > root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 > * /dev/rdsk/c2t0d0s2 partition map > * > * Dimensions: > * 512 bytes/sector > * 126 sectors/track > * 255 tracks/cylinder > * 32130 sectors/cylinder > * 60799 cylinders > * 60797 accessible cylinders > * > * Flags: > * 1: unmountable > * 10: read-only > * > * Unallocated space: > * First Sector Last > * Sector Count Sector > * 0 32130 32129 > * > * First Sector Last > * Partition Tag Flags Sector Count Sector Mount Directory > 0 2 00 32130 1953375480 1953407609 > 2 5 01 0 1953471870 1953471869 > 8 1 01 0 32130 32129 > > Any idea what is going on? > > I tried to format the disk without the install (c2t1d0), just to > start with a completely fresh disk, but it doesn't work. This > appears to be a long-standing (11-month old) Illumos bug > (https://www.illumos.org/issues/3610) > > > _______________________________________________ > 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 mayuresh at kathe.in Sat Feb 8 11:18:30 2014 From: mayuresh at kathe.in (Mayuresh Kathe) Date: Sat, 8 Feb 2014 16:48:30 +0530 Subject: [OmniOS-discuss] building our own packages : suggested prefix? Message-ID: <20140208111830.GA7220@h61m> hello, would anyone with custom software building for omnios be able to suggest the usual value for "--prefix" variable to "./configure"? to test things out, i have installed everything within my home directory, which has created a bunch of directories which kind-a looks messy. :) i have been building and playing with lynx, mutt and ircii. thanks, ~mayuresh From ben at fluffy.co.uk Sat Feb 8 16:00:21 2014 From: ben at fluffy.co.uk (Ben Summers) Date: Sat, 8 Feb 2014 16:00:21 +0000 Subject: [OmniOS-discuss] publisher signature-policy=require-signatures for new zones Message-ID: <3A7AF9D2-AB1E-492A-B18B-C36A86C91E3F@fluffy.co.uk> Hello, r151008 now includes signed packages, but the default signature-policy is verify, so it's still vulnerable to MITM if the attacker simply removes the signatures from the manifests. I can run pkg set-publisher --set-property signature-policy=require-signatures omnios immediately after install from the iso to make sure any updates in the global zone are properly checked. However, when I install a zone, the zone's signature-policy is the default of verify. pkg downloads files from the IPS server, so anything in the zone's image is vulnerable. Is it possible to specify signature-policy=require-signatures for new zones in the initial configuration? Thanks, Ben From tim at multitalents.net Sat Feb 8 19:10:52 2014 From: tim at multitalents.net (Tim Rice) Date: Sat, 8 Feb 2014 11:10:52 -0800 (PST) Subject: [OmniOS-discuss] building our own packages : suggested prefix? In-Reply-To: <20140208111830.GA7220@h61m> References: <20140208111830.GA7220@h61m> Message-ID: Mayuresh, On Sat, 8 Feb 2014, Mayuresh Kathe wrote: > hello, would anyone with custom software building for omnios > be able to suggest the usual value for "--prefix" variable > to "./configure"? That would depend on whether you intend to build installable packages or are just doing the equivalent of "configure ; make ; make install". If you are not packaging up the code and are just doing a "make install", the convention is to use /usr/local as the prefix. If you intend to build a package installable with "pkg install some_package_name", there are more things to consider. If you intend to publish them for others to use, you will probably want to choose some new directory in /opt. Perhaps /opt/mk. If they are only used for systems you control, you may want to consider something like PACKAGE=lynx ./configure \ --prefix=/opt \ --sysconfdir=/etc/opt/${PACKAGE} \ --localstatedir=/var/opt/${PACKAGE} \ --mandir=/opt/man \ --docdir=/opt/share/doc/packages/${PACKAGE} \ --htmldir=/opt/share/doc/packages/${PACKAGE}/html \ > to test things out, i have installed everything within my > home directory, which has created a bunch of directories which > kind-a looks messy. :) > > i have been building and playing with lynx, mutt and ircii. > > thanks, > > ~mayuresh -- Tim Rice Multitalents tim at multitalents.net From peter.tribble at gmail.com Sat Feb 8 21:10:39 2014 From: peter.tribble at gmail.com (Peter Tribble) Date: Sat, 8 Feb 2014 21:10:39 +0000 Subject: [OmniOS-discuss] Warning that partition is too large when mirroring identical disks in root pool In-Reply-To: <52F5CD01.9020500@familyk.org> References: <52F5145F.4060005@familyk.org> <52F5CD01.9020500@familyk.org> Message-ID: On Sat, Feb 8, 2014 at 6:21 AM, Willard Korfhage wrote: > That could happen, depending on how many bad blocks the disk has, but in > this case, the numbers it reports, the numbers it says are inconsistent, > are from the original OmniOS install. I am surprised that the original > install would generate an inconsistent partition arrangement. > Why do you think that? What the error you've given is saying is that the size of the Solaris partition on the new disk is smaller than the size of the Solaris partition on the original disk. That's all. > Now if I could just figure out how to format the disk, I could try > starting from scratch. Given the Illumos bug, I suppose I'll have to pull > it and format it on another machine. > I can't see where that bug comes into play. The need to do a low-level format of a drive is extremely rare. I see these discrepancies fairly frequently when fdisk gets out of whack. Most commonly, because some drives have a diagnostic partition on them, but sometimes because it can't decide whether to start at cylinder 0 or 1. Or just because the drives were partitioned up on different OS versions. Compare: fdisk -W - /dev/rdsk/c2t0d0p0 fdisk -W - /dev/rdsk/c2t1d0p0 If the fdisk dimensions do actually match, then you could save out the fdisk table off the first disk and load it onto the second, something like: fdisk -W /tmp/fmap /dev/rdsk/c2t0d0p0 fdisk -F /tmp/fmap /dev/rdsk/c2t1d0p0 and then do the ptrtvtoc|fmthard step. If you look at the sizes reported, specifically: * 32130 sectors/cylinder * 60799 cylinders * 60797 accessible cylinders and * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 32130 1953375480 1953407609 2 5 01 0 1953471870 1953471869 8 1 01 0 32130 32129 then it's allocated slice 0 up to the end of the 60797 accessible cylinders, but slice 2 (which refers to the whole disk) is 64260 sectors or 2 cylinders longer, filling out to the end of 60799. The second disk you have is reporting a size of 1953407610 sectors, or 0-1953407609, or 32130*60797, so it's just picked up the accessible cylinders. The disks appear to be the same size, it's those 2 inaccessible cylinders that are confusing matters. If the fdisk dimensions are different (the second disk only appears to really be 60797 sectors) then it's still not a problem, as all you're interested in is slice 0, which is the right size. Simplest way to do that is to grep out the line in the prtvtoc output for partition 2, and fmthard will fill it in automatically at whatever size it thinks is correct. On 2/7/2014 11:54 AM, Warren Marts wrote: > > This may be a genuine mismatch between the disks. > > A few weeks ago I was trying to image between two apparently identical > Western Digital RE2 400GB drives. They were produced on the same day and > their serial numbers were only ~200 apart, but the disk utility reported > block counts that differed by about 20,000 (10 MB) and neither count > matched the one on the disk label. > > I was surprised, to say the least. > > > On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage wrote: > >> I just installed OmniOS r151008j last night, and today I wanted to mirror >> rpool, but have a warning about the disk size. I have 2 Seagate 1TB disks >> (model ST1000LM024HN), and my OmniOS install is on one of them. I told the >> install to use the whole disk. Some version of OpenIndiana was previously >> installed on the disk. The install went without any problem. >> >> c2t0d0 is the disk with OmniOS >> c2t1d0 is supposed to be its mirror >> >> To do the mirroring, following the directions in the wiki, I did >> >> root at s1:~# pfexec fdisk -B c2t1d0p0 >> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s - >> /dev/rdsk/c2t1d0s2 >> fmthard: Partition 2 specifies the full disk and is not equal >> full size of disk. The full disk capacity is 1953407610 sectors. >> fmthard: Partition 2 specified as 1953471870 sectors starting at 0 >> does not fit. The full disk contains 1953407610 sectors. >> fmthard: New volume table of contents now in place. >> >> >> At this point I stopped, and haven't done the mirror. >> >> For the disk with the install, format reports >> >> Current Disk = c2t0d0 >> >> /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0 >> >> and further information is >> >> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 >> * /dev/rdsk/c2t0d0s2 partition map >> * >> * Dimensions: >> * 512 bytes/sector >> * 126 sectors/track >> * 255 tracks/cylinder >> * 32130 sectors/cylinder >> * 60799 cylinders >> * 60797 accessible cylinders >> * >> * Flags: >> * 1: unmountable >> * 10: read-only >> * >> * Unallocated space: >> * First Sector Last >> * Sector Count Sector >> * 0 32130 32129 >> * >> * First Sector Last >> * Partition Tag Flags Sector Count Sector Mount Directory >> 0 2 00 32130 1953375480 1953407609 >> 2 5 01 0 1953471870 1953471869 >> 8 1 01 0 32130 32129 >> >> Any idea what is going on? >> >> I tried to format the disk without the install (c2t1d0), just to start >> with a completely fresh disk, but it doesn't work. This appears to be a >> long-standing (11-month old) Illumos bug ( >> https://www.illumos.org/issues/3610) >> >> >> >> _______________________________________________ >> 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 > > -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayuresh at kathe.in Sun Feb 9 02:47:45 2014 From: mayuresh at kathe.in (Mayuresh Kathe) Date: Sun, 9 Feb 2014 08:17:45 +0530 Subject: [OmniOS-discuss] building our own packages : suggested prefix? In-Reply-To: References: <20140208111830.GA7220@h61m> Message-ID: <20140209024744.GA9374@h61m> On Sat, Feb 08, 2014 at 11:10:52AM -0800, Tim Rice wrote: > Mayuresh, > > On Sat, 8 Feb 2014, Mayuresh Kathe wrote: > > > hello, would anyone with custom software building for omnios > > be able to suggest the usual value for "--prefix" variable > > to "./configure"? > That would depend on whether you intend to build installable packages or > are just doing the equivalent of "configure ; make ; make install". > If you are not packaging up the code and are just doing a "make install", > the convention is to use /usr/local as the prefix. tim, thanks for that tip, stuff installed and works like a charm. there's just one hitch though, how do i suggest to omnios to also use /usr/local/man as a directory for man pages? i did hunt for man.conf in /etc, found nothing. > If you intend to build a package installable with > "pkg install some_package_name", there are more things to consider. > If you intend to publish them for others to use, you will probably want > to choose some new directory in /opt. Perhaps /opt/mk. > If they are only used for systems you control, you may want to consider > something like i don't have the resources to put up my own repository. is there a way i could work with someone having a repository to put up a bunch of packages which might be useful for general work like mail, www, irc, etc. thanks, ~mayuresh From tim at multitalents.net Sun Feb 9 03:31:49 2014 From: tim at multitalents.net (Tim Rice) Date: Sat, 8 Feb 2014 19:31:49 -0800 (PST) Subject: [OmniOS-discuss] building our own packages : suggested prefix? In-Reply-To: <20140209024744.GA9374@h61m> References: <20140208111830.GA7220@h61m> <20140209024744.GA9374@h61m> Message-ID: On Sun, 9 Feb 2014, Mayuresh Kathe wrote: > tim, thanks for that tip, stuff installed and works like a charm. > there's just one hitch though, how do i suggest to omnios to also > use /usr/local/man as a directory for man pages? Try MANPATH=/usr/share/man:/usr/local/man ; export MANPATH -- Tim Rice Multitalents tim at multitalents.net From mayuresh at kathe.in Sun Feb 9 03:48:17 2014 From: mayuresh at kathe.in (Mayuresh Kathe) Date: Sun, 9 Feb 2014 09:18:17 +0530 Subject: [OmniOS-discuss] building our own packages : suggested prefix? In-Reply-To: References: <20140208111830.GA7220@h61m> <20140209024744.GA9374@h61m> Message-ID: <20140209034817.GA731@h61m> On Sat, Feb 08, 2014 at 07:31:49PM -0800, Tim Rice wrote: > On Sun, 9 Feb 2014, Mayuresh Kathe wrote: > > > tim, thanks for that tip, stuff installed and works like a charm. > > there's just one hitch though, how do i suggest to omnios to also > > use /usr/local/man as a directory for man pages? > > Try > MANPATH=/usr/share/man:/usr/local/man ; export MANPATH perfect. works like a charm. thanks a million. :) ~mayuresh From omniti at familyk.org Sun Feb 9 05:07:33 2014 From: omniti at familyk.org (Willard Korfhage) Date: Sat, 08 Feb 2014 23:07:33 -0600 Subject: [OmniOS-discuss] Warning that partition is too large when mirroring identical disks in root pool In-Reply-To: References: <52F5145F.4060005@familyk.org> <52F5CD01.9020500@familyk.org> Message-ID: <52F70D15.4010109@familyk.org> Thanks for the explanation of the discrepancy. The output of the fdisk -W commands is identical for both disks, as I would expect, and the vtoc is identical on both disks, too. I think I misinterpreted the intent of the message from fmthard. I was concerned that it meant "the vtoc doesn't make sense, but I am copying it to the disk, anyway," leaving me with a disk in a bad state. Instead it appears to have been more of a "fixed that for you" message, and the disk is fine, with all the dimensions matching on both disks. I will continue with the mirroring. On 2/8/2014 3:10 PM, Peter Tribble wrote: > On Sat, Feb 8, 2014 at 6:21 AM, Willard Korfhage > wrote: > > That could happen, depending on how many bad blocks the disk has, > but in this case, the numbers it reports, the numbers it says are > inconsistent, are from the original OmniOS install. I am surprised > that the original install would generate an inconsistent partition > arrangement. > > > Why do you think that? What the error you've given is saying is that > the size of the Solaris partition on the new disk is smaller than the > size of the Solaris partition on the original disk. That's all. > > Now if I could just figure out how to format the disk, I could try > starting from scratch. Given the Illumos bug, I suppose I'll have > to pull it and format it on another machine. > > > I can't see where that bug comes into play. The need to do a low-level > format of a drive is extremely rare. > > I see these discrepancies fairly frequently when fdisk gets out of whack. > Most commonly, because some drives have a diagnostic partition on them, > but sometimes because it can't decide whether to start at cylinder 0 or 1. > Or just because the drives were partitioned up on different OS versions. > > Compare: > > fdisk -W - /dev/rdsk/c2t0d0p0 > fdisk -W - /dev/rdsk/c2t1d0p0 > > If the fdisk dimensions do actually match, then you could save > out the fdisk table off the first disk and load it onto the second, > something like: > > fdisk -W /tmp/fmap /dev/rdsk/c2t0d0p0 > fdisk -F /tmp/fmap /dev/rdsk/c2t1d0p0 > > and then do the ptrtvtoc|fmthard step. > > If you look at the sizes reported, specifically: > > * 32130 sectors/cylinder > * 60799 cylinders > * 60797 accessible cylinders > > and > > * First Sector Last > * Partition Tag Flags Sector Count Sector Mount Directory > 0 2 00 32130 1953375480 1953407609 > 2 5 01 0 1953471870 1953471869 > 8 1 01 0 32130 32129 > > then it's allocated slice 0 up to the end of the 60797 accessible > cylinders, but slice 2 (which refers to the whole disk) is 64260 > sectors or 2 cylinders longer, filling out to the end of 60799. > The second disk you have is reporting a size of 1953407610 > sectors, or 0-1953407609, or 32130*60797, so it's just picked > up the accessible cylinders. The disks appear to be the same > size, it's those 2 inaccessible cylinders that are confusing matters. > > If the fdisk dimensions are different (the second disk only appears > to really be 60797 sectors) then it's still not a problem, as all you're > interested in is slice 0, which is the right size. Simplest way to do > that is to grep out the line in the prtvtoc output for partition 2, and > fmthard will fill it in automatically at whatever size it thinks is > correct. > > > On 2/7/2014 11:54 AM, Warren Marts wrote: >> This may be a genuine mismatch between the disks. >> >> A few weeks ago I was trying to image between two apparently >> identical Western Digital RE2 400GB drives. They were produced on >> the same day and their serial numbers were only ~200 apart, but >> the disk utility reported block counts that differed by about >> 20,000 (10 MB) and neither count matched the one on the disk label. >> >> I was surprised, to say the least. >> >> >> On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage >> > wrote: >> >> I just installed OmniOS r151008j last night, and today I >> wanted to mirror rpool, but have a warning about the disk >> size. I have 2 Seagate 1TB disks (model ST1000LM024HN), and >> my OmniOS install is on one of them. I told the install to >> use the whole disk. Some version of OpenIndiana was >> previously installed on the disk. The install went without >> any problem. >> >> c2t0d0 is the disk with OmniOS >> c2t1d0 is supposed to be its mirror >> >> To do the mirroring, following the directions in the wiki, I did >> >> root at s1:~# pfexec fdisk -B c2t1d0p0 >> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard >> -s - /dev/rdsk/c2t1d0s2 >> fmthard: Partition 2 specifies the full disk and is not equal >> full size of disk. The full disk capacity is 1953407610 sectors. >> fmthard: Partition 2 specified as 1953471870 sectors starting >> at 0 >> does not fit. The full disk contains 1953407610 sectors. >> fmthard: New volume table of contents now in place. >> >> >> At this point I stopped, and haven't done the mirror. >> >> For the disk with the install, format reports >> >> Current Disk = c2t0d0 >> >> /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0 >> >> and further information is >> >> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 >> * /dev/rdsk/c2t0d0s2 partition map >> * >> * Dimensions: >> * 512 bytes/sector >> * 126 sectors/track >> * 255 tracks/cylinder >> * 32130 sectors/cylinder >> * 60799 cylinders >> * 60797 accessible cylinders >> * >> * Flags: >> * 1: unmountable >> * 10: read-only >> * >> * Unallocated space: >> * First Sector Last >> * Sector Count Sector >> * 0 32130 32129 >> * >> * First Sector Last >> * Partition Tag Flags Sector Count Sector Mount >> Directory >> 0 2 00 32130 1953375480 1953407609 >> 2 5 01 0 1953471870 1953471869 >> 8 1 01 0 32130 32129 >> >> Any idea what is going on? >> >> I tried to format the disk without the install (c2t1d0), just >> to start with a completely fresh disk, but it doesn't work. >> This appears to be a long-standing (11-month old) Illumos bug >> (https://www.illumos.org/issues/3610) >> >> >> >> _______________________________________________ >> 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 > > > > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From omniti at familyk.org Sun Feb 9 05:23:03 2014 From: omniti at familyk.org (Willard Korfhage) Date: Sat, 08 Feb 2014 23:23:03 -0600 Subject: [OmniOS-discuss] An error on the VirtualMachinesKVM wiki page Message-ID: <52F710B7.7010606@familyk.org> On http://omnios.omniti.com/wiki.php/VirtualMachinesKVM, the start virtual machine script has an error in it. The 5th line from the bottom is public_nic=$(dladm show-vnic|grep vnic1|awk '{print $2}') but that "vnic1" in the middle should really be ${VNIC} Also, that "prepare a volume for the VM" section on the page, which currently contains only "TBD" can be as simple as a single command, such as zfs create -p -V 10G tank/myvm/disk0 That worked for me, but I expect there are other ways of preparing the disk, too. From franz.schober at firmos.at Mon Feb 10 11:42:08 2014 From: franz.schober at firmos.at (Franz Schober) Date: Mon, 10 Feb 2014 12:42:08 +0100 Subject: [OmniOS-discuss] Kernel panic on using iSCSI target on same host, differences between OmniOS r151006 and r151008 ? Message-ID: <52F8BB10.3090207@firmos.at> Hi, when using a device provided by iSCSI COMSTAR target on the same host for a zpool, the system (OmniOS r151008j) raised a kernel panic after a timeout of the COMSTAR device at the first try, on the second attempt it just did not work. On OmniOS r151006y the same worked without any problems. Are there any possible known changes on COMSTAR and ZFS regarding this problem in between the two stable OmniOS versions ? Details, why to do that anyway :-) and a crash dump are available at https://www.illumos.org/issues/4589 Thx a lot, Franz -- --------------------------------------------------------------------- Dipl.-Ing. Franz Schober franz.schober at firmos.at FirmOS Business Solutions Gmbh Obstweg 4 A-8073 Graz-Neupirka Tel +43 316 242322-10 Fax +43 316 242322-99 http://www.firmos.at FN 278321x, Lg f?r ZRS Graz UID-Nr: ATU62657119 Dieses eMail ist vertraulich und nur f?r die genannten Empf?nger bestimmt. Sollten Sie nicht der gew?nschte Adressat sein, bitten wir Sie, uns umgehend zu informieren sowie vorliegende Nachricht zu l?schen ohne vorher einen Ausdruck oder eine Kopie anzufertigen. This message and any attached files are confidential and intended solely for the adressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee(s) is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission. From franz.schober at firmos.at Mon Feb 10 15:41:25 2014 From: franz.schober at firmos.at (Franz Schober) Date: Mon, 10 Feb 2014 16:41:25 +0100 Subject: [OmniOS-discuss] Kernel panic on using iSCSI target on same host, differences between OmniOS r151006 and r151008 ? In-Reply-To: <52F8BB10.3090207@firmos.at> References: <52F8BB10.3090207@firmos.at> Message-ID: <52F8F325.1070405@firmos.at> Although the creation of the zpool worked on OmniOS r151006y, the zfs send I wanted to test on the pool failed with a kernel panic on r151006y also. zfs create test/testds dd if=/dev/zero of=/test/testds/file1 bs=1M count=50 dd if=/dev/zero of=/test/testds/file2 bs=1M count=50 zfs snapshot test/testds at test zfs send -R test/testds at test | pv > /dev/null > Hi, > > when using a device provided by iSCSI COMSTAR target on the same host > for a zpool, the system (OmniOS r151008j) raised a kernel panic > after a timeout of the COMSTAR device at the first try, on the second > attempt it just did not work. > > On OmniOS r151006y the same worked without any problems. > > Are there any possible known changes on COMSTAR and ZFS regarding > this problem in between the two stable OmniOS versions ? > > Details, why to do that anyway :-) and a crash dump are available at > https://www.illumos.org/issues/4589 > > Thx a lot, > Franz > From thierry.bingen at haulogy.net Mon Feb 10 18:59:42 2014 From: thierry.bingen at haulogy.net (Thierry Bingen) Date: Mon, 10 Feb 2014 19:59:42 +0100 Subject: [OmniOS-discuss] A publisher for certutil ? In-Reply-To: References: Message-ID: <262ABC7D-A1DC-4A8B-ABD3-6DB6989BE9C0@homeshore.be> Does anyone publish a package containing NSS certutil ? Thanks, Thierry From cj.keist at colostate.edu Mon Feb 10 22:55:13 2014 From: cj.keist at colostate.edu (CJ Keist) Date: Mon, 10 Feb 2014 15:55:13 -0700 Subject: [OmniOS-discuss] LFS Support for Samba Message-ID: <52F958D1.5060001@colostate.edu> Hello, Trying to compile Samba 4.1.4 on OminOS 151.08j-r1. running configure I get the following: Checking getconf LFS_CFLAGS : -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Checking getconf large file support flags work : not found Checking for large file support without additional flags : not found Checking for -D_FILE_OFFSET_BITS=64 : not found Checking for -D_LARGE_FILES : not found Samba requires large file support support, but not available on this platform: sizeof(off_t) < 8 I have not been able to find anything searching the net on this issue. Any ideas? I have gcc 4.8.1 installed. -- C. J. Keist Email: cj.keist at colostate.edu Systems Group Manager Solaris 10 OS (SAI) Engineering Network Services Phone: 970-491-0630 College of Engineering, CSU Fax: 970-491-5569 Ft. Collins, CO 80523-1301 All I want is a chance to prove 'Money can't buy happiness' From jimklimov at cos.ru Mon Feb 10 23:01:23 2014 From: jimklimov at cos.ru (Jim Klimov) Date: Tue, 11 Feb 2014 00:01:23 +0100 Subject: [OmniOS-discuss] Shutdown/reboot hangs In-Reply-To: References: Message-ID: <52F95A43.1070002@cos.ru> On 2014-02-04 21:06, Mam Ruoc wrote: > Hello, > > I have recently moved from ZFSguru to OmniOS and love it. > > I do have a "problem" though: > When I reboot/shutdhown, the system seems to hang due to clients connected to samba and nfs shares. > Is it possible to terminate these connects, so the system can shutdown/reboot without me pulling the physical plug? Just to clarify: does this also hang on shutdown requests indeed, or only on reboots? There is this feature called fastboot, which essentially allows a running kernel to execute another kernel and pass control to it, giving the effect of an OS restart without the BIOS POST tests. However, on some hardware this procedure fails and a full reboot is required (configurable via SMF, or done from command line as "reboot -p"). Does this help? ;) //Jim Klimov From cj.keist at colostate.edu Mon Feb 10 23:09:24 2014 From: cj.keist at colostate.edu (CJ Keist) Date: Mon, 10 Feb 2014 16:09:24 -0700 Subject: [OmniOS-discuss] LFS Support for Samba Message-ID: <52F95C24.2060602@colostate.edu> Never mind, I was missing some developer packages: so along with gcc48 I installed the following. Not sure which package fixed the issue though. pkg install pkg:/developer/versioning/git pkg install pkg:/developer/build/gnu-make pkg install pkg:/system/header ------------------------------------- Hello, Trying to compile Samba 4.1.4 on OminOS 151.08j-r1. running configure I get the following: Checking getconf LFS_CFLAGS : -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Checking getconf large file support flags work : not found Checking for large file support without additional flags : not found Checking for -D_FILE_OFFSET_BITS=64 : not found Checking for -D_LARGE_FILES : not found Samba requires large file support support, but not available on this platform: sizeof(off_t) < 8 I have not been able to find anything searching the net on this issue. Any ideas? I have gcc 4.8.1 installed. -- C. J. Keist Email: cj.keist at colostate.edu Systems Group Manager Solaris 10 OS (SAI) Engineering Network Services Phone: 970-491-0630 College of Engineering, CSU Fax: 970-491-5569 Ft. Collins, CO 80523-1301 All I want is a chance to prove 'Money can't buy happiness' From danmcd at omniti.com Mon Feb 10 23:19:15 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 10 Feb 2014 18:19:15 -0500 Subject: [OmniOS-discuss] LFS Support for Samba In-Reply-To: <52F95C24.2060602@colostate.edu> References: <52F95C24.2060602@colostate.edu> Message-ID: On Feb 10, 2014, at 6:09 PM, CJ Keist wrote: > Never mind, > I was missing some developer packages: so along with gcc48 I installed the following. Not sure which package fixed the issue though. > pkg install pkg:/system/header Likely that one. Dan From ben at fluffy.co.uk Tue Feb 11 16:22:38 2014 From: ben at fluffy.co.uk (Ben Summers) Date: Tue, 11 Feb 2014 16:22:38 +0000 Subject: [OmniOS-discuss] publisher signature-policy=require-signatures for new zones In-Reply-To: <3A7AF9D2-AB1E-492A-B18B-C36A86C91E3F@fluffy.co.uk> References: <3A7AF9D2-AB1E-492A-B18B-C36A86C91E3F@fluffy.co.uk> Message-ID: <3E9ABD4B-9752-4BD4-8AE8-BCEFCA4143BD@fluffy.co.uk> Replying to my own email for the archives... It appears you can't do this. pkg is hard coded to use "verify" as the signature-policy. The workaround is to install the zone and before booting, pfexec pkg -R /path/to/zone/root set-publisher --set-property signature-policy=require-signatures omnios to set the property, then pfexec pkg -R /path/to/zone/root fix to check all the signatures and correct any errors. Ben On 8 Feb 2014, at 16:00, Ben Summers wrote: > > Hello, > > r151008 now includes signed packages, but the default signature-policy is verify, so it's still vulnerable to MITM if the attacker simply removes the signatures from the manifests. > > I can run > > pkg set-publisher --set-property signature-policy=require-signatures omnios > > immediately after install from the iso to make sure any updates in the global zone are properly checked. > > However, when I install a zone, the zone's signature-policy is the default of verify. pkg downloads files from the IPS server, so anything in the zone's image is vulnerable. > > Is it possible to specify signature-policy=require-signatures for new zones in the initial configuration? > > Thanks, > > Ben > > > From ben.summers at oneis.co.uk Tue Feb 11 16:25:19 2014 From: ben.summers at oneis.co.uk (Ben Summers) Date: Tue, 11 Feb 2014 16:25:19 +0000 Subject: [OmniOS-discuss] Packages without signatures in r151008j Message-ID: Installing r151008j and running pkg verify with signature-policy=require-signatures shows the updated packages aren't signed: Verifying: pkg://omnios/library/security/openssl ERROR The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/library/security/openssl at 1.0.1.6,5.11-0.151008:20140110T173804Z. Verifying: pkg://omnios/package/pkg ERROR The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/package/pkg at 0.5.11,5.11-0.151008:20131230T201906Z. Verifying: pkg://omnios/system/zones/brand/ipkg ERROR The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/system/zones/brand/ipkg at 0.5.11,5.11-0.151008:20131230T201908Z. Is running with signature-policy=require-signatures a realistic option? Thanks, Ben From ben at fluffy.co.uk Tue Feb 11 16:30:47 2014 From: ben at fluffy.co.uk (Ben Summers) Date: Tue, 11 Feb 2014 16:30:47 +0000 Subject: [OmniOS-discuss] Packages without signatures in r151008j Message-ID: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> Installing r151008j and running pkg verify with signature-policy=require-signatures shows the updated packages aren't signed: Verifying: pkg://omnios/library/security/openssl ERROR The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/library/security/openssl at 1.0.1.6,5.11-0.151008:20140110T173804Z. Verifying: pkg://omnios/package/pkg ERROR The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/package/pkg at 0.5.11,5.11-0.151008:20131230T201906Z. Verifying: pkg://omnios/system/zones/brand/ipkg ERROR The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/system/zones/brand/ipkg at 0.5.11,5.11-0.151008:20131230T201908Z. Is running with signature-policy=require-signatures a realistic option? Thanks, Ben -- http://bens.me.uk From mmabis at vmware.com Tue Feb 11 17:19:09 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Tue, 11 Feb 2014 09:19:09 -0800 (PST) Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e In-Reply-To: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> Message-ID: <1443312846.4351885.1392139149497.JavaMail.root@vmware.com> Hey all, I just checked in with my system remotely and found that it had panic'ed for some reason i have left it in this state just in case i need to get more information... Has this been seen before? using Build OmniOS-6de5e81 64bit on a C2740D4I by ASRock with 2x8GB ECC Memory Modules. Attaching picture Thanks Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-11 at 9.13.51 AM.png Type: image/png Size: 180891 bytes Desc: not available URL: From danmcd at omniti.com Tue Feb 11 19:10:49 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 11 Feb 2014 14:10:49 -0500 Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e In-Reply-To: <1443312846.4351885.1392139149497.JavaMail.root@vmware.com> References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> <1443312846.4351885.1392139149497.JavaMail.root@vmware.com> Message-ID: <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com> On Feb 11, 2014, at 12:19 PM, Matthew Mabis wrote: > Hey all, > > I just checked in with my system remotely and found that it had panic'ed for some reason i have left it in this state just in case i need to get more information... Has this been seen before? using Build OmniOS-6de5e81 64bit on a C2740D4I by ASRock with 2x8GB ECC Memory Modules. Does this constantly happen? Or just this once? Seeing *where* in "unix" it crashed, complete with a stack trace, would be a good first step. Providing a system dump would be better (see dumpadm(1M)). Dan From mmabis at vmware.com Tue Feb 11 19:37:33 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Tue, 11 Feb 2014 11:37:33 -0800 (PST) Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e In-Reply-To: <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com> References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> <1443312846.4351885.1392139149497.JavaMail.root@vmware.com> <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com> Message-ID: <631092638.4391426.1392147453266.JavaMail.root@vmware.com> First time crash, system was up for ~48 hours and it crashed like this... Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... Any way i can get to the dump files now? Matt ----- Original Message ----- From: "Dan McDonald" To: "Matthew Mabis" Cc: "Ben Summers" , "omnios-discuss" Sent: Tuesday, February 11, 2014 11:10:49 AM Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e On Feb 11, 2014, at 12:19 PM, Matthew Mabis wrote: > Hey all, > > I just checked in with my system remotely and found that it had panic'ed for some reason i have left it in this state just in case i need to get more information... Has this been seen before? using Build OmniOS-6de5e81 64bit on a C2740D4I by ASRock with 2x8GB ECC Memory Modules. Does this constantly happen? Or just this once? Seeing *where* in "unix" it crashed, complete with a stack trace, would be a good first step. Providing a system dump would be better (see dumpadm(1M)). Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-11 at 11.34.08 AM.png Type: image/png Size: 86926 bytes Desc: not available URL: From danmcd at omniti.com Tue Feb 11 19:38:52 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 11 Feb 2014 14:38:52 -0500 Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e In-Reply-To: <631092638.4391426.1392147453266.JavaMail.root@vmware.com> References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> <1443312846.4351885.1392139149497.JavaMail.root@vmware.com> <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com> <631092638.4391426.1392147453266.JavaMail.root@vmware.com> Message-ID: On Feb 11, 2014, at 2:37 PM, Matthew Mabis wrote: > First time crash, system was up for ~48 hours and it crashed like this... > > Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... > > Any way i can get to the dump files now? If it's in a crash-on-boot cycle, likely not. Have you tried booting an install CD or USB stick? If it ALSO crashes, it's highly likely a HW problem, like you mention. Dan From mmabis at vmware.com Tue Feb 11 19:46:01 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Tue, 11 Feb 2014 11:46:01 -0800 (PST) Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e In-Reply-To: References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> <1443312846.4351885.1392139149497.JavaMail.root@vmware.com> <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com> <631092638.4391426.1392147453266.JavaMail.root@vmware.com> Message-ID: <434682277.4398481.1392147961082.JavaMail.root@vmware.com> Running Mem-Test on it now to check if its memory issue I will update with results when i have them.. Matt ----- Original Message ----- From: "Dan McDonald" To: "Matthew Mabis" Cc: "Ben Summers" , "omnios-discuss" Sent: Tuesday, February 11, 2014 11:38:52 AM Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e On Feb 11, 2014, at 2:37 PM, Matthew Mabis wrote: > First time crash, system was up for ~48 hours and it crashed like this... > > Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... > > Any way i can get to the dump files now? If it's in a crash-on-boot cycle, likely not. Have you tried booting an install CD or USB stick? If it ALSO crashes, it's highly likely a HW problem, like you mention. Dan From mmabis at vmware.com Tue Feb 11 22:54:29 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Tue, 11 Feb 2014 14:54:29 -0800 (PST) Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e In-Reply-To: <434682277.4398481.1392147961082.JavaMail.root@vmware.com> References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk> <1443312846.4351885.1392139149497.JavaMail.root@vmware.com> <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com> <631092638.4391426.1392147453266.JavaMail.root@vmware.com> <434682277.4398481.1392147961082.JavaMail.root@vmware.com> Message-ID: <390608997.4478107.1392159269331.JavaMail.root@vmware.com> Did a full Pass via memory no issues, now the system is booting.... I have captured the fmdump info and currently am extracting the dump file.. here is the fmdump info, if you want me to send you the dump file please let me know where.. Matt ----- Original Message ----- From: "Matthew Mabis" To: "Dan McDonald" Cc: "omnios-discuss" Sent: Tuesday, February 11, 2014 11:46:01 AM Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e Running Mem-Test on it now to check if its memory issue I will update with results when i have them.. Matt ----- Original Message ----- From: "Dan McDonald" To: "Matthew Mabis" Cc: "Ben Summers" , "omnios-discuss" Sent: Tuesday, February 11, 2014 11:38:52 AM Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e On Feb 11, 2014, at 2:37 PM, Matthew Mabis wrote: > First time crash, system was up for ~48 hours and it crashed like this... > > Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... > > Any way i can get to the dump files now? If it's in a crash-on-boot cycle, likely not. Have you tried booting an install CD or USB stick? If it ALSO crashes, it's highly likely a HW problem, like you mention. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com https://urldefense.proofpoint.com/v1/url?u=http://lists.omniti.com/mailman/listinfo/omnios-discuss&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yqgQ6LhGnfWMd79QvLrmWsnr%2FlpWj5c0oy4MpT8%2Bgik%3D%0A&m=qPhUb5pnPZEs8lTPOtg9k3Tm3gT3xSdxwof9nozrO2Q%3D%0A&s=504976f584b541bb03faffff433091182ddbdfa2d92d3a0e5f013debb9d8682e -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-11 at 2.52.38 PM.png Type: image/png Size: 80336 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-11 at 2.52.32 PM.png Type: image/png Size: 74760 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-02-11 at 2.52.27 PM.png Type: image/png Size: 71730 bytes Desc: not available URL: From moo at wuffers.net Wed Feb 12 15:31:17 2014 From: moo at wuffers.net (wuffers) Date: Wed, 12 Feb 2014 10:31:17 -0500 Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output discrepancy? Message-ID: So I only upgraded to r151008 recently, and was wondering whether the new L2ARC compression was working. After getting an updated arcstat script which added the l2asize option (which returned a 0), and a few rounds in IRC which lead me to the correct kstat (zfs:0:arcstats:l2_asize), and an even more updated arcstat to fix the 0 result.. Now both kstat and arcstat are outputting the same info: zfs:0:arcstats:l2_asize 864682956800 zfs:0:arcstats:l2_size 1374605708288 arcstat: read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size l2asize 2.7K 2.6K 53 98 53 44 9 83 229G 1.3T 806G 5.1K 4.8K 282 94 282 17 265 6 229G 1.3T 806G 7.3K 7.3K 10 99 10 4 6 40 229G 1.3T 806G ... But.. why is zpool iostat -v showing me my cache devices using up ~1.25T (314Gx4), which is close to the 1.3T l2size? capacity operations bandwidth pool alloc free read write read write ------------------------- ----- ----- ----- ----- ----- ----- [snip] cache - - - - - - c2t500117310015D579d0 313G 59.4G 19 15 711K 833K c2t50011731001631FDd0 314G 58.1G 18 15 712K 836K c12t500117310015D59Ed0 314G 58.8G 19 15 710K 835K c12t500117310015D54Ed0 313G 59.7G 18 15 709K 832K ------------------------- ----- ----- ----- ----- ----- ----- What's with the discrepancy? Is zpool iostat calculating the free capacity incorrectly now (my cache drives are 400GB)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From skiselkov.ml at gmail.com Wed Feb 12 15:44:22 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Wed, 12 Feb 2014 15:44:22 +0000 Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output discrepancy? In-Reply-To: References: Message-ID: <52FB96D6.3000206@gmail.com> On 2/12/14, 3:31 PM, wuffers wrote: > So I only upgraded to r151008 recently, and was wondering whether the > new L2ARC compression was working. After getting an updated arcstat > script which added the l2asize option (which returned a 0), and a few > rounds in IRC which lead me to the correct kstat > (zfs:0:arcstats:l2_asize), and an even more updated arcstat to fix the 0 > result.. > > Now both kstat and arcstat are outputting the same info: > zfs:0:arcstats:l2_asize 864682956800 > zfs:0:arcstats:l2_size 1374605708288 > > arcstat: > read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size > l2asize > 2.7K 2.6K 53 98 53 44 9 83 229G > 1.3T 806G > 5.1K 4.8K 282 94 282 17 265 6 229G > 1.3T 806G > 7.3K 7.3K 10 99 10 4 6 40 229G > 1.3T 806G > ... > > But.. why is zpool iostat -v showing me my cache devices using up ~1.25T > (314Gx4), which is close to the 1.3T l2size? > > capacity operations bandwidth > pool alloc free read write read write > ------------------------- ----- ----- ----- ----- ----- ----- > [snip] > > cache - - - - - - > c2t500117310015D579d0 313G 59.4G 19 15 711K 833K > c2t50011731001631FDd0 314G 58.1G 18 15 712K 836K > c12t500117310015D59Ed0 314G 58.8G 19 15 710K 835K > c12t500117310015D54Ed0 313G 59.7G 18 15 709K 832K > ------------------------- ----- ----- ----- ----- ----- ----- > > What's with the discrepancy? Is zpool iostat calculating the free > capacity incorrectly now (my cache drives are 400GB)? What's the block size of your SSDs and the average recordsize of the data on them? -- Saso From skiselkov.ml at gmail.com Wed Feb 12 15:55:53 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Wed, 12 Feb 2014 15:55:53 +0000 Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output discrepancy? In-Reply-To: References: Message-ID: <52FB9989.3090600@gmail.com> On 2/12/14, 3:31 PM, wuffers wrote: > So I only upgraded to r151008 recently, and was wondering whether the > new L2ARC compression was working. After getting an updated arcstat > script which added the l2asize option (which returned a 0), and a few > rounds in IRC which lead me to the correct kstat > (zfs:0:arcstats:l2_asize), and an even more updated arcstat to fix the 0 > result.. > > Now both kstat and arcstat are outputting the same info: > zfs:0:arcstats:l2_asize 864682956800 > zfs:0:arcstats:l2_size 1374605708288 > > arcstat: > read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size > l2asize > 2.7K 2.6K 53 98 53 44 9 83 229G > 1.3T 806G > 5.1K 4.8K 282 94 282 17 265 6 229G > 1.3T 806G > 7.3K 7.3K 10 99 10 4 6 40 229G > 1.3T 806G > ... > > But.. why is zpool iostat -v showing me my cache devices using up ~1.25T > (314Gx4), which is close to the 1.3T l2size? > > capacity operations bandwidth > pool alloc free read write read write > ------------------------- ----- ----- ----- ----- ----- ----- > [snip] > > cache - - - - - - > c2t500117310015D579d0 313G 59.4G 19 15 711K 833K > c2t50011731001631FDd0 314G 58.1G 18 15 712K 836K > c12t500117310015D59Ed0 314G 58.8G 19 15 710K 835K > c12t500117310015D54Ed0 313G 59.7G 18 15 709K 832K > ------------------------- ----- ----- ----- ----- ----- ----- > > What's with the discrepancy? Is zpool iostat calculating the free > capacity incorrectly now (my cache drives are 400GB)? Can you also try running this piece of dtrace on the machine? I have a hypothesis that I'd like to test: dtrace -n 'fbt::l2arc_evict:entry{printf("dev=%p; l2ad_first=%d", args[0], args[0]->l2ad_first)}' (let it run for about 5-10s and post the output) -- Saso From moo at wuffers.net Wed Feb 12 18:11:21 2014 From: moo at wuffers.net (wuffers) Date: Wed, 12 Feb 2014 13:11:21 -0500 Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output discrepancy? In-Reply-To: <52FB9989.3090600@gmail.com> References: <52FB9989.3090600@gmail.com> Message-ID: On Wed, Feb 12, 2014 at 10:55 AM, Saso Kiselkov wrote: Can you also try running this piece of dtrace on the machine? I have a > hypothesis that I'd like to test: > > dtrace -n 'fbt::l2arc_evict:entry{printf("dev=%p; l2ad_first=%d", > args[0], args[0]->l2ad_first)}' > > (let it run for about 5-10s and post the output) > Output from the above dtrace: dtrace: description 'fbt::l2arc_evict:entry' matched 1 probe CPU ID FUNCTION:NAME 12 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 12 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 12 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 14 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 0 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 5 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 5 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 1 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 19 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 21 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 23 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 0 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 11 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 13 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 14 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 15 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 19 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 1 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 3 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 3 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 3 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 3 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 16 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 3 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 13 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 3 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 0 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 21 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 2 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 18 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 1 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 1 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 1 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 2 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 2 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 2 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 20 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 0 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 0 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 0 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 1 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 2 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 0 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 8 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 1 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 4 40955 l2arc_evict:entry dev=ffffff4377e25058; l2ad_first=1 14 40955 l2arc_evict:entry dev=ffffff4377e25148; l2ad_first=1 12 40955 l2arc_evict:entry dev=ffffff432153be68; l2ad_first=1 21 40955 l2arc_evict:entry dev=ffffff43782a8240; l2ad_first=1 And on your other question: > What's the block size of your SSDs and the average recordsize of the > data on them? I'm actually not sure what you're asking about.. the recordsize on the pool itself? It's 128K. I have different volblocksize on various volumes. Or information about the SSD itself? * /dev/rdsk/c2t500117310015D579d0 partition map * * Dimensions: * 512 bytes/sector * 781422768 sectors * 781422701 accessible sectors * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 34 222 255 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 4 00 256 781406095 781406350 8 11 00 781406351 16384 781422734 -------------- next part -------------- An HTML attachment was scrubbed... URL: From skiselkov.ml at gmail.com Wed Feb 12 18:33:07 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Wed, 12 Feb 2014 18:33:07 +0000 Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output discrepancy? In-Reply-To: References: <52FB9989.3090600@gmail.com> Message-ID: <52FBBE63.4090405@gmail.com> Okay, I think I have a convincing analysis for this: TL;DR Sadly, the zpool vdev space stats are less than useless for L2ARC here and they're confusing you. L2ARC devices are rotors, so they start writing at low offsets and progress higher until they wrap around. What your vdev space stats (zpool iostat -v) show is really the difference between the maximum and the minimum buffer offsets. It doesn't actually say how much of the space in between is occupied by usable buffers. l2asize, however, does. The reason why I asked for the l2ad_first measurement is because I wanted to understand why your space usage was showing ~59GB of free space on each device - it's because your L2ARC devices have not yet even completed a single run through the rotor. If it had completed the first, it would have indicated a serious flaw in the wrap-around logic. So this is currently the situation: write hand--------, L2ARC device \ +------------------------------------------------V---------------------+ | |lowest| ...... buffers & gaps ..... |highest| (nothing here yet) | +----------------------------------------------------------------------+ | "allocated" | "free" | |<----------------- 313G -------------------->|<------ 59G ------->| The gaps in between the "lowest" and "highest" L2ARC buffers get created when the buffers previously written there are evicted from L2ARC for whatever reason (e.g. the filesystem holding them is destroyed, or they are written to in ARC, invalidating the contents cached in L2ARC). Unfortunately, the "allocated" vdev space stat is not altered when this happens, so your L2ARC could really just hold two buffers and still appear as full in the vdev stats. The reason why l2asize is different is because it *does* take eviction into account. So as the vdev space allocated metric was growing due to the write hand moving to the right, the actual amount of data stored in the L2ARC didn't grow nearly as quickly since buffers that had previously been written had to be evicted. As for why the (uncompressed) l2size is roughly equal to vdev space allocated, I'd say it's due to a rounding error in the reporting tools and some luck. The numbers don't actually even add up to the same result: l2size: 1374605708288 bytes / 2^30 = 1280 GB vdev space: 313 + 314 + 314 + 313 = 1254 GB As for general ZFS design, I think we should either fix the vdev space stats on L2ARC devices so that they precisely correspond to l2asize, or get rid of them altogether. Right now, the discrepancy there just confuses people. Hope this helps. Cheers, -- Saso From moo at wuffers.net Wed Feb 12 19:19:23 2014 From: moo at wuffers.net (wuffers) Date: Wed, 12 Feb 2014 14:19:23 -0500 Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output discrepancy? In-Reply-To: <52FBBE63.4090405@gmail.com> References: <52FB9989.3090600@gmail.com> <52FBBE63.4090405@gmail.com> Message-ID: Wow, thanks for the insightful explanation (and brilliant ASCII diagram). You're right in that my L2ARC hasn't had time to fill up yet, as my system uptime is creeping up to 5 days since the upgrade. Will be nice when the persistent L2ARC feature finally makes it in so that it doesn't take that long to rebuild. As for general ZFS design, I think we should either fix the vdev space > stats on L2ARC devices so that they precisely correspond to l2asize, or > get rid of them altogether. Right now, the discrepancy there just > confuses people. > Consider my curiosity sated (and confusion resolved), but I was glad I was able to help raise this point. I'll just ignore the, as you call them, "vdev space stats" for now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thibault.vincent at smartjog.com Thu Feb 13 10:18:58 2014 From: thibault.vincent at smartjog.com (Thibault VINCENT) Date: Thu, 13 Feb 2014 11:18:58 +0100 Subject: [OmniOS-discuss] Overheating faults with ST4000NM0023 In-Reply-To: <6B4199959CFA4E1CB067BBF9270654CB@486dx4> References: <6B4199959CFA4E1CB067BBF9270654CB@486dx4> Message-ID: <52FC9C12.9090900@smartjog.com> On 02/12/2014 09:59 PM, Steamer wrote: > Did you ever find a solution to the overheating faults with the > ST4000NM0023? > > I'm currently having the exact same issue with ST1000NM0023 drives, > seems like seagate has the user temp probe set at 40'C. The manual > states that the temperature settings are programmable via smart, but I > haven't found a way to do that. Hello Emile, I've found a workaround but the definitive fix should be handled by Illumos I guess. There is no open ticket, first I was waiting for something to happen with #4051 before going back to using that distro and kernel. Here's the story: The SCSI specification defines two registers to store the temperature thresholds in SMART data. One contains the recommended maximum operation temperature for best MTBF, and the other register is for the absolute maximum rating. Usually the industry has always put the same value in both, and that is the absolute maximum. That's why we always see something like 60/65?C from SMART. But recently Seagate has changed that because it was asked by a large OS company to comply with the specification for better hardware monitoring integration. The change did not only occur in newer products but in a firmware update for existing disks and that was applied to the production line which explains some disks mays or may not expose this problem although they are the same model. Our disks are of the Megalodon serie and all share the same firmware basecode. So any Seagate disk will now trigger faults in FMA if they have a firmware with the newer policy. Also I think other brands will follow the same path. Like other members suggested in that thread, maybe nothing should change in FMA but let's face it, you can't maintain a temperature steadily under 40?C in a JBOD of hundreds of busy disks. Especially in eco-friendly datacenters. IMHO we should not trigger a fault on the lower threshold, and certainly not a drive retirement. It breaks storage servers on reboot or before a pool import, also spare disks could disappear with the retirement triggered. The workaround is to downgrade firmware to the last version before the change, and to reset the register with an SCSI command. It is not possible to set the register to a user specified value like the documentation suggests, they confirmed it. I'm sending a working firmware to you in a private mail. I'm not aware of any issue working with that older version and hopefully it should upload to 1TB drives as well. I'm applying it like this but from Linux not OmniOS: # ./dl_sea_fw-0.2.3_32 -f Megalodon_StdOEM_SAS_0002+C84C.lod -m ST4000NM0023 # ./dl_sea_fw-0.2.3_32 -i Then you should reset the drives so they reload the firmware. Here's our example for 4TB drives: ------------- for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do sg_reset -d $i done ------------- And reset the register that contains value from the previous firmware. It doesn't work well so we've got this script to run a few times until all disks got it. Again it matches 4TB Megalodon. ------------- for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do echo -n "$i " if sg_logs $i --page=0x0d | grep 'Reference temperature = 68 C' >/dev/null ; then echo 'ok' else sg_logs $i --page=0x0d --reset echo 'reset' fi done ------------- Cheers -- Thibault VINCENT - Lead System Engineer, Infrastructure - Arkena | Phone: +33 1 58 68 62 38 | Mobile: +33 6 78 97 01 08 27 Blvd Hippolyte Marqu?s, 94200 Ivry-sur-Seine, France | www.arkena.com Arkena - Ready to Play From dswartz at druber.com Fri Feb 14 16:29:43 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Fri, 14 Feb 2014 11:29:43 -0500 Subject: [OmniOS-discuss] Disappearing drives? Message-ID: I've been running an install on r151008. rpool mirrored on two WD black 160GB sata drives. 8 SAS nearline drives in a raid10. Two samsung 840PRO 128GB drives as l2arc. The sas and l2arc drives are on an LSI HBA, and the rpool on motherboard sata ports. Twice now, I've had drives disappear - the first time was one of the rpool drives, and yesterday one of the l2arc drives. The symptom is that zpool status shows thousands of read/write errors and the drive is offlined. If I run the format command, it shows that drive as 'unknown drive type'. I apologize for not getting more specific data - the first time, I wrote off as an anomaly, but yesterday I really should have cut&pasted anything relevant. Anyway, I'm puzzled that there seems no common hardware or driver factor. The rpool drives are sata, and are using the sata-phy driver (I think that's what I dug out of prtconf -v), whereas, although the l2arc drives are sata, since they are on the lsi hba, they are using the sas-mpt driver. I wasn't that concerned about yesterday's incident, since l2arc drives could both die suddenly and not take things down, but having rpool go bye-bye is not good - this is why I was paranoid and mirrored it. Any ideas? If this happens again, what should I look for? From natxo.asenjo at gmail.com Sat Feb 15 09:09:53 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 15 Feb 2014 10:09:53 +0100 Subject: [OmniOS-discuss] apache22 from ms.omniti.com Message-ID: hi, maybe handy for anyone trying to get this package operational. Obviosly, you need to add the publisher ms.omniti.com first. Then add the packge. After which, import the xml service schema in /opt/apache22/conf/: svccfg import /opt/apache22/conf/http-apache.xml After wich, you can enable/disable the service. Configure /opt/apache22/conf/httpd.conf to your needs. If after editing httpd.conf and verifying its syntax with /opt/apache22/bin/httpd -t the syntax is ok and apache2 does not start with the unhelpful error Feb 14 21:46:21 Executing start method ("/opt/apache22/bin/httpd -f /opt/apache22/conf/httpd.conf -k start"). ] [ Feb 14 21:46:21 Method "start" exited with status 1. ] adding the hostnanme to the hosts file fixed it for me -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Sat Feb 15 18:54:15 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 15 Feb 2014 19:54:15 +0100 Subject: [OmniOS-discuss] software compilation errors Message-ID: hi, When trying to compile some Perl modules using cpanm I get errors. My google fu is not being helpful, maybe you could point me in the right direction. This is the compiler I have in a zone: root at zone2:~# pkg list | grep gcc developer/gcc48 4.8.1-0.151008 i-- developer/gcc48/libgmp-gcc48 5.0.5-0.151008 i-- developer/gcc48/libmpc-gcc48 1.0.1-0.151008 i-- developer/gcc48/libmpfr-gcc48 3.1.1-0.151008 i-- system/library/gcc-4-runtime When trying to install Text::Markdown::Discount I get this error: cpanm (App::cpanminus) 1.7001 on perl 5.016001 built for i86pc-solaris-thread-multi-64int Work directory is /root/.cpanm/work/1392489889.18009 You have make /usr/bin/make You have /usr/bin/wget You have /usr/bin/tar, /usr/bin/gzip and /usr/bin/bzip2 You have /usr/bin/unzip Searching Text::Markdown::Discount on cpanmetadb ... --> Working on Text::Markdown::Discount Fetching http://www.cpan.org/authors/id/S/SE/SEKIMURA/Text-Markdown-Discount-0.11.tar.gz -> OK Unpacking Text-Markdown-Discount-0.11.tar.gz Entering Text-Markdown-Discount-0.11 Checking configure dependencies from META.yml Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.63_02) Configuring Text-Markdown-Discount-0.11 Running Makefile.PL Checking if your kit is complete... Looks good Warning: -Ldiscount changed to -L/root/.cpanm/work/1392489889.18009/Text-Markdown-Discount-0.11/discount Writing Makefile for Text::Markdown::Discount Writing MYMETA.yml and MYMETA.json -> OK Checking dependencies from MYMETA.json ... Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.63_02) Building and testing Text-Markdown-Discount-0.11 cp lib/Text/Markdown/Discount.pm blib/lib/Text/Markdown/Discount.pm ( cd discount; CC='cc -fPIC' sh configure.sh; make ) Configuring for [markdown] Looking for cpp (/opt/gcc-4.8.1/bin/cpp) ok looking for install (/usr/gnu/bin/install) checking the C compiler (cc -fPIC) does not compile code properly *** Error code 1 make: Fatal error: Command failed for target `discount/libmarkdown.a' -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at multitalents.net Sat Feb 15 19:55:09 2014 From: tim at multitalents.net (Tim Rice) Date: Sat, 15 Feb 2014 11:55:09 -0800 (PST) Subject: [OmniOS-discuss] software compilation errors In-Reply-To: References: Message-ID: On Sat, 15 Feb 2014, Natxo Asenjo wrote: > checking the C compiler (cc -fPIC) does not compile code properly > *** Error code 1 > make: Fatal error: Command failed for target `discount/libmarkdown.a' Can you compile anything on that system? Is pkg://omnios/system/header installed? -- Tim Rice Multitalents tim at multitalents.net From natxo.asenjo at gmail.com Sat Feb 15 21:32:53 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 15 Feb 2014 22:32:53 +0100 Subject: [OmniOS-discuss] software compilation errors In-Reply-To: References: Message-ID: -- Groeten, natxo On Sat, Feb 15, 2014 at 8:55 PM, Tim Rice wrote: > On Sat, 15 Feb 2014, Natxo Asenjo wrote: > > > checking the C compiler (cc -fPIC) does not compile code properly > > *** Error code 1 > > make: Fatal error: Command failed for target `discount/libmarkdown.a' > > Can you compile anything on that system? > > Is pkg://omnios/system/header installed? > > yes: # pkg info system/header Name: system/header Summary: SunOS Header Files Description: SunOS C/C++ header files for general development of software Category: System/Core State: Installed Publisher: omnios Version: 0.5.11 Build Release: 5.11 Branch: 0.151008 Packaging Date: Wed Dec 4 02:47:08 2013 Size: 12.19 MB FMRI: pkg://omnios/system/header at 0.5.11 ,5.11-0.151008:20131204T024708Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at multitalents.net Sat Feb 15 22:51:48 2014 From: tim at multitalents.net (Tim Rice) Date: Sat, 15 Feb 2014 14:51:48 -0800 (PST) Subject: [OmniOS-discuss] software compilation errors In-Reply-To: References: Message-ID: On Sat, 15 Feb 2014, Natxo Asenjo wrote: | -- | Groeten, | natxo | | | On Sat, Feb 15, 2014 at 8:55 PM, Tim Rice wrote: | | > On Sat, 15 Feb 2014, Natxo Asenjo wrote: | > | > > checking the C compiler (cc -fPIC) does not compile code properly ^^^^^^^^ I should have caught this last time. The OmniOS gcc packages do not provide a cc only gcc. Unless you have the sun compilers installed, there is no cc. Even if they were installed, "cc -fPIC" is not valid for sun compilers. It would need to be "cc -Kpic". You'll need to patch the perl module and build manually. A possible workaround would be to (cd /opt/gcc/bin ; ln -s gcc cc) | > > *** Error code 1 | > > make: Fatal error: Command failed for target `discount/libmarkdown.a' | > | > Can you compile anything on that system? | > | > Is pkg://omnios/system/header installed? | > | > yes: | | # pkg info system/header | Name: system/header [snip] -- Tim Rice Multitalents tim at multitalents.net From rmarc at copacetic.net Sun Feb 16 03:57:06 2014 From: rmarc at copacetic.net (Marc Phillips) Date: Sat, 15 Feb 2014 21:57:06 -0600 Subject: [OmniOS-discuss] New to OmniOS (hopefully easy question) Message-ID: <20140216035706.GA30682@copacetic.net> I'm trying to get going use OmniOS but can't seem to get paste a basic hurdle. I installed LTS (I've not tried stable), I then used pkg to install developer/gcc48 (I also tried gcc47) My goal is to compile and create packages for the services I require. The first item I'm trying to compile is x11vnc. When I do a ./configure I get: checking how to run the C preprocessor... /lib/cpp configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. I'm sure I'm glossing over something simple, but I'm at an impass. Guidance would be appreciated. R. Marc From ben at fluffy.co.uk Sun Feb 16 07:26:39 2014 From: ben at fluffy.co.uk (Ben Summers) Date: Sun, 16 Feb 2014 07:26:39 +0000 Subject: [OmniOS-discuss] New to OmniOS (hopefully easy question) In-Reply-To: <20140216035706.GA30682@copacetic.net> References: <20140216035706.GA30682@copacetic.net> Message-ID: <491902031.113312.1392535602487@08350ac283874659a4c1a48e1ff998c5.nuevasync.com> Have you installed the system/headers package? What does config.log say? Ben > On 16 Feb 2014, at 03:59, "Marc Phillips" wrote: > > > I'm trying to get going use OmniOS but can't seem to get paste a basic hurdle. > > I installed LTS (I've not tried stable), I then used pkg to install developer/gcc48 (I also tried gcc47) > My goal is to compile and create packages for the services I require. > > The first item I'm trying to compile is x11vnc. When I do a ./configure I get: > > checking how to run the C preprocessor... /lib/cpp > configure: error: C preprocessor "/lib/cpp" fails sanity check > See `config.log' for more details. > > I'm sure I'm glossing over something simple, but I'm at an impass. > Guidance would be appreciated. > > R. Marc > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From natxo.asenjo at gmail.com Sun Feb 16 07:56:09 2014 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sun, 16 Feb 2014 08:56:09 +0100 Subject: [OmniOS-discuss] software compilation errors In-Reply-To: References: Message-ID: On Sat, Feb 15, 2014 at 11:51 PM, Tim Rice wrote: > | > On Sat, 15 Feb 2014, Natxo Asenjo wrote: > | > > | > > checking the C compiler (cc -fPIC) does not compile code properly > ^^^^^^^^ > I should have caught this last time. The OmniOS gcc packages do not > provide a cc only gcc. Unless you have the sun compilers installed, > there is no cc. Even if they were installed, "cc -fPIC" is not valid > for sun compilers. It would need to be "cc -Kpic". > You'll need to patch the perl module and build manually. > Yes! I installed developer/sunstudio12.1, modified Makefile.PL with your suggestion, installed pkg:/developer/object-file (needed for ar), used gmake instead of make and finally got it to work. Thanks so much for your tip! -- groet, Natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.stanczak at gmail.com Sun Feb 16 10:35:58 2014 From: mariusz.stanczak at gmail.com (Mariusz Stanczak) Date: Sun, 16 Feb 2014 02:35:58 -0800 Subject: [OmniOS-discuss] SUNW* libraries Message-ID: <20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com> Hello All, I'm trying to install Nvidia drivers, and I found instructions [https://community.oracle.com/thread/2487788] for creating a boot environment, but when trying to add the driver package I get the following errors: ---- root at Omni:~/NVIDIA-Solaris-x86-334.16# pkgadd -R /mnt -d . NVDAgraphics NVDAgraphicsr Processing package instance from NVIDIA Graphics System Software(i386) 334.16,REV=2014.02.04.15.20 Copyright 2005-2009 by NVIDIA Corporation. All rights reserved. Use is subject to license terms. This appears to be an attempt to install the same architecture and version of a package which is already installed. This installation will attempt to overwrite this package. Using as the package base directory. ## Processing package information. ## Processing system information. 189 package pathnames are already properly installed. ## Verifying package dependencies. WARNING: The package "Math & Microtasking Libraries (Root)" is a prerequisite package and should be installed. WARNING: The package "X Window System & Graphics Runtime Library Links in /usr/lib" is a prerequisite package and should be installed. WARNING: The package "X Window System platform software" is a prerequisite package and should be installed. WARNING: The package "GNOME base GUI libraries" is a prerequisite package and should be installed. WARNING: The package "GCC Runtime libraries" is a prerequisite package and should be installed. WARNING: The package "X.Org Foundation X Client Libraries" is a prerequisite package and should be installed. Do you want to continue with the installation of [y,n,?] n ---- Here the force (Google ;) has failed me, except for clues that things may not be what they seem to. So, what's the story with those libs. Thank you, /Mariusz From jdg117 at elvis.arl.psu.edu Sun Feb 16 17:33:03 2014 From: jdg117 at elvis.arl.psu.edu (John D Groenveld) Date: Sun, 16 Feb 2014 12:33:03 -0500 Subject: [OmniOS-discuss] SUNW* libraries In-Reply-To: Your message of "Sun, 16 Feb 2014 02:35:58 PST." <20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com> References: <20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com> Message-ID: <201402161733.s1GHX35H011496@elvis.arl.psu.edu> In message <20140216023558.b34940c1f29e5a71f49d4cdd at gmail.com>, Mariusz Stancza k writes: >be what they seem to. So, what's the story with those libs. The libraries are not supported by OmniTI. However, /kernel/drv/amd64/nvidia from NVDAgraphicsr package is not dependent on them. John groenveld at acm.org From derek at umiacs.umd.edu Mon Feb 17 22:48:58 2014 From: derek at umiacs.umd.edu (Derek Yarnell) Date: Mon, 17 Feb 2014 17:48:58 -0500 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL Message-ID: <530291DA.6050009@umiacs.umd.edu> Hi, So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped as a Pliant-LB206S-D323-186.31GB via format. The bulk of the storage is just a 6+2 RaidZ2 with 3TB disks. When doing a simple untar (40MB/2000 files) over NFS (synchronous IO) having the mirrored slog of Pliant SSDs seems to offer horrendous performance. On the order of 18-20 OPs per second (via zpool iostat -v 1). We have a number of other ZFS builds with ZeusRAM slogs and they work very well and while the Pliant may not be as good a choice it shouldn't be as bad as this. # zfs get sync,dedup,logbias,compression,checksum zpool0 NAME PROPERTY VALUE SOURCE zpool0 sync standard default zpool0 dedup off default zpool0 logbias latency default zpool0 compression off default zpool0 checksum on default Adding a ramdisk slog device makes everything perform as expected. Setting sync=disabled of course makes things all better. # zpool status zpool0 pool: zpool0 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zpool0 ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 c1t5000C50057EC4B73d0 ONLINE 0 0 0 c1t5000C50057EC6EABd0 ONLINE 0 0 0 c1t5000C50057EC7CB7d0 ONLINE 0 0 0 c1t5000C50057EC8F23d0 ONLINE 0 0 0 c1t5000C50057EC998Bd0 ONLINE 0 0 0 c1t5000C50057ECB1BBd0 ONLINE 0 0 0 c1t5000C50057ECFEE7d0 ONLINE 0 0 0 c1t5000C50057ED03F7d0 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 c3t5001E820026DA2CAd0 ONLINE 0 0 0 c3t5001E820026DA45Ad0 ONLINE 0 0 0 errors: No known data errors -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies From mir at miras.org Mon Feb 17 23:06:57 2014 From: mir at miras.org (Michael Rasmussen) Date: Tue, 18 Feb 2014 00:06:57 +0100 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <530291DA.6050009@umiacs.umd.edu> References: <530291DA.6050009@umiacs.umd.edu> Message-ID: <20140218000657.020f86f3@sleipner.datanom.net> On Mon, 17 Feb 2014 17:48:58 -0500 Derek Yarnell wrote: > Adding a ramdisk slog device makes everything perform as expected. > Setting sync=disabled of course makes things all better. > To the best of my knowledge using sync=disabled means no data hitting your log. sync=standard means respect request for synchronous writes while sync=always means make all write synchronous. Only synchronous writes will ever hit the log. -- 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: Q: What's the difference between Bell Labs and the Boy Scouts of America? A: The Boy Scouts have adult supervision. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From richard.elling at richardelling.com Tue Feb 18 00:31:42 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 17 Feb 2014 16:31:42 -0800 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <530291DA.6050009@umiacs.umd.edu> References: <530291DA.6050009@umiacs.umd.edu> Message-ID: On Feb 17, 2014, at 2:48 PM, Derek Yarnell wrote: > Hi, > > So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped > as a Pliant-LB206S-D323-186.31GB via format. Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for lots of concurrent I/O operations. This is not the kind of workload generated by the ZIL, which is more contiguous, single thread-like. > The bulk of the storage is > just a 6+2 RaidZ2 with 3TB disks. When doing a simple untar (40MB/2000 > files) over NFS (synchronous IO) having the mirrored slog of Pliant SSDs > seems to offer horrendous performance. On the order of 18-20 OPs per > second (via zpool iostat -v 1). Never ever use zpool iostat to measure application performance. zpool iostat measures workload to the vdevs, showing back-end operations to disk. As such there is no correlation to client-side operations of any sort, especially writes and metadata updates. You'll need to go up the stack and see what it is doing. For NFS I highly recommend nfssvrtop. To see the response time of the Pliant, use "iostat -x" or, as I prefer, "iostat -zxCn" Note: response time (measured by iostat -x as a variant of "svc_t") is the critical measurement for NFS workloads. Bandwidth is almost meaningless in analyzing NFS. > We have a number of other ZFS builds > with ZeusRAM slogs and they work very well and while the Pliant may not > be as good a choice it shouldn't be as bad as this. It can be as bad as that. > # zfs get sync,dedup,logbias,compression,checksum zpool0 > NAME PROPERTY VALUE SOURCE > zpool0 sync standard default > zpool0 dedup off default > zpool0 logbias latency default > zpool0 compression off default > zpool0 checksum on default > > Adding a ramdisk slog device makes everything perform as expected. yep. A ZeusRAM will also help. -- richard > Setting sync=disabled of course makes things all better. > > # zpool status zpool0 > pool: zpool0 > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > zpool0 ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > c1t5000C50057EC4B73d0 ONLINE 0 0 0 > c1t5000C50057EC6EABd0 ONLINE 0 0 0 > c1t5000C50057EC7CB7d0 ONLINE 0 0 0 > c1t5000C50057EC8F23d0 ONLINE 0 0 0 > c1t5000C50057EC998Bd0 ONLINE 0 0 0 > c1t5000C50057ECB1BBd0 ONLINE 0 0 0 > c1t5000C50057ECFEE7d0 ONLINE 0 0 0 > c1t5000C50057ED03F7d0 ONLINE 0 0 0 > logs > mirror-1 ONLINE 0 0 0 > c3t5001E820026DA2CAd0 ONLINE 0 0 0 > c3t5001E820026DA45Ad0 ONLINE 0 0 0 > > errors: No known data errors > > > -- > Derek T. Yarnell > University of Maryland > Institute for Advanced Computer Studies > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at umiacs.umd.edu Tue Feb 18 01:48:55 2014 From: derek at umiacs.umd.edu (Derek Yarnell) Date: Mon, 17 Feb 2014 20:48:55 -0500 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: References: <530291DA.6050009@umiacs.umd.edu> Message-ID: <5302BC07.9070304@umiacs.umd.edu> On 2/17/14, 7:31 PM, Richard Elling wrote: > On Feb 17, 2014, at 2:48 PM, Derek Yarnell wrote: > >> Hi, >> >> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped >> as a Pliant-LB206S-D323-186.31GB via format. > > Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for > lots of concurrent I/O operations. This is not the kind of workload generated by > the ZIL, which is more contiguous, single thread-like. I realize that they may not be as good as Stec/HGST ZeusRAM drives for the slog. I still can't wrap my head around that it is as bad as having no discrete slog. > > Never ever use zpool iostat to measure application performance. zpool iostat > measures workload to the vdevs, showing back-end operations to disk. As such > there is no correlation to client-side operations of any sort, especially writes and > metadata updates. You'll need to go up the stack and see what it is doing. For NFS > I highly recommend nfssvrtop. To see the response time of the Pliant, use "iostat -x" > or, as I prefer, "iostat -zxCn" Yes I realize that iostat will show me this information and the svc_t for the Pliant ssd(s) is anywhere from 2-7ms. But zpool iostat will show you your ZIL writes accurately no? I realize that it will then coalesce these into its transactions and write it out at the 5sec interval. > > Note: response time (measured by iostat -x as a variant of "svc_t") is the critical > measurement for NFS workloads. Bandwidth is almost meaningless in analyzing > NFS. Yes and I have done this too. The average RTT on untaring is 43.000 ms. I guess we will just be getting another set of ZeusRAM drives. Thanks, derek -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies From richard.elling at richardelling.com Tue Feb 18 07:05:23 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 17 Feb 2014 23:05:23 -0800 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <5302BC07.9070304@umiacs.umd.edu> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> Message-ID: <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> On Feb 17, 2014, at 5:48 PM, Derek Yarnell wrote: > On 2/17/14, 7:31 PM, Richard Elling wrote: >> On Feb 17, 2014, at 2:48 PM, Derek Yarnell wrote: >> >>> Hi, >>> >>> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped >>> as a Pliant-LB206S-D323-186.31GB via format. >> >> Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for >> lots of concurrent I/O operations. This is not the kind of workload generated by >> the ZIL, which is more contiguous, single thread-like. > > I realize that they may not be as good as Stec/HGST ZeusRAM drives for > the slog. They are not. By your measurements, the ZeusRAM is 2 orders of magnitude faster. > I still can't wrap my head around that it is as bad as having > no discrete slog. > >> >> Never ever use zpool iostat to measure application performance. zpool iostat >> measures workload to the vdevs, showing back-end operations to disk. As such >> there is no correlation to client-side operations of any sort, especially writes and >> metadata updates. You'll need to go up the stack and see what it is doing. For NFS >> I highly recommend nfssvrtop. To see the response time of the Pliant, use "iostat -x" >> or, as I prefer, "iostat -zxCn" > > Yes I realize that iostat will show me this information and the svc_t > for the Pliant ssd(s) is anywhere from 2-7ms. But zpool iostat will > show you your ZIL writes accurately no? zpool iostat does not show latency (svc_t) except for a very limited few, distros. For NFS, latency matters. > I realize that it will then > coalesce these into its transactions and write it out at the 5sec interval. > >> >> Note: response time (measured by iostat -x as a variant of "svc_t") is the critical >> measurement for NFS workloads. Bandwidth is almost meaningless in analyzing >> NFS. > > Yes and I have done this too. The average RTT on untaring is 43.000 ms. > I guess we will just be getting another set of ZeusRAM drives. Be careful with these measurements. Untar is the pathological worst case workload for NFS because of sync-on-close for clients. This workload is the poster child for Amdahl?s Law. Also, the bulk of the latency could in fact be due to transfer from the client to the server waiting to occur. In other words, the client can significantly impact these measurements. From a server?s perspective, nfssvrtop is the only tool I?m aware of that measures NFS operation latency from IP down to disk and back (the reason I wrote it :-). Of course, dtrace allows you to measure almost everything in the system, so you can add more measurements. Fortunately, most real workloads are not tar -x. ? richard > > Thanks, > derek > > -- > Derek T. Yarnell > University of Maryland > Institute for Advanced Computer Studies > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- ZFS storage and performance consulting at http://www.RichardElling.com From richard.elling at richardelling.com Tue Feb 18 07:16:16 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 17 Feb 2014 23:16:16 -0800 Subject: [OmniOS-discuss] Disappearing drives? In-Reply-To: References: Message-ID: On Feb 14, 2014, at 8:29 AM, Dan Swartzendruber wrote: > > I've been running an install on r151008. rpool mirrored on two WD black > 160GB sata drives. 8 SAS nearline drives in a raid10. Two samsung 840PRO > 128GB drives as l2arc. The sas and l2arc drives are on an LSI HBA, and > the rpool on motherboard sata ports. Twice now, I've had drives disappear > - the first time was one of the rpool drives, and yesterday one of the > l2arc drives. The symptom is that zpool status shows thousands of > read/write errors and the drive is offlined. If I run the format command, > it shows that drive as 'unknown drive type'. I apologize for not getting > more specific data - the first time, I wrote off as an anomaly, but > yesterday I really should have cut&pasted anything relevant. Anyway, I'm > puzzled that there seems no common hardware or driver factor. The rpool > drives are sata, and are using the sata-phy driver (I think that's what I > dug out of prtconf -v), whereas, although the l2arc drives are sata, since > they are on the lsi hba, they are using the sas-mpt driver. I wasn't that > concerned about yesterday's incident, since l2arc drives could both die > suddenly and not take things down, but having rpool go bye-bye is not good > - this is why I was paranoid and mirrored it. Any ideas? If this happens > again, what should I look for? ?fmadm faulty? and "fmdump -eV? sheds a lot of light on these sorts of problems. ? richard -- ZFS storage and performance consulting at http://www.RichardElling.com From dswartz at druber.com Tue Feb 18 14:15:49 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Tue, 18 Feb 2014 09:15:49 -0500 Subject: [OmniOS-discuss] Disappearing drives? In-Reply-To: References: Message-ID: <0a6f4c57871ffbfbd813161d96532c72.squirrel@webmail.druber.com> Thanks, Richard. I will make a note of this... From jimklimov at cos.ru Tue Feb 18 18:40:37 2014 From: jimklimov at cos.ru (Jim Klimov) Date: Tue, 18 Feb 2014 19:40:37 +0100 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> Message-ID: <5303A925.6060209@cos.ru> On 2014-02-18 08:05, Richard Elling wrote: > Fortunately, most real workloads are not tar -x. Oh, alas, on build farms they are. And the hordes of files produced as a result of "make" are not far behind. Oh, well, often they are behind - and subsequent accesses fail for a few seconds, just until something syncs down the pipe and back to the client. So the typical mantra is "gmake -j -k all; gmake all" for producing as many objects as we can first, and then cleaning up the mess sequentially :) //Jim From anhquach at me.com Wed Feb 19 00:17:18 2014 From: anhquach at me.com (Anh Quach) Date: Tue, 18 Feb 2014 16:17:18 -0800 Subject: [OmniOS-discuss] Granular control of fma modules Message-ID: Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks?? I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates.? Thanks in advance! --? Anh Quach Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakansom at ohsu.edu Wed Feb 19 02:41:13 2014 From: hakansom at ohsu.edu (Marion Hakanson) Date: Tue, 18 Feb 2014 18:41:13 -0800 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: Message from Derek Yarnell of "Mon, 17 Feb 2014 20:48:55 EST." <5302BC07.9070304@umiacs.umd.edu> Message-ID: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu> Derek Yarnell wrote: >>> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped >>> as a Pliant-LB206S-D323-186.31GB via format. Richard Elling wrote: >> Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for >> lots of concurrent I/O operations. This is not the kind of workload generated >> by the ZIL, which is more contiguous, single thread-like. Derek Yarnell wrote: > I realize that they may not be as good as Stec/HGST ZeusRAM drives for > the slog. I still can't wrap my head around that it is as bad as having > no discrete slog. Hi Derek, No better than with the ZIL running on the pool's HDD's? Really? Out of curiosity, what HBA is being used for these drives (and slog) in this R720xd, H710 or H310? Something else? I'm also looking at the R720xd here, though I was thinking of using the Intel DC S3700 SSD for a log device (in one of the internal flex-bay's), with the pool drives being of the 2.5" form-factor. Regards, Marion From danmcd at omniti.com Wed Feb 19 02:51:18 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 18 Feb 2014 21:51:18 -0500 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu> References: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu> Message-ID: On Feb 18, 2014, at 9:41 PM, Marion Hakanson wrote: > Derek Yarnell wrote: >>>> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped >>>> as a Pliant-LB206S-D323-186.31GB via format. > > Richard Elling wrote: >>> Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized > for >>> lots of concurrent I/O operations. This is not the kind of workload > generated >>> by the ZIL, which is more contiguous, single thread-like. > > Derek Yarnell wrote: >> I realize that they may not be as good as Stec/HGST ZeusRAM drives for >> the slog. I still can't wrap my head around that it is as bad as having >> no discrete slog. > > Hi Derek, > > No better than with the ZIL running on the pool's HDD's? Really? > > Out of curiosity, what HBA is being used for these drives (and slog) > in this R720xd, H710 or H310? Something else? > > I'm also looking at the R720xd here, though I was thinking of using the > Intel DC S3700 SSD for a log device (in one of the internal flex-bay's), > with the pool drives being of the 2.5" form-factor. The H710 sticks you with HW-RAID. Ick. The H310 allows you to use raw SAS disks, BUT I've encountered problems with BIOS failing INT13 reads on H310 raw disks, which makes booting difficult. (Also some Dell-issued disks require power entries in /kernel/drv/sd.conf.) Just be cautious when using the Dell HBAs. Dan From derek at umiacs.umd.edu Wed Feb 19 03:09:51 2014 From: derek at umiacs.umd.edu (Derek Yarnell) Date: Tue, 18 Feb 2014 22:09:51 -0500 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu> References: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu> Message-ID: <5304207F.9010406@umiacs.umd.edu> On 2/18/14, 9:41 PM, Marion Hakanson wrote: > No better than with the ZIL running on the pool's HDD's? Really? Yes it would seem I was getting just as bad svc_t from these Pliant SSDs then from the pools spinners. > Out of curiosity, what HBA is being used for these drives (and slog) > in this R720xd, H710 or H310? Something else? This is a R720xd shipped with a pristine LSI card (mine even came with IT firmware). You will need to talk to your rep but they can do it. My hope here was to get a fully supported OmniOS box from Dell which the biggest problem was before making me take a H710/H800 card. While we have been successful running ZFS with a R510 w/ H700s drives all in R0 and setting zfs_nocacheflush it just isn't right. We have also never gone more than 9 data drives with the R0 configuration (also this has been mostly on Nexenta not Omni). > > I'm also looking at the R720xd here, though I was thinking of using the > Intel DC S3700 SSD for a log device (in one of the internal flex-bay's), > with the pool drives being of the 2.5" form-factor. The R720xd flex bays are no longer internal but in the back of the machine[1]. I actually will test some spare DC S3700 drives as the slog devices that we have for a Ceph cluster in this in the next few days and will report back on this thread. One also thing to note is that Dell "Enterprise" drives have this problem of not spinning up[2] which made for a very fun to get installed. I had to install on a non-dell disk that was equal or smaller than my OS disks then modify the /kernel/drv/sd.conf file, then mirror the rpool reboot and then detach the non-dell drive and add the other drive back to the mirror. [1] - http://www.anchor.com.au/blog/2012/10/shiny-new-hardware-dell-r720xd/ [2] - https://www.illumos.org/issues/2091 Thanks, derek -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies From hakansom at ohsu.edu Wed Feb 19 03:54:05 2014 From: hakansom at ohsu.edu (Marion Hakanson) Date: Tue, 18 Feb 2014 19:54:05 -0800 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: Message from Derek Yarnell of "Tue, 18 Feb 2014 22:09:51 EST." <5304207F.9010406@umiacs.umd.edu> Message-ID: <201402190354.s1J3s59O004444@kyklops.ohsu.edu> Thanks for everybody's comments. More data from folks doing similar stuff is always welcome. Marion Hakanson wrote: >> Out of curiosity, what HBA is being used for these drives (and slog) >> in this R720xd, H710 or H310? Something else? > Derek Yarnell wrote: > This is a R720xd shipped with a pristine LSI card (mine even came with > IT firmware). You will need to talk to your rep but they can do it. My > hope here was to get a fully supported OmniOS box from Dell which the > biggest problem was before making me take a H710/H800 card. While we > have been successful running ZFS with a R510 w/ H700s drives all in R0 > and setting zfs_nocacheflush it just isn't right. We have also never > gone more than 9 data drives with the R0 configuration (also this has > been mostly on Nexenta not Omni). We have quite a few R710's with the PERC/6i internally, but for those used as ZFS file servers, the PERC's only apply to the two boot drives, where the "R0" approach is relatively painless. BTW, with these RAID HBA's that have non-volatile caches, you shouldn't need "zfs_nocacheflush" -- the OS recognizes when a cache is NV, and won't send a flush. That's been my experience since late 2008, anyway. We've had mixed results when asking Dell to send us LSI-branded HBA's. Sometimes they'll do it, sometimes not. Lately, we've gotten them to sell us Dell branded SAS 6gbps HBA's for use with external MD1200's, and those seem to be working just like LSI 9200-8e's & 9207-8e's. Anyway, thanks for the suggestion, I'll see what our rep can do for the internal HBA. That would be much nicer than having to deal with possible H310 glitches. > The R720xd flex bays are no longer internal but in the back of the > machine[1]. Well, that's close enough to "internal" for my purposes (:-). We have an Oracle X4270-M2 configured like that, now 3+ years old. Very nice layout, it's a pity they stopped selling them to mere mortals. > I actually will test some spare DC S3700 drives as the slog > devices that we have for a Ceph cluster in this in the next few days and > will report back on this thread. Cool, I look forward to seeing what you find out. Thanks and regards, Marion From doug at will.to Wed Feb 19 04:11:30 2014 From: doug at will.to (Doug Hughes) Date: Tue, 18 Feb 2014 23:11:30 -0500 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <201402190354.s1J3s59O004444@kyklops.ohsu.edu> References: <201402190354.s1J3s59O004444@kyklops.ohsu.edu> Message-ID: <53042EF2.6020703@will.to> On 2/18/2014 10:54 PM, Marion Hakanson wrote: > Thanks for everybody's comments. More data from folks doing similar stuff > is always welcome. > > > Marion Hakanson wrote: >>> Out of curiosity, what HBA is being used for these drives (and slog) >>> in this R720xd, H710 or H310? Something else? >> > Derek Yarnell wrote: >> This is a R720xd shipped with a pristine LSI card (mine even came with >> IT firmware). You will need to talk to your rep but they can do it. My >> hope here was to get a fully supported OmniOS box from Dell which the >> biggest problem was before making me take a H710/H800 card. While we >> have been successful running ZFS with a R510 w/ H700s drives all in R0 >> and setting zfs_nocacheflush it just isn't right. We have also never >> gone more than 9 data drives with the R0 configuration (also this has >> been mostly on Nexenta not Omni). > > We have quite a few R710's with the PERC/6i internally, but for those used > as ZFS file servers, the PERC's only apply to the two boot drives, where > the "R0" approach is relatively painless. BTW, with these RAID HBA's that > have non-volatile caches, you shouldn't need "zfs_nocacheflush" -- the OS > recognizes when a cache is NV, and won't send a flush. That's been my > experience since late 2008, anyway. > > We've had mixed results when asking Dell to send us LSI-branded HBA's. > Sometimes they'll do it, sometimes not. Lately, we've gotten them to > sell us Dell branded SAS 6gbps HBA's for use with external MD1200's, > and those seem to be working just like LSI 9200-8e's & 9207-8e's. > > Anyway, thanks for the suggestion, I'll see what our rep can do for the > internal HBA. That would be much nicer than having to deal with possible > H310 glitches. > > >> The R720xd flex bays are no longer internal but in the back of the >> machine[1]. > > Well, that's close enough to "internal" for my purposes (:-). We have > an Oracle X4270-M2 configured like that, now 3+ years old. Very nice > layout, it's a pity they stopped selling them to mere mortals. > > >> I actually will test some spare DC S3700 drives as the slog >> devices that we have for a Ceph cluster in this in the next few days and >> will report back on this thread. > > Cool, I look forward to seeing what you find out. > > Thanks and regards, > We've used S3700 as SLOG. it's a fine device for that. I find the current price point for the Intel 320 series to be hard to beat though. It's just over $1/GB. It also seems to perform better than the DCS3700 on the tests that I've run that seem to be reasonable predictors, up to 20%. The worst case for NFS performance tends to be lots of synchronous metadata operations, so I have a test that creates 100 0 byte files in each of 100 directories. And then an rm -rf on the lot. The rm difference is insignificant. I didn't compare exactly the same physical hardware (machine or data disks) though, so in the end the performance difference may not be that significant. From derek at umiacs.umd.edu Wed Feb 19 19:59:27 2014 From: derek at umiacs.umd.edu (Derek Yarnell) Date: Wed, 19 Feb 2014 14:59:27 -0500 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <201402190354.s1J3s59O004444@kyklops.ohsu.edu> References: <201402190354.s1J3s59O004444@kyklops.ohsu.edu> Message-ID: <53050D1F.2070505@umiacs.umd.edu> On 2/18/14, 10:54 PM, Marion Hakanson wrote: >> I actually will test some spare DC S3700 drives as the slog >> devices that we have for a Ceph cluster in this in the next few days and >> will report back on this thread. > > Cool, I look forward to seeing what you find out. For a 44MB/1981 file tar file. With DC S3700 drive in slog (ATA-INTEL SSDSC2BA10-0265-93.16GB) # time tar -xf littletarfile.tar real 0m8.337s user 0m0.056s sys 0m0.659s With Pliant LB206S drive in slog (Pliant-LB206S-D323-186.31GB) # time tar -xf littletarfile.tar real 8m43.268s user 0m0.109s sys 0m1.493s With no slog # time tar -xf littletarfile.tar real 9m17.243s user 0m0.127s sys 0m1.409s -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies From hakansom at ohsu.edu Wed Feb 19 21:14:58 2014 From: hakansom at ohsu.edu (Marion Hakanson) Date: Wed, 19 Feb 2014 13:14:58 -0800 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: Message from Derek Yarnell of "Wed, 19 Feb 2014 14:59:27 EST." <53050D1F.2070505@umiacs.umd.edu> Message-ID: <201402192114.s1JLEwQ2005540@kyklops.ohsu.edu> derek at umiacs.umd.edu said: > For a 44MB/1981 file tar file. > > With DC S3700 drive in slog (ATA-INTEL SSDSC2BA10-0265-93.16GB) > # time tar -xf littletarfile.tar > real 0m8.337s > user 0m0.056s > sys 0m0.659s > > With Pliant LB206S drive in slog (Pliant-LB206S-D323-186.31GB) > # time tar -xf littletarfile.tar > real 8m43.268s > user 0m0.109s > sys 0m1.493s > > With no slog > # time tar -xf littletarfile.tar > real 9m17.243s > user 0m0.127s > sys 0m1.409s Wow. One review I read says the LB206S has no DRAM cache, thus it's not prone to power-fail data loss. The DC S3700 does have such a cache, but with capacitor protection. Good latency for small ops, eh? Thanks and regards, Marion From alex at cooperi.net Thu Feb 20 03:58:06 2014 From: alex at cooperi.net (Alex Wilson) Date: Thu, 20 Feb 2014 13:58:06 +1000 Subject: [OmniOS-discuss] Granular control of fma modules In-Reply-To: References: Message-ID: <94925D68-A787-4BF4-9A26-AD9CF80D7268@cooperi.net> I?ve been recently trying to find a way to get disk-transport to ignore certain SMART values when deciding if a disk is going to fail ? in particular, the Seek Error figures, which Seagate drives tend to make out to be a lot more significant than they really are, using a different scale to everyone else. I had a look through the code for disk-transport though and it doesn?t seem like it can do very much to help: the module itself is pretty dumb and just passes on errors from deeper down in the libraries it uses (where there is also no means of filtering out events). The closest you can get is to use ?fmadm acquit?, but it doesn?t seem to work for me ? it clears out the fault that?s there for the moment, but doesn?t block it from coming back again, even though the man page suggests that it should. I guess this is because of disk-transport generating new UUIDs for each individual event rather than on the type of event? It?s a bit annoying. I?d really like a disk-transport.conf var to say ?ignore this particular type of SMART data? or ?ignore it for these disks?. Maybe I should sit down and try to write some code for it... On 19 Feb 2014, at 10:17 am, Anh Quach wrote: > Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks? > > I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates. > > Thanks in advance! > > -- > Anh Quach > Sent with Airmail > _______________________________________________ > 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 mariusz.stanczak at gmail.com Thu Feb 20 12:36:32 2014 From: mariusz.stanczak at gmail.com (M.S.) Date: Thu, 20 Feb 2014 04:36:32 -0800 Subject: [OmniOS-discuss] SUNW* libraries In-Reply-To: <201402161733.s1GHX35H011496@elvis.arl.psu.edu> References: <20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com> <201402161733.s1GHX35H011496@elvis.arl.psu.edu> Message-ID: <20140220043632.d66a9c6a7ac34b0b68385cf0@gmail.com> On Sun, 16 Feb 2014 12:33:03 -0500 John D Groenveld wrote: > In message <20140216023558.b34940c1f29e5a71f49d4cdd at gmail.com>, Mariusz Stancza > k writes: > >be what they seem to. So, what's the story with those libs. > > The libraries are not supported by OmniTI. > > However, /kernel/drv/amd64/nvidia from NVDAgraphicsr package is not > dependent on them. Works well enough. Thanks, /Mariusz > > John > groenveld at acm.org > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss --- M.S. From mweiss at cimlbr.com Thu Feb 20 17:06:40 2014 From: mweiss at cimlbr.com (Matt Weiss) Date: Thu, 20 Feb 2014 11:06:40 -0600 Subject: [OmniOS-discuss] Performance Issues In-Reply-To: <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> Message-ID: <53063620.3020404@cimlbr.com> I am having some major performance issues and cannot figure out why. All-in-one box sharing storage with NFS From Veaam (another vm on same box) I am getting 55 MB/s backup speeds. Everything has vmware tools 5.5 installed and shows up as a 10 Gbit adapter. Veeam says my bottleneck is source (which would be the omnios vm) I have a 2nd box setup with freenas on a smaller supermicro with similar specs but with an expander backplane and WD Red drives. I can write to that at 156 MB/s In general, the system just seems way slower than it should be, not just from veeam. iostats on the zpool don't seem to be really hitting things all that hard. What can I do to narrow this down? SPECS and info: Supermicro SC846A-R900B (Direct Attach, 6 SFF 8087) Supermicro X9DR7-LN4F-JBOD 14x Seagate 4TB Constellation ES.3 3.5" 7200RPM SAS ST4000NM0023 2x Intel Xeon E5-2620V2 2.1GHZ 15MB DDR3 Up to 1866MHZ 6C 256 GB ram 16 Axiom Memory Solutions 16GB DDR3-1600 ECC Rdimm- 1 STEC Zues RAM 6 GB SAS 8 GB 2 x LSI 9207-8I plus onboard motherboard lsi 10 Gbit ethernet via Intel TX540 All 6 SFF connections from the 2308 lsi's are hooked up to the 6 connections on the backplane of the supermicro case. Here is my zpool info: zpool status tank pool: tank state: ONLINE scan: scrub repaired 0 in 16h54m with 0 errors on Tue Feb 4 11:54:24 2014 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c4t5000C5005702158Fd0 ONLINE 0 0 0 c4t5000C500570880CBd0 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 c4t5000C500572792B3d0 ONLINE 0 0 0 c4t5000C5005731D42Bd0 ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 c4t5000C5005731DA97d0 ONLINE 0 0 0 c4t5000C5005731DBD3d0 ONLINE 0 0 0 mirror-4 ONLINE 0 0 0 c4t5000C5005731DEFBd0 ONLINE 0 0 0 c4t5000C5005731DF4Fd0 ONLINE 0 0 0 mirror-5 ONLINE 0 0 0 c4t5000C5005731F03Fd0 ONLINE 0 0 0 c4t5000C500573209EBd0 ONLINE 0 0 0 mirror-6 ONLINE 0 0 0 c4t5000C50057320E5Bd0 ONLINE 0 0 0 c4t5000C50057321177d0 ONLINE 0 0 0 mirror-7 ONLINE 0 0 0 c4t5000C5005732F953d0 ONLINE 0 0 0 c4t5000C50057330B27d0 ONLINE 0 0 0 logs c6t5000A72A3008DF19d0 ONLINE 0 0 0 cache c4t50025388A01D572Cd0 ONLINE 0 0 0 spares c4t5000C500570212AFd0 AVAIL errors: No known data errors logs: zuesram cache: samsung 840 evo (just added yesterday) uname -a SunOS omnios.kcgo.com 5.11 omnios-b281e50 i86pc i386 i86pc This is currently a napp-it all in one box. Vmware 5.1 sharing a OmniOS vmbox with 8 cpu 64 GB ram All reserved From tim at multitalents.net Thu Feb 20 17:32:24 2014 From: tim at multitalents.net (Tim Rice) Date: Thu, 20 Feb 2014 09:32:24 -0800 (PST) Subject: [OmniOS-discuss] Performance Issues In-Reply-To: <53063620.3020404@cimlbr.com> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <53063620.3020404@cimlbr.com> Message-ID: On Thu, 20 Feb 2014, Matt Weiss wrote: > I am having some major performance issues and cannot figure out why. [snip] > > This is currently a napp-it all in one box. > > Vmware 5.1 sharing a OmniOS vmbox with > 8 cpu > 64 GB ram All reserved What happens if you drop the OmniOS VM down to 2 CPU? -- Tim Rice Multitalents tim at multitalents.net From dswartz at druber.com Thu Feb 20 17:41:23 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 20 Feb 2014 12:41:23 -0500 Subject: [OmniOS-discuss] Performance Issues In-Reply-To: References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <53063620.3020404@cimlbr.com> Message-ID: <68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com> > On Thu, 20 Feb 2014, Matt Weiss wrote: > >> I am having some major performance issues and cannot figure out why. > [snip] >> >> This is currently a napp-it all in one box. >> >> Vmware 5.1 sharing a OmniOS vmbox with >> 8 cpu >> 64 GB ram All reserved > > What happens if you drop the OmniOS VM down to 2 CPU? Yeah, I am wondering that too. I am very skeptical you would ever need more than 2 threads to service a network link that size. Too many cores for a VM can actually hurt performance. From anhquach at me.com Thu Feb 20 19:03:38 2014 From: anhquach at me.com (Anh Quach) Date: Thu, 20 Feb 2014 11:03:38 -0800 Subject: [OmniOS-discuss] Granular control of fma modules In-Reply-To: <94925D68-A787-4BF4-9A26-AD9CF80D7268@cooperi.net> References: <94925D68-A787-4BF4-9A26-AD9CF80D7268@cooperi.net> Message-ID: Thanks for the reply, Alex.? Yeah, to my knowledge fmadm acquit seems to just clear the one unique event. From a ?for your own good? standpoint, it makes sense that one probably shouldn?t be disabling this kind of stuff, but I?m surprised the .conf has no way of filtering by SMART data. Looks like you can set these properties:? setprop temp-multiple ? ?? setprop selftest-multiple? setprop smart-multiple but no granular control for specific devices.? --? Anh Quach Sent with Airmail On February 19, 2014 at 8:04:20 PM, Alex Wilson (alex at cooperi.net) wrote: I?ve been recently trying to find a way to get disk-transport to ignore certain SMART values when deciding if a disk is going to fail ? in particular, the Seek Error figures, which Seagate drives tend to make out to be a lot more significant than they really are, using a different scale to everyone else. I had a look through the code for disk-transport though and it doesn?t seem like it can do very much to help: the module itself is pretty dumb and just passes on errors from deeper down in the libraries it uses (where there is also no means of filtering out events). The closest you can get is to use ?fmadm acquit?, but it doesn?t seem to work for me ? it clears out the fault that?s there for the moment, but doesn?t block it from coming back again, even though the man page suggests that it should. I guess this is because of disk-transport generating new UUIDs for each individual event rather than on the type of event? It?s a bit annoying. I?d really like a disk-transport.conf var to say ?ignore this particular type of SMART data? or ?ignore it for these disks?. Maybe I should sit down and try to write some code for it... On 19 Feb 2014, at 10:17 am, Anh Quach wrote: Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks?? I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates.? Thanks in advance! --? Anh Quach Sent with Airmail _______________________________________________ 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 mweiss at cimlbr.com Thu Feb 20 19:16:33 2014 From: mweiss at cimlbr.com (Matt Weiss) Date: Thu, 20 Feb 2014 13:16:33 -0600 Subject: [OmniOS-discuss] Performance Issues In-Reply-To: <68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <53063620.3020404@cimlbr.com> <68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com> Message-ID: <53065491.8000306@cimlbr.com> I will try that as soon as I can take down the array. 10 Gbit on one array shouldn't need more than 2 new CPU cores eh? On 2/20/2014 11:41 AM, Dan Swartzendruber wrote: >> On Thu, 20 Feb 2014, Matt Weiss wrote: >> >>> I am having some major performance issues and cannot figure out why. >> [snip] >>> This is currently a napp-it all in one box. >>> >>> Vmware 5.1 sharing a OmniOS vmbox with >>> 8 cpu >>> 64 GB ram All reserved >> What happens if you drop the OmniOS VM down to 2 CPU? > Yeah, I am wondering that too. I am very skeptical you would ever need > more than 2 threads to service a network link that size. Too many cores > for a VM can actually hurt performance. > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From dswartz at druber.com Thu Feb 20 19:24:50 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 20 Feb 2014 14:24:50 -0500 Subject: [OmniOS-discuss] Performance Issues In-Reply-To: <53065491.8000306@cimlbr.com> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <53063620.3020404@cimlbr.com> <68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com> <53065491.8000306@cimlbr.com> Message-ID: > I will try that as soon as I can take down the array. 10 Gbit on one > array shouldn't need more than 2 new CPU cores eh? Well, it might or it might not. You'd have to know for sure that even if it does, the guest is multi-threaded enough to take advantage of them. Note that if you give too many cores to a guest, vsphere can have problems scheduling the guest, so latency and performance in general might suck. If you run with two cores and performance is not good enough, look at how much CPU is being used... From paladinemishakal at gmail.com Fri Feb 21 15:05:02 2014 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Fri, 21 Feb 2014 23:05:02 +0800 Subject: [OmniOS-discuss] SolarFlare 10GB network card Message-ID: Hi All, I have a Solarflare SFN5122F Dual-Port 10GbE SFP+ Onload Server Adapter which I would like to use with OmniOS and I am currently using r150008j. >From this post on the OmniOS-discuss, http://lists.omniti.com/pipermail/omnios-discuss/2013-August/001254.html , someone mentioned the sfxge driver is being integrate into the illumos tree. Is this release to the stable release? Where can I find information on how to install the drivers? Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Feb 21 15:14:17 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 21 Feb 2014 10:14:17 -0500 Subject: [OmniOS-discuss] SolarFlare 10GB network card In-Reply-To: References: Message-ID: On Feb 21, 2014, at 10:05 AM, Lawrence Giam wrote: > Hi All, > > I have a Solarflare SFN5122F Dual-Port 10GbE SFP+ Onload Server Adapter which I would like to use with OmniOS and I am currently using r150008j. > > From this post on the OmniOS-discuss, http://lists.omniti.com/pipermail/omnios-discuss/2013-August/001254.html , someone mentioned the sfxge driver is being integrate into the illumos tree. > > Is this release to the stable release? Where can I find information on how to install the drivers? It was put up for review on the Illumos list in August, but nobody reviewed it. It's not in any illumos-gate or child (incl. illumos-omnios) yet. You could compile it from source. Heck, *I* could compile it from source if you're feeling brave and want to do some testing. Reviewing a driver like this takes time, and properly testing it 10x as much time. I'm not sure if the original poster on the Illumos list is here as well, but if he is, perhaps he can speak to how ready-or-not the code is. Sorry I can't be of more immediate assistance, Dan From esproul at omniti.com Fri Feb 21 15:24:16 2014 From: esproul at omniti.com (Eric Sproul) Date: Fri, 21 Feb 2014 10:24:16 -0500 Subject: [OmniOS-discuss] SolarFlare 10GB network card In-Reply-To: References: Message-ID: On Fri, Feb 21, 2014 at 10:14 AM, Dan McDonald wrote: > It was put up for review on the Illumos list in August, but nobody reviewed it. It's not in any illumos-gate or child (incl. illumos-omnios) yet. For the record, the issue report is https://www.illumos.org/issues/4057 From richard.elling at richardelling.com Sun Feb 23 05:14:46 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Sat, 22 Feb 2014 21:14:46 -0800 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <5303A925.6060209@cos.ru> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <5303A925.6060209@cos.ru> Message-ID: <6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com> On Feb 18, 2014, at 10:40 AM, Jim Klimov wrote: > On 2014-02-18 08:05, Richard Elling wrote: >> Fortunately, most real workloads are not tar -x. > > Oh, alas, on build farms they are. And the hordes of files produced > as a result of "make" are not far behind. Oh, well, often they are > behind - and subsequent accesses fail for a few seconds, just until > something syncs down the pipe and back to the client. So the typical > mantra is "gmake -j -k all; gmake all" for producing as many objects > as we can first, and then cleaning up the mess sequentially :) For build farms, why do you care about NFS sync writes? This is the canonical case for sync=disabled, because there is no unique data. ? richard -- ZFS storage and performance consulting at http://www.RichardElling.com From richard.elling at richardelling.com Sun Feb 23 05:50:25 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Sat, 22 Feb 2014 21:50:25 -0800 Subject: [OmniOS-discuss] Granular control of fma modules In-Reply-To: References: Message-ID: <989404F2-E09D-4681-9CD4-9614CD795518@RichardElling.com> On Feb 18, 2014, at 4:17 PM, Anh Quach wrote: > Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks? In Solaris 11, yes this is possible. However, the open source community has not implemented it yet, AFAIK. > > I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates. You can unload disk-transport altogether as a workaround. The root cause is a bug in the Seagate firmware introduced in version 3 of their firmware. A fix is in the works for version 4, available RSN. ? richard -- ZFS storage and performance consulting at http://www.RichardElling.com From anhquach at me.com Sun Feb 23 20:09:51 2014 From: anhquach at me.com (Anh Quach) Date: Sun, 23 Feb 2014 12:09:51 -0800 Subject: [OmniOS-discuss] Granular control of fma modules In-Reply-To: <989404F2-E09D-4681-9CD4-9614CD795518@RichardElling.com> References: <989404F2-E09D-4681-9CD4-9614CD795518@RichardElling.com> Message-ID: Thanks, Richard.? Yeah, it seems in Solaris 11.1, you can disable over-temp in the disk-transport module in /usr/lib/fm/fmd/plugins/disk-transport.conf by:? setprop temp-multiple 0 but it applies to all disks as far as I know. I haven?t found a way to only specify certain disks to be omitted. Anyway, is this parameter not implemented in OminOS then? I?ve got the module unloaded for now, as you suggested.? Not a huge deal as we won?t be going with these Seagates in production, but a minor annoyance during testing. :) --? Anh Quach Sent with Airmail On February 22, 2014 at 9:49:59 PM, Richard Elling (richard.elling at richardelling.com) wrote: On Feb 18, 2014, at 4:17 PM, Anh Quach wrote: > Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks? In Solaris 11, yes this is possible. However, the open source community has not implemented it yet, AFAIK. > > I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates. You can unload disk-transport altogether as a workaround. The root cause is a bug in the Seagate firmware introduced in version 3 of their firmware. A fix is in the works for version 4, available RSN. ? richard -- ZFS storage and performance consulting at http://www.RichardElling.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Mon Feb 24 02:42:47 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Sun, 23 Feb 2014 18:42:47 -0800 Subject: [OmniOS-discuss] Overheating faults with ST4000NM0023 In-Reply-To: <52FC9C12.9090900@smartjog.com> References: <6B4199959CFA4E1CB067BBF9270654CB@486dx4> <52FC9C12.9090900@smartjog.com> Message-ID: <9970E697-9693-4405-A85C-9369DDD3048D@RichardElling.com> Clarification below... On Feb 13, 2014, at 2:18 AM, Thibault VINCENT wrote: > On 02/12/2014 09:59 PM, Steamer wrote: >> Did you ever find a solution to the overheating faults with the >> ST4000NM0023? >> >> I'm currently having the exact same issue with ST1000NM0023 drives, >> seems like seagate has the user temp probe set at 40'C. The manual >> states that the temperature settings are programmable via smart, but I >> haven't found a way to do that. > > Hello Emile, > > I've found a workaround but the definitive fix should be handled by > Illumos I guess. There is no open ticket, first I was waiting for > something to happen with #4051 before going back to using that distro > and kernel. > > Here's the story: > The SCSI specification defines two registers to store the temperature > thresholds in SMART data. One contains the recommended maximum operation > temperature for best MTBF, and the other register is for the absolute > maximum rating. Usually the industry has always put the same value in > both, and that is the absolute maximum. Yes, because the SPC-4 (section 7.3.21.3) standard is very precise in its defined use. Seagate made a mistake and didn't follow the spec. AIUI, this is being corrected in firmware 0004, available RSN. -- richard > That's why we always see > something like 60/65?C from SMART. But recently Seagate has changed that > because it was asked by a large OS company to comply with the > specification for better hardware monitoring integration. The change did > not only occur in newer products but in a firmware update for existing > disks and that was applied to the production line which explains some > disks mays or may not expose this problem although they are the same > model. Our disks are of the Megalodon serie and all share the same > firmware basecode. > > So any Seagate disk will now trigger faults in FMA if they have a > firmware with the newer policy. Also I think other brands will follow > the same path. > > Like other members suggested in that thread, maybe nothing should change > in FMA but let's face it, you can't maintain a temperature steadily > under 40?C in a JBOD of hundreds of busy disks. Especially in > eco-friendly datacenters. IMHO we should not trigger a fault on the > lower threshold, and certainly not a drive retirement. It breaks storage > servers on reboot or before a pool import, also spare disks could > disappear with the retirement triggered. > > The workaround is to downgrade firmware to the last version before the > change, and to reset the register with an SCSI command. It is not > possible to set the register to a user specified value like the > documentation suggests, they confirmed it. > > I'm sending a working firmware to you in a private mail. I'm not aware > of any issue working with that older version and hopefully it should > upload to 1TB drives as well. > I'm applying it like this but from Linux not OmniOS: > # ./dl_sea_fw-0.2.3_32 -f Megalodon_StdOEM_SAS_0002+C84C.lod -m ST4000NM0023 > # ./dl_sea_fw-0.2.3_32 -i > > Then you should reset the drives so they reload the firmware. > Here's our example for 4TB drives: > ------------- > for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do > sg_reset -d $i > done > ------------- > > And reset the register that contains value from the previous firmware. > It doesn't work well so we've got this script to run a few times until > all disks got it. Again it matches 4TB Megalodon. > ------------- > for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do > echo -n "$i " > if sg_logs $i --page=0x0d | grep 'Reference temperature = 68 C' >> /dev/null ; then > echo 'ok' > else > sg_logs $i --page=0x0d --reset > echo 'reset' > fi > done > ------------- > > > Cheers > > -- > Thibault VINCENT - Lead System Engineer, Infrastructure - > Arkena | Phone: +33 1 58 68 62 38 | Mobile: +33 6 78 97 01 08 > 27 Blvd Hippolyte Marqu?s, 94200 Ivry-sur-Seine, France | www.arkena.com > Arkena - Ready to Play > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Richard.Elling at RichardElling.com +1-760-896-4422 -------------- next part -------------- An HTML attachment was scrubbed... URL: From groups at tierarzt-mueller.de Mon Feb 24 20:23:46 2014 From: groups at tierarzt-mueller.de (Alexander Lesle) Date: Mon, 24 Feb 2014 21:23:46 +0100 Subject: [OmniOS-discuss] unknown kernel-crash Message-ID: <1596969154.20140224212346@tierarzt-mueller.de> Hello All, I have here a new server and the kernel crashes and I cant find why. Now I hope I get some help and a solution here. Supermicro X10SLH-F, XEON E3-1230, 32GB ECC RAM, 2 x SSD Samsung 840, LSI 9211-8i On the first SSD ESXi5.5 and on the second SSD Omnios r151008f and napp-it appliance as VM (1 socket, 2 cores, 16GB RAM reserved) The rpool is customize with Paul Hensons script - I have changed: ,-----[ ]----- | # uncomment to set size of s0 on install disk (in format syntax) | #$rpool_size = '30gb'; | | # uncomment to add additional options for zpool create | $rpool_opts = '-O compression=lz4 -O copies=2 -O checksum=sha256 | -O atime=off'; `------------------- My data pool is a 3-way-mirror. One extra fs for other VMs. This crash I reported here I do an new VM installation. Before crash the CPU push up to 100%, Omnios getting very slow and the VM install too. Thats not the only one crash but this crash I am sitting in front of the screen. Panic was at Feb 23 17:30:37 See attachments please. In putty.log the output from: root at aio:~# fmadm faulty root at aio:~# fmdump -Vp -u c040c25b-b481-ea5c-a1a6-a7cb74097521 root at aio:~# fmstat root at aio:~# fmdump -e root at aio:~# fmdump -eV root at aio:~# fmdump -I This messages confused me too: genunix: [ID 723599 kern.warning] WARNING: Driver alias "pciex8086,1526" conflicts with an existing driver name or alias. genunix: [ID 127566 kern.info] device pciclass,030000 at f(display#0) keeps up device sd at 0,0(sd#1), but the former is not power managed smbd[556]: [ID 413393 daemon.error] dyndns: failed to get domainname Thanks in advance. -- Best Regards Alexander Februar, 24 2014 Attachments / Dateianlagen: ---------------------------- [1] putty.log [2] messages.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: putty.log Type: application/octet-stream Size: 43415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: messages.0 Type: application/octet-stream Size: 144528 bytes Desc: not available URL: From paladinemishakal at gmail.com Tue Feb 25 13:42:03 2014 From: paladinemishakal at gmail.com (Lawrence Giam) Date: Tue, 25 Feb 2014 21:42:03 +0800 Subject: [OmniOS-discuss] fmd core dump in r150008j Message-ID: Hi All, I have a new server and today I got an alert that diskspace was almost fully used up. Checking on the system, I found that under /var/fm/fmd, there is a core dump file. I checked /var/adm/messages and fmdump, cannot find anything suspicious. I am running OmniOS r150008j. This is an analysis of the core dump. root at sgbk02:/tankD01/backups/sgsan1n1/fmd# mdb core.fmd.559 Loading modules: [ fmd libumem.so.1 libc.so.1 libnvpair.so.1 libtopo.so.1 libuutil.so.1 libavl.so.1 libsysevent.so.1 eft.so ld.so.1 ] > $c libc.so.1`_lwp_kill+0x15(4, 6, 6786, fef56000, fef56000, 95) libc.so.1`raise+0x2b(6, 0, fda5ea00, feed5a09, 0, 0) libc.so.1`abort+0x10e(3a646d66, 4f424120, 203a5452, 75736e69, 63696666, 746e6569) fmd_panic(80835e0, fda5ee84, 1, 0) fmd_panic+0x12(80835e0, 50, 3e8, feb0e8e4) fmd_alloc+0x81(50, 1, 80, e3b74613, 1, 3b9aca00) fmd_event_create+0x18(1, 88fe3252, 11f57f, 0, fbd3ab30, 896ab30) fmd_module_timeout+0x20(fbd3ab30, c4, 88fe3252, 11f57f, 8393e08) fmd_timerq_exec+0x127(8393e00, 0, fed922a0, fef56000) fmd_thread_start+0x5b(819e6d0, 0, 0, 0) libc.so.1`_thrp_setup+0x88(fed92240) libc.so.1`_lwp_start(fed92240, 0, 0, 0, 0, 0) > ::showrev Hostname: sgsan1n1 Release: 5.11 Kernel architecture: i86pc Application architecture: i386 Kernel version: SunOS 5.11 i86pc omnios-6de5e81 Platform: i86pc > ::status debugging core file of fmd (32-bit) from sgsan1n1 file: /usr/lib/fm/fmd/fmd initial argv: /usr/lib/fm/fmd/fmd threading model: native threads status: process terminated by SIGABRT (Abort), pid=559 uid=0 code=-1 > $r %cs = 0x0043 %eax = 0x00000000 %ds = 0x004b %ebx = 0xfef56000 %ss = 0x004b %ecx = 0xfda5e9ac %es = 0x004b %edx = 0x00000000 %fs = 0x0000 %esi = 0x00000095 %gs = 0x01c3 %edi = 0x080835e0 %eip = 0xfeee78b5 libc.so.1`_lwp_kill+0x15 %ebp = 0xfda5e9c8 %kesp = 0x00000000 %eflags = 0x00000282 id=0 vip=0 vif=0 ac=0 vm=0 rf=0 nt=0 iopl=0x0 status= %esp = 0xfda5e9ac %trapno = 0xe %err = 0x6 > 0xfeee78b5::dis libc.so.1`_lwp_kill: call +0x0 libc.so.1`_lwp_kill+5: popl %edx libc.so.1`_lwp_kill+6: movl $0xa3,%eax libc.so.1`_lwp_kill+0xb: movl %esp,%ecx libc.so.1`_lwp_kill+0xd: addl $0x10,%edx libc.so.1`_lwp_kill+0x13: sysenter libc.so.1`_lwp_kill+0x15: jae +0xc libc.so.1`_lwp_kill+0x17: cmpl $0x5b,%eax libc.so.1`_lwp_kill+0x1a: jne +0x9 libc.so.1`_lwp_kill+0x1c: movl $0x4,%eax libc.so.1`_lwp_kill+0x21: jmp +0x2 libc.so.1`_lwp_kill+0x23: xorl %eax,%eax libc.so.1`_lwp_kill+0x25: ret 0xfeee78c6: leal 0x0(%esi),%esi 0xfeee78c9: leal 0x0(%edi),%edi libc.so.1`_lwp_self: call +0x0 libc.so.1`_lwp_self+5: popl %edx Looks like fmd crashed. Can anyone help me confirm that I am right? Thanks & Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svavar at januar.is Thu Feb 27 09:54:58 2014 From: svavar at januar.is (=?ISO-8859-1?Q?Svavar_=D6rn_Eysteinsson?=) Date: Thu, 27 Feb 2014 09:54:58 +0000 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator Message-ID: Hello List. I'm experimenting with ZFS on a iSCSI target. Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI target located out on the public internet from my hosting provider. As for now the iSCSI target is about 300GB which I have managed to connect and created a ZFS pool on the target. Now for the questions, what would the scenario be if I asked my provider to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see the new size ? Do I need any to scrub the pool, or how to I grow my pool to the new size provided by my hosting provider ? As before, now I have a 300GB ZFS pool on the iSCSI target. Which I have mounted and everything seems to work fine. Later the iSCSI target will be grown to 500GB. Are there anything special work that needs to be done regarding growing the ZFS datapool from 300GB to 500GB. (those extra 200GB) ? Thanks in advance people. Best regards, Svavar O - Reykjavik - Iceland -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimklimov at cos.ru Thu Feb 27 14:25:15 2014 From: jimklimov at cos.ru (Jim Klimov) Date: Thu, 27 Feb 2014 15:25:15 +0100 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <5303A925.6060209@cos.ru> <6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com> Message-ID: <530F4ACB.40607@cos.ru> On 2014-02-23 06:14, Richard Elling wrote: > On Feb 18, 2014, at 10:40 AM, Jim Klimov wrote: > >> On 2014-02-18 08:05, Richard Elling wrote: >>> Fortunately, most real workloads are not tar -x. >> >> Oh, alas, on build farms they are. And the hordes of files produced >> as a result of "make" are not far behind. Oh, well, often they are >> behind - and subsequent accesses fail for a few seconds, just until >> something syncs down the pipe and back to the client. So the typical >> mantra is "gmake -j -k all; gmake all" for producing as many objects >> as we can first, and then cleaning up the mess sequentially :) > > For build farms, why do you care about NFS sync writes? This is the > canonical case for sync=disabled, because there is no unique data. > ? richard Interesting suggestion :) In one example I have, the builds from several nodes are done in subdirectories of a user's home directory, as well as edition of some files (sources, recipes/makefiles) in the process. And being a home, it is sync'ed per defaults. But I might investigate if dedicating a sub-dataset without sync would help and won't cause races (i.e. edit a file on one host, initiate a build quickly on another, and compile the obsolete version which was cached by NFS client), so thanks :) I hope, NFS cached-data syncs and locks, and ZFS write-syncs are not very related in this case (i.e. zfs sync=disabled does not influence co-ordination of NFS data between hosts), right? Thanks, //Jim From mark at omniti.com Thu Feb 27 15:49:52 2014 From: mark at omniti.com (Mark Harrison) Date: Thu, 27 Feb 2014 10:49:52 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: References: Message-ID: If you have the pool on the raw device (i.e. you haven't created any slices/partitions and instructed zfs to use the whole 'disk'), and the device suddenly appears to the OS with a larger size, then ZFS will use all the space available. This also applies to physical drives, where if you replace all the mirrored drives in a pool or top level vdev with larger drives, the pool will suddenly be larger. On Thu, Feb 27, 2014 at 4:54 AM, Svavar ?rn Eysteinsson wrote: > Hello List. > > I'm experimenting with ZFS on a iSCSI target. > Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI > target > located out on the public internet from my hosting provider. > > As for now the iSCSI target is about 300GB which I have managed to connect > and created a ZFS pool on the target. > > Now for the questions, what would the scenario be if I asked my provider > to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see > the new size ? Do I need any to scrub the pool, or how to I grow my pool > to the new size provided by my hosting provider ? > > As before, now I have a 300GB ZFS pool on the iSCSI target. > Which I have mounted and everything seems to work fine. > > Later the iSCSI target will be grown to 500GB. Are there anything > special work that needs to be done regarding growing the ZFS datapool from > 300GB to 500GB. > (those extra 200GB) ? > > > Thanks in advance people. > > Best regards, > > Svavar O - Reykjavik - Iceland > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From dswartz at druber.com Thu Feb 27 15:54:33 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 27 Feb 2014 10:54:33 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: References: Message-ID: > Hello List. > > I'm experimenting with ZFS on a iSCSI target. > Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI > target > located out on the public internet from my hosting provider. > > As for now the iSCSI target is about 300GB which I have managed to connect > and created a ZFS pool on the target. > > Now for the questions, what would the scenario be if I asked my provider > to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see > the new size ? Do I need any to scrub the pool, or how to I grow my pool > to the new size provided by my hosting provider ? > > As before, now I have a 300GB ZFS pool on the iSCSI target. > Which I have mounted and everything seems to work fine. > > Later the iSCSI target will be grown to 500GB. Are there anything > special work that needs to be done regarding growing the ZFS datapool from > 300GB to 500GB. I can't see this working at all. Even if the iscsi initiator presents the new bigger size, the pool/vdevs/etc have all been created using a specific 'disk' size. Rather than grow the target, can they carve off more space and present you a 2nd LUN? You could then add that as a 2nd vdev to the pool... From dswartz at druber.com Thu Feb 27 15:56:34 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 27 Feb 2014 10:56:34 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator Message-ID: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> > If you have the pool on the raw device (i.e. you haven't created any slices/partitions and instructed zfs to use the whole 'disk'), and the device suddenly appears to the OS with a larger size, then ZFS will use all the space available. This also applies to physical drives, where if you replace all the mirrored drives in a pool or top level vdev with larger drives, the pool will suddenly be larger. Mark, you are talking about a scenario where a pool has redundancy. You replace a disk with a larger one and it resilvers, using the new size. He has (it seems) a single drive in that vdev. By definition, you can't replace it without losing all the data, no? From dswartz at druber.com Thu Feb 27 16:00:39 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 27 Feb 2014 11:00:39 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> Message-ID: <10674b0becfb9605662aec47b8a5861e.squirrel@webmail.druber.com> Re-reading Mark's reply, I'm not so sure about my answer. I want to take a look at this... From mark at omniti.com Thu Feb 27 16:04:20 2014 From: mark at omniti.com (Mark Harrison) Date: Thu, 27 Feb 2014 11:04:20 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> Message-ID: Good point. I probably should have added the disclaimer that I haven't tested this with iscsi devices directly, and was working on the assumption that the device would suddenly show as a larger device with all data intact. If that's not possible, then one possible may of making this work would be requesting a second device of the larger size, adding it to the pool as a mirror, waiting for the resilver to finish, and then removing the smaller device. On Thu, Feb 27, 2014 at 10:56 AM, Dan Swartzendruber wrote: >> If you have the pool on the raw device (i.e. you haven't created any > slices/partitions and instructed zfs to use the whole 'disk'), and the > device suddenly appears to the OS with a larger size, then ZFS will use > all the space available. This also applies to physical drives, where if > you replace all the mirrored drives in a pool or top level vdev with > larger drives, the pool will suddenly be larger. > > Mark, you are talking about a scenario where a pool has redundancy. You > replace a disk with a larger one and it resilvers, using the new size. He > has (it seems) a single drive in that vdev. By definition, you can't > replace it without losing all the data, no? > > > > -- Mark Harrison Lead Site Reliability Engineer OmniTI From dswartz at druber.com Thu Feb 27 16:15:11 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 27 Feb 2014 11:15:11 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> Message-ID: I can't actually swear that a dynamically grown LUN wouldn't work, it just seems unlikely, but who knows? I agree the simplest thing is to have them give him another bigger lun, mirror them, detach the first, then make sure the new one gets grown... From danmcd at omniti.com Thu Feb 27 16:20:42 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 27 Feb 2014 11:20:42 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> Message-ID: <69FB85D9-ED75-494B-BC8D-900D6D11E56A@omniti.com> On Feb 27, 2014, at 11:15 AM, Dan Swartzendruber wrote: > > I can't actually swear that a dynamically grown LUN wouldn't work, it just > seems unlikely, but who knows? I agree the simplest thing is to have them > give him another bigger lun, mirror them, detach the first, then make sure > the new one gets grown... MAKE SURE that the "autoexpand" property of the pool is enabled: zpool get autoexpand And set it to "on" if need be. Dan From esproul at omniti.com Thu Feb 27 16:20:51 2014 From: esproul at omniti.com (Eric Sproul) Date: Thu, 27 Feb 2014 11:20:51 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> Message-ID: See the autoexpand property in zpool(1M). It defaults to off, but if you turn it on, growing a LUN should result in growing the pool size. On Thu, Feb 27, 2014 at 11:15 AM, Dan Swartzendruber wrote: > > I can't actually swear that a dynamically grown LUN wouldn't work, it just > seems unlikely, but who knows? I agree the simplest thing is to have them > give him another bigger lun, mirror them, detach the first, then make sure > the new one gets grown... > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From doug at will.to Thu Feb 27 16:25:20 2014 From: doug at will.to (Doug Hughes) Date: Thu, 27 Feb 2014 11:25:20 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> Message-ID: <530F66F0.1080304@will.to> On 2/27/2014 10:56 AM, Dan Swartzendruber wrote: >> If you have the pool on the raw device (i.e. you haven't created any > slices/partitions and instructed zfs to use the whole 'disk'), and the > device suddenly appears to the OS with a larger size, then ZFS will use > all the space available. This also applies to physical drives, where if > you replace all the mirrored drives in a pool or top level vdev with > larger drives, the pool will suddenly be larger. > > Mark, you are talking about a scenario where a pool has redundancy. You > replace a disk with a larger one and it resilvers, using the new size. He > has (it seems) a single drive in that vdev. By definition, you can't > replace it without losing all the data, no? Are you taking into account this option from the zpool? zpool1 autoexpand off default if you set autoexpand = on, you will see the behavior that replacing all of the disks will autoexpand the pool. This can be unfortunate if the disk model has been slightly tweaked (happened to us) for the same exact disk and shows to the OS as slightly fewer blocks. It won't resilver. I usually only set autoexpand = on if I explicitly want to grow the size of the pool, and then turn it back off again right away. From dswartz at druber.com Thu Feb 27 17:03:02 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 27 Feb 2014 12:03:02 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: <530F66F0.1080304@will.to> References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com> <530F66F0.1080304@will.to> Message-ID: <363c0af8fa88505206bc0201e7c4b9c2.squirrel@webmail.druber.com> Yes, that's the property I was thinking of. I don't have an easy way to confirm/disprove that an iSCSI lun being resized will work for the OP - I am dubious, since the auto-partition code creates (AFAIR) a full-sized EFI partition. OmniOS would have to resize it and do who knows what juju. Scary, I think... From richard.elling at richardelling.com Thu Feb 27 19:39:05 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Thu, 27 Feb 2014 11:39:05 -0800 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <530F4ACB.40607@cos.ru> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <5303A925.6060209@cos.ru> <6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com> <530F4ACB.40607@cos.ru> Message-ID: <17E70147-79EB-471C-A9F4-496F8C99BF77@richardelling.com> On Feb 27, 2014, at 6:25 AM, Jim Klimov wrote: > On 2014-02-23 06:14, Richard Elling wrote: >> On Feb 18, 2014, at 10:40 AM, Jim Klimov wrote: >> >>> On 2014-02-18 08:05, Richard Elling wrote: >>>> Fortunately, most real workloads are not tar -x. >>> >>> Oh, alas, on build farms they are. And the hordes of files produced >>> as a result of "make" are not far behind. Oh, well, often they are >>> behind - and subsequent accesses fail for a few seconds, just until >>> something syncs down the pipe and back to the client. So the typical >>> mantra is "gmake -j -k all; gmake all" for producing as many objects >>> as we can first, and then cleaning up the mess sequentially :) >> >> For build farms, why do you care about NFS sync writes? This is the >> canonical case for sync=disabled, because there is no unique data. >> ? richard > > Interesting suggestion :) > > In one example I have, the builds from several nodes are done in > subdirectories of a user's home directory, as well as edition of > some files (sources, recipes/makefiles) in the process. And being > a home, it is sync'ed per defaults. > > But I might investigate if dedicating a sub-dataset without sync > would help and won't cause races (i.e. edit a file on one host, > initiate a build quickly on another, and compile the obsolete > version which was cached by NFS client), so thanks :) > > I hope, NFS cached-data syncs and locks, and ZFS write-syncs are > not very related in this case (i.e. zfs sync=disabled does not > influence co-ordination of NFS data between hosts), right? Right. The file system is consistent. The NFS sync is for the case when the server reboots. As long as your server isn't rebooting, everything should be consistent (assuming the clients are configured appropriately) -- richard From slefevre at indy.rr.com Thu Feb 27 21:10:33 2014 From: slefevre at indy.rr.com (Scott LeFevre) Date: Thu, 27 Feb 2014 16:10:33 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: References: Message-ID: <1393535433.707.6.camel@exilis.si-consulting.us> As others have pointed out, setting autoexpand=on on the pool is the key to making use of any new space allocated to your drive. As a test, I created a 30GB drive and created a new pool. I then expanded that drive to 50GB. The size of the pool didn't change until I turned on autoexpand on the pool. This was done in a VM and not with a iscsi target lun but the principle should apply the same. root at omnios1:~# zpool create tank0 /dev/rdsk/c1t2d0 root at omnios1:~# zpool list NAME SIZE ALLOC FREE EXPANDSZ CAP DEDUP HEALTH ALTROOT rpool 15.9G 2.51G 13.4G - 15% 1.00x ONLINE - tank0 29.8G 156K 29.7G - 0% 1.00x ONLINE - root at omnios1:~# zpool get autoexpand tank0 NAME PROPERTY VALUE SOURCE tank0 autoexpand off default root at omnios1:~# prtvtoc /dev/rdsk/c1t2d0s0 * /dev/rdsk/c1t2d0s0 partition map * * Dimensions: * 512 bytes/sector * 62914560 sectors * 62914493 accessible sectors * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 34 222 255 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 4 00 256 62897887 62898142 8 11 00 62898143 16384 62914526 --- Expanded /dev/rdsk/c1t2d0 to 50GB --- root at omnios1:~# zpool list NAME SIZE ALLOC FREE EXPANDSZ CAP DEDUP HEALTH ALTROOT rpool 15.9G 2.51G 13.4G - 15% 1.00x ONLINE - tank0 29.8G 130K 29.7G 20G 0% 1.00x ONLINE - root at omnios1:~# zpool get autoexpand tank0 NAME PROPERTY VALUE SOURCE tank0 autoexpand off default root at omnios1:~# zpool set autoexpand=on tank0 root at omnios1:~# zpool list NAME SIZE ALLOC FREE EXPANDSZ CAP DEDUP HEALTH ALTROOT rpool 15.9G 2.51G 13.4G - 15% 1.00x ONLINE - tank0 49.8G 200K 49.7G - 0% 1.00x ONLINE - root at omnios1:~# prtvtoc /dev/rdsk/c1t2d0 * /dev/rdsk/c1t2d0 partition map * * Dimensions: * 512 bytes/sector * 104857600 sectors * 104857533 accessible sectors * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 34 222 255 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 4 00 256 104840927 104841182 8 11 00 104841183 16384 104857566 -- Scott LeFevre On Thu, 2014-02-27 at 09:54 +0000, Svavar ?rn Eysteinsson wrote: > Hello List. > > > > I'm experimenting with ZFS on a iSCSI target. > Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI > target > located out on the public internet from my hosting provider. > > > As for now the iSCSI target is about 300GB which I have managed to > connect > and created a ZFS pool on the target. > > > Now for the questions, what would the scenario be if I asked my > provider > to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see > the new size ? Do I need any to scrub the pool, or how to I grow my > pool > to the new size provided by my hosting provider ? > > > As before, now I have a 300GB ZFS pool on the iSCSI target. > Which I have mounted and everything seems to work fine. > > > Later the iSCSI target will be grown to 500GB. Are there anything > special work that needs to be done regarding growing the ZFS datapool > from 300GB to 500GB. > (those extra 200GB) ? > > > > > Thanks in advance people. > > > Best regards, > > > Svavar O - Reykjavik - Iceland > > _______________________________________________ > 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 dswartz at druber.com Thu Feb 27 21:15:48 2014 From: dswartz at druber.com (Dan Swartzendruber) Date: Thu, 27 Feb 2014 16:15:48 -0500 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: <1393535433.707.6.camel@exilis.si-consulting.us> References: <1393535433.707.6.camel@exilis.si-consulting.us> Message-ID: <180ce8932be1f5de67374c83b067bf88.squirrel@webmail.druber.com> Fascinating. Thanks for the experiment! From jimklimov at cos.ru Thu Feb 27 22:01:01 2014 From: jimklimov at cos.ru (Jim Klimov) Date: Thu, 27 Feb 2014 23:01:01 +0100 Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL In-Reply-To: <17E70147-79EB-471C-A9F4-496F8C99BF77@richardelling.com> References: <530291DA.6050009@umiacs.umd.edu> <5302BC07.9070304@umiacs.umd.edu> <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com> <5303A925.6060209@cos.ru> <6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com> <530F4ACB.40607@cos.ru> <17E70147-79EB-471C-A9F4-496F8C99BF77@richardelling.com> Message-ID: <530FB59D.3000703@cos.ru> On 2014-02-27 20:39, Richard Elling wrote: >> I hope, NFS cached-data syncs and locks, and ZFS write-syncs are >> not very related in this case (i.e. zfs sync=disabled does not >> influence co-ordination of NFS data between hosts), right? > > Right. The file system is consistent. The NFS sync is for the case when > the server reboots. As long as your server isn't rebooting, everything > should be consistent (assuming the clients are configured appropriately) And "appropriately" is just how much different from "default"? I.e. if I set sharenfs on the server dataset, and walk in with autofs + nfs/client from the build host, with no special configs other than those in solaris 10 or OpenIndiana, is that appropriate? Or should some specific stuff be configured on clients and servers? Thanks! //Jim From johan.kragsterman at capvert.se Fri Feb 28 07:13:44 2014 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Fri, 28 Feb 2014 08:13:44 +0100 Subject: [OmniOS-discuss] illumos power management...again... Message-ID: Hi! I remember a discussion on this theme last year. I've been reading up on that, but that didn't answer my questions. I'm in the process of building a new main home server, and I would of coarse like it to be energy efficient. I don't use much space normally, so my daily working environment doesn't need much space, which means I can use all SSD's for that. Though I would like a backup/nfs environment, with more space on spinning disks, and I got two different scenarious to choose from here: One is building a separate machine for backup/nfs, and only start it when it needs to be started( with wake on LAN). The other is to have the spinning disks in my main home server, and use illumos power management to take care of powering down the disks when they are not in use. This would of coarse be the easiest way, if the power management system is efficient enough. I don't know if the system can/do power down the disks if the nfs server is active and the shares are mounted? (I don't have any problems with latencies/delays here, since it isn't in regular use) If so, good! If not, I could umount the shares and turn off the nfs server, and export the pool, if that would help spinning down disks... Someone got any insight and/or suggestions here...? Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert From svavar at januar.is Fri Feb 28 09:21:37 2014 From: svavar at januar.is (=?ISO-8859-1?Q?Svavar_=D6rn_Eysteinsson?=) Date: Fri, 28 Feb 2014 09:21:37 +0000 Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator In-Reply-To: <180ce8932be1f5de67374c83b067bf88.squirrel@webmail.druber.com> References: <1393535433.707.6.camel@exilis.si-consulting.us> <180ce8932be1f5de67374c83b067bf88.squirrel@webmail.druber.com> Message-ID: Thank you all for the help, and the tech talk about this scenario. I have configured the autoexpand to ON on the pool. I will also ask my provider to grow the LUN and test it before using it. Will post information soon. Thanks again. Best regards, Svavar O *SVAVAR ?RN EYSTEINSSON*Kerfisstj?ri Gsm / mobile +354 862 1624 S?mi / tel +354 531 0101 *Jan?ar marka?sh?s*www.januar.is / Facebook On 27 February 2014 21:15, Dan Swartzendruber wrote: > > Fascinating. Thanks for the experiment! > > _______________________________________________ > 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 Fri Feb 28 09:36:47 2014 From: jimklimov at cos.ru (jimklimov at cos.ru) Date: Fri, 28 Feb 2014 10:36:47 +0100 Subject: [OmniOS-discuss] illumos power management...again... Message-ID: <072n48b3g5t0ujaah6lbh4ks.1393580207933@email.android.com> When i asked about this a few years back, when Sun was high in the sky and OpenSolaris roamed the web, the answer was that the one thing that might keep disks from spinning down is outstanding i/o's, which may include scrubs, slocate/mlocate uodatedb runs, zds-autosnap, and in case of homedirs - stuff like firefox caches and DE working files. Otherwise, disks can spin down even with a pool imported and mounted (possibly, some data would even be read off the cache and won't require spinups). I am not sure how valid this remains today, but seems worth a try. Typos courtesy of my Samsung Mobile -------- ???????? ????????? -------- ??: Johan Kragsterman ????: 2014.02.28 8:13 (GMT+01:00) ????: omnios-discuss ????: [OmniOS-discuss] illumos power management...again... Hi! I remember a discussion on this theme last year. I've been reading up on that, but that didn't answer my questions. I'm in the process of building a new main home server, and I would of coarse like it to be energy efficient. I don't use much space normally, so my daily working environment doesn't need much space, which means I can use all SSD's for that. Though I would like a backup/nfs environment, with more space on spinning disks, and I got two different scenarious to choose from here: One is building a separate machine for backup/nfs, and only start it when it needs to be started( with wake on LAN). The other is to have the spinning disks in my main home server, and use illumos power management to take care of powering down the disks when they are not in use. This would of coarse be the easiest way, if the power management system is efficient enough. I don't know if the system can/do power down the disks if the nfs server is active and the shares are mounted? (I don't have any problems with latencies/delays here, since it isn't in regular use) If so, good! If not, I could umount the shares and turn off the nfs server, and export the pool, if that would help spinning down disks... Someone got any insight and/or suggestions here...? Best regards from/Med v?nliga h?lsningar fr?n Johan Kragsterman Capvert _______________________________________________ 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 lists at marzocchi.net Fri Feb 28 11:14:28 2014 From: lists at marzocchi.net (Olaf Marzocchi) Date: Fri, 28 Feb 2014 12:14:28 +0100 Subject: [OmniOS-discuss] illumos power management...again... In-Reply-To: <072n48b3g5t0ujaah6lbh4ks.1393580207933@email.android.com> References: <072n48b3g5t0ujaah6lbh4ks.1393580207933@email.android.com> Message-ID: I remember connecting two USB disks and they never spun down, even after exporting the pool. The light was briefly blinking anyway. Am I going to try soon the same using eSATA... But the same external case and bridge chipset. Olaf Inviato da iPhone > Il giorno 28/feb/2014, alle ore 10:36, "jimklimov at cos.ru" ha scritto: > > When i asked about this a few years back, when Sun was high in the sky and OpenSolaris roamed the web, the answer was that the one thing that might keep disks from spinning down is outstanding i/o's, which may include scrubs, slocate/mlocate uodatedb runs, zds-autosnap, and in case of homedirs - stuff like firefox caches and DE working files. Otherwise, disks can spin down even with a pool imported and mounted (possibly, some data would even be read off the cache and won't require spinups). > > I am not sure how valid this remains today, but seems worth a try. > > > Typos courtesy of my Samsung Mobile > > > -------- ???????? ????????? -------- > ??: Johan Kragsterman > ????: 2014.02.28 8:13 (GMT+01:00) > ????: omnios-discuss > ????: [OmniOS-discuss] illumos power management...again... > > > Hi! > > I remember a discussion on this theme last year. I've been reading up on that, but that didn't answer my questions. > > I'm in the process of building a new main home server, and I would of coarse like it to be energy efficient. I don't use much space normally, so my daily working environment doesn't need much space, which means I can use all SSD's for that. > > Though I would like a backup/nfs environment, with more space on spinning disks, and I got two different scenarious to choose from here: > > One is building a separate machine for backup/nfs, and only start it when it needs to be started( with wake on LAN). > > The other is to have the spinning disks in my main home server, and use illumos power management to take care of powering down the disks when they are not in use. > This would of coarse be the easiest way, if the power management system is efficient enough. > > I don't know if the system can/do power down the disks if the nfs server is active and the shares are mounted? (I don't have any problems with latencies/delays here, since it isn't in regular use) > > If so, good! > If not, I could umount the shares and turn off the nfs server, and export the pool, if that would help spinning down disks... > > Someone got any insight and/or suggestions here...? > > > > Best regards from/Med v?nliga h?lsningar fr?n > > Johan Kragsterman > > Capvert > > _______________________________________________ > 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 From cks at cs.toronto.edu Fri Feb 28 18:16:45 2014 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Fri, 28 Feb 2014 13:16:45 -0500 Subject: [OmniOS-discuss] How do you configure serial ports on OmniOS? Message-ID: <20140228181645.624801A0BBB@apps0.cs.toronto.edu> This question makes me feel silly but I'm lost in a confusing maze of documentation for sacadm, pmadm, and so on and I can't find anything with web searches. What I would like to do is configure what I believe is /dev/term/c ('ttyS3' in Linux) to run a getty or the OmniOS/Illumos/etc equivalent at 115200 baud. Relatedly, I'd also like to change the getty-equivalent that 'pmadm -l' at least theoretically says is talking to /dev/term/a from 9600 baud to 115200 baud. How to do this is also, well, not obvious to me. (Please note that I do not want to make this the serial console, a procedure for which there seems to be plenty of documentation. I just want to be able to log in over that serial port, or it and /dev/term/a.) Thanks in advance. - cks From lotheac at iki.fi Fri Feb 28 18:28:16 2014 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Fri, 28 Feb 2014 20:28:16 +0200 Subject: [OmniOS-discuss] How do you configure serial ports on OmniOS? In-Reply-To: <20140228181645.624801A0BBB@apps0.cs.toronto.edu> References: <20140228181645.624801A0BBB@apps0.cs.toronto.edu> Message-ID: <20140228182816.GC28245@gutsman.lotheac.fi> On Fri, Feb 28 2014 13:16:45 -0500, Chris Siebenmann wrote: > This question makes me feel silly but I'm lost in a confusing maze of > documentation for sacadm, pmadm, and so on and I can't find anything > with web searches. What I would like to do is configure what I believe is > /dev/term/c ('ttyS3' in Linux) to run a getty or the OmniOS/Illumos/etc > equivalent at 115200 baud. I found this pretty useful: http://iws.cs.uni-magdeburg.de/~elkner/keyboard/serialconsole.txt > (Please note that I do not want to make this the serial console, a > procedure for which there seems to be plenty of documentation. I just > want to be able to log in over that serial port, or it and /dev/term/a.) Right, so skip setting console stuff; sttydefs and a console-login service instance should do it I believe. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet