From vab at bb-c.de Mon Jan 2 08:48:12 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 2 Jan 2017 09:48:12 +0100 Subject: [OmniOS-discuss] ms.omniti.com Publisher tuntap manifest missing In-Reply-To: References: Message-ID: <22634.5068.550461.2238@shelob.bb-c.de> [Happy New Year everyone!] Hi Dale! > Just closing the loop on this - the tuntap driver is now part of > OmniOS-proper, from 014 onwards. As such, the tuntap package in the > ms.omniti.com repo has been removed, and I've corrected the issue you > reported. That's nice. While you are there, the ms.omniti.com repo does need some more love: # /usr/bin/pkgrecv -v -m latest -s http://pkg.omniti.com/omniti-ms/ -d /pkg/ms.omniti.com pkg://ms.omniti.com/network/iftop Processing packages for publisher omniti-ms ... Retrieving catalog 1/1 omniti-ms 154.65 kB Unable to retrieve package data for publisher 'omniti-ms' from one of the following origin(s): http://pkg.omniti.com/omniti-ms/ The catalog retrieved from one of the origin(s) listed above only contains package data for: ms.omniti.com. This is either a result of invalid origin information being provided for publisher 'omniti-ms', or because the wrong publisher name was provided when this publisher was added. Retrieving and evaluating 1 package(s)... Retrieving packages ... Packages to add: 1 Files to retrieve: 0 Estimated transfer size: 0.00 B Packages to transfer: network/iftop at 1.0.2,5.11-0.151006:20130816T191418Z PROCESS ITEMS GET (MB) SEND (MB) network/iftop 0/1 0.0/0.0 0.0/0.0 pkgrecv: 'open' failed for transaction ID '1376680458_pkg%3A%2F%2Fms.omniti.com%2Fnetwork%2Fiftop%401.0.2%2C5.11-0.151006%3A20130816T191418Z': The specified FMRI, 'pkg://ms.omniti.com/network/iftop at 1.0.2,5.11-0.151006:20130816T191418Z', already exists or has been restricted. I think the best fix would be to just remove everything that does not have "omniti" as first package name component. :-) Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From bfriesen at simple.dallas.tx.us Mon Jan 2 21:52:11 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 2 Jan 2017 15:52:11 -0600 (CST) Subject: [OmniOS-discuss] Unexpected BE name after upgrade to r151020 Message-ID: Today I upgraded from r151018 to r151020 using the lipkg zones procedure described at https://omnios.omniti.com/wiki.php/Upgrade_to_r151020 The upgrade seems to be successful and the /etc/release file in the global and non-global zones says r151020. However, I was surprised that the default boot environment name due to the upgrade (I did not specify a name) is 'omnios-r151018-4' rather than 'omnios-r151020'. This feels like a bug to me. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From bfriesen at simple.dallas.tx.us Mon Jan 2 23:07:37 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 2 Jan 2017 17:07:37 -0600 (CST) Subject: [OmniOS-discuss] Unexpected BE name after upgrade to r151020 In-Reply-To: References: Message-ID: After some consideration, I realize that it could be difficult to know an appropriate boot environment name since all that is known is the publisher setting. It is necessary to download something from the new publisher in order to know a better default naming. Perhaps what is needed is a documentation improvement which more strongly suggests that the user supply the new BE name (e.g. 'omnios-r151020') since otherwise the new name will be based off of an inappropriate default. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From alka at hfg-gmuend.de Tue Jan 3 17:03:16 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Tue, 3 Jan 2017 18:03:16 +0100 Subject: [OmniOS-discuss] Fwd: NVMe in ESXi-Passthrough crashes In-Reply-To: <1987622123.20161023160905@gmx.de> References: <1344112614.20161023025416@gmx.de> <1878224113.20161023030628@gmx.de> <1987622123.20161023160905@gmx.de> Message-ID: <3f072957-0754-aa4c-2d91-2dff4f99b04c@hfg-gmuend.de> seems the long awaited fix can be expected soon https://www.listbox.com/member/archive/182179/2017/01/sort/time_rev/page/1/entry/0:16/20170103103744:8FBB4C0C-D1CA-11E6-A873-F6C0C0E74B80/ Gea Am 23.10.2016 um 16:09 schrieb Frank M.: > Hi, > > I?ve tested now on another machine (HP DL380 G6). > The new bloody OmniOS crashes here too... > > Frank > > Sunday, October 23, 2016, 3:11:09 AM, you wrote: > > >>> On Oct 22, 2016, at 9:06 PM, Frank M. wrote: >>> >>> >>> I?ve installed the new bloody as a new test virtual machine. The vm >>> crashes whenever there is a access to the nvme device. >>> Tests with a "special nvme driver" on the last stable had no problems. >>> I tested a Samsung SM951 on ESXi 6.0 U2 on a Supermicro X10DRi-T4+. >>> Tomorrow I will test shortly a Samsung SM961 on another Server (HP). >>> I hope, you will find a solution until the next stable release... > DM> Oddly enough: > > DM> 1.) r151020 (next stable) is coming soon (November). > > DM> 2.) Due to some interesting circumstances, the NVMe fixes in > DM> bloody & 020 may be backported to LTS (014) and last-stable (018). > > DM> Dan > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- H f G Hochschule f?r Gestaltung university of design Schw?bisch Gm?nd Rektor-Klaus Str. 100 73525 Schw?bisch Gm?nd Guenther Alka, Dipl.-Ing. (FH) Leiter des Rechenzentrums head of computer center Tel 07171 602 627 Fax 07171 69259 guenther.alka at hfg-gmuend.de http://rz.hfg-gmuend.de From danmcd at omniti.com Wed Jan 4 01:45:45 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 3 Jan 2017 20:45:45 -0500 Subject: [OmniOS-discuss] Unexpected BE name after upgrade to r151020 In-Reply-To: References: Message-ID: > On Jan 2, 2017, at 6:07 PM, Bob Friesenhahn wrote: > > Perhaps what is needed is a documentation improvement which more strongly suggests that the user supply the new BE name (e.g. 'omnios-r151020') since otherwise the new name will be based off of an inappropriate default. That should land on one of the wiki pages, I just don't know off the top of my head which one it should be. I'll look into it before 022 ships, for sure. Dan From danmcd at omniti.com Wed Jan 4 01:48:58 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 3 Jan 2017 20:48:58 -0500 Subject: [OmniOS-discuss] Unexpected BE name after upgrade to r151020 In-Reply-To: References: Message-ID: > On Jan 3, 2017, at 8:45 PM, Dan McDonald wrote: > > That should land on one of the wiki pages, I just don't know off the top of my head which one it should be. Added something here: https://omnios.omniti.com/wiki.php/Upgrade_to_r151020 Dan From omnios at citrus-it.net Wed Jan 4 09:01:10 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Wed, 4 Jan 2017 09:01:10 +0000 (UTC) Subject: [OmniOS-discuss] uname -v change Message-ID: Morning, Just finished updating servers after last week's update to r151020 and noticed that the uname -v output has lost the revision information. Before: SunOS carolina 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc After: SunOS reaper 5.11 omnios-bed3013 i86pc i386 i86pc Was that deliberate? Thanks, Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From danmcd at omniti.com Wed Jan 4 16:43:29 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 4 Jan 2017 11:43:29 -0500 Subject: [OmniOS-discuss] uname -v change In-Reply-To: References: Message-ID: It was a build accident, not intentional. Next time kernels get updated, it'll be fixed. If this is breaking scripts, I'll push an update that fixes it (at the cost of requiring another reboot). I'm very sorry about it. It's my fault for making build environment assumptions. A very recent omnios-build push will prevent things like this going forward. Sorry, Dan Sent from my iPhone (typos, autocorrect, and all) > On Jan 4, 2017, at 4:01 AM, Andy Fiddaman wrote: > > Morning, > > Just finished updating servers after last week's update to r151020 and > noticed that the uname -v output has lost the revision information. > > Before: > > SunOS carolina 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc > > After: > > SunOS reaper 5.11 omnios-bed3013 i86pc i386 i86pc > > Was that deliberate? > > Thanks, > > Andy > -- > Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ > Registered in England and Wales | Company number 4899123 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Wed Jan 4 17:29:14 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 4 Jan 2017 12:29:14 -0500 Subject: [OmniOS-discuss] Happy New Year, and Python2.7 Message-ID: <5FD14374-2704-4A53-A8AA-409D5F1E7DCE@omniti.com> The first of the big changes for this bloody cycle is underway internally, i.e. the move from Python2.6 to Python2.7 for OmniOS-internal users of Python. Those users are currently: pkg(5) traditional installer media (not kayak) As of now, the pkg5 test suite is mostly passing with Python2.7, and bloody users know that Python2.7 is AVAILABLE in the main "omnios" publisher repo. The installer still needs work, but I'm curious how many bloody users out there would be comfortable with having (for now) older install media, but when "pkg update" occurs, moving entirely to Python2.7? The possible answers are: * We want both: Basically, don't jump to Python2.7 until all components are ready. * We can cope: Basically, make the jump for pkg5, but for now, traditional install media would be frozen, until the Python2.7 jump has been completed. Appreciate your feedback, and I have one more longer-term question coming later today or tomorrow. Thanks! Dan From cks at cs.toronto.edu Wed Jan 4 18:04:25 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Wed, 04 Jan 2017 13:04:25 -0500 Subject: [OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them Message-ID: <20170104180425.8DAE05A1098@apps1.cs.toronto.edu> We recently had a server reboot due to the ZFS vdev_deadman/spa_deadman timeout timer activating and panicing the system. If you haven't heard of this timer before, that's not surprising; triggering it requires an IO to a vdev to take more than 1000 seconds (by default; it's controlled by the value of zfs_deadman_synctime_ms, in spa_misc.c). Before this happened, I would not have expected that our OmniOS system allowed an IO to run that long before timing it out and returning an error to ZFS. Clearly I'm wrong, which means that I'd like to understand what disk IO timeouts OmniOS has and where (or if) we can control them so that really long IOs get turned into forced errors well before 16 minutes go by. Unfortunately our disk topology is a bit complicated; we have scsi_vhci multipathing on top of iSCSI disks. In some Internet searching I've found sd_io_time (60 seconds by default) and the default SD retry count of 5 (I think, it may be 3), which can be adjusted on a per-disk-type basis through the retries-timeout parameter (per the sd manpage). Searching the kernel code suggests that there are some hard-coded timeouts in the 30 to 90 second range, which also doesn't seem excessive. (I have a crash dump from this panic, so I can in theory use mdb to look through it to see just what level an IO appears stuck at if I know what to look for and how.) Based on 'fmdump -eV' output, it looks like our server was retrying IO repeatedly. Does anyone know what I should be looking at to find and adjust timeouts, retry counts, and so on? Is there any documentation that I'm overlooking? Thanks in advance. - cks PS: some links I've dug up in searches: http://everycity.co.uk/alasdair/2011/05/adjusting-drive-timeouts-with-mdb-on-solaris-or-openindiana/ https://smartos.org/bugview/OS-2415 https://www.illumos.org/issues/1553 From eric.sproul at circonus.com Wed Jan 4 18:18:08 2017 From: eric.sproul at circonus.com (Eric Sproul) Date: Wed, 4 Jan 2017 13:18:08 -0500 Subject: [OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them In-Reply-To: <20170104180425.8DAE05A1098@apps1.cs.toronto.edu> References: <20170104180425.8DAE05A1098@apps1.cs.toronto.edu> Message-ID: On Wed, Jan 4, 2017 at 1:04 PM, Chris Siebenmann wrote: > (I have a crash dump from this panic, so I can in theory use mdb > to look through it to see just what level an IO appears stuck at > if I know what to look for and how.) Hi Chris, I recently blogged about digging into a deadman crash with mdb: http://www.circonus.com/blog/crash-dump-necromancy I'll let others with more direct experience respond about the timeout settings. HTH, Eric From miniflowtrader at gmail.com Wed Jan 4 18:19:41 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 4 Jan 2017 13:19:41 -0500 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files Message-ID: Hello all, Is there any support for NFS 4.2 in Illumos? I am interested in the Sparse File functionality that has been introduced. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.elling at richardelling.com Wed Jan 4 18:29:51 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Wed, 4 Jan 2017 10:29:51 -0800 Subject: [OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them In-Reply-To: <20170104180425.8DAE05A1098@apps1.cs.toronto.edu> References: <20170104180425.8DAE05A1098@apps1.cs.toronto.edu> Message-ID: <8FA836CB-143C-4422-BF34-E2B657B8C251@richardelling.com> > On Jan 4, 2017, at 10:04 AM, Chris Siebenmann wrote: > > We recently had a server reboot due to the ZFS vdev_deadman/spa_deadman > timeout timer activating and panicing the system. If you haven't heard > of this timer before, that's not surprising; triggering it requires an > IO to a vdev to take more than 1000 seconds (by default; it's controlled > by the value of zfs_deadman_synctime_ms, in spa_misc.c). > > Before this happened, I would not have expected that our OmniOS system > allowed an IO to run that long before timing it out and returning an > error to ZFS. Clearly I'm wrong, which means that I'd like to understand > what disk IO timeouts OmniOS has and where (or if) we can control them > so that really long IOs get turned into forced errors well before 16 > minutes go by. Unfortunately our disk topology is a bit complicated; > we have scsi_vhci multipathing on top of iSCSI disks. Do not assume the timeout reflects properly operating software or firmware. The original impetus for the deadman was to allow debugging of the underlying stack. Prior to adding the deadman, the I/O could be stuck forever. > > In some Internet searching I've found sd_io_time (60 seconds by > default) and the default SD retry count of 5 (I think, it may be > 3), which can be adjusted on a per-disk-type basis through the > retries-timeout parameter (per the sd manpage). Searching the kernel > code suggests that there are some hard-coded timeouts in the 30 to 90 > second range, which also doesn't seem excessive. For sd-level, most commands follow the sd_io_time and retries. scsi_vhci adds significant complexity above sd and below zfs. ? richard > > (I have a crash dump from this panic, so I can in theory use mdb > to look through it to see just what level an IO appears stuck at > if I know what to look for and how.) > > Based on 'fmdump -eV' output, it looks like our server was > retrying IO repeatedly. > > Does anyone know what I should be looking at to find and adjust > timeouts, retry counts, and so on? Is there any documentation that > I'm overlooking? > > Thanks in advance. > > - cks > PS: some links I've dug up in searches: > http://everycity.co.uk/alasdair/2011/05/adjusting-drive-timeouts-with-mdb-on-solaris-or-openindiana/ > https://smartos.org/bugview/OS-2415 > https://www.illumos.org/issues/1553 > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Wed Jan 4 19:01:16 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 4 Jan 2017 14:01:16 -0500 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: References: Message-ID: > On Jan 4, 2017, at 1:19 PM, Mini Trader wrote: > > Hello all, > > Is there any support for NFS 4.2 in Illumos? I am interested in the Sparse File functionality that has been introduced. There is not, currently. There have been some stop/starts on this, but at the end of the day, at least one illumos shop's customers basically didn't care enough to make it a priority for that shop. The other illumos shops either have similar customer viewpoints, don't care about NFS at all, or don't have the resources to devote to such a nontrivial project. I'm sorry I don't have a better answer for you at the moment. Dan From john.barfield at bissinc.com Wed Jan 4 20:02:01 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 20:02:01 +0000 Subject: [OmniOS-discuss] New SAN deployment HBA recommendations Message-ID: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com> Greetings, I?m designing a new ZFS SAN and I?m wondering if anyone knows the latest greatest supported HBA that I should use for external JBOD?s. We have tons of SAN?s in production using LSI HBAs today but I?m wondering if there is anything new out there that I?m missing or not aware of yet. Thanks for any recommendations. John Barfield M: +1 (214) 425-0783 O: +1 (214) 506-8354 john.barfield at bissinc.com [cid:image001.png at 01D26693.1E73B1D0] 4925 Greenville Ave, Ste 900 Dallas, TX 75206 For Support Requests: http://support.bissinc.com or support at bissinc.com k -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3504 bytes Desc: image001.png URL: From danmcd at omniti.com Wed Jan 4 20:18:42 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 4 Jan 2017 15:18:42 -0500 Subject: [OmniOS-discuss] New SAN deployment HBA recommendations In-Reply-To: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com> References: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com> Message-ID: > On Jan 4, 2017, at 3:02 PM, John Barfield wrote: > > Greetings, > > I?m designing a new ZFS SAN and I?m wondering if anyone knows the latest greatest supported HBA that I should use for external JBOD?s. > > We have tons of SAN?s in production using LSI HBAs today but I?m wondering if there is anything new out there that I?m missing or not aware of yet. Are you using LSI 9300 series (driven by the 3008 chipset) yet? That's the latest from the world of LSI. Those are fairly recent (last 3-4 years), and many still use the 2008 chipset or 2208 chipset. There are parts currently just-in-SmartOS that may be getting upstreamed soon as well. You may be better off asking this question on the illumos developers' list, to see what the latest/greatest in supported HBA HW is. Dan From john.barfield at bissinc.com Wed Jan 4 20:21:19 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 20:21:19 +0000 Subject: [OmniOS-discuss] New SAN deployment HBA recommendations In-Reply-To: References: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com> Message-ID: <17B21797-734A-4177-88B4-E50F9E3387D9@bissinc.com> I was specifically wondering what is supported in the latest OmniOS release, but I suppose youre suggesting that I could backport an illumos driver from the latest build into ominos? OmniOS is the distro I use for SAN deployments. I use SmartOS for hypervisors. On 1/4/17, 2:18 PM, "Dan McDonald" wrote: > On Jan 4, 2017, at 3:02 PM, John Barfield wrote: > > Greetings, > > I?m designing a new ZFS SAN and I?m wondering if anyone knows the latest greatest supported HBA that I should use for external JBOD?s. > > We have tons of SAN?s in production using LSI HBAs today but I?m wondering if there is anything new out there that I?m missing or not aware of yet. Are you using LSI 9300 series (driven by the 3008 chipset) yet? That's the latest from the world of LSI. Those are fairly recent (last 3-4 years), and many still use the 2008 chipset or 2208 chipset. There are parts currently just-in-SmartOS that may be getting upstreamed soon as well. You may be better off asking this question on the illumos developers' list, to see what the latest/greatest in supported HBA HW is. Dan From john.barfield at bissinc.com Wed Jan 4 20:29:43 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 20:29:43 +0000 Subject: [OmniOS-discuss] device probe related command timeouts Message-ID: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> Greetings again, I?ve got a SAN that seems to be timing out on any hardware probing commands such as ?format? or ?diskinfo? although prtconf seems to work. Fmadm faulty shows a bad fan in the MD1200 JBOD that is connected and that is all. I?m trying to nail down the root but I?m hitting a brick wall. Prstat, iostat all seem to be showing normal activity on all of the disks. Does anyone happen to have a dtrace one liner or maybe kstat command I can run to see why/what they?re hanging on? We?ve been experiencing some intermittent storage related freezes on the system (ESXi hosts) and I can?t seem to get very to close to the source?wondering if this is related. Have a great day! John Barfield M: +1 (214) 425-0783 O: +1 (214) 506-8354 john.barfield at bissinc.com [cid:image001.png at 01D26696.FD87AAE0] 4925 Greenville Ave, Ste 900 Dallas, TX 75206 For Support Requests: http://support.bissinc.com or support at bissinc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3504 bytes Desc: image001.png URL: From danmcd at omniti.com Wed Jan 4 20:31:28 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 4 Jan 2017 15:31:28 -0500 Subject: [OmniOS-discuss] New SAN deployment HBA recommendations In-Reply-To: <17B21797-734A-4177-88B4-E50F9E3387D9@bissinc.com> References: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com> <17B21797-734A-4177-88B4-E50F9E3387D9@bissinc.com> Message-ID: <8040EC47-1CF4-4001-95B5-1096EDF2CA45@omniti.com> > On Jan 4, 2017, at 3:21 PM, John Barfield wrote: > > I was specifically wondering what is supported in the latest OmniOS release, but I suppose youre suggesting that I could backport an illumos driver from the latest build into ominos? > > OmniOS is the distro I use for SAN deployments. I use SmartOS for hypervisors. Ahh, okay. Everything HBA-wise in illumos-gate is already in OmniOS r151020. I was projecting forward for you, in case you were gauging future HW purchases (and the upcoming OmniOS r151022, which is ALSO our next LTS). Dan From john.barfield at bissinc.com Wed Jan 4 20:35:33 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 20:35:33 +0000 Subject: [OmniOS-discuss] New SAN deployment HBA recommendations In-Reply-To: <8040EC47-1CF4-4001-95B5-1096EDF2CA45@omniti.com> References: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com> <17B21797-734A-4177-88B4-E50F9E3387D9@bissinc.com> <8040EC47-1CF4-4001-95B5-1096EDF2CA45@omniti.com> Message-ID: <69124AF3-2C15-404B-9375-EABD40711401@bissinc.com> We will definitely use the latest omnios after everything is ordered. Are you suggesting that I buy a 9300 series or simply stating that we can move to that series soon in the future? I am looking to start purchasing and building immediately. What is the release timeline for 151022? On 1/4/17, 2:31 PM, "Dan McDonald" wrote: > On Jan 4, 2017, at 3:21 PM, John Barfield wrote: > > I was specifically wondering what is supported in the latest OmniOS release, but I suppose youre suggesting that I could backport an illumos driver from the latest build into ominos? > > OmniOS is the distro I use for SAN deployments. I use SmartOS for hypervisors. Ahh, okay. Everything HBA-wise in illumos-gate is already in OmniOS r151020. I was projecting forward for you, in case you were gauging future HW purchases (and the upcoming OmniOS r151022, which is ALSO our next LTS). Dan From danmcd at omniti.com Wed Jan 4 20:39:58 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 4 Jan 2017 15:39:58 -0500 Subject: [OmniOS-discuss] New SAN deployment HBA recommendations In-Reply-To: <69124AF3-2C15-404B-9375-EABD40711401@bissinc.com> References: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com> <17B21797-734A-4177-88B4-E50F9E3387D9@bissinc.com> <8040EC47-1CF4-4001-95B5-1096EDF2CA45@omniti.com> <69124AF3-2C15-404B-9375-EABD40711401@bissinc.com> Message-ID: > On Jan 4, 2017, at 3:35 PM, John Barfield wrote: > > Are you suggesting that I buy a 9300 series or simply stating that we can move to that series soon in the future? Buy a 9300 now. It's been working for ALL of our supported releases (i.e. 014 and later). > I am looking to start purchasing and building immediately. What is the release timeline for 151022? 022 is being pushed out to Summer due to major upstream changes in illumos (watch this list for a user-visible design-decision I need to make, e.g.). Dan From rjahnel at ellipseinc.com Wed Jan 4 20:47:19 2017 From: rjahnel at ellipseinc.com (Richard Jahnel) Date: Wed, 4 Jan 2017 20:47:19 +0000 Subject: [OmniOS-discuss] upgrading from 151014 Message-ID: <65DC5816D4BEE043885A89FD54E273FC71D388C4@MAIL101.Ellipseinc.com> I'm trying to update some omnios machines I use a fibre targets from 101514 to current one step at a time. In step one just trying to get to 16 I've already gotten stuck. Any ideas on how to get the upgrade to proceed? # cat /etc/release OmniOS v11 r151014 Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. # pkg update Creating Plan (Running solver): - 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/entire at 11,5.11-0.151016:20151202T161203Z pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151016:20160603T025742Z pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151016:20160315T193155Z The following indicates why the system cannot update to the latest version: No suitable version of required package pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z found: Reject: pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151016:20151102T185724Z Reason: A version for 'incorporate' dependency on pkg:/system/data/zoneinfo at 2015.7,5.11-0.151016 cannot be found No suitable version of required package pkg://omnios/network/openssh-server at 7.1.1,5.11-0.151016:20151102T190719Z found: Reject: pkg://omnios/network/openssh-server at 7.1.1,5.11-0.151016:20151102T190719Z Reason: Package contains 'exclude' dependency pkg:/service/network/ssh on installed package and much much more along the above lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at sysmgr.org Wed Jan 4 20:52:07 2017 From: josh at sysmgr.org (Joshua M. Clulow) Date: Wed, 4 Jan 2017 12:52:07 -0800 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> Message-ID: On 4 January 2017 at 12:29, John Barfield wrote: > I?ve got a SAN that seems to be timing out on any hardware probing commands such as ?format? or ?diskinfo? although prtconf seems to work. > > Does anyone happen to have a dtrace one liner or maybe kstat command I can run to see why/what they?re hanging on? I would start by running "pstack" with the pid of one of the stuck processes. That will give you the part of the user program which is stuck. Then, I would get the in-kernel state of the stuck threads; e.g., looking at my bash process: asgard # echo $$ 45435 asgard # ps -fp 45435 UID PID PPID C STIME TTY TIME CMD root 45435 45433 0 20:47:17 pts/3 0:00 -bash asgard # mdb -k Loading modules: [ unix genunix specfs ... ] > 0t45435::pid2proc | ::ps -f S PID PPID PGID SID UID FLAGS ADDR NAME R 45435 45433 45435 45435 0 0x4a014000 ffffff1b14d33048 -bash > 0t45435::pid2proc | ::walk thread | ::findstack -v stack pointer for thread ffffff03f776c080: ffffff0011b57c10 [ ffffff0011b57c10 _resume_from_idle+0x112() ] ffffff0011b57c40 swtch+0x141() ffffff0011b57cd0 cv_wait_sig_swap_core+0x1b9(ffffff1b14d33108, ...) ffffff0011b57cf0 cv_wait_sig_swap+0x17(ffffff1b14d33108, ...) ffffff0011b57da0 waitid+0x315(7, 0, ffffff0011b57e30, f) ffffff0011b57eb0 waitsys32+0x36(7, 0, 8047750, f) ffffff0011b57f10 sys_syscall32+0x123() That might tell us where in the storage subsystem you're getting stuck. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From danmcd at omniti.com Wed Jan 4 20:56:17 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 4 Jan 2017 15:56:17 -0500 Subject: [OmniOS-discuss] upgrading from 151014 In-Reply-To: <65DC5816D4BEE043885A89FD54E273FC71D388C4@MAIL101.Ellipseinc.com> References: <65DC5816D4BEE043885A89FD54E273FC71D388C4@MAIL101.Ellipseinc.com> Message-ID: Start with 014, get rid of SunSSH, and you should be able to Just Upgrade: https://omnios.omniti.com/wiki.php/Upgrade_to_r151020 (Note the get-rid-of-SunSSH before actually upgrading part.) Dan From john.barfield at bissinc.com Wed Jan 4 20:57:59 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 20:57:59 +0000 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> Message-ID: <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> Hi Joshua, As requested: root at PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 18919 18919: sudo diskinfo fee8e665 pollsys (8047b50, 2, 0, 0) fee264af pselect (6, 8089c30, 8089c50, fef06320, 0, 0) + 1bf fee267b8 select (6, 8089c30, 8089c50, 0, 0, 0) + 8e 08055f64 sudo_execute (807c960, 8047ce8, 41e, c0) + 4ba 080606f8 run_command (807c960, 807c9c0, 8047d88, 805dff9) + 4c 0805e03f main (8047d7c, fef076a8, 8047db4, 8054cc3, 2, 8047dc0) + 681 08054cc3 _start (2, 8047e7c, 8047e81, 0, 8047e8a, 8047e95) + 83 root at PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs sata sd ip hook neti sockfs arp usba uhci stmf stmf_sbd md lofs mpt_sas random idm ipc nfs ptm crypto cpc kvm ufs logindmux nsmb smbsrv ] > 0t18919::pid2proc | ::ps -f S PID PPID PGID SID UID FLAGS ADDR NAME R 18919 18022 18919 18022 0 0x5a016000 ffffff24c389d000 sudo diskinfo > 0t18919::pid2proc | ::walk thread | ::findstack -v stack pointer for thread ffffff24c5bf4500: ffffff010a032c50 [ ffffff010a032c50 _resume_from_idle+0xf4() ] ffffff010a032c80 swtch+0x141() ffffff010a032d10 cv_wait_sig_swap_core+0x1b9(ffffff26a30f47fa, ffffff26a30f47c0, 0) ffffff010a032d30 cv_wait_sig_swap+0x17(ffffff26a30f47fa, ffffff26a30f47c0) ffffff010a032d60 cv_timedwait_sig_hrtime+0x35(ffffff26a30f47fa, ffffff26a30f47c0, ffffffffffffffff) ffffff010a032e20 poll_common+0x554(8047b50, 2, 0, 0) ffffff010a032ec0 pollsys+0xe7(8047b50, 2, 0, 0) ffffff010a032f10 _sys_sysenter_post_swapgs+0x149() > On 1/4/17, 2:52 PM, "Joshua M. Clulow" wrote: On 4 January 2017 at 12:29, John Barfield wrote: > I?ve got a SAN that seems to be timing out on any hardware probing commands such as ?format? or ?diskinfo? although prtconf seems to work. > > Does anyone happen to have a dtrace one liner or maybe kstat command I can run to see why/what they?re hanging on? I would start by running "pstack" with the pid of one of the stuck processes. That will give you the part of the user program which is stuck. Then, I would get the in-kernel state of the stuck threads; e.g., looking at my bash process: asgard # echo $$ 45435 asgard # ps -fp 45435 UID PID PPID C STIME TTY TIME CMD root 45435 45433 0 20:47:17 pts/3 0:00 -bash asgard # mdb -k Loading modules: [ unix genunix specfs ... ] > 0t45435::pid2proc | ::ps -f S PID PPID PGID SID UID FLAGS ADDR NAME R 45435 45433 45435 45435 0 0x4a014000 ffffff1b14d33048 -bash > 0t45435::pid2proc | ::walk thread | ::findstack -v stack pointer for thread ffffff03f776c080: ffffff0011b57c10 [ ffffff0011b57c10 _resume_from_idle+0x112() ] ffffff0011b57c40 swtch+0x141() ffffff0011b57cd0 cv_wait_sig_swap_core+0x1b9(ffffff1b14d33108, ...) ffffff0011b57cf0 cv_wait_sig_swap+0x17(ffffff1b14d33108, ...) ffffff0011b57da0 waitid+0x315(7, 0, ffffff0011b57e30, f) ffffff0011b57eb0 waitsys32+0x36(7, 0, 8047750, f) ffffff0011b57f10 sys_syscall32+0x123() That might tell us where in the storage subsystem you're getting stuck. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From josh at sysmgr.org Wed Jan 4 21:05:53 2017 From: josh at sysmgr.org (Joshua M. Clulow) Date: Wed, 4 Jan 2017 13:05:53 -0800 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> Message-ID: On 4 January 2017 at 12:57, John Barfield wrote: > root at PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 18919 > 18919: sudo diskinfo > fee8e665 pollsys (8047b50, 2, 0, 0) > fee264af pselect (6, 8089c30, 8089c50, fef06320, 0, 0) + 1bf > fee267b8 select (6, 8089c30, 8089c50, 0, 0, 0) + 8e > 08055f64 sudo_execute (807c960, 8047ce8, 41e, c0) + 4ba > 080606f8 run_command (807c960, 807c9c0, 8047d88, 805dff9) + 4c > 0805e03f main (8047d7c, fef076a8, 8047db4, 8054cc3, 2, 8047dc0) + 681 > 08054cc3 _start (2, 8047e7c, 8047e81, 0, 8047e8a, 8047e95) + 83 I think you've grabbed the "sudo" process, rather than the child "diskinfo" process. If you use "ptree" on the pid first, you'll be able to see the full tree of processes. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From john.barfield at bissinc.com Wed Jan 4 21:09:58 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 21:09:58 +0000 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> Message-ID: It actually finally completed. Doing it again with the proper PID as suggested provides the following: root at PRD-GIP-cpls-san1:/export/home/jbarfield# ps aux | grep diskinfo root 19448 0.0 0.0 7024 3820 pts/1 S 15:10:12 0:00 diskinfo root 19452 0.0 0.0 2252 1292 pts/2 S 15:10:16 0:00 grep diskinfo root at PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 19448 19448: diskinfo ----------------- lwp# 1 -------------------------------- ----------------- lwp# 2 -------------------------------- fee1f46e door (0, 0, 0, fe75ee00, f5f00, a) fee05dd8 door_create_func (0, 0, 0, 0) + 4a fee19d6b _thrp_setup (fe650240) + 88 fee19f00 _lwp_start (fe650240, 0, 0, 0, 0, 0) ----------------- lwp# 3 -------------------------------- fee19f59 lwp_park (0, 0, 0) fee13f98 cond_wait_queue (813e560, 813e570, 0, 0, 0, 3) + 6a fee14610 __cond_wait (813e560, 813e570, 0, 8147c88, fe9f8000, 0) + 8f fee14664 cond_wait (813e560, 813e570, 0, fe9e49b9) + 2e fe9e49fc subscriber_event_handler (8147c88, 0, 0, 0) + 51 fee19d6b _thrp_setup (fe650a40) + 88 fee19f00 _lwp_start (fe650a40, 0, 0, 0, 0, 0) root at PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs sata sd ip hook neti sockfs arp usba uhci stmf stmf_sbd md lofs mpt_sas random idm ipc nfs ptm crypto cpc kvm ufs logindmux nsmb smbsrv ] > ::0t19448::pid2proc | ::walk thread | ::findstack -v mdb: syntax error near ":" > 0t19448::pid2proc | ::walk thread | ::findstack -v stack pointer for thread ffffff2490590000: ffffff010a286750 [ ffffff010a286750 _resume_from_idle+0xf4() ] ffffff010a286780 swtch+0x141() ffffff010a2867c0 sema_p+0x1c7(ffffff26e094b600) ffffff010a286800 biowait+0xa4(ffffff26e094b540) ffffff010a2868d0 scsi_uscsi_handle_cmd+0x127(c100000d40, 1, ffffff24907f3da8, fffffffff7b159b0, 0, ffffff27c23171e8) ffffff010a286960 sd_ssc_send+0x136(ffffff24227d4e00, ffffff010a286970, 80000000, 1, 0) ffffff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ffffff24227d4e00, 1) ffffff010a286b40 sd_get_media_info_com+0xaf(c100000d40, ffffff010a286b50, ffffff010a286b54, ffffff010a286b58, 0) ffffff010a286ba0 sd_get_media_info+0x41(c100000d40, 8047330, 100005) ffffff010a286c80 sdioctl+0xc57(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) ffffff010a286cc0 cdev_ioctl+0x39(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) ffffff010a286d10 spec_ioctl+0x60(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) ffffff010a286da0 fop_ioctl+0x55(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) ffffff010a286ec0 ioctl+0x9b(3, 42a, 8047330) ffffff010a286f10 _sys_sysenter_post_swapgs+0x149() stack pointer for thread ffffff24907e6060: ffffff0107e53d50 [ ffffff0107e53d50 _resume_from_idle+0xf4() ] ffffff0107e53d80 swtch+0x141() ffffff0107e53db0 shuttle_swtch+0x203(fffffffffbd11090) ffffff0107e53e50 door_return+0x214(0, 0, 0, 0, fe75ee00, f5f00) ffffff0107e53ec0 doorfs32+0x180(0, 0, 0, fe75ee00, f5f00, a) ffffff0107e53f10 _sys_sysenter_post_swapgs+0x149() stack pointer for thread ffffff249198c020: ffffff010a032c50 [ ffffff010a032c50 _resume_from_idle+0xf4() ] ffffff010a032c80 swtch+0x141() ffffff010a032d10 cv_wait_sig_swap_core+0x1b9(ffffff249198c20e, ffffff249198c210, 0) ffffff010a032d30 cv_wait_sig_swap+0x17(ffffff249198c20e, ffffff249198c210) ffffff010a032dc0 cv_waituntil_sig+0xbd(ffffff249198c20e, ffffff249198c210, 0, 0) ffffff010a032e70 lwp_park+0x15e(0, 0) ffffff010a032ec0 syslwp_park+0x63(0, 0, 0) ffffff010a032f10 _sys_sysenter_post_swapgs+0x149() > 0t19448::pid2proc | ::walk thread | ::ps -f S PID PPID PGID SID UID FLAGS ADDR NAME S 0 0 0 283935560 0 0xffffff01 ffffff2490590000 S 0 0 0 283935560 0 0xffffff01 ffffff24907e6060 S 0 0 0 283935560 0 0xffffff01 ffffff249198c020 > On 1/4/17, 3:05 PM, "Joshua M. Clulow" wrote: On 4 January 2017 at 12:57, John Barfield wrote: > root at PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 18919 > 18919: sudo diskinfo > fee8e665 pollsys (8047b50, 2, 0, 0) > fee264af pselect (6, 8089c30, 8089c50, fef06320, 0, 0) + 1bf > fee267b8 select (6, 8089c30, 8089c50, 0, 0, 0) + 8e > 08055f64 sudo_execute (807c960, 8047ce8, 41e, c0) + 4ba > 080606f8 run_command (807c960, 807c9c0, 8047d88, 805dff9) + 4c > 0805e03f main (8047d7c, fef076a8, 8047db4, 8054cc3, 2, 8047dc0) + 681 > 08054cc3 _start (2, 8047e7c, 8047e81, 0, 8047e8a, 8047e95) + 83 I think you've grabbed the "sudo" process, rather than the child "diskinfo" process. If you use "ptree" on the pid first, you'll be able to see the full tree of processes. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From richard.elling at richardelling.com Wed Jan 4 21:13:18 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Wed, 4 Jan 2017 13:13:18 -0800 Subject: [OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them In-Reply-To: <8FA836CB-143C-4422-BF34-E2B657B8C251@richardelling.com> References: <20170104180425.8DAE05A1098@apps1.cs.toronto.edu> <8FA836CB-143C-4422-BF34-E2B657B8C251@richardelling.com> Message-ID: <49B9D756-889C-4C47-BB61-C73F39D52454@richardelling.com> one more thing? > On Jan 4, 2017, at 10:29 AM, Richard Elling wrote: > >> >> On Jan 4, 2017, at 10:04 AM, Chris Siebenmann wrote: >> >> We recently had a server reboot due to the ZFS vdev_deadman/spa_deadman >> timeout timer activating and panicing the system. If you haven't heard >> of this timer before, that's not surprising; triggering it requires an >> IO to a vdev to take more than 1000 seconds (by default; it's controlled >> by the value of zfs_deadman_synctime_ms, in spa_misc.c). >> >> Before this happened, I would not have expected that our OmniOS system >> allowed an IO to run that long before timing it out and returning an >> error to ZFS. Clearly I'm wrong, which means that I'd like to understand >> what disk IO timeouts OmniOS has and where (or if) we can control them >> so that really long IOs get turned into forced errors well before 16 >> minutes go by. Unfortunately our disk topology is a bit complicated; >> we have scsi_vhci multipathing on top of iSCSI disks. > > Do not assume the timeout reflects properly operating software or firmware. > The original impetus for the deadman was to allow debugging of the underlying > stack. Prior to adding the deadman, the I/O could be stuck forever. > >> >> In some Internet searching I've found sd_io_time (60 seconds by >> default) and the default SD retry count of 5 (I think, it may be >> 3), which can be adjusted on a per-disk-type basis through the >> retries-timeout parameter (per the sd manpage). Searching the kernel >> code suggests that there are some hard-coded timeouts in the 30 to 90 >> second range, which also doesn't seem excessive. > > For sd-level, most commands follow the sd_io_time and retries. scsi_vhci adds > significant complexity above sd and below zfs. > ? richard > >> >> (I have a crash dump from this panic, so I can in theory use mdb >> to look through it to see just what level an IO appears stuck at >> if I know what to look for and how.) >> >> Based on 'fmdump -eV' output, it looks like our server was >> retrying IO repeatedly. >> >> Does anyone know what I should be looking at to find and adjust >> timeouts, retry counts, and so on? Is there any documentation that >> I'm overlooking? I find the "zio_state" mdb macro helpful in these cases. It shows all of the I/Os in the zio pipeline and the timeout values relative to the deadman. ? richard >> >> Thanks in advance. >> >> - cks >> PS: some links I've dug up in searches: >> http://everycity.co.uk/alasdair/2011/05/adjusting-drive-timeouts-with-mdb-on-solaris-or-openindiana/ >> https://smartos.org/bugview/OS-2415 >> https://www.illumos.org/issues/1553 >> _______________________________________________ >> 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 josh at sysmgr.org Wed Jan 4 21:15:11 2017 From: josh at sysmgr.org (Joshua M. Clulow) Date: Wed, 4 Jan 2017 13:15:11 -0800 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> Message-ID: On 4 January 2017 at 13:09, John Barfield wrote: > It actually finally completed. Doing it again with the proper PID as suggested provides the following: > root at PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k >> 0t19448::pid2proc | ::walk thread | ::findstack -v > stack pointer for thread ffffff2490590000: ffffff010a286750 > [ ffffff010a286750 _resume_from_idle+0xf4() ] > ffffff010a286780 swtch+0x141() > ffffff010a2867c0 sema_p+0x1c7(ffffff26e094b600) > ffffff010a286800 biowait+0xa4(ffffff26e094b540) > ffffff010a2868d0 scsi_uscsi_handle_cmd+0x127(c100000d40, 1, ffffff24907f3da8, fffffffff7b159b0, 0, ffffff27c23171e8) > ffffff010a286960 sd_ssc_send+0x136(ffffff24227d4e00, ffffff010a286970, 80000000, 1, 0) > ffffff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ffffff24227d4e00, 1) > ffffff010a286b40 sd_get_media_info_com+0xaf(c100000d40, ffffff010a286b50, ffffff010a286b54, ffffff010a286b58, 0) > ffffff010a286ba0 sd_get_media_info+0x41(c100000d40, 8047330, 100005) > ffffff010a286c80 sdioctl+0xc57(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286cc0 cdev_ioctl+0x39(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286d10 spec_ioctl+0x60(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286da0 fop_ioctl+0x55(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286ec0 ioctl+0x9b(3, 42a, 8047330) > ffffff010a286f10 _sys_sysenter_post_swapgs+0x149() OK, it seems that we're hanging while sending a TEST UNIT READY to some device. It's probably easiest to just use truss(1), here; e.g.: truss -t "open,ioctl" -f diskinfo Once it starts hanging, you should be able to see which open(2) and ioctl(2) calls happened just before the hang. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From john.barfield at bissinc.com Wed Jan 4 21:17:55 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 21:17:55 +0000 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> Message-ID: You?re awesome! Its hanging on ?open /dev/rdsk/c14t0d0s0? Looking at that disk now. On 1/4/17, 3:15 PM, "Joshua M. Clulow" wrote: On 4 January 2017 at 13:09, John Barfield wrote: > It actually finally completed. Doing it again with the proper PID as suggested provides the following: > root at PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k >> 0t19448::pid2proc | ::walk thread | ::findstack -v > stack pointer for thread ffffff2490590000: ffffff010a286750 > [ ffffff010a286750 _resume_from_idle+0xf4() ] > ffffff010a286780 swtch+0x141() > ffffff010a2867c0 sema_p+0x1c7(ffffff26e094b600) > ffffff010a286800 biowait+0xa4(ffffff26e094b540) > ffffff010a2868d0 scsi_uscsi_handle_cmd+0x127(c100000d40, 1, ffffff24907f3da8, fffffffff7b159b0, 0, ffffff27c23171e8) > ffffff010a286960 sd_ssc_send+0x136(ffffff24227d4e00, ffffff010a286970, 80000000, 1, 0) > ffffff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ffffff24227d4e00, 1) > ffffff010a286b40 sd_get_media_info_com+0xaf(c100000d40, ffffff010a286b50, ffffff010a286b54, ffffff010a286b58, 0) > ffffff010a286ba0 sd_get_media_info+0x41(c100000d40, 8047330, 100005) > ffffff010a286c80 sdioctl+0xc57(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286cc0 cdev_ioctl+0x39(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286d10 spec_ioctl+0x60(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286da0 fop_ioctl+0x55(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286ec0 ioctl+0x9b(3, 42a, 8047330) > ffffff010a286f10 _sys_sysenter_post_swapgs+0x149() OK, it seems that we're hanging while sending a TEST UNIT READY to some device. It's probably easiest to just use truss(1), here; e.g.: truss -t "open,ioctl" -f diskinfo Once it starts hanging, you should be able to see which open(2) and ioctl(2) calls happened just before the hang. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From mir at miras.org Wed Jan 4 21:21:02 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 4 Jan 2017 22:21:02 +0100 Subject: [OmniOS-discuss] upgrading from 151014 In-Reply-To: References: <65DC5816D4BEE043885A89FD54E273FC71D388C4@MAIL101.Ellipseinc.com> Message-ID: <20170104222102.17086412@sleipner.datanom.net> On Wed, 4 Jan 2017 15:56:17 -0500 Dan McDonald wrote: > > (Note the get-rid-of-SunSSH before actually upgrading part.) > I guess this will be a prerequisite doing 151014 -> 151022 anyway? -- 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: When women kiss it always reminds one of prize fighters shaking hands. -- H. L. Mencken, "Sententiae" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From john.barfield at bissinc.com Wed Jan 4 21:34:50 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 21:34:50 +0000 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> Message-ID: <4EDEC2CB-8F16-4FEE-89CA-F1F9F54C8E54@bissinc.com> For the record?here is the complete command output after it finally completed: root at PRD-GIP-cpls-san1:/export/home/jbarfield# truss -t "open,ioctl" -f diskinfo 19752: open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT 19752: open("/lib/libdladm.so.1", O_RDONLY) = 3 19752: open("/usr/lib/libdiskmgt.so.1", O_RDONLY) = 3 19752: open("/lib/libnvpair.so.1", O_RDONLY) = 3 19752: open("/usr/lib/fm/libtopo.so.1", O_RDONLY) = 3 19752: open("/lib/libc.so.1", O_RDONLY) = 3 19752: open("/lib/libumem.so.1", O_RDONLY) = 3 19752: open("/lib/libcurses.so.1", O_RDONLY) = 3 19752: open("/lib/libnsl.so.1", O_RDONLY) = 3 19752: open("/usr/lib/libxml2.so.2", O_RDONLY) = 3 19752: open("/lib/libpthread.so.1", O_RDONLY) = 3 19752: open("/usr/lib/libz.so", O_RDONLY) = 3 19752: open("/usr/lib/liblzma.so.5", O_RDONLY) = 3 19752: open("/lib/libm.so.2", O_RDONLY) = 3 19752: open("/lib/libsocket.so.1", O_RDONLY) = 3 19752: open("/lib/libmd.so.1", O_RDONLY) = 3 19752: ioctl(1, TCGETA, 0x08047C2E) = 0 TYPE DISK VID PID SIZE RMV SSD 19752: open("/lib/libdevinfo.so.1", O_RDONLY) = 3 19752: open("/etc/dev/.devlink_db", O_RDONLY) = 3 19752: open("/devices/pseudo/devinfo at 0:devinfo", O_RDONLY) = 4 19752: ioctl(4, DINFOIDENT, 0x00000000) = 57311 19752: ioctl(4, 0x10DF00, 0x0804730C) = 515519 19752: ioctl(4, DINFOUSRLD, 0x080B1000) = 516096 19752: open("/dev/openprom", O_RDONLY) = 4 19752: open("/lib/libdevid.so.1", O_RDONLY) = 5 19752: open("/devices/pseudo/devinfo at 0:devinfo", O_RDONLY) = 5 19752: ioctl(5, DINFOIDENT, 0x00000000) = 57311 19752: ioctl(5, 0xDF0F, 0x0804730C) = 515519 19752: ioctl(5, DINFOUSRLD, 0x080B1000) = 516096 19752: open("/devices/pseudo/devinfo at 0:devinfo", O_RDONLY) = 5 19752: ioctl(5, DINFOIDENT, 0x00000000) = 57311 19752: ioctl(5, 0x10DF00, 0x0804730C) = 515519 19752: ioctl(5, DINFOUSRLD, 0x080B1000) = 516096 19752: open("/lib/libsysevent.so.1", O_RDONLY) = 3 19752: open("/etc/mnttab", O_RDONLY) = 3 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4) = 0 19752: open("/var/run/sysevent_channels/syseventd_channel/24", O_RDWR|O_CREAT, 0600) = 3 19752/1: ioctl(4, I_CANPUT, 0x00000000) Err#89 ENOSYS 19752/1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 3 19752/1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 3 19752/1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 3 19752/1: open("/dev/rdsk/c14t0d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x08047340) Err#5 EIO 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x08047340) Err#5 EIO 19752/1: open("/dev/rdsk/c18t5000C50041439FE7d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C500565DDAFBd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004143DC0Fd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004164150Fd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C500414406BFd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5005646520Bd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C50041450EEBd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C500565B32ABd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004143DD4Fd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C500414455BBd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C500414472C7d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004145F803d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004144F613d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C500414486E7d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004143919Bd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004143ADEFd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004145FE2Bd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004142AE9Fd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004144856Fd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004144A257d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004145BEDFd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004144A3B7d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004144A693d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c18t5000C5004143BC6Bd0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c25t0d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c26t0d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c27t0d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/rdsk/c28t0d0s0", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/dev/zvol/rdsk/spool/GZ/dump", O_RDONLY|O_NDELAY) = 3 19752/1: ioctl(3, DKIOCGMEDIAINFO, 0x080477F0) = 0 19752/1: open("/usr/lib/libsmbios.so.1", O_RDONLY) = 3 19752/1: open64("/dev/smbios", O_RDONLY) = 3 19752/1: open("/etc/smbios_product", O_RDONLY) Err#2 ENOENT 19752/1: open("/lib/libkstat.so.1", O_RDONLY) = 3 19752/1: open("/dev/kstat", O_RDONLY) = 3 19752/1: ioctl(3, KSTAT_IOC_CHAIN_ID, 0x00000000) = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "kstat_headers") Err#12 ENOMEM 19752/1: ioctl(3, KSTAT_IOC_READ, "kstat_headers") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info0") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info1") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info2") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info3") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info4") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info5") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info6") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info7") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info8") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info9") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info10") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info11") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info12") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info13") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info14") = 9229 19752/1: ioctl(3, KSTAT_IOC_READ, "cpu_info15") = 9229 19752/1: open("/lib/libscf.so.1", O_RDONLY) = 5 19752/1: open("/lib/libuutil.so.1", O_RDONLY) = 5 19752/1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 5 19752/1: open("/lib/libzfs.so.1", O_RDONLY) = 5 19752/1: open("/usr/lib//libshare.so.1", O_RDONLY) = 5 19752/1: open("/dev/zfs", O_RDWR) = 5 19752/1: open("/etc/mnttab", O_RDONLY) = 7 19752/1: open("/etc/dfs/sharetab", O_RDONLY) = 8 19752/1: open("/lib/libzfs_core.so.1", O_RDONLY) = 9 19752/1: open("/dev/zfs", O_RDWR) = 9 19752/1: open("/lib/libavl.so.1", O_RDONLY) = 10 19752/1: open("/lib/libuuid.so.1", O_RDONLY) = 10 19752/1: open("/devices/pseudo/devinfo at 0:devinfo", O_RDONLY) = 10 19752/1: ioctl(10, DINFOIDENT, 0x00000000) = 57311 19752/1: ioctl(10, 0x10DF00, 0x080473BC) = 515519 19752/1: ioctl(10, DINFOUSRLD, 0x080B1000) = 516096 19752/1: open("/dev/openprom", O_RDONLY) = 10 19752/1: open("//usr/platform/i86pc/lib/fm/topo/maps/i86pc-hc-topology.xml", O_RDONLY) = 11 19752/1: open("//usr/platform/i86pc/lib/fm/topo/plugins/x86pi.so", O_RDONLY) = 11 19752/1: open("/lib/libelf.so.1", O_RDONLY) = 11 19752/1: open("/usr/lib/libipmi.so.1", O_RDONLY) = 11 19752/1: open("/lib/libgen.so.1", O_RDONLY) = 11 19752/1: open("/usr/lib/libidmap.so.1", O_RDONLY) = 11 19752/1: open("/lib/libtsol.so.2", O_RDONLY) = 11 19752/1: open("/lib/libsecdb.so.1", O_RDONLY) = 11 19752/1: open("/lib/libadm.so.1", O_RDONLY) = 11 19752/1: open("/lib/libefi.so.1", O_RDONLY) = 11 19752/1: open("/lib/libdlpi.so.1", O_RDONLY) = 11 19752/1: open("/lib/libinetutil.so.1", O_RDONLY) = 11 19752/1: open("/lib/libsec.so.1", O_RDONLY) = 11 19752/1: open("/lib/libmp.so.2", O_RDONLY) = 11 19752/1: open("/usr/lib/libpool.so.1", O_RDONLY) = 11 19752/1: open("/usr/lib/libexacct.so.1", O_RDONLY) = 11 19752/1: open("/lib/librcm.so.1", O_RDONLY) = 11 19752/1: open64("/dev/smbios", O_RDONLY) = 11 19752/1: open("/dev/fm", O_RDONLY) = 11 19752/1: ioctl(11, 0xFA0009, 0x080473E4) = 0 19752/1: open("//usr/platform/i86pc/lib/fm/topo/maps/i86pc-legacy-hc-topology.xml", O_RDONLY) = 11 19752/1: open("//usr/platform/i86pc/lib/fm/topo/plugins/chip.so", O_RDONLY) = 11 19752/1: open("/usr/lib/fm/libfmd_agent.so.1", O_RDONLY) = 11 19752/1: open("/dev/mc/mc", O_RDONLY) Err#2 ENOENT 19752/1: open("/dev/fm", O_RDONLY) = 11 19752/1: ioctl(11, 0xFA0001, 0x0804694C) = 0 19752/1: ioctl(11, 0xFA0005, 0x0804693C) = 0 19752/1: open("/dev/mc/mc0", O_RDONLY) = 11 19752/1: ioctl(11, _IORN(0x0, 1, 67), 0x080468F8) = 0 19752/1: ioctl(11, _IORN(0x0, 2, 67), 0x0829E000) = 0 19752/1: open("/dev/mc/mc1", O_RDONLY) = 11 19752/1: ioctl(11, _IORN(0x0, 1, 67), 0x080468F8) = 0 19752/1: ioctl(11, _IORN(0x0, 2, 67), 0x082F1000) = 0 19752/1: open("//usr/platform/i86pc/lib/fm/topo/maps/chip-hc-topology.xml", O_RDONLY) = 11 19752/1: open("//usr/platform/i86pc/lib/fm/topo/plugins/hostbridge.so", O_RDONLY) = 11 19752/1: open("//usr/platform/i86pc/lib/fm/topo/plugins/pcibus.so", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/igb/object", O_RDONLY) = 11 19752/1: open("/system/object/igb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/igb/object", O_RDONLY) = 11 19752/1: open("/system/object/igb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/ixgbe/object", O_RDONLY) = 11 19752/1: open("/system/object/ixgbe/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/aac/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/ahci/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/ahci/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/ahci/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/ahci/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/mpt_sas/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/pcieb/object", O_RDONLY) = 11 19752/1: open("/system/object/mpt_sas/object", O_RDONLY) = 11 19752/1: open("/system/object/pci_pci/object", O_RDONLY) = 11 19752/1: open("/system/object/pci_pci/object", O_RDONLY) = 11 19752/1: open("/system/object/pci_pci/object", O_RDONLY) = 11 19752/1: open("/system/object/vgatext/object", O_RDONLY) = 11 19752/1: open("//usr/platform/i86pc/lib/fm/topo/maps/chassis-hc-topology.xml", O_RDONLY) = 11 19752/1: open("//usr/lib/fm/topo/plugins/ipmi.so", O_RDONLY) = 11 19752/1: open("/dev/ipmi0", O_RDWR) Err#2 ENOENT 19752/1: open("/dev/ipmi0", O_RDWR) Err#2 ENOENT 19752/1: open("//usr/lib/fm/topo/plugins/ses.so", O_RDONLY) = 11 19752/1: open("/usr/lib/scsi/libses.so.1", O_RDONLY) = 11 19752/1: open("/usr/lib/scsi/libscsi.so.1", O_RDONLY) = 11 19752/1: open("/lib/libcontract.so.1", O_RDONLY) = 11 19752/1: open("/usr/lib/fm/libdiskstatus.so.1", O_RDONLY) = 11 19752/1: open("/etc/dev/.devlink_db", O_RDONLY) = 11 19752/5: open64("/system/contract/device/pbundle", O_RDONLY) = 12 19752/1: open("/dev/es", O_RDONLY|O_NDELAY|O_LARGEFILE) = 11 19752/1: open("/usr/lib/scsi/plugins/scsi/engines//uscsi.so", O_RDONLY) = 13 19752/1: open("/dev/es/ses0", O_RDONLY) Err#2 ENOENT 19752/1: open("/usr/lib/scsi/plugins/scsi/engines//uscsi.so", O_RDONLY) = 13 19752/1: open("/dev/es/ses1", O_RDONLY) Err#2 ENOENT 19752/1: open("/usr/lib/scsi/plugins/scsi/engines//uscsi.so", O_RDONLY) = 13 19752/1: open("/dev/es/ses2", O_RDONLY) = 13 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: open("/usr/lib/scsi/plugins/ses/framework", O_RDONLY|O_NDELAY|O_LARGEFILE) = 14 19752/1: open("/usr/lib/scsi/plugins/ses/framework//ses2.so", O_RDONLY) = 15 19752/1: open("/usr/lib/scsi/plugins/ses/framework//libses.so", O_RDONLY) = 15 19752/1: ioctl(13, USCSICMD, 0x080467CC) = 0 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(13, USCSICMD, 0x0804681C) = 0 19752/1: open64("/system/contract/device/template", O_RDWR) = 14 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046554) = 0 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046574) = 0 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046554) = 0 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|2), 0x080465AD) = 565 19752/1: open("/dev/es/ses3", O_RDONLY) = 14 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: open("/usr/lib/scsi/plugins/ses/framework", O_RDONLY|O_NDELAY|O_LARGEFILE) = 15 19752/1: ioctl(14, USCSICMD, 0x080467CC) = 0 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: ioctl(14, USCSICMD, 0x0804681C) = 0 19752/1: open64("/system/contract/device/template", O_RDWR) = 15 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046554) = 0 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046574) = 0 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046554) = 0 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|2), 0x080465AD) = 566 19752/1: open("/dev/scsi/ses", O_RDONLY|O_NDELAY|O_LARGEFILE) Err#2 ENOENT 19752/1: open64("/system/contract/device/565/ctl", O_WRONLY) = 11 19752/1: ioctl(11, (('c'<<24)|('t'<<16)|('c'<<8)|0), 0x08046DB8) = 0 19752/1: open64("/system/contract/device/566/ctl", O_WRONLY) = 11 19752/1: ioctl(11, (('c'<<24)|('t'<<16)|('c'<<8)|0), 0x08046DB8) = 0 19752/1: open("/etc/dev/.devlink_db", O_RDONLY) = 11 19752/1: open("/dev/es", O_RDONLY|O_NDELAY|O_LARGEFILE) = 11 19752/1: open("/usr/lib/scsi/plugins/scsi/engines//uscsi.so", O_RDONLY) = 13 19752/1: open("/dev/es/ses0", O_RDONLY) Err#2 ENOENT 19752/1: open("/usr/lib/scsi/plugins/scsi/engines//uscsi.so", O_RDONLY) = 13 19752/1: open("/dev/es/ses1", O_RDONLY) Err#2 ENOENT 19752/1: open("/usr/lib/scsi/plugins/scsi/engines//uscsi.so", O_RDONLY) = 13 19752/1: open("/dev/es/ses2", O_RDONLY) = 13 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: open("/usr/lib/scsi/plugins/ses/framework", O_RDONLY|O_NDELAY|O_LARGEFILE) = 14 19752/1: open("/usr/lib/scsi/plugins/ses/framework//ses2.so", O_RDONLY) = 15 19752/1: open("/usr/lib/scsi/plugins/ses/framework//libses.so", O_RDONLY) = 15 19752/1: ioctl(13, USCSICMD, 0x08046E3C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046E8C) = 0 19752/1: open64("/system/contract/device/template", O_RDWR) = 14 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046BC4) = 0 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046BE4) = 0 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046BC4) = 0 19752/1: ioctl(14, (('c'<<24)|('t'<<16)|('t'<<8)|2), 0x08046C1D) = 567 19752/1: open("/dev/es/ses3", O_RDONLY) = 14 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: open("/usr/lib/scsi/plugins/ses/framework", O_RDONLY|O_NDELAY|O_LARGEFILE) = 15 19752/1: ioctl(14, USCSICMD, 0x08046E3C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046E8C) = 0 19752/1: open64("/system/contract/device/template", O_RDWR) = 15 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046BC4) = 0 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046BE4) = 0 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|3), 0x08046BC4) = 0 19752/1: ioctl(15, (('c'<<24)|('t'<<16)|('t'<<8)|2), 0x08046C1D) = 568 19752/1: open("/dev/scsi/ses", O_RDONLY|O_NDELAY|O_LARGEFILE) Err#2 ENOENT 19752/1: open("/dev/rdsk/c18t5000C50041439FE7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C50041439FE7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C50041439FE7d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C500565DDAFBd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C500565DDAFBd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C500565DDAFBd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004143DC0Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004143DC0Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004143DC0Fd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004164150Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004164150Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004164150Fd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C500414406BFd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C500414406BFd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C500414406BFd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5005646520Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5005646520Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5005646520Bd0 SEAGATE ST3000NM0023 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C50041450EEBd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C50041450EEBd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C50041450EEBd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C500565B32ABd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C500565B32ABd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C500565B32ABd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004143DD4Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004143DD4Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004143DD4Fd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C500414455BBd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C500414455BBd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046EBC) = 0 19752/1: ioctl(13, USCSICMD, 0x08046F0C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046F0C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046F0C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046F0C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046F0C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046F0C) = 0 19752/1: ioctl(13, USCSICMD, 0x08046F0C) = 0 SCSI c18t5000C500414455BBd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C500414472C7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C500414472C7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C500414472C7d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004145F803d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004145F803d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004145F803d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004144F613d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004144F613d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046D6C) = 0 19752/1: ioctl(14, USCSICMD, 0x08046DBC) = 0 19752/1: ioctl(14, USCSICMD, 0x08046DBC) = 0 19752/1: ioctl(14, USCSICMD, 0x08046DBC) = 0 19752/1: ioctl(14, USCSICMD, 0x08046DBC) = 0 19752/1: ioctl(14, USCSICMD, 0x08046DBC) = 0 19752/1: ioctl(14, USCSICMD, 0x08046DBC) = 0 19752/1: ioctl(14, USCSICMD, 0x08046DBC) = 0 SCSI c18t5000C5004144F613d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C500414486E7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C500414486E7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C500414486E7d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004143919Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004143919Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004143919Bd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004143ADEFd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004143ADEFd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004143ADEFd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004145FE2Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004145FE2Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004145FE2Bd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004142AE9Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004142AE9Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004142AE9Fd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004144856Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004144856Fd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004144856Fd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004144A257d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004144A257d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004144A257d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004145BEDFd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004145BEDFd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004145BEDFd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004144A3B7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004144A3B7d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004144A3B7d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004144A693d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004144A693d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004144A693d0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c18t5000C5004143BC6Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) Err#48 ENOTSUP 19752/1: open("/dev/rdsk/c18t5000C5004143BC6Bd0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) = 0 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 SCSI c18t5000C5004143BC6Bd0 SEAGATE ST33000650SS 2794.52 GiB no no 19752/1: open("/dev/rdsk/c25t0d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080477E0) = 0 19752/1: ioctl(11, DKIOCGMBOOT, 0x08046E70) = 0 19752/1: ioctl(11, DKIOCG_PHYGEOM, 0x080477B6) = 0 19752/1: ioctl(11, DKIOCGEXTVTOC, 0x0804749C) = 0 19752/1: ioctl(11, DKIOCINFO, 0x0804741C) = 0 19752/1: open("/dev/rdsk/c25t0d0s0", O_RDONLY|O_NDELAY) = 11 19752/1: ioctl(11, DKIOCGMEDIAINFO, 0x080473D0) = 0 19752/1: ioctl(11, USCSICMD, 0x0804721C) Err#5 EIO 19752/1: ioctl(11, USCSICMD, 0x0804721C) Err#5 EIO 19752/1: ioctl(11, USCSICMD, 0x0804721C) Err#5 EIO 19752/1: ioctl(11, 0x0426, 0x0804739C) = 0 On 1/4/17, 3:15 PM, "Joshua M. Clulow" wrote: On 4 January 2017 at 13:09, John Barfield wrote: > It actually finally completed. Doing it again with the proper PID as suggested provides the following: > root at PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k >> 0t19448::pid2proc | ::walk thread | ::findstack -v > stack pointer for thread ffffff2490590000: ffffff010a286750 > [ ffffff010a286750 _resume_from_idle+0xf4() ] > ffffff010a286780 swtch+0x141() > ffffff010a2867c0 sema_p+0x1c7(ffffff26e094b600) > ffffff010a286800 biowait+0xa4(ffffff26e094b540) > ffffff010a2868d0 scsi_uscsi_handle_cmd+0x127(c100000d40, 1, ffffff24907f3da8, fffffffff7b159b0, 0, ffffff27c23171e8) > ffffff010a286960 sd_ssc_send+0x136(ffffff24227d4e00, ffffff010a286970, 80000000, 1, 0) > ffffff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ffffff24227d4e00, 1) > ffffff010a286b40 sd_get_media_info_com+0xaf(c100000d40, ffffff010a286b50, ffffff010a286b54, ffffff010a286b58, 0) > ffffff010a286ba0 sd_get_media_info+0x41(c100000d40, 8047330, 100005) > ffffff010a286c80 sdioctl+0xc57(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286cc0 cdev_ioctl+0x39(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286d10 spec_ioctl+0x60(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286da0 fop_ioctl+0x55(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286ec0 ioctl+0x9b(3, 42a, 8047330) > ffffff010a286f10 _sys_sysenter_post_swapgs+0x149() OK, it seems that we're hanging while sending a TEST UNIT READY to some device. It's probably easiest to just use truss(1), here; e.g.: truss -t "open,ioctl" -f diskinfo Once it starts hanging, you should be able to see which open(2) and ioctl(2) calls happened just before the hang. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From mdoehle at mpi-bremen.de Wed Jan 4 21:39:18 2017 From: mdoehle at mpi-bremen.de (=?UTF-8?Q?Mathias_D=c3=b6hle?=) Date: Wed, 4 Jan 2017 22:39:18 +0100 Subject: [OmniOS-discuss] unsubcribe Message-ID: <586D6B86.8040701@mpi-bremen.de> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4893 bytes Desc: S/MIME Cryptographic Signature URL: From daleg at omniti.com Wed Jan 4 21:39:55 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 4 Jan 2017 16:39:55 -0500 Subject: [OmniOS-discuss] upgrading from 151014 In-Reply-To: <20170104222102.17086412@sleipner.datanom.net> References: <65DC5816D4BEE043885A89FD54E273FC71D388C4@MAIL101.Ellipseinc.com> <20170104222102.17086412@sleipner.datanom.net> Message-ID: > On Jan 4, 2017, at 4:21 PM, Michael Rasmussen wrote: > > On Wed, 4 Jan 2017 15:56:17 -0500 > Dan McDonald wrote: > >> >> (Note the get-rid-of-SunSSH before actually upgrading part.) >> > I guess this will be a prerequisite doing 151014 -> 151022 anyway? Yes. Even if you?re on 014, there?s no reason not to migrate to OpenSSH right away. The packages are available on 014. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From nrhuff at umn.edu Wed Jan 4 21:52:31 2017 From: nrhuff at umn.edu (Nathan Huff) Date: Wed, 4 Jan 2017 14:52:31 -0700 Subject: [OmniOS-discuss] New SAN deployment HBA recommendations Message-ID: Just as a data point we have a couple hosts running the LSI 9300-8e HBA to JBODs on 151014 with no issues so far. I was specifically wondering what is supported in the latest OmniOS > release, but I suppose youre suggesting that I could backport an illumos > driver from the latest build into ominos? > > OmniOS is the distro I use for SAN deployments. I use SmartOS for > hypervisors. > > > On 1/4/17, 2:18 PM, "Dan McDonald" wrote: > > > > On Jan 4, 2017, at 3:02 PM, John Barfield > wrote: > > > > Greetings, > > > > I?m designing a new ZFS SAN and I?m wondering if anyone knows the > latest greatest supported HBA that I should use for external JBOD?s. > > > > We have tons of SAN?s in production using LSI HBAs today but I?m > wondering if there is anything new out there that I?m missing or not aware > of yet. > > Are you using LSI 9300 series (driven by the 3008 chipset) yet? > That's the latest from the world of LSI. Those are fairly recent (last 3-4 > years), and many still use the 2008 chipset or 2208 chipset. > > There are parts currently just-in-SmartOS that may be getting > upstreamed soon as well. > > You may be better off asking this question on the illumos developers' > list, to see what the latest/greatest in supported HBA HW is. > > Dan > > -- Nathan Huff System Administrator Academic Health Center Information Systems University of Minnesota 612-626-9136 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Wed Jan 4 21:57:31 2017 From: mir at miras.org (Michael Rasmussen) Date: Wed, 4 Jan 2017 22:57:31 +0100 Subject: [OmniOS-discuss] ms.omniti.com down? Message-ID: <20170104225731.0cead61d@sleipner.datanom.net> Hi all, pkg search diskinfo pkg: Some repositories failed to respond appropriately: ms.omniti.com: http protocol error: code: 503 reason: Service Unavailable URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/search/1/False_2_None_None_%3A%3A%3Adiskinfo' -- 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: Chicago law prohibits eating in a place that is on fire. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From john.barfield at bissinc.com Wed Jan 4 22:34:03 2017 From: john.barfield at bissinc.com (John Barfield) Date: Wed, 4 Jan 2017 22:34:03 +0000 Subject: [OmniOS-discuss] device probe related command timeouts In-Reply-To: References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com> <2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com> Message-ID: So odd thing about this server?.there is NO ?/dev/rdsk/c14t0d0s0? anywhere. I wonder what that?s all about On 1/4/17, 3:17 PM, "John Barfield" wrote: You?re awesome! Its hanging on ?open /dev/rdsk/c14t0d0s0? Looking at that disk now. On 1/4/17, 3:15 PM, "Joshua M. Clulow" wrote: On 4 January 2017 at 13:09, John Barfield wrote: > It actually finally completed. Doing it again with the proper PID as suggested provides the following: > root at PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k >> 0t19448::pid2proc | ::walk thread | ::findstack -v > stack pointer for thread ffffff2490590000: ffffff010a286750 > [ ffffff010a286750 _resume_from_idle+0xf4() ] > ffffff010a286780 swtch+0x141() > ffffff010a2867c0 sema_p+0x1c7(ffffff26e094b600) > ffffff010a286800 biowait+0xa4(ffffff26e094b540) > ffffff010a2868d0 scsi_uscsi_handle_cmd+0x127(c100000d40, 1, ffffff24907f3da8, fffffffff7b159b0, 0, ffffff27c23171e8) > ffffff010a286960 sd_ssc_send+0x136(ffffff24227d4e00, ffffff010a286970, 80000000, 1, 0) > ffffff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ffffff24227d4e00, 1) > ffffff010a286b40 sd_get_media_info_com+0xaf(c100000d40, ffffff010a286b50, ffffff010a286b54, ffffff010a286b58, 0) > ffffff010a286ba0 sd_get_media_info+0x41(c100000d40, 8047330, 100005) > ffffff010a286c80 sdioctl+0xc57(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286cc0 cdev_ioctl+0x39(c100000d40, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68) > ffffff010a286d10 spec_ioctl+0x60(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286da0 fop_ioctl+0x55(ffffff2492b62d80, 42a, 8047330, 100005, ffffff24930f7580, ffffff010a286e68, 0) > ffffff010a286ec0 ioctl+0x9b(3, 42a, 8047330) > ffffff010a286f10 _sys_sysenter_post_swapgs+0x149() OK, it seems that we're hanging while sending a TEST UNIT READY to some device. It's probably easiest to just use truss(1), here; e.g.: truss -t "open,ioctl" -f diskinfo Once it starts hanging, you should be able to see which open(2) and ioctl(2) calls happened just before the hang. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org From daleg at omniti.com Wed Jan 4 22:47:43 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 4 Jan 2017 17:47:43 -0500 Subject: [OmniOS-discuss] ms.omniti.com down? In-Reply-To: <20170104225731.0cead61d@sleipner.datanom.net> References: <20170104225731.0cead61d@sleipner.datanom.net> Message-ID: <77FFD1C9-88B4-48CF-A4E2-CAAA3F19F613@omniti.com> > On Jan 4, 2017, at 4:57 PM, Michael Rasmussen wrote: > > Hi all, > > pkg search diskinfo > pkg: Some repositories failed to respond appropriately: > ms.omniti.com: > http protocol error: code: 503 reason: Service Unavailable > URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/search/1/False_2_None_None_%3A%3A%3Adiskinfo' We?ve corrected this. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From miniflowtrader at gmail.com Wed Jan 4 23:59:15 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 04 Jan 2017 23:59:15 +0000 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: References: Message-ID: That is unfortunate. The requirement stems from the need to perform an incremental backup to cloud storage (backblaze). Many of my files are large and sparse (VMs). Unfortunately the only software that I have found to perform the backups runs on BSD or Linux hence the use for NFS. Running the utility over NFS without sparse support is not ideal. If anyone has any recommendations for an incremental cloud storage solution that is compatible with OmniOS it would be greatly appreciated. I realize that ZFS send works quite well but haven't found an off site provider who I consider to be cost effective. On Wed, Jan 4, 2017 at 2:01 PM Dan McDonald wrote: > > > > On Jan 4, 2017, at 1:19 PM, Mini Trader > wrote: > > > > > > Hello all, > > > > > > Is there any support for NFS 4.2 in Illumos? I am interested in the > Sparse File functionality that has been introduced. > > > > There is not, currently. > > > > There have been some stop/starts on this, but at the end of the day, at > least one illumos shop's customers basically didn't care enough to make it > a priority for that shop. The other illumos shops either have similar > customer viewpoints, don't care about NFS at all, or don't have the > resources to devote to such a nontrivial project. > > > > I'm sorry I don't have a better answer for you at the moment. > > > > Dan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Thu Jan 5 00:15:18 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 5 Jan 2017 01:15:18 +0100 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: References: Message-ID: <20170105011518.76311089@sleipner.datanom.net> On Wed, 04 Jan 2017 23:59:15 +0000 Mini Trader wrote: > > If anyone has any recommendations for an incremental cloud storage solution > that is compatible with OmniOS it would be greatly appreciated. I realize > that ZFS send works quite well but haven't found an off site provider who I > consider to be cost effective. > Would it be possible to use rsync with backblaze? rsync handles sparse files equally well using option --sparse -- 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: "Whoever undertakes to set himself up as a judge of Truth and Knowledge is shipwrecked by the laughter of the gods." -- Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From mir at miras.org Thu Jan 5 00:25:46 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 5 Jan 2017 01:25:46 +0100 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: <20170105011518.76311089@sleipner.datanom.net> References: <20170105011518.76311089@sleipner.datanom.net> Message-ID: <20170105012546.72d2bf34@sleipner.datanom.net> On Thu, 5 Jan 2017 01:15:18 +0100 Michael Rasmussen wrote: > Would it be possible to use rsync with backblaze? > rsync handles sparse files equally well using option --sparse > A quick google: http://www.rsync.net/resources/howto/unix.html https://www.elastichosts.com/blog/cloud-storage-backup-using-rsync/ NB: I dont know the companies nor their solutions but it looks very Unix like;-) -- 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: From concentrate. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From mtalbott at lji.org Thu Jan 5 00:27:29 2017 From: mtalbott at lji.org (Michael Talbott) Date: Wed, 4 Jan 2017 16:27:29 -0800 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: <20170105011518.76311089@sleipner.datanom.net> References: <20170105011518.76311089@sleipner.datanom.net> Message-ID: <112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org> You can create an LX zone with the latest stable Omni release, share the dataset(s) with the zone and run the backup agent in there. That's what I'm using for a bunch of things such as Veeam, BeeGFS, and Plex. Works like a charm as long as you don't need extended attribute support. Michael Sent from my iPhone > On Jan 4, 2017, at 4:15 PM, Michael Rasmussen wrote: > > On Wed, 04 Jan 2017 23:59:15 +0000 > Mini Trader wrote: > >> >> If anyone has any recommendations for an incremental cloud storage solution >> that is compatible with OmniOS it would be greatly appreciated. I realize >> that ZFS send works quite well but haven't found an off site provider who I >> consider to be cost effective. >> > Would it be possible to use rsync with backblaze? > rsync handles sparse files equally well using option --sparse > > -- > 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: > "Whoever undertakes to set himself up as a judge of Truth and Knowledge > is shipwrecked by the laughter of the gods." > -- Albert Einstein > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From miniflowtrader at gmail.com Thu Jan 5 01:07:43 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 05 Jan 2017 01:07:43 +0000 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: <20170105011518.76311089@sleipner.datanom.net> References: <20170105011518.76311089@sleipner.datanom.net> Message-ID: Not really. There is one tool called rclone. But it will do a full upload on any changed file so does not help. There are some FUSE file systems but I don't believe these will work with Illumos either. I'd really like to avoid moving my pool if I don't have to. OmniOS has been great. On Wed, Jan 4, 2017 at 7:17 PM Michael Rasmussen wrote: > On Wed, 04 Jan 2017 23:59:15 +0000 > > Mini Trader wrote: > > > > > > > > If anyone has any recommendations for an incremental cloud storage > solution > > > that is compatible with OmniOS it would be greatly appreciated. I realize > > > that ZFS send works quite well but haven't found an off site provider > who I > > > consider to be cost effective. > > > > > Would it be possible to use rsync with backblaze? > > rsync handles sparse files equally well using option --sparse > > > > -- > > 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: > > "Whoever undertakes to set himself up as a judge of Truth and Knowledge > > is shipwrecked by the laughter of the gods." > > -- Albert Einstein > > _______________________________________________ > > 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 miniflowtrader at gmail.com Thu Jan 5 13:19:00 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 08:19:00 -0500 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: <20170105012546.72d2bf34@sleipner.datanom.net> References: <20170105011518.76311089@sleipner.datanom.net> <20170105012546.72d2bf34@sleipner.datanom.net> Message-ID: They are .10 per GB. Backblaze is 0.005 per GB. About $2400/yr vs $120/yr. On Wed, Jan 4, 2017 at 7:25 PM, Michael Rasmussen wrote: > On Thu, 5 Jan 2017 01:15:18 +0100 > Michael Rasmussen wrote: > > > Would it be possible to use rsync with backblaze? > > rsync handles sparse files equally well using option --sparse > > > A quick google: > http://www.rsync.net/resources/howto/unix.html > https://www.elastichosts.com/blog/cloud-storage-backup-using-rsync/ > > NB: I dont know the companies nor their solutions but it looks very > Unix like;-) > > -- > 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: > From concentrate. > > _______________________________________________ > 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 miniflowtrader at gmail.com Thu Jan 5 13:19:33 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 08:19:33 -0500 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: <112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org> References: <20170105011518.76311089@sleipner.datanom.net> <112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org> Message-ID: This could work :) Thank you. On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott wrote: > You can create an LX zone with the latest stable Omni release, share the > dataset(s) with the zone and run the backup agent in there. That's what I'm > using for a bunch of things such as Veeam, BeeGFS, and Plex. Works like a > charm as long as you don't need extended attribute support. > > Michael > Sent from my iPhone > > > On Jan 4, 2017, at 4:15 PM, Michael Rasmussen wrote: > > > > On Wed, 04 Jan 2017 23:59:15 +0000 > > Mini Trader wrote: > > > >> > >> If anyone has any recommendations for an incremental cloud storage > solution > >> that is compatible with OmniOS it would be greatly appreciated. I > realize > >> that ZFS send works quite well but haven't found an off site provider > who I > >> consider to be cost effective. > >> > > Would it be possible to use rsync with backblaze? > > rsync handles sparse files equally well using option --sparse > > > > -- > > 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: > > "Whoever undertakes to set himself up as a judge of Truth and Knowledge > > is shipwrecked by the laughter of the gods." > > -- Albert Einstein > > _______________________________________________ > > 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 lists at marzocchi.net Thu Jan 5 14:56:34 2017 From: lists at marzocchi.net (Olaf Marzocchi) Date: Thu, 05 Jan 2017 15:56:34 +0100 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: References: <20170105011518.76311089@sleipner.datanom.net> <112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org> Message-ID: <2DFC19B6-19DA-43CA-9F20-BD44DF720EE4@marzocchi.net> Their Linux tool is working with Backblaze B2, but it's a python tool, not a native closed source application. They do not offer the normal backup agent for anything but Win/Mac. At that point it may be possible to run the pytjon tool directly on OmniOS? I thought about it but never went on with the testing. If you try please report any success. I'm using right now Crashplan under OmniOS but it's been already declared as discontinued and I may need an alternative sometimes in the future, even if it still works fine. Olaf Il 5 gennaio 2017 14:19:33 CET, Mini Trader ha scritto: >This could work :) Thank you. > >On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott >wrote: > >> You can create an LX zone with the latest stable Omni release, share >the >> dataset(s) with the zone and run the backup agent in there. That's >what I'm >> using for a bunch of things such as Veeam, BeeGFS, and Plex. Works >like a >> charm as long as you don't need extended attribute support. >> >> Michael >> Sent from my iPhone >> >> > On Jan 4, 2017, at 4:15 PM, Michael Rasmussen >wrote: >> > >> > On Wed, 04 Jan 2017 23:59:15 +0000 >> > Mini Trader wrote: >> > >> >> >> >> If anyone has any recommendations for an incremental cloud storage >> solution >> >> that is compatible with OmniOS it would be greatly appreciated. I >> realize >> >> that ZFS send works quite well but haven't found an off site >provider >> who I >> >> consider to be cost effective. >> >> >> > Would it be possible to use rsync with backblaze? >> > rsync handles sparse files equally well using option --sparse >> > >> > -- >> > 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: >> > "Whoever undertakes to set himself up as a judge of Truth and >Knowledge >> > is shipwrecked by the laughter of the gods." >> > -- Albert Einstein >> > _______________________________________________ >> > 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 miniflowtrader at gmail.com Thu Jan 5 15:13:04 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 10:13:04 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images Message-ID: Hello all, I am trying to use a Debian LX Image based on the instructions from: https://omnios.omniti.com/wiki.php/LXZones The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 I've been able to get my zone to start up no problems. But I cannot login. Is there a default password for these images? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Jan 5 15:15:07 2017 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 5 Jan 2017 16:15:07 +0100 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: <2DFC19B6-19DA-43CA-9F20-BD44DF720EE4@marzocchi.net> References: <20170105011518.76311089@sleipner.datanom.net> <112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org> <2DFC19B6-19DA-43CA-9F20-BD44DF720EE4@marzocchi.net> Message-ID: On Thu, Jan 5, 2017 at 3:56 PM, Olaf Marzocchi wrote: > I'm using right now Crashplan under OmniOS but it's been already declared > as discontinued and I may need an alternative sometimes in the future, even > if it still works fine. > same here, althouth since the lx zones I think I will just install a linux container with the crashplan software and backup zfs nfs volumes. As it all works in the same box, there should not be any performance hit. So not a problem anymore in my opinion, thankfully. -- regards, Natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Thu Jan 5 15:21:00 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 05 Jan 2017 15:21:00 +0000 Subject: [OmniOS-discuss] NFS 4.2 Support - Sparse Files In-Reply-To: <2DFC19B6-19DA-43CA-9F20-BD44DF720EE4@marzocchi.net> References: <20170105011518.76311089@sleipner.datanom.net> <112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org> <2DFC19B6-19DA-43CA-9F20-BD44DF720EE4@marzocchi.net> Message-ID: I have not used the tool but it doesn't seem to offer the same intelligence you would get with something like BORG or hashbackup. I did not know about the LX feature so that seems like it can help significantly - trying to get it going but currently unable to login to the zones system! On Thu, Jan 5, 2017 at 9:56 AM Olaf Marzocchi wrote: > Their Linux tool is working with Backblaze B2, but it's a python tool, not > a native closed source application. They do not offer the normal backup > agent for anything but Win/Mac. > > > > > > At that point it may be possible to run the pytjon tool directly on OmniOS? > > > > > > I thought about it but never went on with the testing. > > > If you try please report any success. I'm using right now Crashplan under > OmniOS but it's been already declared as discontinued and I may need an > alternative sometimes in the future, even if it still works fine. > > > > > > > Olaf > > > > > > > > > Il 5 gennaio 2017 14:19:33 CET, Mini Trader ha > scritto: > > > > This could work :) Thank you. > > On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott wrote: > > You can create an LX zone with the latest stable Omni release, share the > dataset(s) with the zone and run the backup agent in there. That's what I'm > using for a bunch of things such as Veeam, BeeGFS, and Plex. Works like a > charm as long as you don't need extended attribute support. > > > > > > Michael > > > Sent from my iPhone > > > > > > > On Jan 4, 2017, at 4:15 PM, Michael Rasmussen wrote: > > > > > > > > On Wed, 04 Jan 2017 23:59:15 +0000 > > > > Mini Trader wrote: > > > > > > > >> > > > >> If anyone has any recommendations for an incremental cloud storage > solution > > > >> that is compatible with OmniOS it would be greatly appreciated. I > realize > > > >> that ZFS send works quite well but haven't found an off site provider > who I > > > >> consider to be cost effective. > > > >> > > > > Would it be possible to use rsync with backblaze? > > > > rsync handles sparse files equally well using option --sparse > > > > > > > > -- > > > > 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: > > > > "Whoever undertakes to set himself up as a judge of Truth and Knowledge > > > > is shipwrecked by the laughter of the gods." > > > > -- Albert Einstein > > > > _______________________________________________ > > > > 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 rafapi at gmail.com Thu Jan 5 15:23:29 2017 From: rafapi at gmail.com (Rafael Pardinas) Date: Thu, 05 Jan 2017 15:23:29 +0000 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: >From your host you should be able to do: ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian machine. >From there you can assign passwords. By default there isn't one assigned to the root user as far as I know. -Rafa On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: > Hello all, > > I am trying to use a Debian LX Image based on the instructions from: > > https://omnios.omniti.com/wiki.php/LXZones > > The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 > > I've been able to get my zone to start up no problems. But I cannot login. > > Is there a default password for these images? > > Thanks! > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Thu Jan 5 15:41:32 2017 From: daleg at omniti.com (Dale Ghent) Date: Thu, 5 Jan 2017 10:41:32 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: As someone else already said - there's no root password on these images and you need to use zlogin to get a "console" root prompt. General thing is, is that these images are essentially what you would download directly from Ubuntu or CentOS/Redhat, but with some specific tweaks to make them jive better with LX Zones. Other than those tweaks, using them is no different from using their official ISO on bare metal, so their distro-specific documentation picks up from that point. /dale > On Jan 5, 2017, at 10:13 AM, Mini Trader wrote: > > Hello all, > > I am trying to use a Debian LX Image based on the instructions from: > > https://omnios.omniti.com/wiki.php/LXZones > > The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 > > I've been able to get my zone to start up no problems. But I cannot login. > > Is there a default password for these images? > > Thanks! > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From miniflowtrader at gmail.com Thu Jan 5 15:44:39 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 10:44:39 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: My system is acting funny. If I login via zlogin nameofzone I don't get dumped into the command prompt right away. I was able to change the password via zlogin nameofzone passwd If I login via zlogin -C nameofzone Everything seems normal. It's like the shell is not properly feeding back if using zlogin without the -C option. On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas wrote: > From your host you should be able to do: > > ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian > machine. > > From there you can assign passwords. By default there isn't one assigned > to the root user as far as I know. > > -Rafa > > On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: > >> Hello all, >> >> I am trying to use a Debian LX Image based on the instructions from: >> >> https://omnios.omniti.com/wiki.php/LXZones >> >> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >> >> I've been able to get my zone to start up no problems. But I cannot >> login. >> >> Is there a default password for these images? >> >> Thanks! >> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Thu Jan 5 15:45:23 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 10:45:23 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: root at storage1:/main/zones# zlogin -e ! lx0 [Connected to zone 'lx0' pts/2] Last login: Thu Jan 5 15:43:39 UTC 2017 on console Linux debian-8 3.16.0 BrandZ virtual linux x86_64 __ . . _| |_ | .-. . . .-. :--. |- |_ _| ;| || |(.-' | | | |__| `--' `-' `;-| `-' ' ' `-' / ; Instance (Debian 8.6 (jessie) 20161213) `-' https://docs.joyent.com/images/container-native-linux Login timed out after 60 seconds. [Connection to zone 'lx0' pts/2 closed] On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader wrote: > My system is acting funny. > > If I login via zlogin nameofzone > > I don't get dumped into the command prompt right away. I was able to > change the password via zlogin nameofzone passwd > > If I login via zlogin -C nameofzone > > Everything seems normal. It's like the shell is not properly feeding back > if using zlogin without the -C option. > > On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas wrote: > >> From your host you should be able to do: >> >> ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian >> machine. >> >> From there you can assign passwords. By default there isn't one assigned >> to the root user as far as I know. >> >> -Rafa >> >> On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: >> >>> Hello all, >>> >>> I am trying to use a Debian LX Image based on the instructions from: >>> >>> https://omnios.omniti.com/wiki.php/LXZones >>> >>> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >>> >>> I've been able to get my zone to start up no problems. But I cannot >>> login. >>> >>> Is there a default password for these images? >>> >>> Thanks! >>> >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafapi at gmail.com Thu Jan 5 15:47:39 2017 From: rafapi at gmail.com (Rafael Pardinas) Date: Thu, 05 Jan 2017 15:47:39 +0000 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: Have you tried rebooting the LX zone? Sometimes they don't load correctly the first time. On Thu, 5 Jan 2017 at 15:45 Mini Trader wrote: > root at storage1:/main/zones# zlogin -e ! lx0 > [Connected to zone 'lx0' pts/2] > Last login: Thu Jan 5 15:43:39 UTC 2017 on console > Linux debian-8 3.16.0 BrandZ virtual linux x86_64 > __ . . > _| |_ | .-. . . .-. :--. |- > |_ _| ;| || |(.-' | | | > |__| `--' `-' `;-| `-' ' ' `-' > / ; Instance (Debian 8.6 (jessie) 20161213) > `-' > https://docs.joyent.com/images/container-native-linux > > > Login timed out after 60 seconds. > > [Connection to zone 'lx0' pts/2 closed] > > > On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader > wrote: > > My system is acting funny. > > If I login via zlogin nameofzone > > I don't get dumped into the command prompt right away. I was able to > change the password via zlogin nameofzone passwd > > If I login via zlogin -C nameofzone > > Everything seems normal. It's like the shell is not properly feeding back > if using zlogin without the -C option. > > On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas wrote: > > From your host you should be able to do: > > ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian > machine. > > From there you can assign passwords. By default there isn't one assigned > to the root user as far as I know. > > -Rafa > > On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: > > Hello all, > > I am trying to use a Debian LX Image based on the instructions from: > > https://omnios.omniti.com/wiki.php/LXZones > > The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 > > I've been able to get my zone to start up no problems. But I cannot login. > > Is there a default password for these images? > > Thanks! > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Thu Jan 5 15:51:50 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 10:51:50 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: Yes. Doesn't seem to make a difference. On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas wrote: > Have you tried rebooting the LX zone? Sometimes they don't load correctly > the first time. > > On Thu, 5 Jan 2017 at 15:45 Mini Trader wrote: > >> root at storage1:/main/zones# zlogin -e ! lx0 >> [Connected to zone 'lx0' pts/2] >> Last login: Thu Jan 5 15:43:39 UTC 2017 on console >> Linux debian-8 3.16.0 BrandZ virtual linux x86_64 >> __ . . >> _| |_ | .-. . . .-. :--. |- >> |_ _| ;| || |(.-' | | | >> |__| `--' `-' `;-| `-' ' ' `-' >> / ; Instance (Debian 8.6 (jessie) 20161213) >> `-' https://docs.joyent.com/ >> images/container-native-linux >> >> >> Login timed out after 60 seconds. >> >> [Connection to zone 'lx0' pts/2 closed] >> >> >> On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader >> wrote: >> >> My system is acting funny. >> >> If I login via zlogin nameofzone >> >> I don't get dumped into the command prompt right away. I was able to >> change the password via zlogin nameofzone passwd >> >> If I login via zlogin -C nameofzone >> >> Everything seems normal. It's like the shell is not properly feeding >> back if using zlogin without the -C option. >> >> On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas >> wrote: >> >> From your host you should be able to do: >> >> ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian >> machine. >> >> From there you can assign passwords. By default there isn't one assigned >> to the root user as far as I know. >> >> -Rafa >> >> On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: >> >> Hello all, >> >> I am trying to use a Debian LX Image based on the instructions from: >> >> https://omnios.omniti.com/wiki.php/LXZones >> >> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >> >> I've been able to get my zone to start up no problems. But I cannot >> login. >> >> Is there a default password for these images? >> >> Thanks! >> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafapi at gmail.com Thu Jan 5 16:19:32 2017 From: rafapi at gmail.com (Rafael Pardinas) Date: Thu, 05 Jan 2017 16:19:32 +0000 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: It may be useful to take a look at your config file then. On Thu, 5 Jan 2017 at 15:51 Mini Trader wrote: > Yes. Doesn't seem to make a difference. > > On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas wrote: > > Have you tried rebooting the LX zone? Sometimes they don't load correctly > the first time. > > On Thu, 5 Jan 2017 at 15:45 Mini Trader wrote: > > root at storage1:/main/zones# zlogin -e ! lx0 > [Connected to zone 'lx0' pts/2] > Last login: Thu Jan 5 15:43:39 UTC 2017 on console > Linux debian-8 3.16.0 BrandZ virtual linux x86_64 > __ . . > _| |_ | .-. . . .-. :--. |- > |_ _| ;| || |(.-' | | | > |__| `--' `-' `;-| `-' ' ' `-' > / ; Instance (Debian 8.6 (jessie) 20161213) > `-' > https://docs.joyent.com/images/container-native-linux > > > Login timed out after 60 seconds. > > [Connection to zone 'lx0' pts/2 closed] > > > On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader > wrote: > > My system is acting funny. > > If I login via zlogin nameofzone > > I don't get dumped into the command prompt right away. I was able to > change the password via zlogin nameofzone passwd > > If I login via zlogin -C nameofzone > > Everything seems normal. It's like the shell is not properly feeding back > if using zlogin without the -C option. > > On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas wrote: > > From your host you should be able to do: > > ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian > machine. > > From there you can assign passwords. By default there isn't one assigned > to the root user as far as I know. > > -Rafa > > On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: > > Hello all, > > I am trying to use a Debian LX Image based on the instructions from: > > https://omnios.omniti.com/wiki.php/LXZones > > The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 > > I've been able to get my zone to start up no problems. But I cannot login. > > Is there a default password for these images? > > Thanks! > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Thu Jan 5 16:27:07 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 11:27:07 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: I deleted and re-created. And it seems to be fine now. Odd. My ifconfig settings keep getting overwritten. Is there something special that needs to be done to have these settings maintained? Looking for a simple DHCP or Static IP config. On Thu, Jan 5, 2017 at 11:19 AM, Rafael Pardinas wrote: > It may be useful to take a look at your config file then. > > On Thu, 5 Jan 2017 at 15:51 Mini Trader wrote: > >> Yes. Doesn't seem to make a difference. >> >> On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas >> wrote: >> >> Have you tried rebooting the LX zone? Sometimes they don't load correctly >> the first time. >> >> On Thu, 5 Jan 2017 at 15:45 Mini Trader wrote: >> >> root at storage1:/main/zones# zlogin -e ! lx0 >> [Connected to zone 'lx0' pts/2] >> Last login: Thu Jan 5 15:43:39 UTC 2017 on console >> Linux debian-8 3.16.0 BrandZ virtual linux x86_64 >> __ . . >> _| |_ | .-. . . .-. :--. |- >> |_ _| ;| || |(.-' | | | >> |__| `--' `-' `;-| `-' ' ' `-' >> / ; Instance (Debian 8.6 (jessie) 20161213) >> `-' https://docs.joyent.com/ >> images/container-native-linux >> >> >> Login timed out after 60 seconds. >> >> [Connection to zone 'lx0' pts/2 closed] >> >> >> On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader >> wrote: >> >> My system is acting funny. >> >> If I login via zlogin nameofzone >> >> I don't get dumped into the command prompt right away. I was able to >> change the password via zlogin nameofzone passwd >> >> If I login via zlogin -C nameofzone >> >> Everything seems normal. It's like the shell is not properly feeding >> back if using zlogin without the -C option. >> >> On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas >> wrote: >> >> From your host you should be able to do: >> >> ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian >> machine. >> >> From there you can assign passwords. By default there isn't one assigned >> to the root user as far as I know. >> >> -Rafa >> >> On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: >> >> Hello all, >> >> I am trying to use a Debian LX Image based on the instructions from: >> >> https://omnios.omniti.com/wiki.php/LXZones >> >> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >> >> I've been able to get my zone to start up no problems. But I cannot >> login. >> >> Is there a default password for these images? >> >> Thanks! >> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Jan 5 16:35:08 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 5 Jan 2017 11:35:08 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: https://omnios.omniti.com/wiki.php/LXZones See the zonecfg example where you add properties to the "net" instance. For now, this is the only way to support network configurations on LX Zones. We plan to have /native/sbin/ipadm working before r151022 ships. Dan From miniflowtrader at gmail.com Thu Jan 5 17:47:51 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 12:47:51 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: Having trouble with networking. Any thoughts on this? ipadm show-addr ADDROBJ TYPE STATE ADDR vmxnet3s0/v4 static ok 10.255.0.15/24 dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID lx0 vmxnet3s0 10000 2:8:20:94:5e:c random 0 netstat -rn -finet Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 10.255.0.1 UG 2 66534 10.250.0.0 10.250.1.2 U 4 54902 vmxnet3s1 10.255.0.0 10.255.0.15 U 9 22094 vmxnet3s0 127.0.0.1 127.0.0.1 UH 2 60 lo0 Here is the config: create set zonepath=/main/zones/lx0 set brand=lx set autoboot=false set ip-type=exclusive add net set physical=lx0 add property (name=gateway,value="10.255.0.1") add property (name=ips,value="10.255.0.16/24") add property (name=primary,value="true") end add attr set name=dns-domain set type=string set value=mydomain.com end add attr set name=resolvers set type=string set value=10.255.0.1 end add attr set name=kernel-version set type=string set value=3.16.0 end exit On Thu, Jan 5, 2017 at 11:35 AM, Dan McDonald wrote: > https://omnios.omniti.com/wiki.php/LXZones > > See the zonecfg example where you add properties to the "net" instance. > For now, this is the only way to support network configurations on LX > Zones. We plan to have /native/sbin/ipadm working before r151022 ships. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Jan 5 18:11:59 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 5 Jan 2017 13:11:59 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: Why are you showing me global-zone things when the problem is in the LX zone? Dan From miniflowtrader at gmail.com Thu Jan 5 18:32:11 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 13:32:11 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: The only machine I can ping is the host. Nothing else. root at debian-8:~# ifconfig -a lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MULTICAST MTU:8232 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lx0 Link encap:Ethernet HWaddr 02:08:20:75:44:a6 inet addr:10.255.0.16 Bcast:10.255.0.255 Mask:255.255.255.0 inet6 addr: fe80::8:20ff:fe75:44a6/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:588 errors:0 dropped:0 overruns:0 frame:0 TX packets:125 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:57459 (56.1 KiB) TX bytes:6458 (6.3 KiB) root at debian-8:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 10.255.0.1 0.0.0.0 UG 0 0 0 * 10.255.0.0 * 255.255.255.0 U 0 0 0 lx0 root at debian-8:~# cat /etc/network/interfaces # AUTOMATIC ZONE CONFIG iface lo inet manual iface lx0 inet manual root at debian-8:~# cat /etc/resolv.conf # AUTOMATIC ZONE CONFIG nameserver 10.255.0.1 search mydomain.com root at debian-8:~# ip route show default via 10.255.0.1 proto static 10.255.0.0/24 dev lx0 proto kernel scope link src 10.255.0.16 On Thu, Jan 5, 2017 at 1:11 PM, Dan McDonald wrote: > Why are you showing me global-zone things when the problem is in the LX > zone? > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Jan 5 18:34:40 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 5 Jan 2017 13:34:40 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: Message-ID: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> Hmmm. So now we do have to go back to the global zone... but not what you showed me. Please show: dladm show-link dladm show-vnic dladm show-ether I notice you're running on vmxnet... I wonder if your host is preventing you from creating vNICs through some sort of address filtering? One thing to try is to pass a native NIC to the LX zone (instead of an lx0 vnic) to see if that works. Dan From miniflowtrader at gmail.com Thu Jan 5 18:37:41 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 13:37:41 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> Message-ID: root at storage1:/root# dladm show-link LINK CLASS MTU STATE BRIDGE OVER vmxnet3s0 phys 1500 up -- -- vmxnet3s1 phys 9000 up -- -- lx0 vnic 1500 up -- vmxnet3s0 root at storage1:/root# root at storage1:/root# dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID lx0 vmxnet3s0 10000 2:8:20:75:44:a6 random 0 root at storage1:/root# root at storage1:/root# dladm show-ether LINK PTYPE STATE AUTO SPEED-DUPLEX PAUSE vmxnet3s0 current up no 10G-f none vmxnet3s1 current up no 10G-f none Will be hard to get a physical NIC on the machine. On Thu, Jan 5, 2017 at 1:34 PM, Dan McDonald wrote: > Hmmm. > > So now we do have to go back to the global zone... but not what you showed > me. > > Please show: > > dladm show-link > > dladm show-vnic > > dladm show-ether > > I notice you're running on vmxnet... I wonder if your host is preventing > you from creating vNICs through some sort of address filtering? > > One thing to try is to pass a native NIC to the LX zone (instead of an lx0 > vnic) to see if that works. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Jan 5 18:40:38 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 5 Jan 2017 13:40:38 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> Message-ID: > On Jan 5, 2017, at 1:37 PM, Mini Trader wrote: > > root at storage1:/root# dladm show-link > LINK CLASS MTU STATE BRIDGE OVER > vmxnet3s0 phys 1500 up -- -- > vmxnet3s1 phys 9000 up -- -- > lx0 vnic 1500 up -- vmxnet3s0 > root at storage1:/root# > root at storage1:/root# dladm show-vnic > LINK OVER SPEED MACADDRESS MACADDRTYPE VID > lx0 vmxnet3s0 10000 2:8:20:75:44:a6 random 0 > root at storage1:/root# > root at storage1:/root# dladm show-ether > LINK PTYPE STATE AUTO SPEED-DUPLEX PAUSE > vmxnet3s0 current up no 10G-f none > vmxnet3s1 current up no 10G-f none > > Will be hard to get a physical NIC on the machine. Oh, I wasn't clear. Can you assigned vmxnet3s1 to your LX zone? If not, I get it. It doesn't need to be physical, but it needs to be "not a vNIC". vmxnet counts as a "native NIC" in this case. Another experiment you can try to prove my VMware-host-is-the-problem hypothesis is to create a boring old ipkg or lipkg zone, and see if networking works or not in it. A beer says you can't get networking with a vnic to work in a regular zone as well. Dan From mir at miras.org Thu Jan 5 18:44:40 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 5 Jan 2017 19:44:40 +0100 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> Message-ID: <20170105194440.0ea6ff45@sleipner.datanom.net> On Thu, 5 Jan 2017 13:34:40 -0500 Dan McDonald wrote: > I notice you're running on vmxnet... I wonder if your host is preventing you from creating vNICs through some sort of address filtering? > Does it not require promiscuous mode to be able to create a nic alias? I do not think this is supported with default settings in VmWare. -- 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: Lack of money is the root of all evil. -- George Bernard Shaw -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Thu Jan 5 18:48:18 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 5 Jan 2017 13:48:18 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: <20170105194440.0ea6ff45@sleipner.datanom.net> References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> <20170105194440.0ea6ff45@sleipner.datanom.net> Message-ID: <0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com> > On Jan 5, 2017, at 1:44 PM, Michael Rasmussen wrote: > > Does it not require promiscuous mode to be able to create a nic alias? > I do not think this is supported with default settings in VmWare. I don't know my VMware-fu very well, but this sounds like what I was talking about. Thanks! Dan From miniflowtrader at gmail.com Thu Jan 5 19:03:48 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Thu, 5 Jan 2017 14:03:48 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: <0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com> References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> <20170105194440.0ea6ff45@sleipner.datanom.net> <0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com> Message-ID: Only added the vnic because I saw it in some other install manual. Obviously not needed - thank you for pointing that out! I added a third NIC on the same network and wham I am up and running :) Thank you for the help. Is there any documentation on what I need to do to make my datasets visible? On Thu, Jan 5, 2017 at 1:48 PM, Dan McDonald wrote: > > > On Jan 5, 2017, at 1:44 PM, Michael Rasmussen wrote: > > > > Does it not require promiscuous mode to be able to create a nic alias? > > I do not think this is supported with default settings in VmWare. > > I don't know my VMware-fu very well, but this sounds like what I was > talking about. > > Thanks! > Dan > > _______________________________________________ > 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 mir at miras.org Thu Jan 5 19:04:31 2017 From: mir at miras.org (Michael Rasmussen) Date: Thu, 5 Jan 2017 20:04:31 +0100 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: <0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com> References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> <20170105194440.0ea6ff45@sleipner.datanom.net> <0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com> Message-ID: <20170105200431.6ebabc2a@sleipner.datanom.net> On Thu, 5 Jan 2017 13:48:18 -0500 Dan McDonald wrote: > > On Jan 5, 2017, at 1:44 PM, Michael Rasmussen wrote: > > > > Does it not require promiscuous mode to be able to create a nic alias? > > I do not think this is supported with default settings in VmWare. > > I don't know my VMware-fu very well, but this sounds like what I was talking about. > > Thanks! > Dan > Jup, promiscuous mode is required to be able to mess with arp and other low level IP stuff. -- 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: Spock: The odds of surviving another attack are 13562190123 to 1, Captain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Thu Jan 5 19:05:33 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 5 Jan 2017 14:05:33 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> <20170105194440.0ea6ff45@sleipner.datanom.net> <0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com> Message-ID: <36B91AB4-8E12-4093-84F3-F1B3BD99973B@omniti.com> > On Jan 5, 2017, at 2:03 PM, Mini Trader wrote: > > Only added the vnic because I saw it in some other install manual. Obviously not needed - thank you for pointing that out! I added a third NIC on the same network and wham I am up and running :) Thank you for the help. > > Is there any documentation on what I need to do to make my datasets visible? The zonecfg(1M) has some information on how to let a zone see and maniuplate a dataset. Do you need full ZFS capacities, or just POSIX-access to the filesystem(s)? The latter is simple for LX zones, but of unknown difficulty for full ZFS capacities. Dan From danmcd at omniti.com Thu Jan 5 19:27:26 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 5 Jan 2017 14:27:26 -0500 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> <20170105194440.0ea6ff45@sleipner.datanom.net> <0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com> <36B91AB4-8E12-4093-84F3-F1B3BD99973B@omniti.com> Message-ID: > On Jan 5, 2017, at 2:14 PM, Mini Trader wrote: > > Just access and hopefully recognition of sparse files. You should be able to use zonecfg(1M) to share things appropriately. Dan From pasztor at sagv5.gyakg.u-szeged.hu Thu Jan 5 20:20:54 2017 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Thu, 5 Jan 2017 21:20:54 +0100 Subject: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images In-Reply-To: <20170105194440.0ea6ff45@sleipner.datanom.net> References: <8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com> <20170105194440.0ea6ff45@sleipner.datanom.net> Message-ID: <20170105202054.GA17590@linux.gyakg.u-szeged.hu> Hi, "Michael Rasmussen" ?rta 2017-01-05 19:44-kor: > On Thu, 5 Jan 2017 13:34:40 -0500 > Dan McDonald wrote: > > > I notice you're running on vmxnet... I wonder if your host is preventing you from creating vNICs through some sort of address filtering? > > > Does it not require promiscuous mode to be able to create a nic alias? > I do not think this is supported with default settings in VmWare. In my home nas, I bumped into a similar problem. - Host is omnios 151014. -- There is a zone, named vbox. --- There is a linux virtual machine inside that, which access the local network as it should, interface: eth0, br0(lxcname.eth0) ---- There is a lxc container in that virtual machine The lxc container didn't had access to the network, since virtualbox+ vnic filtered out frames, didn't belong to it's address, so from the global zone's perspective, the linux machine's vnic shouldn't get the frames where it's destination was the lxc's mac. So, I set up a proxy arp in the linux virtual machine: $ cat /etc/sysctl.d/lxc-net-dep.conf net.ipv4.ip_forward=1 net.ipv4.conf.br0.proxy_arp=1 net.ipv4.conf.eth0.proxy_arp=1 Also, for safety, inside the /etc/network/interfaces, there is an up command entry for the iface br0 inet static: up route add -host 172.28.33.40 dev br0 up sysctl net.ipv4.conf.br0.proxy_arp=1 down route del -host 172.28.33.40 So for eth0, there is a regular eth0 inet static entry, and there is this br0, with the same ip, as eth0, but it adds a p2p route entry to the routing table at bringing up. Since, br0 doesn't exist at host boot up time, the net.ipv4.conf.br0.proxy_arp=1 is practically useless in the sysctl.d.conf The 172.28.33.40 is the address of the lxc, while my whole home network is the 172.28.33.0/24. Outside from my omni nas, the linux vm, and the lxc seems like the same mac: # arp -n | grep -E '36|40' 172.28.33.36 ether 02:08:20:0d:ae:ea C wlan0 172.28.33.40 ether 02:08:20:0d:ae:ea C wlan0 I don't know, if it's possible on illumos but proxy arp can be a solution. Not a nice one, but a sulution! ;-) Cheers, Gyu From omnios at citrus-it.net Thu Jan 5 23:39:00 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Thu, 5 Jan 2017 23:39:00 +0000 (UTC) Subject: [OmniOS-discuss] uname -v change In-Reply-To: References: Message-ID: No problem - easily worked around. Andy On Wed, 4 Jan 2017, Dan McDonald wrote: ; It was a build accident, not intentional. ; ; Next time kernels get updated, it'll be fixed. If this is breaking scripts, I'll push an update that fixes it (at the cost of requiring another reboot). ; ; I'm very sorry about it. It's my fault for making build environment assumptions. A very recent omnios-build push will prevent things like this going forward. ; ; Sorry, ; Dan ; ; Sent from my iPhone (typos, autocorrect, and all) ; ; > On Jan 4, 2017, at 4:01 AM, Andy Fiddaman wrote: ; > ; > Morning, ; > ; > Just finished updating servers after last week's update to r151020 and ; > noticed that the uname -v output has lost the revision information. ; > ; > Before: ; > ; > SunOS carolina 5.11 omnios-r151020-b5b8c75 i86pc i386 i86pc ; > ; > After: ; > ; > SunOS reaper 5.11 omnios-bed3013 i86pc i386 i86pc ; > ; > Was that deliberate? ; > ; > Thanks, ; > ; > Andy ; > -- ; > Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk ; > Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ ; > Registered in England and Wales | Company number 4899123 ; > ; > _______________________________________________ ; > OmniOS-discuss mailing list ; > OmniOS-discuss at lists.omniti.com ; > http://lists.omniti.com/mailman/listinfo/omnios-discuss ; From bauernfeind at ipk-gatersleben.de Fri Jan 6 16:09:10 2017 From: bauernfeind at ipk-gatersleben.de (Jens Bauernfeind) Date: Fri, 6 Jan 2017 16:09:10 +0000 Subject: [OmniOS-discuss] ms.omniti.com Publisher tuntap manifest missing In-Reply-To: References: Message-ID: Hi all, at first happy new year! Thanks Dale, but it seems that tuntap is not removed from the ms.omniti.com publisher. When I browse the webpage its still there, and a pkgrecv is still complaining about it. For testing I have also setup a new local repo for this: zfs create rpool/pkgrepo/omnios/ms.omniti.com2 pkgrepo create /pkgrepo/omnios/ms.omniti.com2 pkgrepo set -s /pkgrepo/omnios/ms.omniti.com2 publisher/prefix=ms.omniti.com pkgrecv -v -s http://pkg.omniti.com/omniti-ms/ -d /pkgrepo/omnios/ms.omniti.com2/ -m all-versions --clone -p ms.omniti.com Processing packages for publisher ms.omniti.com ... Retrieving and evaluating 2030 package(s)... Reading Manifests ( 881/2030) |pkgrecv: http protocol error: code: 404 reason: Not Found URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/manifest/0/omniti%2Fnetwork%2Ftuntap at 1.3.3%2C5.11-0.151014%3A20161209T164618Z' (happened 4 times) Thanks in Advance Jens -----Urspr?ngliche Nachricht----- Von: Dale Ghent [mailto:daleg at omniti.com] Gesendet: Samstag, 31. Dezember 2016 19:16 An: Jens Bauernfeind Cc: "OmniOS-discuss ?[omnios-discuss at lists.omniti.com]?" Betreff: Re: [OmniOS-discuss] ms.omniti.com Publisher tuntap manifest missing Hello, Jens Just closing the loop on this - the tuntap driver is now part of OmniOS-proper, from 014 onwards. As such, the tuntap package in the ms.omniti.com repo has been removed, and I've corrected the issue you reported. Thanks /dale > On Dec 29, 2016, at 6:18 PM, Jens Bauernfeind wrote: > > Hello, the tuntap package from ms.omniti.com is missing the manifest: > pkg info -r -g http://pkg.omniti.com/omniti-ms/ms.omniti.com tuntap > pkg: http protocol error: code: 404 reason: Not Found > URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/manifest/0/omniti%2Fnetwork%2Ftuntap at 1.3.3%2C5.11-0.151014%3A20161213T171835Z' (happened 4 times) > > Greetings > Jens > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6023 bytes Desc: not available URL: From vab at bb-c.de Fri Jan 6 17:04:38 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 6 Jan 2017 18:04:38 +0100 Subject: [OmniOS-discuss] ms.omniti.com Publisher tuntap manifest missing In-Reply-To: References: Message-ID: <22639.52774.865720.235903@shelob.bb-c.de> Hi Jens! > at first happy new year! And a very good 2017 to you! > Thanks Dale, but it seems that tuntap is not removed from the ms.omniti.com publisher. When I browse the webpage its still there, and a pkgrecv is still complaining about it. For testing I have also setup a new local repo for this: > zfs create rpool/pkgrepo/omnios/ms.omniti.com2 > pkgrepo create /pkgrepo/omnios/ms.omniti.com2 > pkgrepo set -s /pkgrepo/omnios/ms.omniti.com2 publisher/prefix=ms.omniti.com > pkgrecv -v -s http://pkg.omniti.com/omniti-ms/ -d /pkgrepo/omnios/ms.omniti.com2/ -m all-versions --clone -p ms.omniti.com > Processing packages for publisher ms.omniti.com ... > Retrieving and evaluating 2030 package(s)... > Reading Manifests ( 881/2030) |pkgrecv: http protocol error: code: 404 reason: Not Found > URL: 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/manifest/0/omniti%2Fnetwork%2Ftuntap at 1.3.3%2C5.11-0.151014%3A20161209T164618Z' (happened 4 times) Yes, the ms.omniti.com repository has been a bit broken for quite some time (for another example, see my mail to Dale from last Monday). The only way to get a copy of that repository is a workaround: Use the --raw flag for pkgrecv. Then you will get the "raw" data from the repository in the location you specify with "-d". You will also need to explicitly specify the packages you want, leaving out all broken ones. >From there, you can easily reconstruct the repository by recreating the directory structure and moving the contents there. For example: # cat MISSING pkg://ms.omniti.com/omniti/developer/versioning/subversion at 1.9.4-0.151014:20161021T174720Z pkg://ms.omniti.com/omniti/developer/versioning/subversion at 1.9.4-0.151014:20161102T145637Z # /usr/bin/pkgrecv -v --raw -s http://pkg.omniti.com/omniti-ms -d . `cat MISSING` Processing packages for publisher omniti-ms ... Retrieving catalog 1/1 omniti-ms 155.16 kB Unable to retrieve package data for publisher 'omniti-ms' from one of the following origin(s): http://pkg.omniti.com/omniti-ms/ The catalog retrieved from one of the origin(s) listed above only contains package data for: ms.omniti.com. This is either a result of invalid origin information being provided for publisher 'omniti-ms', or because the wrong publisher name was provided when this publisher was added. Retrieving and evaluating 2 package(s)... Retrieving packages ... Packages to add: 2 Files to retrieve: 414 Estimated transfer size: 14.16 MB Packages to transfer: omniti/developer/versioning/subversion at 1.9.4,5.11-0.151014:20161021T174720Z omniti/developer/versioning/subversion at 1.9.4,5.11-0.151014:20161102T145637Z PROCESS ITEMS GET (MB) SEND (MB) Completed 2/2 14.2/14.2 0.0/0.0 Processing packages for publisher perl.omniti.com ... Processing packages for publisher ms.omniti.com ... Retrieving and evaluating 2 package(s)... Retrieving packages ... Packages to add: 2 Files to retrieve: 414 Estimated transfer size: 14.16 MB Packages to transfer: omniti/developer/versioning/subversion at 1.9.4,5.11-0.151014:20161021T174720Z omniti/developer/versioning/subversion at 1.9.4,5.11-0.151014:20161102T145637Z PROCESS ITEMS GET (MB) SEND (MB) Completed 2/2 14.2/14.2 0.0/0.0 Processing packages for publisher localhost ... Processing packages for publisher omnios ... (You can safely ignore the warning about the broken publisher.) Then you will get a directory structure like this: # ls -golFR drwxr-xr-x 4 311 Jan 6 17:46 omniti%2Fdeveloper%2Fversioning%2Fsubversion/ ./omniti%2Fdeveloper%2Fversioning%2Fsubversion: total 80 drwxr-xr-x 2 16547 Jan 6 17:46 1.9.4%2C5.11-0.151014%3A20161021T174720Z/ drwxr-xr-x 2 16547 Jan 6 17:47 1.9.4%2C5.11-0.151014%3A20161102T145637Z/ ./omniti%2Fdeveloper%2Fversioning%2Fsubversion/1.9.4%2C5.11-0.151014%3A20161021T174720Z: total 48360 -rw-r--r-- 1 813240 Jan 6 17:46 00370e03bd4b799dc893dce90752df6cfaf972e8 -rw-r--r-- 1 1714 Jan 6 17:46 013ab51d3c6c3356066642b7ed7388d8fc23fb12 -rw-r--r-- 1 3564 Jan 6 17:46 0539ba5fd5e1102801035f78ba0644e31423370b -rw-r--r-- 1 61984 Jan 6 17:46 0927d0f5be0e344ed0ff22a8b08d1f003aca21b8 [...] -rw-r--r-- 1 1131 Jan 6 17:46 fc9d34774c2a4a21ace7eb1c1da3fb984090eb46 -rw-r--r-- 1 52457 Jan 6 17:46 manifest -rw-r--r-- 1 927 Jan 6 17:46 manifest.depend -rw-r--r-- 1 1085 Jan 6 17:46 manifest.dir -rw-r--r-- 1 540 Jan 6 17:46 manifest.dircache -rw-r--r-- 1 45036 Jan 6 17:46 manifest.file -rw-r--r-- 1 142 Jan 6 17:46 manifest.license -rw-r--r-- 1 4232 Jan 6 17:46 manifest.link -rw-r--r-- 1 0 Jan 6 17:46 manifest.mediatorcache -rw-r--r-- 1 477 Jan 6 17:46 manifest.set -rw-r--r-- 1 677 Jan 6 17:46 manifest.signature The files you want are the ones with the "hash" filenames and the manifest file. You need to move these into the "real" local copy of your repository. The hash files go into the "file" subdirectory but must be compressed by gzip first. For example: # gzip -c 00370e03bd4b799dc893dce90752df6cfaf972e8 > /my_repo/publisher/ms.omniti.com/publisher/ms.omniti.com/file/00/00370e03bd4b799dc893dce90752df6cfaf972e8 The manifest file goes into the "pkg" subdirectory with a special naming structure. In this case: # mv manifest /my_repo/publisher/ms.omniti.com/pkg/omniti%2Fdeveloper%2Fversioning%2Fsubversion/1.9.4%2C5.11-0.151014%3A20161021T174720Z You may need to create the "omniti%2Fdeveloper%2Fversioning%2Fsubversion" directory first. Finally, you need to do a "pkgrepo rebuild" on the entire repository. Yes, it is absolutely tedious, but it works. One of these days I will write a Perl script to do this. The real fix would be on the repository side, but it seems that will take a while yet. :-) Viele Gr??e -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From vab at bb-c.de Fri Jan 6 17:25:10 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 6 Jan 2017 18:25:10 +0100 Subject: [OmniOS-discuss] ms.omniti.com Publisher tuntap manifest missing In-Reply-To: <22639.52774.865720.235903@shelob.bb-c.de> References: <22639.52774.865720.235903@shelob.bb-c.de> Message-ID: <22639.54006.64778.850515@shelob.bb-c.de> > The files you want are the ones with the "hash" filenames and the > manifest file. You need to move these into the "real" local copy of > your repository. The hash files go into the "file" subdirectory but > must be compressed by gzip first. For example: > > > # gzip -c 00370e03bd4b799dc893dce90752df6cfaf972e8 > /my_repo/publisher/ms.omniti.com/publisher/ms.omniti.com/file/00/00370e03bd4b799dc893dce90752df6cfaf972e8 The usual cut-and-paste error... :-( # gzip -c 00370e03bd4b799dc893dce90752df6cfaf972e8 > /my_repo/publisher/ms.omniti.com/file/00/00370e03bd4b799dc893dce90752df6cfaf972e8 Maybe you *do* want to wait for my Perl script. :-) Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From vab at bb-c.de Fri Jan 6 17:39:38 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Fri, 6 Jan 2017 18:39:38 +0100 Subject: [OmniOS-discuss] ms.omniti.com Publisher tuntap manifest missing In-Reply-To: <22639.54006.64778.850515@shelob.bb-c.de> References: <22639.52774.865720.235903@shelob.bb-c.de> <22639.54006.64778.850515@shelob.bb-c.de> Message-ID: <22639.54874.719410.732703@shelob.bb-c.de> I am playing around with this solution because I haven't done this for a while (and I need an excuse to avoid the paperwork I should be doing). So I am going through my old notes. > # /usr/bin/pkgrecv -v --raw -s http://pkg.omniti.com/omniti-ms -d . `cat MISSING` If you use the "-k" flag, you can skip the "gzip" step completely. The "-k" will keep the files in gzip format. Just move them into the proper directory. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From cks at cs.toronto.edu Fri Jan 6 22:22:57 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Fri, 06 Jan 2017 17:22:57 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots Message-ID: <20170106222257.187DA5A0360@apps1.cs.toronto.edu> We have an automated system for making regular (roughly hourly) snapshots of some especially important filesystems where we want fast restores. This has been running smoothly for some time and without problems. However, starting this week we have twice gone to do from-snapshot restores on one of the filesystems involved and discovered that almost all of the snapshots are mysteriously missing. By 'missing' I mean that they aren't present in either /.zfs/snapshots or in 'zfs list -r -t all ', which as far as I know means they don't exist at all. By 'mysteriously' I mean that not only did the snapshot-making process not report any errors to us, but 'zpool history' reports that the snapshot commands happened and there were no matching snapshot deletions. In addition this has only been happening on one of the filesystems that gets snapshots; all of the other ones (which are all in the same pool) have everything present. 'zpool history' recent output for the filesystem is: 2017-01-06.06:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-06 2017-01-06.07:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-07 2017-01-06.08:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-08 2017-01-06.09:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-09 2017-01-06.10:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-10 2017-01-06.11:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-11 2017-01-06.12:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-12 2017-01-06.13:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-13 2017-01-06.14:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-14 2017-01-06.15:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-15 2017-01-06.16:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-16 2017-01-06.16:45:55 zfs snapshot fs0-admin-02/h/105 at Fri-16 The actual snapshots present in the pool are: NAME USED AVAIL REFER MOUNTPOINT fs0-admin-02/h/105 at Fri-15 604M - 343G - fs0-admin-02/h/105 at Fri-16 23.4M - 343G - (The second @Fri-16 snapshot was made when we discovered that the first one was missing.) As far as I can tell from 'zpool history', no errant broad 'zfs destroy' operations have been done against the pool that might have swept up these snapshots as a side effect. (I don't think thet's even possible, but ...) (Also, because of how our automation for this operates, I'm confident that none of the @Fri-NN snapshots existed before they were nominally created. If they had appeared in eg 'zfs list' output, the automation would have deleted them before trying to recreate them.) The fileserver in question has not suffered a power failure or crash since before this started happening. Does anyone have any idea what could be happening here? For example, is there some way where snapshots can be removed without that being logged in 'zpool history'? (I'm scrubbing the pool now, so far without errors.) Thanks in advance. - cks PS: we're on OmniOS r151014, kernel rev omnios-f090f73. Yes, I know, it's old. We like stability whenever possible, and testing & mostly qualifying upgrades takes a lot of work. (We can't be sure an upgrade works until we're running it in production, either; we can't reproduce production loads and stresses in testing.) From cks at cs.toronto.edu Fri Jan 6 23:09:22 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Fri, 06 Jan 2017 18:09:22 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots In-Reply-To: cks's message of Fri, 06 Jan 2017 17:22:57 -0500. <20170106222257.187DA5A0360@apps1.cs.toronto.edu> Message-ID: <20170106230922.6E3C75A0360@apps1.cs.toronto.edu> I wrote, quoting first 'zpool history' and then 'zfs list' output: [...] > 2017-01-06.15:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-15 > 2017-01-06.16:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-16 > 2017-01-06.16:45:55 zfs snapshot fs0-admin-02/h/105 at Fri-16 > 2017-01-06.16:45:55 zfs snapshot fs0-admin-02/h/105 at Fri-16 > > The actual snapshots present in the pool are: > NAME USED AVAIL REFER MOUNTPOINT > fs0-admin-02/h/105 at Fri-15 604M - 343G - > fs0-admin-02/h/105 at Fri-16 23.4M - 343G - The @Fri-15 snapshot has since vanished from the pool. The full 'zpool history' output since the first /h/105 at Fri-16 snapshot is: 2017-01-06.16:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-16 2017-01-06.16:10:01 zfs snapshot fs0-admin-02/h/193 at Fri-16 2017-01-06.16:10:06 zfs snapshot fs0-admin-02/h/194 at Fri-16 2017-01-06.16:43:03 zpool scrub fs0-admin-02 2017-01-06.16:45:55 zfs snapshot fs0-admin-02/h/105 at Fri-16 2017-01-06.17:10:11 zfs destroy fs0-admin-02/h/69 at Fri-17 2017-01-06.17:10:22 zfs destroy fs0-admin-02/h/70 at Fri-17 2017-01-06.17:10:32 zfs destroy fs0-admin-02/w/72 at Fri-17 2017-01-06.17:10:43 zfs destroy fs0-admin-02/h/193 at Fri-17 2017-01-06.17:10:54 zfs destroy fs0-admin-02/h/194 at Fri-17 2017-01-06.17:11:04 zfs snapshot fs0-admin-02/h/69 at Fri-17 2017-01-06.17:11:15 zfs snapshot fs0-admin-02/h/70 at Fri-17 2017-01-06.17:11:26 zfs snapshot fs0-admin-02/w/72 at Fri-17 2017-01-06.17:11:36 zfs snapshot fs0-admin-02/h/105 at Fri-17 2017-01-06.17:11:47 zfs snapshot fs0-admin-02/h/193 at Fri-17 2017-01-06.17:11:58 zfs snapshot fs0-admin-02/h/194 at Fri-17 And 'zfs list' says: NAME USED AVAIL REFER MOUNTPOINT fs0-admin-02/h/105 344G 107G 343G /h/105 fs0-admin-02/h/105 at Fri-16 712M - 343G - fs0-admin-02/h/105 at Fri-17 9.42M - 343G - This is completely mysterious to me. Any clues or things to look at are very welcome. - cks From danmcd at omniti.com Mon Jan 9 15:49:28 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 10:49:28 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots In-Reply-To: <20170106230922.6E3C75A0360@apps1.cs.toronto.edu> References: <20170106230922.6E3C75A0360@apps1.cs.toronto.edu> Message-ID: <6C62E1AE-CAE7-4CAD-8936-4D9AEE477413@omniti.com> > On Jan 6, 2017, at 6:09 PM, Chris Siebenmann wrote: > > The @Fri-15 snapshot has since vanished from the pool. The full > 'zpool history' output since the first /h/105 at Fri-16 snapshot is: > > 2017-01-06.16:10:01 zfs snapshot fs0-admin-02/h/105 at Fri-16 > 2017-01-06.16:10:01 zfs snapshot fs0-admin-02/h/193 at Fri-16 > 2017-01-06.16:10:06 zfs snapshot fs0-admin-02/h/194 at Fri-16 Look here... > 2017-01-06.16:43:03 zpool scrub fs0-admin-02 .... > 2017-01-06.16:45:55 zfs snapshot fs0-admin-02/h/105 at Fri-16 > 2017-01-06.17:10:11 zfs destroy fs0-admin-02/h/69 at Fri-17 > 2017-01-06.17:10:22 zfs destroy fs0-admin-02/h/70 at Fri-17 > 2017-01-06.17:10:32 zfs destroy fs0-admin-02/w/72 at Fri-17 > 2017-01-06.17:10:43 zfs destroy fs0-admin-02/h/193 at Fri-17 > 2017-01-06.17:10:54 zfs destroy fs0-admin-02/h/194 at Fri-17 > 2017-01-06.17:11:04 zfs snapshot fs0-admin-02/h/69 at Fri-17 > 2017-01-06.17:11:15 zfs snapshot fs0-admin-02/h/70 at Fri-17 > 2017-01-06.17:11:26 zfs snapshot fs0-admin-02/w/72 at Fri-17 > 2017-01-06.17:11:36 zfs snapshot fs0-admin-02/h/105 at Fri-17 > 2017-01-06.17:11:47 zfs snapshot fs0-admin-02/h/193 at Fri-17 > 2017-01-06.17:11:58 zfs snapshot fs0-admin-02/h/194 at Fri-17 > > And 'zfs list' says: > NAME USED AVAIL REFER MOUNTPOINT > fs0-admin-02/h/105 344G 107G 343G /h/105 > fs0-admin-02/h/105 at Fri-16 712M - 343G - > fs0-admin-02/h/105 at Fri-17 9.42M - 343G - > > This is completely mysterious to me. Any clues or things to look > at are very welcome. I wonder if the scrub has something to do with it? Are you in the middle of the scrub when noticing missing snapshots? Do they reappear after the scrub is done? The scrub seems like it's relevant. I take it you're doing a cron-driven scrub? If so, with what frequency? I'd normally push this along to the ZFS list, but given it's r151014 AND a non-updated r151014 at that, a bit more work here is probably a good idea. Dan From cks at cs.toronto.edu Mon Jan 9 15:56:19 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Mon, 09 Jan 2017 10:56:19 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots In-Reply-To: danmcd's message of Mon, 09 Jan 2017 10:49:28 -0500. <6C62E1AE-CAE7-4CAD-8936-4D9AEE477413@omniti.com> Message-ID: <20170109155619.675F35A06C3@apps1.cs.toronto.edu> > I wonder if the scrub has something to do with it? Are you in the > middle of the scrub when noticing missing snapshots? Do they reappear > after the scrub is done? The scrub seems like it's relevant. I take > it you're doing a cron-driven scrub? If so, with what frequency? We scrub periodically but relatively infrequently (roughly once every four weeks). That particular scrub was a manual one that I started by hand after noticing the latest round of missing snapshots, because scrubbing seemed like a good idea at that point (it was the second occurrence we'd spotted, soon followed by a third covered in the same email, and we've now had a fourth). The snapshots didn't reappear when the scrub finished (and the scrub reported no errors). - cks From cks at cs.toronto.edu Mon Jan 9 16:13:50 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Mon, 09 Jan 2017 11:13:50 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots In-Reply-To: cks's message of Fri, 06 Jan 2017 17:22:57 -0500. <20170106222257.187DA5A0360@apps1.cs.toronto.edu> Message-ID: <20170109161350.797815A06C3@apps1.cs.toronto.edu> I wrote, about our mysteriously disappearing snapshots: > [...] For example, is there some way where snapshots can be removed > without that being logged in 'zpool history'? The answer to my question turns out to be 'yes'. If you do: rmdir /.zfs/snapshot/ and ZFS accepts this, there is no entry made in 'zpool history'; the snapshot is silently deleted. A successful rmdir of a snapshot can be done by root either locally or over NFS, if the NFS client has been given root permissions. Like other snapshot removals, this rmdir will be blocked if the snapshot has a hold on it ('zfs hold'/'zfs release'). We have some client systems that have NFS root access to this filesystem. Notably, one of them is a Samba server, and it is possible that some Samba client is doing something that persuades the Samba server to issue a rmdir against .zfs/snapshot/ as root, possibly for all things in the directory that it sees at the time. I guess this is where I reach for DTrace to see if we can trace usage of this snapshot removal path to see if we can confirm that something is removing (or attempting to remove[*]) snapshots through this path. - cks [*: I have just changed our scripting to apply holds to all of these automatically created snapshots, and remove them just before the script would normally delete the snapshot. ] From miniflowtrader at gmail.com Mon Jan 9 16:25:20 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 09 Jan 2017 16:25:20 +0000 Subject: [OmniOS-discuss] LX Program Issue Message-ID: I have a program that is behaving differently in an LX environment. Specifically something about permission issues. I've corresponded with the author and they believe the issue could take place if the system was falsely reporting the status of a file e.g. file open instead of closed. Regardless issue does not happen if running Debian on VMware. What would be the appropriate route to go to report this bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 9 16:31:16 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 11:31:16 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots In-Reply-To: <20170109161350.797815A06C3@apps1.cs.toronto.edu> References: <20170109161350.797815A06C3@apps1.cs.toronto.edu> Message-ID: > On Jan 9, 2017, at 11:13 AM, Chris Siebenmann wrote: > > The answer to my question turns out to be 'yes'. If you do: > rmdir /.zfs/snapshot/ > > and ZFS accepts this, there is no entry made in 'zpool history'; the > snapshot is silently deleted. Now I wonder if THAT should be addressed as a ZFS bug? If you'd like, I can engage OpenZFS, or you can. And as for OmniOS availability, bugs fixed before end-of-May are 99%-likely to make it into r151022. 022 is going to break the 6-month cadence due to Python2.7 switch and the BSD Loader transition. Since you migrate on LTS released, 022 is where you'll likely jump-to-next (Am I right?). Thanks for the update! Dan From cks at cs.toronto.edu Mon Jan 9 16:39:16 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Mon, 09 Jan 2017 11:39:16 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots In-Reply-To: danmcd's message of Mon, 09 Jan 2017 11:31:16 -0500. Message-ID: <20170109163916.808C25A06C3@apps1.cs.toronto.edu> > > On Jan 9, 2017, at 11:13 AM, Chris Siebenmann wrote: > > > > The answer to my question turns out to be 'yes'. If you do: > > rmdir /.zfs/snapshot/ > > > > and ZFS accepts this, there is no entry made in 'zpool history'; the > > snapshot is silently deleted. > > Now I wonder if THAT should be addressed as a ZFS bug? > > If you'd like, I can engage OpenZFS, or you can. I'd be happy to see this addressed as a ZFS bug. I think it's better if you engaged OpenZFS on it; you're probably better set up to argue that this should show up in zpool history even if it's not a command as such. It turns out that you can also make snapshots with mkdir and they don't show up in zpool history either, so probably both issues should be raised and fixed as one. > And as for OmniOS availability, bugs fixed before end-of-May are > 99%-likely to make it into r151022. 022 is going to break the 6-month > cadence due to Python2.7 switch and the BSD Loader transition. Since > you migrate on LTS released, 022 is where you'll likely jump-to-next > (Am I right?). It's most likely that we'll go for LTS updates. My odds of persuading my co-workers to agree to an update are certainly much better when a new LTS release comes out and our current LTS release stops being supported. (My co-workers are rationally very conservative about changing a critical piece of our infrastructure when the current setup works, and it's basically impossible to fully test things short of throwing it into production.) - cks From danmcd at omniti.com Mon Jan 9 16:58:02 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 11:58:02 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: Message-ID: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> > On Jan 9, 2017, at 11:25 AM, Mini Trader wrote: > > I have a program that is behaving differently in an LX environment. Specifically something about permission issues. I've corresponded with the author and they believe the issue could take place if the system was falsely reporting the status of a file e.g. file open instead of closed. > > Regardless issue does not happen if running Debian on VMware. > > What would be the appropriate route to go to report this bug? Good question. The primary maintainers of LX are all at Joyent. Yet now LX has spread beyond just SmartOS/illumos-joyent. First off: Can you reduce your program (mis)behavior to a simple test case? If so, that'll be easier regardless of where you report it. I'm Bcc:ing some SmartOS people, who can either jump in here or tell me & you privately what they think the best course of action is. Thanks, Dan From danmcd at omniti.com Mon Jan 9 17:10:57 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 12:10:57 -0500 Subject: [OmniOS-discuss] Bloody users --> anyone have the install tools installed? Message-ID: <2C59EB2F-3868-4CDB-853E-3AA0B6C188D8@omniti.com> Hello! We're moving forward with our removal of Python2.6 from OmniOS. Internal tests show that the ability to upgrade appears to work, even when some installable components aren't using Python2.7 yet. These components are all part of the installer packages: system/install 0.5.11-0.151021 i-- system/install/configuration 0.5.11-0.151021 i-- system/library/install 0.5.11-0.151021 i-- install/distribution-constructor 0.5.11-0.151021 i-- I hope to have updated bloody bits out this week, but they will not included updated installer packages (this also means no ISO for this update). I don't see any good reason to hold up moving forward, but can be convinced with a VERY persuasive argument. Otherwise, consider this a warning email. Thanks, Dan From daleg at omniti.com Mon Jan 9 17:13:10 2017 From: daleg at omniti.com (Dale Ghent) Date: Mon, 9 Jan 2017 12:13:10 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: Message-ID: <308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com> Can you talk more about the program you're having issues with, how you're using it and how this problem is manifesting itself? /dale > On Jan 9, 2017, at 11:25 AM, Mini Trader wrote: > > I have a program that is behaving differently in an LX environment. Specifically something about permission issues. I've corresponded with the author and they believe the issue could take place if the system was falsely reporting the status of a file e.g. file open instead of closed. > > Regardless issue does not happen if running Debian on VMware. > > What would be the appropriate route to go to report this bug? > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Mon Jan 9 17:14:23 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 12:14:23 -0500 Subject: [OmniOS-discuss] Bloody users --> anyone have the install tools installed? In-Reply-To: <2C59EB2F-3868-4CDB-853E-3AA0B6C188D8@omniti.com> References: <2C59EB2F-3868-4CDB-853E-3AA0B6C188D8@omniti.com> Message-ID: And for the morbidly curious: http://kebe.com/~danmcd/webrevs/kill-26/ Dan From miniflowtrader at gmail.com Mon Jan 9 17:35:50 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 09 Jan 2017 17:35:50 +0000 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: <308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com> References: <308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com> Message-ID: The program is from hashbackup.com it's a backup utility that allows you to backup to backblaze To reproduce create a directory with some files. And instruct the program to backup the directory hb init -c hb # init backup to directory hb hb backup -c hb ./data # backup directory data hb backup -c hb ./data # Program crashes only on LX On Mon, Jan 9, 2017 at 12:13 PM Dale Ghent wrote: > > > Can you talk more about the program you're having issues with, how you're > using it and how this problem is manifesting itself? > > > > /dale > > > > > On Jan 9, 2017, at 11:25 AM, Mini Trader > wrote: > > > > > > I have a program that is behaving differently in an LX environment. > Specifically something about permission issues. I've corresponded with the > author and they believe the issue could take place if the system was > falsely reporting the status of a file e.g. file open instead of closed. > > > > > > Regardless issue does not happen if running Debian on VMware. > > > > > > What would be the appropriate route to go to report this bug? > > > _______________________________________________ > > > 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 miniflowtrader at gmail.com Mon Jan 9 17:36:57 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 09 Jan 2017 17:36:57 +0000 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com> Message-ID: The above was tested with Debian 8.6 SmartOS image. On Mon, Jan 9, 2017 at 12:35 PM Mini Trader wrote: > The program is from hashbackup.com it's a backup utility that allows you > to backup to backblaze > > To reproduce create a directory with some files. And instruct the program > to backup the directory > > hb init -c hb # init backup to directory hb > hb backup -c hb ./data # backup directory data > hb backup -c hb ./data # Program crashes only on LX > > > > On Mon, Jan 9, 2017 at 12:13 PM Dale Ghent wrote: > > > > Can you talk more about the program you're having issues with, how you're > using it and how this problem is manifesting itself? > > > > /dale > > > > > On Jan 9, 2017, at 11:25 AM, Mini Trader > wrote: > > > > > > I have a program that is behaving differently in an LX environment. > Specifically something about permission issues. I've corresponded with the > author and they believe the issue could take place if the system was > falsely reporting the status of a file e.g. file open instead of closed. > > > > > > Regardless issue does not happen if running Debian on VMware. > > > > > > What would be the appropriate route to go to report this bug? > > > _______________________________________________ > > > 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 skeltonr at btconnect.com Mon Jan 9 17:42:42 2017 From: skeltonr at btconnect.com (Richard Skelton) Date: Mon, 09 Jan 2017 17:42:42 +0000 Subject: [OmniOS-discuss] Where is the FTP server package Message-ID: <5873CB92.6070106@btconnect.com> Hi, I need an ftp server for a quick test and can't find the pkg On Solaris 11 it's part of network/ftp Cheers Richard From mir at miras.org Mon Jan 9 17:50:53 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 9 Jan 2017 18:50:53 +0100 Subject: [OmniOS-discuss] Where is the FTP server package In-Reply-To: <5873CB92.6070106@btconnect.com> References: <5873CB92.6070106@btconnect.com> Message-ID: <20170109185053.60144cf6@sleipner.datanom.net> On Mon, 09 Jan 2017 17:42:42 +0000 Richard Skelton wrote: > Hi, > I need an ftp server for a quick test and can't find the pkg > On Solaris 11 it's part of network/ftp > Lots of hits doing your search here but maybe you are looking for this? pkg search omnios/network/ftp INDEX ACTION VALUE PACKAGE pkg.fmri set omnios/network/ftp pkg:/network/ftp at 0.5.11-0.151014 -- 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: Debian Hint #5: If you need to build a custom kernel, use the 'make-kpkg' script found in the kernel-package package. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From skeltonr at btconnect.com Mon Jan 9 17:54:42 2017 From: skeltonr at btconnect.com (Richard Skelton) Date: Mon, 09 Jan 2017 17:54:42 +0000 Subject: [OmniOS-discuss] Where is the FTP server package In-Reply-To: <20170109185053.60144cf6@sleipner.datanom.net> References: <5873CB92.6070106@btconnect.com> <20170109185053.60144cf6@sleipner.datanom.net> Message-ID: <5873CE62.6090506@btconnect.com> Hi. I don't see that :-( # pkg publisher PUBLISHER TYPE STATUS P LOCATION omnios origin online F http://pkg.omniti.com/omnios/r151018/ ms.omniti.com origin online F http://pkg.omniti.com/omniti-ms/ # pkg search omnios/network/ftp # Michael Rasmussen wrote: > On Mon, 09 Jan 2017 17:42:42 +0000 > Richard Skelton wrote: > > >> Hi, >> I need an ftp server for a quick test and can't find the pkg >> On Solaris 11 it's part of network/ftp >> >> > Lots of hits doing your search here but maybe you are looking for this? > pkg search omnios/network/ftp > INDEX ACTION VALUE PACKAGE > pkg.fmri set omnios/network/ftp pkg:/network/ftp at 0.5.11-0.151014 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Mon Jan 9 18:01:16 2017 From: daleg at omniti.com (Dale Ghent) Date: Mon, 9 Jan 2017 13:01:16 -0500 Subject: [OmniOS-discuss] Where is the FTP server package In-Reply-To: <5873CB92.6070106@btconnect.com> References: <5873CB92.6070106@btconnect.com> Message-ID: <2B5B6AA7-F25F-4583-9171-6946C8C3C797@omniti.com> in.ftpd was removed in 2014 (ref: https://www.illumos.org/issues/5069). This coincided with the 151014 LTS release of OmniOS. ref: http://lists.omniti.com/pipermail/omnios-discuss/2014-September/003136.html /dale > On Jan 9, 2017, at 12:42 PM, Richard Skelton wrote: > > Hi, > I need an ftp server for a quick test and can't find the pkg > On Solaris 11 it's part of network/ftp > > Cheers > Richard > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From skeltonr at btconnect.com Mon Jan 9 18:37:39 2017 From: skeltonr at btconnect.com (Richard Skelton) Date: Mon, 09 Jan 2017 18:37:39 +0000 Subject: [OmniOS-discuss] Where is the FTP server package In-Reply-To: <2B5B6AA7-F25F-4583-9171-6946C8C3C797@omniti.com> References: <5873CB92.6070106@btconnect.com> <2B5B6AA7-F25F-4583-9171-6946C8C3C797@omniti.com> Message-ID: <5873D873.90809@btconnect.com> Hi Dale, Where is the proftpd package? Dale Ghent wrote: > in.ftpd was removed in 2014 (ref: https://www.illumos.org/issues/5069). This coincided with the 151014 LTS release of OmniOS. > > ref: http://lists.omniti.com/pipermail/omnios-discuss/2014-September/003136.html > > /dale > > >> On Jan 9, 2017, at 12:42 PM, Richard Skelton wrote: >> >> Hi, >> I need an ftp server for a quick test and can't find the pkg >> On Solaris 11 it's part of network/ftp >> >> Cheers >> Richard >> _______________________________________________ >> 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 daleg at omniti.com Mon Jan 9 19:13:49 2017 From: daleg at omniti.com (Dale Ghent) Date: Mon, 9 Jan 2017 14:13:49 -0500 Subject: [OmniOS-discuss] Where is the FTP server package In-Reply-To: <5873D873.90809@btconnect.com> References: <5873CB92.6070106@btconnect.com> <2B5B6AA7-F25F-4583-9171-6946C8C3C797@omniti.com> <5873D873.90809@btconnect.com> Message-ID: <6438FCFD-DD37-4CD4-A7E6-1413ED1C874B@omniti.com> The responder to that thread was mistaken - It was OI/hipster that introduced a proftpd package, which he confused with illumos-proper replacing wu-ftpd with proftpd. We elected to not ship a replacement FTP daemon in OmniOS, mainly because we saw no need to in light of SFTP being available, and no one from the community either strongly disagreed or provided a patch which re-added a FTP daemon to OmniOS in a supportable way. /dale > On Jan 9, 2017, at 1:37 PM, Richard Skelton wrote: > > Hi Dale, > Where is the proftpd package? > > Dale Ghent wrote: >> in.ftpd was removed in 2014 (ref: https://www.illumos.org/issues/5069 >> ). This coincided with the 151014 LTS release of OmniOS. >> >> ref: >> http://lists.omniti.com/pipermail/omnios-discuss/2014-September/003136.html >> >> >> /dale >> >> >> >>> On Jan 9, 2017, at 12:42 PM, Richard Skelton >>> wrote: >>> >>> Hi, >>> I need an ftp server for a quick test and can't find the pkg >>> On Solaris 11 it's part of network/ftp >>> >>> Cheers >>> Richard >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >>> >>> >> >> >> >> From miniflowtrader at gmail.com Mon Jan 9 19:31:55 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 09 Jan 2017 19:31:55 +0000 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> Message-ID: The test case was in my previous post. On Mon, Jan 9, 2017 at 1:53 PM Jerry Jelinek wrote: > A simple test case would be great, or at least we'll need details on what > you are running and how to reproduce the problem. You could also check the > known bug list at https://smartos.org/bugview/index.html, although > searching there is not very good. All open lx bugs are listed there under > OS-. > > Thanks, > Jerry > > > On Mon, Jan 9, 2017 at 9:58 AM, Dan McDonald wrote: > > > > > > On Jan 9, 2017, at 11:25 AM, Mini Trader > wrote: > > > > > > > > I have a program that is behaving differently in an LX environment. > Specifically something about permission issues. I've corresponded with the > author and they believe the issue could take place if the system was > falsely reporting the status of a file e.g. file open instead of closed. > > > > > > > > Regardless issue does not happen if running Debian on VMware. > > > > > > > > What would be the appropriate route to go to report this bug? > > > > > > Good question. > > > > > > The primary maintainers of LX are all at Joyent. Yet now LX has spread > beyond just SmartOS/illumos-joyent. > > > > > > First off: Can you reduce your program (mis)behavior to a simple test > case? If so, that'll be easier regardless of where you report it. > > > > > > I'm Bcc:ing some SmartOS people, who can either jump in here or tell me & > you privately what they think the best course of action is. > > > > > > Thanks, > > > Dan > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 9 19:34:08 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 14:34:08 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> Message-ID: > On Jan 9, 2017, at 2:31 PM, Mini Trader wrote: > > The test case was in my previous post. Does this require a whole wad of installation? I was hoping you (or the hashbackup folks) would be able to produce a smaller, easy-to-compile, test case of some sort. They told you what they thought the problem was, they should be able to extract the bit of failing code and shrink it to a test case. Dan From skeltonr at btconnect.com Mon Jan 9 19:36:54 2017 From: skeltonr at btconnect.com (Richard Skelton) Date: Mon, 09 Jan 2017 19:36:54 +0000 Subject: [OmniOS-discuss] Where is the FTP server package In-Reply-To: <2B5B6AA7-F25F-4583-9171-6946C8C3C797@omniti.com> References: <5873CB92.6070106@btconnect.com> <2B5B6AA7-F25F-4583-9171-6946C8C3C797@omniti.com> Message-ID: <5873E656.2080003@btconnect.com> Hi Dale, Thanks for your input.I am now clear on the OmniOS position. I have downloaded proftpd-1.3.5b and it compiles and runs fine for me simple test :-) Dale Ghent wrote: > in.ftpd was removed in 2014 (ref: https://www.illumos.org/issues/5069). This coincided with the 151014 LTS release of OmniOS. > > ref: http://lists.omniti.com/pipermail/omnios-discuss/2014-September/003136.html > > /dale > > >> On Jan 9, 2017, at 12:42 PM, Richard Skelton wrote: >> >> Hi, >> I need an ftp server for a quick test and can't find the pkg >> On Solaris 11 it's part of network/ftp >> >> Cheers >> Richard >> _______________________________________________ >> 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 miniflowtrader at gmail.com Mon Jan 9 19:58:06 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 09 Jan 2017 19:58:06 +0000 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> Message-ID: It's a single binary. That can be downloaded. I don't think the author is available to generate the test case. My question was as an end user how can we determine why the software is not working on LX. On Mon, Jan 9, 2017 at 2:34 PM Dan McDonald wrote: > On Jan 9, 2017, at 2:31 PM, Mini Trader wrote: > > The test case was in my previous post. Does this require a whole wad of installation? I was hoping you (or the hashbackup folks) would be able to produce a smaller, easy-to-compile, test case of some sort. They told you what they thought the problem was, they should be able to extract the bit of failing code and shrink it to a test case. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 9 20:07:32 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 15:07:32 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com> Message-ID: <43DC5C73-6B1D-4707-9EE3-E7138413131C@omniti.com> > On Jan 9, 2017, at 12:36 PM, Mini Trader wrote: > > The above was tested with Debian 8.6 SmartOS image. Hmmm... I wonder if there's a debian image problem or some other sort of issue. Perhaps the wrong kernel revision? Here it is on my CentOS 6.8: [root at lx0 ~]# /tmp/hb backup -c hb ./foo HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC Backup directory: /root/hb Backup start: 2017-01-09 20:04:47 Copied HB program to /root/hb/hb#1751 This is backup version: 0 Dedup not enabled; use -Dmemsize to enable /root/foo /root/foo/1 /root/hb/inex.conf Time: 0.2s CPU: 0.1s, 57% Checked: 6 paths, 106 bytes, 106 B Saved: 6 paths, 106 bytes, 106 B Excluded: 0 Dupbytes: 0 Space: 144 B, 139 KB total No errors [root at lx0 ~]# uname -a Linux lx0 2.6.32 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux [root at lx0 ~]# Here it is (with more complete output) on a Ubuntu 16 zone: Last login: Wed Dec 14 21:53:54 UTC 2016 from zone:global on pts/2 Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.3.0 x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage __ . . _| |_ | .-. . . .-. :--. |- |_ _| ;| || |(.-' | | | |__| `--' `-' `;-| `-' ' ' `-' / ; Instance (Ubuntu 16.04 20161004) `-' https://docs.joyent.com/images/container-native-linux root at ubuntu-14-04-b:~# mkdir foo root at ubuntu-14-04-b:~# echo 1 > foo/1 root at ubuntu-14-04-b:~# echo 2 > foo/2 root at ubuntu-14-04-b:~# /tmp/hb init -c hb HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC Backup directory: /root/hb Permissions set for owner access only Created key file /root/hb/key.conf Key file set to read-only Setting include/exclude defaults: /root/hb/inex.conf VERY IMPORTANT: your backup is encrypted and can only be accessed with the encryption key, stored in the file: /root/hb/key.conf You MUST make copies of this file and store them in a secure location, separate from your computer and backup data. If your hard drive fails, you will need this key to restore your files. If you setup any remote destinations in dest.conf, that file should be copied too. Backup directory initialized root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC Backup directory: /root/hb Backup start: 2017-01-09 20:06:09 Copied HB program to /root/hb/hb#1751 This is backup version: 0 Dedup not enabled; use -Dmemsize to enable /root/foo /root/foo/1 /root/foo/2 /root/hb/inex.conf Time: 0.2s CPU: 0.1s, 58% Checked: 7 paths, 108 bytes, 108 B Saved: 7 paths, 108 bytes, 108 B Excluded: 0 Dupbytes: 0 Space: 144 B, 139 KB total No errors root at ubuntu-14-04-b:~# uname -a Linux ubuntu-14-04-b 4.3.0 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux root at ubuntu-14-04-b:~# Dan From danmcd at omniti.com Mon Jan 9 20:08:34 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 15:08:34 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> Message-ID: <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> > On Jan 9, 2017, at 2:58 PM, Mini Trader wrote: > > It's a single binary. That can be downloaded. > Oh that's not so bad. You saw my other note. What I neglected to mention, however, is that my tests were on OmniOS bloody, which has more fixes from Joyent than r151020 does. Dan From miniflowtrader at gmail.com Mon Jan 9 20:22:33 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 09 Jan 2017 20:22:33 +0000 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> Message-ID: I tested on 1520. I also used Debian 8.6 and when I did a backup. The first one worked but a second call to same directory with no changes did not. On Mon, Jan 9, 2017 at 3:08 PM Dan McDonald wrote: > > > > On Jan 9, 2017, at 2:58 PM, Mini Trader > wrote: > > > > > > It's a single binary. That can be downloaded. > > > > > > > Oh that's not so bad. > > > > You saw my other note. > > > > What I neglected to mention, however, is that my tests were on OmniOS > bloody, which has more fixes from Joyent than r151020 does. > > > > Dan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 9 20:24:31 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 15:24:31 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> Message-ID: <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> > On Jan 9, 2017, at 3:22 PM, Mini Trader wrote: > > I also used Debian 8.6 and when I did a backup. The first one worked but a second call to same directory with no changes did not. Still bloody, the Ubuntu 16 zone, and it works with multiple followups: root at ubuntu-14-04-b:~# /tmp/hb init -c hb HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC Backup directory: /root/hb Permissions set for owner access only Created key file /root/hb/key.conf Key file set to read-only Setting include/exclude defaults: /root/hb/inex.conf VERY IMPORTANT: your backup is encrypted and can only be accessed with the encryption key, stored in the file: /root/hb/key.conf You MUST make copies of this file and store them in a secure location, separate from your computer and backup data. If your hard drive fails, you will need this key to restore your files. If you setup any remote destinations in dest.conf, that file should be copied too. Backup directory initialized root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC Backup directory: /root/hb Backup start: 2017-01-09 20:23:43 Copied HB program to /root/hb/hb#1751 This is backup version: 0 Dedup not enabled; use -Dmemsize to enable /root/foo /root/foo/1 /root/foo/2 /root/hb/inex.conf Time: 0.2s CPU: 0.1s, 52% Checked: 7 paths, 108 bytes, 108 B Saved: 7 paths, 108 bytes, 108 B Excluded: 0 Dupbytes: 0 Space: 144 B, 139 KB total No errors root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC Backup directory: /root/hb Backup start: 2017-01-09 20:23:44 This is backup version: 1 Dedup not enabled; use -Dmemsize to enable Time: 0.0s CPU: 0.0s, 91% Checked: 7 paths, 108 bytes, 108 B Saved: 3 paths, 0 bytes, 0 Excluded: 0 No errors root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC Backup directory: /root/hb Backup start: 2017-01-09 20:23:47 This is backup version: 2 Dedup not enabled; use -Dmemsize to enable Time: 0.0s CPU: 0.0s, 93% Checked: 7 paths, 108 bytes, 108 B Saved: 3 paths, 0 bytes, 0 Excluded: 0 No errors root at ubuntu-14-04-b:~# Dan From daleg at omniti.com Mon Jan 9 20:46:13 2017 From: daleg at omniti.com (Dale Ghent) Date: Mon, 9 Jan 2017 15:46:13 -0500 Subject: [OmniOS-discuss] Where is the FTP server package In-Reply-To: <5873E656.2080003@btconnect.com> References: <5873CB92.6070106@btconnect.com> <2B5B6AA7-F25F-4583-9171-6946C8C3C797@omniti.com> <5873E656.2080003@btconnect.com> Message-ID: <692B90AA-06F4-4623-BE83-95F0A93845B7@omniti.com> Yeah sorry for the confusion, I meant to link Dan's original post, not that reply to it. I guess the wrong thing ended up in my paste buffer! > On Jan 9, 2017, at 2:36 PM, Richard Skelton wrote: > > Hi Dale, > Thanks for your input.I am now clear on the OmniOS position. > I have downloaded proftpd-1.3.5b and it compiles and runs fine for me simple test :-) > > > Dale Ghent wrote: >> in.ftpd was removed in 2014 (ref: https://www.illumos.org/issues/5069 >> ). This coincided with the 151014 LTS release of OmniOS. >> >> ref: >> http://lists.omniti.com/pipermail/omnios-discuss/2014-September/003136.html >> >> >> /dale >> >> >> >>> On Jan 9, 2017, at 12:42 PM, Richard Skelton >>> wrote: >>> >>> Hi, >>> I need an ftp server for a quick test and can't find the pkg >>> On Solaris 11 it's part of network/ftp >>> >>> Cheers >>> Richard >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >>> >>> >> >> >> >> From miniflowtrader at gmail.com Tue Jan 10 01:09:16 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 9 Jan 2017 20:09:16 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> Message-ID: I can't reproduce this evening :) I started with a fresh install off the CD instead of upgrading from LTS. Will continue and get back to you. On Mon, Jan 9, 2017 at 3:24 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 3:22 PM, Mini Trader > wrote: > > > > I also used Debian 8.6 and when I did a backup. The first one worked but > a second call to same directory with no changes did not. > > Still bloody, the Ubuntu 16 zone, and it works with multiple followups: > > root at ubuntu-14-04-b:~# /tmp/hb init -c hb > HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC > Backup directory: /root/hb > Permissions set for owner access only > Created key file /root/hb/key.conf > Key file set to read-only > Setting include/exclude defaults: /root/hb/inex.conf > > VERY IMPORTANT: your backup is encrypted and can only be accessed with > the encryption key, stored in the file: > /root/hb/key.conf > You MUST make copies of this file and store them in a secure location, > separate from your computer and backup data. If your hard drive fails, > you will need this key to restore your files. If you setup any > remote destinations in dest.conf, that file should be copied too. > > Backup directory initialized > root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo > HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC > Backup directory: /root/hb > Backup start: 2017-01-09 20:23:43 > Copied HB program to /root/hb/hb#1751 > This is backup version: 0 > Dedup not enabled; use -Dmemsize to enable > /root/foo > /root/foo/1 > /root/foo/2 > /root/hb/inex.conf > > Time: 0.2s > CPU: 0.1s, 52% > Checked: 7 paths, 108 bytes, 108 B > Saved: 7 paths, 108 bytes, 108 B > Excluded: 0 > Dupbytes: 0 > Space: 144 B, 139 KB total > No errors > root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo > HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC > Backup directory: /root/hb > Backup start: 2017-01-09 20:23:44 > This is backup version: 1 > Dedup not enabled; use -Dmemsize to enable > > Time: 0.0s > CPU: 0.0s, 91% > Checked: 7 paths, 108 bytes, 108 B > Saved: 3 paths, 0 bytes, 0 > Excluded: 0 > No errors > root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo > HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC > Backup directory: /root/hb > Backup start: 2017-01-09 20:23:47 > This is backup version: 2 > Dedup not enabled; use -Dmemsize to enable > > Time: 0.0s > CPU: 0.0s, 93% > Checked: 7 paths, 108 bytes, 108 B > Saved: 3 paths, 0 bytes, 0 > Excluded: 0 > No errors > root at ubuntu-14-04-b:~# > > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Jan 10 01:11:03 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 20:11:03 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> Message-ID: <2044EEC2-68B2-4748-AA76-4EF388DFDEEA@omniti.com> > On Jan 9, 2017, at 8:09 PM, Mini Trader wrote: > > I can't reproduce this evening :) I started with a fresh install off the CD instead of upgrading from LTS. Will continue and get back to you. That should be a NOP, you'll land on the same r151020 bits. Share your "zonecfg -z lx-zone export" and what image you used so I can see if it's an 020-specific bug or not. Thanks, Dan From miniflowtrader at gmail.com Tue Jan 10 01:56:15 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 9 Jan 2017 20:56:15 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: <2044EEC2-68B2-4748-AA76-4EF388DFDEEA@omniti.com> References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <2044EEC2-68B2-4748-AA76-4EF388DFDEEA@omniti.com> Message-ID: One thing that is weird. I am seeing that after installing the zone. I get the following error when shutting down or rebooting. Often followed by a kernel panic. showmount: hostname: RPC: Program Not registered On Mon, Jan 9, 2017 at 8:11 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 8:09 PM, Mini Trader > wrote: > > > > I can't reproduce this evening :) I started with a fresh install off > the CD instead of upgrading from LTS. Will continue and get back to you. > > That should be a NOP, you'll land on the same r151020 bits. > > Share your "zonecfg -z lx-zone export" and what image you used so I can > see if it's an 020-specific bug or not. > > Thanks, > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Tue Jan 10 02:51:36 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 9 Jan 2017 21:51:36 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> Message-ID: So I tried the following. 1. Update my system from LTS to stable. 2. Setup the LX System The same way I tested before. 3. Download the program again It failed. Basically I have a successful run off of a fresh install and a failed run off of a non fresh install. Will try a fresh install of LTS, and an update up to 20 to see if that makes a difference. Weird. On Mon, Jan 9, 2017 at 8:09 PM, Mini Trader wrote: > I can't reproduce this evening :) I started with a fresh install off the > CD instead of upgrading from LTS. Will continue and get back to you. > > On Mon, Jan 9, 2017 at 3:24 PM, Dan McDonald wrote: > >> >> > On Jan 9, 2017, at 3:22 PM, Mini Trader >> wrote: >> > >> > I also used Debian 8.6 and when I did a backup. The first one worked >> but a second call to same directory with no changes did not. >> >> Still bloody, the Ubuntu 16 zone, and it works with multiple followups: >> >> root at ubuntu-14-04-b:~# /tmp/hb init -c hb >> HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC >> Backup directory: /root/hb >> Permissions set for owner access only >> Created key file /root/hb/key.conf >> Key file set to read-only >> Setting include/exclude defaults: /root/hb/inex.conf >> >> VERY IMPORTANT: your backup is encrypted and can only be accessed with >> the encryption key, stored in the file: >> /root/hb/key.conf >> You MUST make copies of this file and store them in a secure location, >> separate from your computer and backup data. If your hard drive fails, >> you will need this key to restore your files. If you setup any >> remote destinations in dest.conf, that file should be copied too. >> >> Backup directory initialized >> root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo >> HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC >> Backup directory: /root/hb >> Backup start: 2017-01-09 20:23:43 >> Copied HB program to /root/hb/hb#1751 >> This is backup version: 0 >> Dedup not enabled; use -Dmemsize to enable >> /root/foo >> /root/foo/1 >> /root/foo/2 >> /root/hb/inex.conf >> >> Time: 0.2s >> CPU: 0.1s, 52% >> Checked: 7 paths, 108 bytes, 108 B >> Saved: 7 paths, 108 bytes, 108 B >> Excluded: 0 >> Dupbytes: 0 >> Space: 144 B, 139 KB total >> No errors >> root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo >> HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC >> Backup directory: /root/hb >> Backup start: 2017-01-09 20:23:44 >> This is backup version: 1 >> Dedup not enabled; use -Dmemsize to enable >> >> Time: 0.0s >> CPU: 0.0s, 91% >> Checked: 7 paths, 108 bytes, 108 B >> Saved: 3 paths, 0 bytes, 0 >> Excluded: 0 >> No errors >> root at ubuntu-14-04-b:~# /tmp/hb backup -c hb foo >> HashBackup build #1751 Copyright 2009-2017 HashBackup, LLC >> Backup directory: /root/hb >> Backup start: 2017-01-09 20:23:47 >> This is backup version: 2 >> Dedup not enabled; use -Dmemsize to enable >> >> Time: 0.0s >> CPU: 0.0s, 93% >> Checked: 7 paths, 108 bytes, 108 B >> Saved: 3 paths, 0 bytes, 0 >> Excluded: 0 >> No errors >> root at ubuntu-14-04-b:~# >> >> >> Dan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Jan 10 02:52:39 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 21:52:39 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> Message-ID: <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> > On Jan 9, 2017, at 9:51 PM, Mini Trader wrote: > > 2. Setup the LX System The same way I tested before. > I want that setup! I want: - zonecfg input (modulo IP addresses) - image you used I can test it on 020 and bloody, to see if it's a problem fixed post-020. Dan From miniflowtrader at gmail.com Tue Jan 10 03:01:45 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 9 Jan 2017 22:01:45 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> Message-ID: # zonecfg -z lx0 create set zonepath=/main/zones/lx0 set brand=lx set autoboot=false set ip-type=exclusive add net set physical=vmxnet3s2 add property (name=gateway,value="10.255.0.1") add property (name=ips,value="10.255.0.16/24") add property (name=primary,value="true") end add attr set name=dns-domain set type=string set value=mydomain.systems end add attr set name=resolvers set type=string set value=10.255.0.1 end add attr set name=kernel-version set type=string set value=3.16.0 end exit Image was from here: https://images.joyent.com/images/9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1/file Just to reiterate on a fresh install of 20 I got no error. Different hardware too. On Mon, Jan 9, 2017 at 9:52 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 9:51 PM, Mini Trader > wrote: > > > > 2. Setup the LX System The same way I tested before. > > > > I want that setup! I want: > > - zonecfg input (modulo IP addresses) > > - image you used > > I can test it on 020 and bloody, to see if it's a problem fixed post-020. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Jan 10 03:03:34 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 9 Jan 2017 22:03:34 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> Message-ID: <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com> > On Jan 9, 2017, at 10:01 PM, Mini Trader wrote: > > Just to reiterate on a fresh install of 20 I got no error. Different hardware too. WEIRD. (Sorry I didn't catch that earlier. Juggling other balls concurrently!) Okay, thanks for the update. Not sure if there's anything I can do in the immediate term, but thanks for keeping me informed (and giving me the full zonecfg). Thanks! Dan From miniflowtrader at gmail.com Tue Jan 10 04:18:52 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 9 Jan 2017 23:18:52 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com> References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com> Message-ID: So i have reproducible steps and also solve my problem. If I create my dataset via napp-it. It seems like it applies special permissions. LX will complain that other and group should not have write permissions on the zone directory. So I remove these via chmod o-w and chmod g-w. At this point I can create the zone and in doing so I can reproduce the error. If I create the data set with your standard zfs create tank/zones the permissions are fine by default and the bug is not reproducible. So somehow somewhere whatever is happening underneath the hood is sensitive to these permissions on the second write in this program. Strange indeed. On Mon, Jan 9, 2017 at 10:03 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 10:01 PM, Mini Trader > wrote: > > > > Just to reiterate on a fresh install of 20 I got no error. Different > hardware too. > > WEIRD. (Sorry I didn't catch that earlier. Juggling other balls > concurrently!) > > Okay, thanks for the update. Not sure if there's anything I can do in the > immediate term, but thanks for keeping me informed (and giving me the full > zonecfg). > > Thanks! > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alka at hfg-gmuend.de Tue Jan 10 09:42:51 2017 From: alka at hfg-gmuend.de (Guenther Alka) Date: Tue, 10 Jan 2017 10:42:51 +0100 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com> Message-ID: <84b131d8-b4c7-4cda-449c-0ab1b38a83b2@hfg-gmuend.de> When you create a filesystem in napp-it it is writeable for everyone as this is what you mayexpect in an SMB filer use (be Windows alike) LX zone folder require a 700 permission. I have updated current napp-it 17.01 to restrict permissions automatically when you create a zone in napp-it. You can also set nics and mounts for ZFS filesystems now during the VM creation process. see http://www.napp-it.org/doc/downloads/zones.pdf Gea Am 10.01.2017 um 05:18 schrieb Mini Trader: > So i have reproducible steps and also solve my problem. > > If I create my dataset via napp-it. It seems like it applies special > permissions. LX will complain that other and group should not have > write permissions on the zone directory. So I remove these via chmod > o-w and chmod g-w. > > At this point I can create the zone and in doing so I can reproduce > the error. If I create the data set with your standard zfs create > tank/zones the permissions are fine by default and the bug is not > reproducible. > > So somehow somewhere whatever is happening underneath the hood is > sensitive to these permissions on the second write in this program. > > Strange indeed. > > On Mon, Jan 9, 2017 at 10:03 PM, Dan McDonald > wrote: > > > > On Jan 9, 2017, at 10:01 PM, Mini Trader > > wrote: > > > > Just to reiterate on a fresh install of 20 I got no error. > Different hardware too. > > WEIRD. (Sorry I didn't catch that earlier. Juggling other balls > concurrently!) > > Okay, thanks for the update. Not sure if there's anything I can > do in the immediate term, but thanks for keeping me informed (and > giving me the full zonecfg). > > Thanks! > Dan > > > > > _______________________________________________ > 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 kiv at kiv.pp.ru Tue Jan 10 10:40:33 2017 From: kiv at kiv.pp.ru (=?UTF-8?B?0JjQu9GM0Y8g0JrRg9C70LDQs9C40L0=?=) Date: Tue, 10 Jan 2017 13:40:33 +0300 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com> Message-ID: <9694c37d-818b-1c8c-64c8-5d6ee8e919bc@kiv.pp.ru> Hi all. 1st, it seems to me that it is necessary for all lx-users to find/share/explain some common steps to debug software misbehaviour in lx zone. Because for my (very small, of course) practice, linux software often is based on strange assumptions and even 'dirty hacks'. Maybe with dtrace, like it was done for 'unimplemented syscalls' in SmartOS wiki https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBrandedZones-huntingforunsupportedsyscalls Maybe whatelse... > So i have reproducible steps and also solve my problem. > > If I create my dataset via napp-it. It seems like it applies special > permissions. LX will complain that other and group should not have > write permissions on the zone directory. So I remove these via chmod > o-w and chmod g-w. I think that in this case it will be useful that you compare full zfs properties list (`zfs get all ` for zone root) and full acls (`/usr/bin/ls -lV ` -- of course, issued from host with zone running to display actual permissions while FS is mounted) for both zones - working and crashing ones. > > At this point I can create the zone and in doing so I can reproduce > the error. If I create the data set with your standard zfs create > tank/zones the permissions are fine by default and the bug is not > reproducible. > > So somehow somewhere whatever is happening underneath the hood is > sensitive to these permissions on the second write in this program. > > Strange indeed. > > On Mon, Jan 9, 2017 at 10:03 PM, Dan McDonald > wrote: > > > > On Jan 9, 2017, at 10:01 PM, Mini Trader > > wrote: > > > > Just to reiterate on a fresh install of 20 I got no error. > Different hardware too. > > WEIRD. (Sorry I didn't catch that earlier. Juggling other balls > concurrently!) > > Okay, thanks for the update. Not sure if there's anything I can > do in the immediate term, but thanks for keeping me informed (and > giving me the full zonecfg). > > Thanks! > Dan > > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3808 bytes Desc: Firma criptogr??fica S/MIME URL: From chip at innovates.com Tue Jan 10 13:41:52 2017 From: chip at innovates.com (Schweiss, Chip) Date: Tue, 10 Jan 2017 07:41:52 -0600 Subject: [OmniOS-discuss] Network >10Gb/s Message-ID: It appears that my options for 40Gb/s Ethernet are Intel, Chelsio and SolarFlare. Can anyone comment on which of these is the most stable solution when running under OmniOS? What's the fastest NFS throughput you've been able to achieve? Also is there any work being done by anyone to bring an Omni-Path compatible NIC to Illumos/OmniOS? Thanks! -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Tue Jan 10 14:04:39 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Tue, 10 Jan 2017 09:04:39 -0500 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: <9694c37d-818b-1c8c-64c8-5d6ee8e919bc@kiv.pp.ru> References: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com> <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com> <9694c37d-818b-1c8c-64c8-5d6ee8e919bc@kiv.pp.ru> Message-ID: Working + Broken Config below. On a positive note I'm very happy this is working. The performance improvement over a VM using NFS on a virtual 10GBE switch is significant. Working root at storage1:/main# zfs get all main/zones NAME PROPERTY VALUE SOURCE main/zones type filesystem - main/zones creation Tue Jan 10 4:20 2017 - main/zones used 7.53G - main/zones available 3.71T - main/zones referenced 226M - main/zones compressratio 1.06x - main/zones mounted yes - main/zones quota none default main/zones reservation none default main/zones recordsize 128K default main/zones mountpoint /main/zones default main/zones sharenfs off default main/zones checksum on default main/zones compression lz4 inherited from main main/zones atime on default main/zones devices on default main/zones exec on default main/zones setuid on default main/zones readonly off default main/zones zoned off default main/zones snapdir hidden default main/zones aclmode discard default main/zones aclinherit restricted default main/zones canmount on default main/zones xattr on default main/zones copies 1 default main/zones version 5 - main/zones utf8only off - main/zones normalization none - main/zones casesensitivity sensitive - main/zones vscan off default main/zones nbmand off default main/zones sharesmb off default main/zones refquota none default main/zones refreservation none default main/zones primarycache all default main/zones secondarycache all default main/zones usedbysnapshots 0 - main/zones usedbydataset 226M - main/zones usedbychildren 7.31G - main/zones usedbyrefreservation 0 - main/zones logbias latency default main/zones dedup off default main/zones mlslabel none default main/zones sync standard default main/zones refcompressratio 2.05x - main/zones written 226M - main/zones logicalused 7.96G - main/zones logicalreferenced 463M - main/zones filesystem_limit none default main/zones snapshot_limit none default main/zones filesystem_count none default main/zones snapshot_count none default main/zones redundant_metadata all default root at storage1:/main# /usr/bin/ls -lV zones/ total 2 drwxr-xr-x 2 root root 3 Jan 10 04:20 images owner@:rwxp-DaARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow drwx------ 4 root root 5 Jan 10 13:20 lx0 owner@:rwxp-DaARWcCos:-------:allow group@:------a-R-c--s:-------:allow everyone@:------a-R-c--s:-------:allow Broken root at storage1:/main# zfs get all main/zones NAME PROPERTY VALUE SOURCE main/zones type filesystem - main/zones creation Tue Jan 10 13:57 2017 - main/zones used 226M - main/zones available 3.71T - main/zones referenced 226M - main/zones compressratio 2.05x - main/zones mounted yes - main/zones quota none default main/zones reservation none default main/zones recordsize 128K default main/zones mountpoint /main/zones default main/zones sharenfs off default main/zones checksum on default main/zones compression lz4 inherited from main main/zones atime off local main/zones devices on default main/zones exec on default main/zones setuid on default main/zones readonly off default main/zones zoned off default main/zones snapdir hidden local main/zones aclmode passthrough local main/zones aclinherit passthrough local main/zones canmount on default main/zones xattr on default main/zones copies 1 default main/zones version 5 - main/zones utf8only on - main/zones normalization formD - main/zones casesensitivity insensitive - main/zones vscan off default main/zones nbmand on local main/zones sharesmb off local main/zones refquota none default main/zones refreservation none default main/zones primarycache all default main/zones secondarycache all default main/zones usedbysnapshots 0 - main/zones usedbydataset 226M - main/zones usedbychildren 0 - main/zones usedbyrefreservation 0 - main/zones logbias latency default main/zones dedup off default main/zones mlslabel none default main/zones sync standard default main/zones refcompressratio 2.05x - main/zones written 226M - main/zones logicalused 463M - main/zones logicalreferenced 463M - main/zones filesystem_limit none default main/zones snapshot_limit none default main/zones filesystem_count none default main/zones snapshot_count none default main/zones redundant_metadata all default root at storage1:/main# /usr/bin/ls -lV ./zones/ total 1 drwxrwxrwx+ 2 root root 3 Jan 10 13:57 images user:root:rwxpdDaARWcCos:fd----I:allow everyone@:rwxpdDaARWc--s:fd----I:allow owner@:rwxp-DaARWcCos:-------:allow group@:r-x---a-R-c--s:-------:allow everyone@:r-x---a-R-c--s:-------:allow On Tue, Jan 10, 2017 at 5:40 AM, ???? ??????? wrote: > Hi all. > > 1st, it seems to me that it is necessary for all lx-users to > find/share/explain some common steps to debug software misbehaviour in lx > zone. Because for my (very small, of course) practice, linux software often > is based on strange assumptions and even 'dirty hacks'. > Maybe with dtrace, like it was done for 'unimplemented syscalls' in > SmartOS wiki https://wiki.smartos.org/display/DOC/LX+Branded+Zones# > LXBrandedZones-huntingforunsupportedsyscalls > Maybe whatelse... > > So i have reproducible steps and also solve my problem. > > If I create my dataset via napp-it. It seems like it applies special > permissions. LX will complain that other and group should not have write > permissions on the zone directory. So I remove these via chmod o-w and > chmod g-w. > > > I think that in this case it will be useful that you compare full zfs > properties list (`zfs get all ` for zone root) and full acls (`/usr/bin/ls > -lV ` -- of course, issued from host with zone running to display actual > permissions while FS is mounted) for both zones - working and crashing ones. > > > At this point I can create the zone and in doing so I can reproduce the > error. If I create the data set with your standard zfs create tank/zones > the permissions are fine by default and the bug is not reproducible. > > So somehow somewhere whatever is happening underneath the hood is > sensitive to these permissions on the second write in this program. > > Strange indeed. > > On Mon, Jan 9, 2017 at 10:03 PM, Dan McDonald wrote: > >> >> > On Jan 9, 2017, at 10:01 PM, Mini Trader >> wrote: >> > >> > Just to reiterate on a fresh install of 20 I got no error. Different >> hardware too. >> >> WEIRD. (Sorry I didn't catch that earlier. Juggling other balls >> concurrently!) >> >> Okay, thanks for the update. Not sure if there's anything I can do in >> the immediate term, but thanks for keeping me informed (and giving me the >> full zonecfg). >> >> Thanks! >> Dan >> >> > > > _______________________________________________ > OmniOS-discuss mailing listOmniOS-discuss at lists.omniti.comhttp://lists.omniti.com/mailman/listinfo/omnios-discuss > > > -- > ? ?????????, ???? ??????? > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at will.to Tue Jan 10 14:18:56 2017 From: doug at will.to (Doug Hughes) Date: Tue, 10 Jan 2017 09:18:56 -0500 Subject: [OmniOS-discuss] Network >10Gb/s In-Reply-To: References: Message-ID: When I had it in production, I used SolarFlare for 10g (but not 40). I'm contributing this in case it helps..SolarFlare open sourced the code and contributed it and there have been a couple of posts to this list in the past with the updated stuff. (I contributed some fixes for add_drv). It worked very well. With the right workload, I could definitely nearly saturate the NIC (e.g. very large files streaming). say 85%+ utilization. I have not tried 40Gb. On 1/10/2017 8:41 AM, Schweiss, Chip wrote: > It appears that my options for 40Gb/s Ethernet are Intel, Chelsio and > SolarFlare. > > Can anyone comment on which of these is the most stable solution when > running under OmniOS? What's the fastest NFS throughput you've been > able to achieve? > > Also is there any work being done by anyone to bring an Omni-Path > compatible NIC to Illumos/OmniOS? > > Thanks! > -Chip > > > > _______________________________________________ > 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 kiv at kiv.pp.ru Tue Jan 10 14:44:26 2017 From: kiv at kiv.pp.ru (=?UTF-8?B?0JjQu9GM0Y8g0JrRg9C70LDQs9C40L0=?=) Date: Tue, 10 Jan 2017 17:44:26 +0300 Subject: [OmniOS-discuss] LX Program Issue In-Reply-To: References: <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com> <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com> <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com> <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com> <9694c37d-818b-1c8c-64c8-5d6ee8e919bc@kiv.pp.ru> Message-ID: Hi MT! And which significant differences I see in zfs properties (sorry for HTML but without it -- the difference is not so evident): |Good | |Broken | | | | | |NAME PROPERTY VALUE SOURCE| |NAME PROPERTY VALUE SOURCE| |main/zones atime on default | |main/zones atime off local | |main/zones aclmode discard default | |main/zones aclmode passthrough local | |main/zones aclinherit restricted default | |main/zones aclinherit passthrough local | |main/zones utf8only off -| |main/zones utf8only on -| |main/zones normalization none -| |main/zones normalization formD -| |main/zones casesensitivity sensitive -| |main/zones casesensitivity insensitive -| |main/zones nbmand off default | |main/zones nbmand on local | || 1. Atime. Maybe this backup software relies on atime some way? Anyway, atime for root FS is important. 2. Aclmode+aclinherit. These are for ACLs. Non-defaults are used for shares, for root FS the default is must. 3. Utf8only+normalization+casesensitivity. These are for file names. Maybe backup assumes that, ex., .lock and .LOCK are different files (usually on UNIX and Linux tis is true ;) ). BTW Linux (like UNIX or BSD or evem MacOS) likes case-sensitivity and "insensitive" is for network shares for windows-like clients. 4. Nbmand. This is some kind of locking, I don't know details. But I also think that non-default is not a good idea for linux root. So, I think that "right column" is not siutable as linux root filesystem - because of case insensitivity, atime=off and uncommon acls+nbmand. This is my opinion. And if You want - You definitely can fix these settings one by one and realize what is the unique cause of backup creash. It seems so. -- ? ?????????, ???? ??????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3808 bytes Desc: Firma criptogr??fica S/MIME URL: From danmcd at omniti.com Tue Jan 10 15:58:56 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 10 Jan 2017 10:58:56 -0500 Subject: [OmniOS-discuss] Network >10Gb/s In-Reply-To: References: Message-ID: > On Jan 10, 2017, at 8:41 AM, Schweiss, Chip wrote: > > It appears that my options for 40Gb/s Ethernet are Intel, Chelsio and SolarFlare. > > Can anyone comment on which of these is the most stable solution when running under OmniOS? What's the fastest NFS throughput you've been able to achieve? The Intel i40e driver is nascent, but it will receive more attention as time passes. Doug's point about SolarFlare is a good one. You may wish to ping the larger illumos community about this as well. Dan From chip at innovates.com Tue Jan 10 16:10:47 2017 From: chip at innovates.com (Schweiss, Chip) Date: Tue, 10 Jan 2017 10:10:47 -0600 Subject: [OmniOS-discuss] Network >10Gb/s In-Reply-To: References: Message-ID: On Tue, Jan 10, 2017 at 9:58 AM, Dan McDonald wrote: > > > On Jan 10, 2017, at 8:41 AM, Schweiss, Chip wrote: > > > > It appears that my options for 40Gb/s Ethernet are Intel, Chelsio and > SolarFlare. > > > > Can anyone comment on which of these is the most stable solution when > running under OmniOS? What's the fastest NFS throughput you've been able > to achieve? > > The Intel i40e driver is nascent, but it will receive more attention as > time passes. Doug's point about SolarFlare is a good one. > > I'm a bit concerned on the Intel because of posts like this: https://news.ycombinator.com/item?id=11373848 and the fact that they seem to have shifted their focus to Omni-Path which from my understanding is incompatible with the existing 40G gear. SolarFlare seems promising, but I'd like to know of at least on success story. -Chip > You may wish to ping the larger illumos community about this as well. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Jan 10 16:15:13 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 10 Jan 2017 11:15:13 -0500 Subject: [OmniOS-discuss] Network >10Gb/s In-Reply-To: References: Message-ID: <955F208B-CA50-45FC-948F-FBF46082B235@omniti.com> > On Jan 10, 2017, at 11:10 AM, Schweiss, Chip wrote: > > I'm a bit concerned on the Intel because of posts like this: https://news.ycombinator.com/item?id=11373848 and the fact that they seem to have shifted their focus to Omni-Path which from my understanding is incompatible with the existing 40G gear. > Wow, I hadn't read that. That's depressing (and strikes familiar pain points, given I did work a bit on i40e early on). Dan From ikaufman at eng.ucsd.edu Tue Jan 10 16:24:12 2017 From: ikaufman at eng.ucsd.edu (Ian Kaufman) Date: Tue, 10 Jan 2017 08:24:12 -0800 Subject: [OmniOS-discuss] Network >10Gb/s In-Reply-To: References: Message-ID: Hmm, as far as I know, Omni-Path is not an ethernet replacement, but an IB replacement. While Intel is investing heavily in Omni-Path, it should not impact their ethernet offerings as they really are two different markets. Ian On Tue, Jan 10, 2017 at 8:10 AM, Schweiss, Chip wrote: > > On Tue, Jan 10, 2017 at 9:58 AM, Dan McDonald wrote: > >> >> > On Jan 10, 2017, at 8:41 AM, Schweiss, Chip wrote: >> > >> > It appears that my options for 40Gb/s Ethernet are Intel, Chelsio and >> SolarFlare. >> > >> > Can anyone comment on which of these is the most stable solution when >> running under OmniOS? What's the fastest NFS throughput you've been able >> to achieve? >> >> The Intel i40e driver is nascent, but it will receive more attention as >> time passes. Doug's point about SolarFlare is a good one. >> >> > I'm a bit concerned on the Intel because of posts like this: > https://news.ycombinator.com/item?id=11373848 and the fact that they > seem to have shifted their focus to Omni-Path which from my understanding > is incompatible with the existing 40G gear. > > SolarFlare seems promising, but I'd like to know of at least on success > story. > > -Chip > > > >> You may wish to ping the larger illumos community about this as well. >> > > >> Dan >> >> > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -- Ian Kaufman Research Systems Administrator UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From cks at cs.toronto.edu Tue Jan 10 17:05:14 2017 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Tue, 10 Jan 2017 12:05:14 -0500 Subject: [OmniOS-discuss] A problem and puzzle with disappearing ZFS snapshots In-Reply-To: cks's message of Mon, 09 Jan 2017 11:13:50 -0500. <20170109161350.797815A06C3@apps1.cs.toronto.edu> Message-ID: <20170110170514.52F875AC819@apps1.cs.toronto.edu> For the interest of bystanders, here's the resolution to our puzzle. I wrote: > I wrote, about our mysteriously disappearing snapshots: > > [...] For example, is there some way where snapshots can be removed > > without that being logged in 'zpool history'? > > The answer to my question turns out to be 'yes'. If you do: > rmdir /.zfs/snapshot/ > > and ZFS accepts this, there is no entry made in 'zpool history'; the > snapshot is silently deleted. This is actually wrong, because it turns out that I hadn't read the zpool manpage about 'zpool history' carefully enough. By default 'zpool history' shows only ZFS commands; however, you can get it to show 'internally logged ZFS events' in addition with the -i switch, and this did show our snapshot deletions. ('zpool history -i' has some interesting output around scrubs and resilvers too.) > A successful rmdir of a snapshot can be done by root either locally > or over NFS, if the NFS client has been given root permissions. Like > other snapshot removals, this rmdir will be blocked if the snapshot > has a hold on it ('zfs hold'/'zfs release'). > > We have some client systems that have NFS root access to this > filesystem. Notably, one of them is a Samba server, and it is > possible that some Samba client is doing something that persuades the > Samba server to issue a rmdir against .zfs/snapshot/ as > root, possibly for all things in the directory that it sees at the > time. It turns out that I was unjustly suspicious of Samba. The real culprit was part of our home-grown NFS mount management system, which will unmount NFS filesystems that it thinks are not supposed to be there and as part of doing this will rmdir their mount point directories. When it was dealing with a snapshot NFS mount, this rmdir naturally deleted the snapshot (well, when done from our Samba server, with its root permissions). Snapshots were being accessed on our Samba server for the straightforward reason that some users were looking in them for deleted files. (Linux materializes synthetic NFS mounts for .zfs/snapshot/ filesystems when they're accessed on a NFS client. These are almost undistinguishable from regular NFS mounts, so our NFS mount management system saw them as extra, not-supposed-to-be-there NFS mounts that it should deal with.) I'd like to thank Dan McDonald and the others here for their help in leading me towards the ultimate solution. - cks From hasslerd at gmx.li Tue Jan 10 22:04:56 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Tue, 10 Jan 2017 23:04:56 +0100 Subject: [OmniOS-discuss] LX zones: configurations Message-ID: Hi, I thought it might be good to have a public spreadsheet to post LX zone setups and how/if they work. It is not meant to be the book of wisdom, but should encourage people who are thinking of running the same service(s) in an LX zone, to actually try it if they see that someone else already did it before. Even if you plan to use a different distro, it might give you some confidence to step forward. This is just a basic start. Feel free to reformat it, add missing columns etc... If it is found to be useful, ownership could be transferred to OmniTI and linked to the wiki (w/ additional information). http://tinyurl.com/hajz4ap @Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is there a chance to get LX bleeding edge in r20 w/o the risk of breaking something else? From danmcd at omniti.com Tue Jan 10 23:03:36 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 10 Jan 2017 18:03:36 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: Message-ID: > On Jan 10, 2017, at 5:04 PM, Dominik Hassler wrote: > > @Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is there a chance to get LX bleeding edge in r20 w/o the risk of breaking something else? Given how encompassing the 022 work is, don't hold your breath. If there are real, provable show-stoppers in LX, fixes may get backported. Also, the big other change for LX I want in 022 is ipadm(1M) being able to work in an LX zone, so you don't have to do zonecfg(1M) for your network configuration. Dan From daleg at omniti.com Tue Jan 10 23:04:47 2017 From: daleg at omniti.com (Dale Ghent) Date: Tue, 10 Jan 2017 18:04:47 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: Message-ID: <9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com> > On Jan 10, 2017, at 5:04 PM, Dominik Hassler wrote: > > @Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is there a chance to get LX bleeding edge in r20 w/o the risk of breaking something else? Zones in 020 is still largely in sync with the LX code currently in bloody (021). Since zones (beta) was released with 020, we?ve been primarily focussed on other items required for 022, the most laborious of which is the Python 2.6 -> 2.7 upgrade. This is needed for a number of reasons. First, the benefits of getting off of 2.6 and on to 2.7 is self-explanatory, but 2.7 is also needed for being able to stay in sync with the pkg code, as well as the next big project for 022 - a loader-enabled installer (text installer and kayak) to replace the current one. In the mean-time, we?re always looking for ideas (and even contributions!) from the community on how best to handle the management and administrivia involved with LX zones. For now, we?d like this to stay within the realm of zoneadm/zonecfg and family. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From hasslerd at gmx.li Tue Jan 10 23:42:24 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Wed, 11 Jan 2017 00:42:24 +0100 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: <9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com> References: <9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com> Message-ID: Dale, I am very satisfied to stay in the realm of zoneadm/zonecfg and family. This is what I wanted to read: On 01/11/2017 12:03 AM, Dan McDonald wrote: > If there are real, provable show-stoppers in LX, fixes may get backported. Cheers, Dom On 01/11/2017 12:04 AM, Dale Ghent wrote: > >> On Jan 10, 2017, at 5:04 PM, Dominik Hassler wrote: >> >> @Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is there a chance to get LX bleeding edge in r20 w/o the risk of breaking something else? > > Zones in 020 is still largely in sync with the LX code currently in bloody (021). Since zones (beta) was released with 020, we?ve been primarily focussed on other items required for 022, the most laborious of which is the Python 2.6 -> 2.7 upgrade. This is needed for a number of reasons. First, the benefits of getting off of 2.6 and on to 2.7 is self-explanatory, but 2.7 is also needed for being able to stay in sync with the pkg code, as well as the next big project for 022 - a loader-enabled installer (text installer and kayak) to replace the current one. > > In the mean-time, we?re always looking for ideas (and even contributions!) from the community on how best to handle the management and administrivia involved with LX zones. For now, we?d like this to stay within the realm of zoneadm/zonecfg and family. > > /dale > From miniflowtrader at gmail.com Tue Jan 10 23:49:11 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Tue, 10 Jan 2017 18:49:11 -0500 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts Message-ID: Currently the UID Mapping between the host (OmniOS) and my zone (Linux) is based purely on UID. Obviously the UID's on my Linux zone are going to be very different from my OmniOS setup. Is there any NFS4 IDMAPD concept available here? e.g. nobody/nogroup for unrecognized users and groups or mapping from a numerical id to user? -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Tue Jan 10 23:50:27 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Tue, 10 Jan 2017 18:50:27 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: <9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com> References: <9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com> Message-ID: No Python 3.x ? On Tue, Jan 10, 2017 at 6:04 PM, Dale Ghent wrote: > > > On Jan 10, 2017, at 5:04 PM, Dominik Hassler wrote: > > > > @Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is > there a chance to get LX bleeding edge in r20 w/o the risk of breaking > something else? > > Zones in 020 is still largely in sync with the LX code currently in bloody > (021). Since zones (beta) was released with 020, we?ve been primarily > focussed on other items required for 022, the most laborious of which is > the Python 2.6 -> 2.7 upgrade. This is needed for a number of reasons. > First, the benefits of getting off of 2.6 and on to 2.7 is > self-explanatory, but 2.7 is also needed for being able to stay in sync > with the pkg code, as well as the next big project for 022 - a > loader-enabled installer (text installer and kayak) to replace the current > one. > > In the mean-time, we?re always looking for ideas (and even contributions!) > from the community on how best to handle the management and administrivia > involved with LX zones. For now, we?d like this to stay within the realm of > zoneadm/zonecfg and family. > > /dale > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Jan 11 00:19:46 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 10 Jan 2017 19:19:46 -0500 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts In-Reply-To: References: Message-ID: > On Jan 10, 2017, at 6:49 PM, Mini Trader wrote: > > Currently the UID Mapping between the host (OmniOS) and my zone (Linux) is based purely on UID. Obviously the UID's on my Linux zone are going to be very different from my OmniOS setup. > > Is there any NFS4 IDMAPD concept available here? e.g. nobody/nogroup for unrecognized users and groups or mapping from a numerical id to user? http://illumos.org/man/1m/idmap Dan From danmcd at omniti.com Wed Jan 11 00:20:39 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 10 Jan 2017 19:20:39 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com> Message-ID: > On Jan 10, 2017, at 6:50 PM, Mini Trader wrote: > > No Python 3.x ? Baby steps... Plus, the changes for 3.x would be even larger than for 2.6->2.7. Dan From miniflowtrader at gmail.com Wed Jan 11 02:05:19 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 02:05:19 +0000 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts In-Reply-To: References: Message-ID: Any examples on what needs to be done to make this work with LOFS? On Tue, Jan 10, 2017 at 7:19 PM Dan McDonald wrote: > > > > On Jan 10, 2017, at 6:49 PM, Mini Trader > wrote: > > > > > > Currently the UID Mapping between the host (OmniOS) and my zone (Linux) > is based purely on UID. Obviously the UID's on my Linux zone are going to > be very different from my OmniOS setup. > > > > > > Is there any NFS4 IDMAPD concept available here? e.g. nobody/nogroup > for unrecognized users and groups or mapping from a numerical id to user? > > > > http://illumos.org/man/1m/idmap > > > > Dan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Jan 11 04:46:17 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 10 Jan 2017 23:46:17 -0500 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts In-Reply-To: References: Message-ID: <8F47ACAF-745D-4189-B9B8-B7C43F87C9E6@omniti.com> Oh shoot... I honestly don't know about lofs. Sorry, Dan From omnios at citrus-it.net Wed Jan 11 10:04:30 2017 From: omnios at citrus-it.net (Andy Fiddaman) Date: Wed, 11 Jan 2017 10:04:30 +0000 (UTC) Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: Message-ID: On Tue, 10 Jan 2017, Dan McDonald wrote: ; Also, the big ; other change for LX I want in 022 is ipadm(1M) being able to work in an LX ; zone, so you don't have to do zonecfg(1M) for your network configuration. Will we still be able to to configure the networking under zonecfg? Basically what I'm asking is can we stop our zones from being able to change their IP address? Thanks, Andy -- Citrus IT Limited | +44 (0)870 199 8000 | enquiries at citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 From tobi at oetiker.ch Wed Jan 11 10:08:45 2017 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 11 Jan 2017 11:08:45 +0100 (CET) Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: Message-ID: <1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch> On 11 Jan, 2017, at 00:03, Dan McDonald danmcd at omniti.com wrote: > Given how encompassing the 022 work is, don't hold your breath. If there are > real, provable show-stoppers in LX, fixes may get backported. We have setup ThinLinc (www.cendio.com) in an ubuntu 16.04 lx zone ... ThinLinc is a sunray like environment with very fast vnc based software-thin-clients ... the setup works great on lx and is VERY fast, compared to doing the same thing in kvm ... the only 'show-stopper' for us is that chrome (and chromium) crash pretty much instantly after launch ... so I would be quite interesting on how to report lx issues ... (and yes we do have a omniti support contract). cheers tobi From stephan.budach at jvm.de Wed Jan 11 11:05:27 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 11 Jan 2017 12:05:27 +0100 Subject: [OmniOS-discuss] Does anyone know about a 10GbE Quad-Port NIC for omniOS? Message-ID: <7249d0d7-a96c-6a82-e8e7-5fe20274e4d7@jvm.de> Hi guys, I am wondering, if anyone knows about a Quad-Port 10 GbE NIC, that is supported by omniOS? Of course, I could just stuff two X540s in the box, but maybe someone knows about a solid alternative. Cheers, budy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From nshalman at omniti.com Wed Jan 11 14:32:47 2017 From: nshalman at omniti.com (Nahum Shalman) Date: Wed, 11 Jan 2017 09:32:47 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: <1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch> References: <1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch> Message-ID: At this phase I would honestly recommend attempting to reproduce LX issues on the latest SmartOS and reporting them to Joyent. Anything that manifests on OmniOS but not SmartOS would be an indication that there's something we could pull over from SmartOS to fix on OmniOS. Chrome and Chromium I'm confident are still broken on SmartOS too. I think it uses namespace and/or cgroup functionality for sandboxing that have not been implemented in LX yet. I seem to recall Firefox mostly working the last time I tried, for whatever that's worth. -Nahum On Wed, Jan 11, 2017 at 5:08 AM, Tobias Oetiker wrote: > On 11 Jan, 2017, at 00:03, Dan McDonald danmcd at omniti.com wrote: > > > Given how encompassing the 022 work is, don't hold your breath. If > there are > > real, provable show-stoppers in LX, fixes may get backported. > > We have setup ThinLinc (www.cendio.com) in an ubuntu 16.04 lx zone ... > > ThinLinc is a sunray like environment with very fast vnc based > software-thin-clients ... > the setup works great on lx and is VERY fast, compared to > doing the same thing in kvm ... > > the only 'show-stopper' for us is that chrome (and chromium) crash pretty > much instantly after launch ... > > so I would be quite interesting on how to report lx issues ... (and yes we > do have a omniti support contract). > > cheers > tobi > _______________________________________________ > 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 daleg at omniti.com Wed Jan 11 15:34:00 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 11 Jan 2017 10:34:00 -0500 Subject: [OmniOS-discuss] Does anyone know about a 10GbE Quad-Port NIC for omniOS? In-Reply-To: <7249d0d7-a96c-6a82-e8e7-5fe20274e4d7@jvm.de> References: <7249d0d7-a96c-6a82-e8e7-5fe20274e4d7@jvm.de> Message-ID: <921B63AC-0749-4157-AEDE-7B600100AB9C@omniti.com> Since you mention X540, I suppose you mean you that you want twisted pair 10Gb ethernet ports. You're probably looking at the Intel X710-T4. This will actually be driven by the i40e driver rather than the ixgbe driver as the MAC is from the 10/40Gb XL700 series but the 10Gb twisted pair PHY is the X557-AT4 I haven't actually used these, but they would appear to be 4 ports, twisted pair, and supportable under OmniOS. /dale > On Jan 11, 2017, at 6:05 AM, Stephan Budach wrote: > > Hi guys, > > I am wondering, if anyone knows about a Quad-Port 10 GbE NIC, that is supported by omniOS? Of course, I could just stuff two X540s in the box, but maybe someone knows about a solid alternative. > > Cheers, > budy > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From daleg at omniti.com Wed Jan 11 15:38:58 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 11 Jan 2017 10:38:58 -0500 Subject: [OmniOS-discuss] Does anyone know about a 10GbE Quad-Port NIC for omniOS? In-Reply-To: <921B63AC-0749-4157-AEDE-7B600100AB9C@omniti.com> References: <7249d0d7-a96c-6a82-e8e7-5fe20274e4d7@jvm.de> <921B63AC-0749-4157-AEDE-7B600100AB9C@omniti.com> Message-ID: Ah, another thing that I remembered - If you are using Supermicro server hardware that has a SIOM expansion slot, Supermicro has a quad 10Gb SIO module based on the X550 chip: https://www.supermicro.com/products/accessories/addon/AOC-MTG-i4T.cfm /dale > On Jan 11, 2017, at 10:34 AM, Dale Ghent wrote: > > > Since you mention X540, I suppose you mean you that you want twisted pair 10Gb ethernet ports. > > You're probably looking at the Intel X710-T4. This will actually be driven by the i40e driver rather than the ixgbe driver as the MAC is from the 10/40Gb XL700 series but the 10Gb twisted pair PHY is the X557-AT4 > > I haven't actually used these, but they would appear to be 4 ports, twisted pair, and supportable under OmniOS. > > /dale > >> On Jan 11, 2017, at 6:05 AM, Stephan Budach wrote: >> >> Hi guys, >> >> I am wondering, if anyone knows about a Quad-Port 10 GbE NIC, that is supported by omniOS? Of course, I could just stuff two X540s in the box, but maybe someone knows about a solid alternative. >> >> Cheers, >> budy >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > From stephan.budach at jvm.de Wed Jan 11 15:54:07 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 11 Jan 2017 16:54:07 +0100 Subject: [OmniOS-discuss] Does anyone know about a 10GbE Quad-Port NIC for omniOS? In-Reply-To: References: <7249d0d7-a96c-6a82-e8e7-5fe20274e4d7@jvm.de> <921B63AC-0749-4157-AEDE-7B600100AB9C@omniti.com> Message-ID: <15d71835-25a1-a136-9fd9-e3951660a508@jvm.de> Yeah? I just found that one as well and it would actually suit me needs pretty well, I guess. Thanks, budy Am 11.01.17 um 16:38 schrieb Dale Ghent: > Ah, another thing that I remembered - If you are using Supermicro server hardware that has a SIOM expansion slot, Supermicro has a quad 10Gb SIO module based on the X550 chip: > > https://www.supermicro.com/products/accessories/addon/AOC-MTG-i4T.cfm > > /dale > >> On Jan 11, 2017, at 10:34 AM, Dale Ghent wrote: >> >> >> Since you mention X540, I suppose you mean you that you want twisted pair 10Gb ethernet ports. >> >> You're probably looking at the Intel X710-T4. This will actually be driven by the i40e driver rather than the ixgbe driver as the MAC is from the 10/40Gb XL700 series but the 10Gb twisted pair PHY is the X557-AT4 >> >> I haven't actually used these, but they would appear to be 4 ports, twisted pair, and supportable under OmniOS. >> >> /dale >> >>> On Jan 11, 2017, at 6:05 AM, Stephan Budach wrote: >>> >>> Hi guys, >>> >>> I am wondering, if anyone knows about a Quad-Port 10 GbE NIC, that is supported by omniOS? Of course, I could just stuff two X540s in the box, but maybe someone knows about a solid alternative. >>> >>> Cheers, >>> budy >>> _______________________________________________ >>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From miniflowtrader at gmail.com Wed Jan 11 16:01:43 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 16:01:43 +0000 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch> Message-ID: With respect to virtualization, should one be turning on any hardware specific feature for the VM to properly use LX or it doesn't matter? On Wed, Jan 11, 2017 at 9:35 AM Nahum Shalman wrote: > At this phase I would honestly recommend attempting to reproduce LX issues > on the latest SmartOS and reporting them to Joyent. > Anything that manifests on OmniOS but not SmartOS would be an indication > that there's something we could pull over from SmartOS to fix on OmniOS. > > Chrome and Chromium I'm confident are still broken on SmartOS too. I think > it uses namespace and/or cgroup functionality for sandboxing that have not > been implemented in LX yet. > > I seem to recall Firefox mostly working the last time I tried, for > whatever that's worth. > > -Nahum > > On Wed, Jan 11, 2017 at 5:08 AM, Tobias Oetiker wrote: > > On 11 Jan, 2017, at 00:03, Dan McDonald danmcd at omniti.com wrote: > > > > > > > Given how encompassing the 022 work is, don't hold your breath. If > there are > > > > real, provable show-stoppers in LX, fixes may get backported. > > > > > > We have setup ThinLinc (www.cendio.com) in an ubuntu 16.04 lx zone ... > > > > > > ThinLinc is a sunray like environment with very fast vnc based > software-thin-clients ... > > > the setup works great on lx and is VERY fast, compared to > > > doing the same thing in kvm ... > > > > > > the only 'show-stopper' for us is that chrome (and chromium) crash pretty > > > much instantly after launch ... > > > > > > so I would be quite interesting on how to report lx issues ... (and yes we > do have a omniti support contract). > > > > > > cheers > > > tobi > > > _______________________________________________ > > > 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 nshalman at omniti.com Wed Jan 11 16:32:41 2017 From: nshalman at omniti.com (Nahum Shalman) Date: Wed, 11 Jan 2017 11:32:41 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch> Message-ID: On Wed, Jan 11, 2017 at 11:01 AM, Mini Trader wrote: > With respect to virtualization, should one be turning on any hardware > specific feature for the VM to properly use LX or it doesn't matter? > LX doesn't require hardware virtualization support. LX zones are like other zones except that they use an emulated Linux system call table instead of a native illumos system call table. No actual Linux kernel is used so there's no need for the hardware shenanigans (and their associated performance costs) to trick Linux into thinking it's on hardware. -Nahum -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Wed Jan 11 16:36:31 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 16:36:31 +0000 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch> Message-ID: If the hardware is there will it be used? On Wed, Jan 11, 2017 at 11:33 AM Nahum Shalman wrote: > On Wed, Jan 11, 2017 at 11:01 AM, Mini Trader > wrote: > > With respect to virtualization, should one be turning on any hardware > specific feature for the VM to properly use LX or it doesn't matter? > > > LX doesn't require hardware virtualization support. LX zones are like > other zones except that they use an emulated Linux system call table > instead of a native illumos system call table. > No actual Linux kernel is used so there's no need for the hardware > shenanigans (and their associated performance costs) to trick Linux into > thinking it's on hardware. > > -Nahum > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Wed Jan 11 16:49:59 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 11 Jan 2017 11:49:59 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch> Message-ID: If you are referring to things like VT-d, then no. VT-d is not relevant to this sort of virtualization and would provide no direct benefit to it. LX zones are quite literally a Linux kernel syscall compatibility/translation layer on top of the running illumos kernel. This layer is what takes syscalls from Linux apps/libc running inside a LX zone and either directly calls the corresponding illumos syscall if there's no difference between the two, or does what is needed to provide Linux semantics in the results if there isn't. /dale > On Jan 11, 2017, at 11:36 AM, Mini Trader wrote: > > If the hardware is there will it be used? > > On Wed, Jan 11, 2017 at 11:33 AM Nahum Shalman wrote: > On Wed, Jan 11, 2017 at 11:01 AM, Mini Trader wrote: > With respect to virtualization, should one be turning on any hardware specific feature for the VM to properly use LX or it doesn't matter? > > LX doesn't require hardware virtualization support. LX zones are like other zones except that they use an emulated Linux system call table instead of a native illumos system call table. > No actual Linux kernel is used so there's no need for the hardware shenanigans (and their associated performance costs) to trick Linux into thinking it's on hardware. > > -Nahum > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From pasztor at sagv5.gyakg.u-szeged.hu Wed Jan 11 17:27:38 2017 From: pasztor at sagv5.gyakg.u-szeged.hu (=?iso-8859-2?Q?P=C1SZTOR_Gy=F6rgy?=) Date: Wed, 11 Jan 2017 18:27:38 +0100 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts In-Reply-To: References: Message-ID: <20170111172737.GC13272@linux.gyakg.u-szeged.hu> Hi, "Mini Trader" ?rta 2017-01-10 18:49-kor: > Currently the UID Mapping between the host (OmniOS) and my zone (Linux) is > based purely on UID. Obviously the UID's on my Linux zone are going to be > very different from my OmniOS setup. > > Is there any NFS4 IDMAPD concept available here? e.g. nobody/nogroup for > unrecognized users and groups or mapping from a numerical id to user? I think, the power of lofs, that it doesn't do translations, etc. like nfs does. This behaviour doesn't depend on if the zone is an lx zone, or a solarish one. If you have a dataset what you want to use in multiple zones at the same time, then it's your responsibility to keep the same uid set in all of them. And that's also not an impossible thing: you can use yp or ldap for this purpose. Whatever is your favourite. Cheers, Gyu From danmcd at omniti.com Wed Jan 11 18:53:00 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 11 Jan 2017 13:53:00 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: Message-ID: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman wrote: > > Will we still be able to to configure the networking under zonecfg? Yes. > Basically what I'm asking is can we stop our zones from being able to change > their IP address? That's a different question, and the answer is going to be no going forward, as it is no today. I have LX zones using zonecfg(1M) to set DHCP. I can go in as root at lx-zone and use /native/sbin/{ifconfig,route} to take it over. I don't know off the top of my head if SmartOS restricts things this way, but OmniOS does not. Dan From lkateley at kateley.com Wed Jan 11 19:57:58 2017 From: lkateley at kateley.com (Linda Kateley) Date: Wed, 11 Jan 2017 13:57:58 -0600 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts In-Reply-To: References: Message-ID: <7fe09ea4-5e90-4f88-9a91-2f0e78bd3aac@kateley.com> If I remember right, zone create automatically create a mount using lofi.. I used to add additional ones. If you google old preso's of mine called "zany for zones" I used to show examples. On 1/10/17 8:05 PM, Mini Trader wrote: > Any examples on what needs to be done to make this work with LOFS? > > On Tue, Jan 10, 2017 at 7:19 PM Dan McDonald > wrote: > > > > > On Jan 10, 2017, at 6:49 PM, Mini Trader > > wrote: > > > > > > Currently the UID Mapping between the host (OmniOS) and my zone > (Linux) is based purely on UID. Obviously the UID's on my Linux > zone are going to be very different from my OmniOS setup. > > > > > > Is there any NFS4 IDMAPD concept available here? e.g. > nobody/nogroup for unrecognized users and groups or mapping from a > numerical id to user? > > > > http://illumos.org/man/1m/idmap > > > > Dan > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Jan 11 20:08:15 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 11 Jan 2017 15:08:15 -0500 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts In-Reply-To: <7fe09ea4-5e90-4f88-9a91-2f0e78bd3aac@kateley.com> References: <7fe09ea4-5e90-4f88-9a91-2f0e78bd3aac@kateley.com> Message-ID: <1EA2E142-8D6F-4012-898F-E63DFA7E69EF@omniti.com> > On Jan 11, 2017, at 2:57 PM, Linda Kateley wrote: > > If I remember right, zone create automatically create a mount using lofi.. I used to add additional ones. Not true except for LX zones (which lofs mount things into /native) and Joyent-brand zones on SmartOS. There's talk about us doing something like Joyent-brand zones (lofs-mount /usr, /bin, /sbin), but we've too much to do right now to make that happen. Dan From miniflowtrader at gmail.com Wed Jan 11 23:13:39 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 23:13:39 +0000 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> Message-ID: Is it possible for me to add inputs into the interface config for my adapters. I use a utility to restrict uplink speed called wondershaper. Normally my /etc/network/interfaces has something like: up /sbin/wondershaper eth0 X Y Would like to do the same if possible in the zone config. On Wed, Jan 11, 2017 at 1:56 PM Dan McDonald wrote: > > > > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman wrote: > > > > > > Will we still be able to to configure the networking under zonecfg? > > > > Yes. > > > > > Basically what I'm asking is can we stop our zones from being able to > change > > > their IP address? > > > > That's a different question, and the answer is going to be no going > forward, as it is no today. > > > > I have LX zones using zonecfg(1M) to set DHCP. I can go in as root at lx-zone > and use /native/sbin/{ifconfig,route} to take it over. I don't know off > the top of my head if SmartOS restricts things this way, but OmniOS does > not. > > > > Dan > > > > _______________________________________________ > > 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 daleg at omniti.com Wed Jan 11 23:33:10 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 11 Jan 2017 18:33:10 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> Message-ID: No, it doesn't work that way. The LX brand compatibility layer makes hardware primitives such as interfaces *look* like what a linux program would expect, but not necessarily act like one, and that extends to configuring it as well. /dale > On Jan 11, 2017, at 6:13 PM, Mini Trader wrote: > > Is it possible for me to add inputs into the interface config for my adapters. > > I use a utility to restrict uplink speed called wondershaper. > > Normally my /etc/network/interfaces has something like: > > up /sbin/wondershaper eth0 X Y > > Would like to do the same if possible in the zone config. > > On Wed, Jan 11, 2017 at 1:56 PM Dan McDonald wrote: > > > > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman wrote: > > > > > > Will we still be able to to configure the networking under zonecfg? > > > > Yes. > > > > > Basically what I'm asking is can we stop our zones from being able to change > > > their IP address? > > > > That's a different question, and the answer is going to be no going forward, as it is no today. > > > > I have LX zones using zonecfg(1M) to set DHCP. I can go in as root at lx-zone and use /native/sbin/{ifconfig,route} to take it over. I don't know off the top of my head if SmartOS restricts things this way, but OmniOS does not. > > > > Dan > > > > _______________________________________________ > > 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 jimklimov at cos.ru Wed Jan 11 23:41:06 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Thu, 12 Jan 2017 00:41:06 +0100 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> Message-ID: 12 ?????? 2017??. 0:13:39 CET, Mini Trader ?????: >Is it possible for me to add inputs into the interface config for my >adapters. > >I use a utility to restrict uplink speed called wondershaper. > >Normally my /etc/network/interfaces has something like: > >up /sbin/wondershaper eth0 X Y > >Would like to do the same if possible in the zone config. > >On Wed, Jan 11, 2017 at 1:56 PM Dan McDonald wrote: > >> >> >> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman >wrote: >> >> > >> >> > Will we still be able to to configure the networking under zonecfg? >> >> >> >> Yes. >> >> >> >> > Basically what I'm asking is can we stop our zones from being able >to >> change >> >> > their IP address? >> >> >> >> That's a different question, and the answer is going to be no going >> forward, as it is no today. >> >> >> >> I have LX zones using zonecfg(1M) to set DHCP. I can go in as >root at lx-zone >> and use /native/sbin/{ifconfig,route} to take it over. I don't know >off >> the top of my head if SmartOS restricts things this way, but OmniOS >does >> not. >> >> >> >> Dan >> >> >> >> _______________________________________________ >> >> OmniOS-discuss mailing list >> >> OmniOS-discuss at lists.omniti.com >> >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> I am not sure about a direct answer here, but you probably can fiddle with dladm, flowadm, etc. on the illumos host side to limit the capabilities of the vnic you delegate into the zone. -- Typos courtesy of K-9 Mail on my Samsung Android From jimklimov at cos.ru Wed Jan 11 23:54:33 2017 From: jimklimov at cos.ru (Jim Klimov) Date: Thu, 12 Jan 2017 00:54:33 +0100 Subject: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts In-Reply-To: <1EA2E142-8D6F-4012-898F-E63DFA7E69EF@omniti.com> References: <7fe09ea4-5e90-4f88-9a91-2f0e78bd3aac@kateley.com> <1EA2E142-8D6F-4012-898F-E63DFA7E69EF@omniti.com> Message-ID: <2D93513E-A247-49B0-8E32-F305CCFB94D6@cos.ru> 11 ?????? 2017??. 21:08:15 CET, Dan McDonald ?????: > >> On Jan 11, 2017, at 2:57 PM, Linda Kateley >wrote: >> >> If I remember right, zone create automatically create a mount using >lofi.. I used to add additional ones. > >Not true except for LX zones (which lofs mount things into /native) and >Joyent-brand zones on SmartOS. There's talk about us doing something >like Joyent-brand zones (lofs-mount /usr, /bin, /sbin), but we've too >much to do right now to make that happen. > >Dan > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss I'm sure one can set up the mounts to effect of old-day sparse-root zones. Problem comes when you try to upgrade it or just add packages, and tools do not expect such setup anymore. Jim -- Typos courtesy of K-9 Mail on my Samsung Android From miniflowtrader at gmail.com Thu Jan 12 01:15:48 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 20:15:48 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> Message-ID: The values set in flowadm seem odd. They don't align with download speed. Also it is up and down not up or down. wondershaper does not work. root at debian-8:~# wondershaper backup0 4000 4000 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 We have an error talking to the kernel RTNETLINK answers: Unknown error -122 We have an error talking to the kernel RTNETLINK answers: Unknown error -122 We have an error talking to the kernel RTNETLINK answers: Unknown error -122 We have an error talking to the kernel RTNETLINK answers: Unknown error -122 We have an error talking to the kernel RTNETLINK answers: Unknown error -122 RTNETLINK answers: Unknown error -122 We have an error talking to the kernel On Wed, Jan 11, 2017 at 6:41 PM, Jim Klimov wrote: > 12 ?????? 2017 ?. 0:13:39 CET, Mini Trader > ?????: > >Is it possible for me to add inputs into the interface config for my > >adapters. > > > >I use a utility to restrict uplink speed called wondershaper. > > > >Normally my /etc/network/interfaces has something like: > > > >up /sbin/wondershaper eth0 X Y > > > >Would like to do the same if possible in the zone config. > > > >On Wed, Jan 11, 2017 at 1:56 PM Dan McDonald wrote: > > > >> > >> > >> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman > >wrote: > >> > >> > > >> > >> > Will we still be able to to configure the networking under zonecfg? > >> > >> > >> > >> Yes. > >> > >> > >> > >> > Basically what I'm asking is can we stop our zones from being able > >to > >> change > >> > >> > their IP address? > >> > >> > >> > >> That's a different question, and the answer is going to be no going > >> forward, as it is no today. > >> > >> > >> > >> I have LX zones using zonecfg(1M) to set DHCP. I can go in as > >root at lx-zone > >> and use /native/sbin/{ifconfig,route} to take it over. I don't know > >off > >> the top of my head if SmartOS restricts things this way, but OmniOS > >does > >> not. > >> > >> > >> > >> Dan > >> > >> > >> > >> _______________________________________________ > >> > >> OmniOS-discuss mailing list > >> > >> OmniOS-discuss at lists.omniti.com > >> > >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > >> > >> > > I am not sure about a direct answer here, but you probably can fiddle with > dladm, flowadm, etc. on the illumos host side to limit the capabilities of > the vnic you delegate into the zone. > -- > Typos courtesy of K-9 Mail on my Samsung Android > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Jan 12 01:16:59 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 11 Jan 2017 20:16:59 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> Message-ID: <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> > On Jan 11, 2017, at 8:15 PM, Mini Trader wrote: > > The values set in flowadm seem odd. They don't align with download speed. Also it is up and down not up or down. > > wondershaper does not work. It won't because it expects kernel interfaces LX zones don't provide. You will have to use /native/ tools for things like this. Sorry, Dan From miniflowtrader at gmail.com Thu Jan 12 01:25:01 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 20:25:01 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> Message-ID: Is it possible to limit flow control on uploads? flowadm - the numbers don't seem to add up. I'm not sure what its doing. On Wed, Jan 11, 2017 at 8:16 PM, Dan McDonald wrote: > > > On Jan 11, 2017, at 8:15 PM, Mini Trader > wrote: > > > > The values set in flowadm seem odd. They don't align with download > speed. Also it is up and down not up or down. > > > > wondershaper does not work. > > It won't because it expects kernel interfaces LX zones don't provide. > > You will have to use /native/ tools for things like this. > > Sorry, > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Jan 12 01:28:01 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 11 Jan 2017 20:28:01 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> Message-ID: > On Jan 11, 2017, at 8:25 PM, Mini Trader wrote: > > Is it possible to limit flow control on uploads? flowadm - the numbers don't seem to add up. I'm not sure what its doing. From the manual: maxbw Sets the full duplex bandwidth for the flow. The bandwidth is specified as an integer with one of the scale suffixes(K, M, or G for Kbps, Mbps, and Gbps). If no units are specified, the input value will be read as Mbps. The default is no bandwidth limit. Flowadm bandwidth is bidirectional. You can, though, limit uploads based on port number. See the examples section for https, e.g. Dan From miniflowtrader at gmail.com Thu Jan 12 01:32:19 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 20:32:19 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> Message-ID: This does not work. Simple example. Ran wget on an ubuntu ISO. Was downloading at over 1 mega byte per sec. Set adapter to 4000K. I would expect the download to peak at around 500 Kilo Bytes. Was in the 100 range. 16000K put it in the 500kb range. Doesn't add up. Also didn't persist across reboot of zone. On Wed, Jan 11, 2017 at 8:28 PM, Dan McDonald wrote: > > > On Jan 11, 2017, at 8:25 PM, Mini Trader > wrote: > > > > Is it possible to limit flow control on uploads? flowadm - the numbers > don't seem to add up. I'm not sure what its doing. > > From the manual: > > maxbw > > Sets the full duplex bandwidth for the flow. The bandwidth is > specified as an integer with one of the scale suffixes(K, M, or > G > for Kbps, Mbps, and Gbps). If no units are specified, the input > value will be read as Mbps. The default is no bandwidth limit. > > Flowadm bandwidth is bidirectional. You can, though, limit uploads based > on port number. See the examples section for https, e.g. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ergi.thanasko at avsquad.com Thu Jan 12 01:34:11 2017 From: ergi.thanasko at avsquad.com (Ergi Thanasko) Date: Thu, 12 Jan 2017 01:34:11 +0000 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> Message-ID: <1873BA18-38D1-4D68-A1B8-0E6046B02264@avsquad.com> We were using flowadm on a source ip basis. Not easy to keep track of the ip in a big product environment and also want to throttle in or out and the bidirectional was not clean way of doing it > On Jan 11, 2017, at 5:28 PM, Dan McDonald wrote: > > >> On Jan 11, 2017, at 8:25 PM, Mini Trader wrote: >> >> Is it possible to limit flow control on uploads? flowadm - the numbers don't seem to add up. I'm not sure what its doing. > > From the manual: > > maxbw > > Sets the full duplex bandwidth for the flow. The bandwidth is > specified as an integer with one of the scale suffixes(K, M, or G > for Kbps, Mbps, and Gbps). If no units are specified, the input > value will be read as Mbps. The default is no bandwidth limit. > > Flowadm bandwidth is bidirectional. You can, though, limit uploads based on port number. See the examples section for https, e.g. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From miniflowtrader at gmail.com Thu Jan 12 01:46:09 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 20:46:09 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: <1873BA18-38D1-4D68-A1B8-0E6046B02264@avsquad.com> References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> <1873BA18-38D1-4D68-A1B8-0E6046B02264@avsquad.com> Message-ID: Running it right now with 15M and it seems to have capped it at 400 kilo bytes/sec. Whatever is being used to calculate is not correct at least on the driver for this NIC - VMXNET3S. Another thing. I realize that you said that you can limit this to ports. But what if you are downloading and uploading to the same port e.g. 80 but only want to limit on the upload? On Wed, Jan 11, 2017 at 8:34 PM, Ergi Thanasko wrote: > We were using flowadm on a source ip basis. Not easy to keep track of the > ip in a big product environment and also want to throttle in or out and > the bidirectional was not clean way of doing it > > > > > On Jan 11, 2017, at 5:28 PM, Dan McDonald wrote: > > > > > >> On Jan 11, 2017, at 8:25 PM, Mini Trader > wrote: > >> > >> Is it possible to limit flow control on uploads? flowadm - the numbers > don't seem to add up. I'm not sure what its doing. > > > > From the manual: > > > > maxbw > > > > Sets the full duplex bandwidth for the flow. The bandwidth is > > specified as an integer with one of the scale suffixes(K, M, > or G > > for Kbps, Mbps, and Gbps). If no units are specified, the input > > value will be read as Mbps. The default is no bandwidth limit. > > > > Flowadm bandwidth is bidirectional. You can, though, limit uploads > based on port number. See the examples section for https, e.g. > > > > Dan > > > > _______________________________________________ > > 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 danmcd at omniti.com Thu Jan 12 01:52:40 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 11 Jan 2017 20:52:40 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> Message-ID: <39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com> > On Jan 11, 2017, at 8:32 PM, Mini Trader wrote: > > This does not work. Simple example. Ran wget on an ubuntu ISO. Was downloading at over 1 mega byte per sec. Set adapter to 4000K. I would expect the download to peak at around 500 Kilo Bytes. Was in the 100 range. 16000K put it in the 500kb range. Doesn't add up. Also didn't persist across reboot of zone. 1.) flowadm works in units of bits/sec, not bytes. 4000kbit == 4mbit == 500kbytes. Please RTFM carefully. 2.) Use it in the global zone for the NIC you're assigning. Then it'll persist. Persistence of /native commands in LX zones is an open problem right now. We aren't planning on doing it for flowadm, only for ipadm. Dan From miniflowtrader at gmail.com Thu Jan 12 02:15:15 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Wed, 11 Jan 2017 21:15:15 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: <39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com> References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> <39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com> Message-ID: Seems like I am confusing you I do realize that it is in BITS! 4M == 4000KBIT == 500kbytes. Using 4000K OR 4M SHOULD restrict flow to a MAXIMUM of 500 KBYTES. What I am seeing is that using a value restricts flow to a maximum of 100KBYTES! root at storage1:/root# flowadm add-flow -l backup0 -a transport=tcp tcpflow root at storage1:/root# flowadm set-flowprop -p maxbw=4M tcpflow ubuntu-16.04.1-desk 0%[ ] 2.67M 104KB/s eta 3h 45m # Well gosh darnit. That doesn't make sense. Maybe his adapter cant download more than 100KBYTES. Lets undo what we did and see what happens. root at storage1:/root# flowadm remove-flow -l backup0 desktop-amd64.iso?_ 1%[ ] 18.24M 1.00MB/s eta 85m 54s # It appears our download speed is running at 8 MEGABIT or 1MEGABYTE without any flow. So why would a restriction of half of our download rate cause it to run at 1/10th the maximum speed! On Wed, Jan 11, 2017 at 8:52 PM, Dan McDonald wrote: > > > On Jan 11, 2017, at 8:32 PM, Mini Trader > wrote: > > > > This does not work. Simple example. Ran wget on an ubuntu ISO. Was > downloading at over 1 mega byte per sec. Set adapter to 4000K. I would > expect the download to peak at around 500 Kilo Bytes. Was in the 100 > range. 16000K put it in the 500kb range. Doesn't add up. Also didn't > persist across reboot of zone. > > 1.) flowadm works in units of bits/sec, not bytes. 4000kbit == 4mbit == > 500kbytes. Please RTFM carefully. > > 2.) Use it in the global zone for the NIC you're assigning. Then it'll > persist. Persistence of /native commands in LX zones is an open problem > right now. We aren't planning on doing it for flowadm, only for ipadm. > > Dan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Jan 12 02:29:20 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 11 Jan 2017 21:29:20 -0500 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> <39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com> Message-ID: <0CB52D32-5F9E-49CD-8510-A5AD6B40D301@omniti.com> > On Jan 11, 2017, at 9:15 PM, Mini Trader wrote: > > Seems like I am confusing you > > I do realize that it is in BITS! > > 4M == 4000KBIT == 500kbytes. > > Using 4000K OR 4M SHOULD restrict flow to a MAXIMUM of 500 KBYTES. What I am seeing is that using a value restricts flow to a maximum of 100KBYTES! Sorry for being confused. I'm a bit stumped at this point, though did I see that you're using vmxnet3 on VMware? I will say that when these features were brought up, they assumed a vNIC over a physical NIC on metal. I'm not sure if there's a bizarre interaction with vmxnet3 or not. One other thing, and I'd have to consult a larger audience, I thought flowadm worked as low a units of 1Mbit/sec, but it could be units of 10Mbit/sec. (Flowadm was designed for GigE adapters...) It's a function of the system's hz for bizarre reasons, and I'm wondering if being on VMware affects those or not. You can mess with this if you wish: https://blogs.oracle.com/jtc/entry/overhead_in_increasing_the_solaris Dan From lorban at bitronix.be Thu Jan 12 11:01:30 2017 From: lorban at bitronix.be (Ludovic Orban) Date: Thu, 12 Jan 2017 12:01:30 +0100 Subject: [OmniOS-discuss] LX zones documentation Message-ID: Hi, So far, LX zones have been working great for me. Thanks for that! I did find a few things that would be worth better documenting though: - The folder containing the zonepath should be a dataset, otherwise zoneadm install fails with a cryptic error. - You can run dhcp with all bells and whistles in a lx zone, but that works with the illumos native dhcp client. This means you need to copy inittab and inittab6 from the global zone in /etc/dhcp, create /etc/dhcp/eventhook if you want to automatically configure /etc/resolv.conf and create /etc/hostname. if you want DNS name registration. - IPv6 works great too but you need to manually start /native/usr/lib/inet/in.ndpd from within your zone. That's all I have: it all works great but the doc needs some love. I thought it would be worth mentioning here. Thanks again, Ludovic From lkateley at kateley.com Thu Jan 12 17:00:28 2017 From: lkateley at kateley.com (Linda Kateley) Date: Thu, 12 Jan 2017 11:00:28 -0600 Subject: [OmniOS-discuss] LX zones: configurations In-Reply-To: References: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com> <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com> <39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com> Message-ID: <909cee03-c5dd-cc17-1a90-02e522db3625@kateley.com> If I remember correctly it's a max, not a guarantee. lk On 1/11/17 8:15 PM, Mini Trader wrote: > Seems like I am confusing you > > I do realize that it is in BITS! > > 4M == 4000KBIT == 500kbytes. > > Using 4000K OR 4M SHOULD restrict flow to a MAXIMUM of 500 KBYTES. > What I am seeing is that using a value restricts flow to a maximum of > 100KBYTES! > > > root at storage1:/root# flowadm add-flow -l backup0 -a transport=tcp tcpflow > root at storage1:/root# flowadm set-flowprop -p maxbw=4M tcpflow > > ubuntu-16.04.1-desk 0%[ ] 2.67M 104KB/s eta > 3h 45m > > # Well gosh darnit. That doesn't make sense. Maybe his adapter cant > download more than 100KBYTES. Lets undo what we did and see what happens. > > root at storage1:/root# flowadm remove-flow -l backup0 > desktop-amd64.iso?_ 1%[ ] 18.24M 1.00MB/s > eta 85m 54s > > # It appears our download speed is running at 8 MEGABIT or 1MEGABYTE > without any flow. So why would a restriction of half of our download > rate cause it to run at 1/10th the maximum speed! > > > On Wed, Jan 11, 2017 at 8:52 PM, Dan McDonald > wrote: > > > > On Jan 11, 2017, at 8:32 PM, Mini Trader > > wrote: > > > > This does not work. Simple example. Ran wget on an ubuntu > ISO. Was downloading at over 1 mega byte per sec. Set adapter to > 4000K. I would expect the download to peak at around 500 Kilo > Bytes. Was in the 100 range. 16000K put it in the 500kb range. > Doesn't add up. Also didn't persist across reboot of zone. > > 1.) flowadm works in units of bits/sec, not bytes. 4000kbit == > 4mbit == 500kbytes. Please RTFM carefully. > > 2.) Use it in the global zone for the NIC you're assigning. Then > it'll persist. Persistence of /native commands in LX zones is an > open problem right now. We aren't planning on doing it for > flowadm, only for ipadm. > > Dan > > > > > > > _______________________________________________ > 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 martin at matuska.org Thu Jan 12 21:30:42 2017 From: martin at matuska.org (Martin Matuska) Date: Thu, 12 Jan 2017 22:30:42 +0100 Subject: [OmniOS-discuss] libarchive and OmniOS - ACL support Message-ID: <6bdf90b1-9ea7-4994-5542-716d8cdc5d80@matuska.org> Dear OmniOS developers and users, I have fixed compilation issues and finalized Solaris-style ACL support (POSIX.1e and NFSv4) and added it to libarchive's master branch. https://github.com/libarchive/libarchive Libarchive stores ACLs in tar archives using the SCHILY.acl attributes (SCHILY.acl.access, SCHILY.acl.default and SCHILY.acl.ace), in a compatible way with the "star" archiver by J?rg Schilling. ACLs that exactly mirror the mode (see acl_is_trivial_np() in FreeBSD) are treated like no ACLs and are not stored (e.g if there is one additional ACE or one of the trivial ACEs is modified the whole ACL is stored). To build libarchive, I the following dependencies are required: developer/build/autoconf developer/build/automake developer/build/libtool developer/gcc51 developer/object-file developer/pkg-config system/header An OmniOS build is now available in our CI, too. The support will be included in libarchive 3.3 release. It would be great to see a libarchive 3.3 package for OmniOS (including all three tools bsdar, bsdcpio and bsdcat). We would appreciate any feedback at libarchive (testing, bugfixes, code review, suggestions). Thank you, Martin Matuska From lslusser at gmail.com Fri Jan 13 02:29:10 2017 From: lslusser at gmail.com (Liam Slusser) Date: Thu, 12 Jan 2017 18:29:10 -0800 Subject: [OmniOS-discuss] dtrace fibre channel questions Message-ID: Hi OmniOS people - Looks like the dtrace mailing list is pretty quiet so I hope you guys don't mind me ask a question here. If you can recommend a better list please let me know. I am writing a dtrace script to snoop on COMSTAR fibre channel target provider on a OmniOS server sharing a ZFS pool. I've run into a few problems I can't seem to figure out. Using a few dtrace iscsi scripts I've found online I was able to write something that can watch the scsi-commands via the dtrace probe fc:::xfer-start. The output looks something like this: remote_wwn local_wwn sectors_request operation length_of_request 21000024ff48a0c2 21000024ff58fae9 16 write(10) 8192 21000024ff48a0c2 21000024ff58fae9 16 read(10) 8192 21000024ff58262e 21000024ff58fae9 16 write(10) 8192 21000024ff48a0c2 21000024ff58fae8 32 write(10) 16384 21000024ff48a0c2 21000024ff58fae9 128 read(16) 65536 21000024ff58262e 21000024ff58fae9 16 write(10) 8192 So basically the number before the operation name (read/write) is the number of sectors requested which I pull from the ic_cdb packet. I get the request length from fcx_len. Now since each sector is 512k you can do the easy math to verify sector request size * 512 = fcx_len. And it does indeed add up. What I don't understand is some requests look like this. 21000024ff58262f 21000024ff58fae8 0 read(10) 1048576 21000024ff48a0c3 21000024ff58fae8 0 read(10) 1048576 21000024ff48a0c2 21000024ff58fae9 0 write(10) 131072 21000024ff58262f 21000024ff58fae9 0 read(10) 1048576 I don't understand why some requests have a 0 sector transfer length in the ic_cdb packet but a large request length in the fcx_len. They almost always are 1048576 in size, but not always like in the case of the write(10) above. The few scripts and one-liners I've seen that do sums of traffic don't seem to discard these requests. Anybody know what they are? I also am unable to figure out what target LUN each request is going to. The COMSTAR protocol for iscsi has iscsiinfo_t which gives exactly what I'm looking for but there doesn't seem to be a fcinfo_t struct unfortunately. How can I map a request from the probe fc:::xfer-start to a zfs zpool? My script is using fc:::xfer-start for a probe and the documentation I've found give the following variables: Probes Variable Type Description ------ -------- ---- ----------- fc:::xfer-start, args[0] conninfo_t * connection info fc:::xfer-done args[1] fc_port_info_t * local port info args[2] scsi_cmd_t * SCSI command block args[3] fc_port_info_t * remote port info args[4] fc_xferinfo_t * data transfer info I've looked through all those variables and I can't find anything that points to a LUN/target. I figure it can be done because I am able to get those stats on our Oracle zfssa which uses dtrace for its reporting. Thoughts or help? thanks! liam -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Fri Jan 13 05:46:03 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Fri, 13 Jan 2017 00:46:03 -0500 Subject: [OmniOS-discuss] LX Zone DTrace Message-ID: Is there anything that can be done to trace a program having issues on an LX Zone. I am seeing: OSError: [Errno 2] No such file or directory: Again under certain conditions which I am trying to trace - unfortunately this is a closed source program. Can DTrace be used to help track something like this? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.budach at jvm.de Fri Jan 13 07:43:42 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Fri, 13 Jan 2017 08:43:42 +0100 Subject: [OmniOS-discuss] omniOS r018 crashed due to scsi/iSCSI issue Message-ID: Hi Dan, just wanted to know, if you would be interested in the core dump of this crash: Jan 11 07:28:52 zfsha02gh79 scsi: [ID 107833 kern.warning] WARNING: /scsi_vhci/disk at g600144f090d09613000056b8a83b0007 (sd27): Jan 11 07:28:52 zfsha02gh79 incomplete write- retrying Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 /scsi_vhci/disk at g600144f0564d504f4f4c3035534c3133 (sd47): Command Timeout on path iscsi0/disk at 0000iqn.2016-02.de.jvm:nfsvmpool05ssd030002,3 Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 /scsi_vhci/disk at g600144f0564d504f4f4c3035534c3039 (sd44): Command Timeout on path iscsi0/disk at 0000iqn.2016-02.de.jvm:nfsvmpool05ssd030002,0 Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 /scsi_vhci/disk at g600144f0564d504f4f4c3035534c3131 (sd46): Command Timeout on path iscsi0/disk at 0000iqn.2016-02.de.jvm:nfsvmpool05ssd030002,2 Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 /scsi_vhci/disk at g600144f0564d504f4f4c3035534c3130 (sd45): Command Timeout on path iscsi0/disk at 0000iqn.2016-02.de.jvm:nfsvmpool05ssd030002,1 Jan 12 17:30:22 zfsha02gh79 iscsi: [ID 431120 kern.warning] WARNING: iscsi connection(26/3f) closing connection - target requested reason:0x7 Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 /scsi_vhci/disk at g600144f090d09613000056b8a7f10003 (sd19): Command Timeout on path iscsi0/disk at 0000iqn.2015-03.de.jvm:nfsvmpool05ssd010002,2 Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 /scsi_vhci/disk at g600144f090d09613000056b8a7fc0004 (sd21): Command Timeout on path iscsi0/disk at 0000iqn.2015-03.de.jvm:nfsvmpool05ssd010002,3 Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 /scsi_vhci/disk at g600144f090d09613000056b8a84a0008 (sd29): Command Timeout on path iscsi0/disk at 0000iqn.2015-03.de.jvm:nfsvmpool05ssd010002,7 Jan 12 17:30:22 zfsha02gh79 scsi: [ID 243001 kern.warning] WARNING: /scsi_vhci (scsi_vhci0): Jan 12 17:30:22 zfsha02gh79 unix: [ID 836849 kern.notice] Jan 12 17:30:22 zfsha02gh79 ^Mpanic[cpu1]/thread=ffffff00f6539c40: Jan 12 17:30:22 zfsha02gh79 genunix: [ID 335743 kern.notice] BAD TRAP: type=e (#pf Page fault) rp=ffffff00f6539610 addr=10 occurred in module "scsi_vhci" due to a NULL pointer dereference Jan 12 17:30:22 zfsha02gh79 unix: [ID 100000 kern.notice] Jan 12 17:30:22 zfsha02gh79 unix: [ID 839527 kern.notice] sched: Jan 12 17:30:22 zfsha02gh79 unix: [ID 753105 kern.notice] #pf Page fault Jan 12 17:30:22 zfsha02gh79 unix: [ID 532287 kern.notice] Bad kernel fault at addr=0x10 Jan 12 17:30:22 zfsha02gh79 unix: [ID 243837 kern.notice] pid=0, pc=0xfffffffff7948e15, sp=0xffffff00f6539700, eflags=0x10246 Jan 12 17:30:22 zfsha02gh79 unix: [ID 211416 kern.notice] cr0: 8005003b cr4: 1426f8 Jan 12 17:30:22 zfsha02gh79 unix: [ID 624947 kern.notice] cr2: 10 Jan 12 17:30:22 zfsha02gh79 unix: [ID 625075 kern.notice] cr3: c000000 Jan 12 17:30:22 zfsha02gh79 unix: [ID 625715 kern.notice] cr8: 0 Jan 12 17:30:22 zfsha02gh79 unix: [ID 100000 kern.notice] Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] rdi: ffffff226adb90d8 rsi: 1 rdx: ffffff227063d400 Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] rcx: 2 r8: 0 r9: fffffffff794bd10 Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] rax: 0 rbx: 1 rbp: ffffff00f6539780 Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] r10: 0 r11: ffffff00f65397b0 r12: 2 Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] r13: 1 r14: 0 r15: 4 Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] fsb: 0 gsb: ffffff21f0e81040 ds: 4b Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] es: 4b fs: 0 gs: 1c3 Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] trp: e err: 0 rip: fffffffff7948e15 Jan 12 17:30:22 zfsha02gh79 unix: [ID 592667 kern.notice] cs: 30 rfl: 10246 rsp: ffffff00f6539700 Jan 12 17:30:22 zfsha02gh79 unix: [ID 266532 kern.notice] ss: 38 Jan 12 17:30:22 zfsha02gh79 unix: [ID 100000 kern.notice] Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f65394f0 unix:die+df () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539600 unix:trap+dd8 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539610 unix:_cmntrap+e6 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539780 scsi_vhci:vhci_scsi_reset_target+75 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f65397d0 scsi_vhci:vhci_recovery_reset+7d () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539820 scsi_vhci:vhci_pathinfo_offline+e5 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f65398c0 scsi_vhci:vhci_pathinfo_state_change+d5 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539950 genunix:i_mdi_pi_state_change+16a () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539990 genunix:mdi_pi_offline+39 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539a20 iscsi:iscsi_lun_offline+b3 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539a60 iscsi:iscsi_sess_offline_luns+4d () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539ab0 iscsi:iscsi_sess_state_logged_in+11e () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539b00 iscsi:iscsi_sess_state_machine+13e () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539b60 iscsi:iscsi_client_notify_task+17e () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539c20 genunix:taskq_thread+2d0 () Jan 12 17:30:22 zfsha02gh79 genunix: [ID 655072 kern.notice] ffffff00f6539c30 unix:thread_start+8 () Jan 12 17:30:22 zfsha02gh79 unix: [ID 100000 kern.notice] Jan 12 17:30:22 zfsha02gh79 genunix: [ID 672855 kern.notice] syncing file systems... Jan 12 17:30:24 zfsha02gh79 genunix: [ID 904073 kern.notice] done Jan 12 17:30:22 zfsha02gh79 genunix: [ID 111219 kern.notice] dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel Jan 12 17:30:22 zfsha02gh79 ahci: [ID 405573 kern.info] NOTICE: ahci0: ahci_tran_reset_dport port 0 reset port Jan 12 17:48:01 zfsha02gh79 genunix: [ID 100000 kern.notice] Jan 12 17:48:02 zfsha02gh79 genunix: [ID 665016 kern.notice] ^M100% done: 4721646 pages dumped, This happend on a rather higher load situation, when I was copying a 200G file from a snapshot back to it's original place on its zvol, when this happened. Luckily these are RSF-1 nodes and the other one took over very quickliy, such as that my VM cluster didn't even seem to notice this issue. However, at that time I was conencted to the crashing host via ssh and my heart skipped a beat. ;) As I have (unvoluntarily) freed this node of it's duties, I could jump to r020 on it, but I wonder if there has been any changes to the scsi_vhci layer at all in recent times? Cheers, Stephan -- Krebs's 3 Basic Rules for Online Safety 1st - "If you didn't go looking for it, don't install it!" 2nd - "If you installed it, update it." 3rd - "If you no longer need it, remove it." http://krebsonsecurity.com/2011/05/krebss-3-basic-rules-for-online-safety Stephan Budach Head of IT Jung von Matt AG Glash?ttenstra?e 79 20357 Hamburg Tel: +49 40-4321-1353 Fax: +49 40-4321-1114 E-Mail: stephan.budach at jvm.de Internet: http://www.jvm.com CiscoJabber Video: https://exp-e2.jvm.de/call/stephan.budach Vorstand: Dr. Peter Figge, Jean-Remy von Matt, Larissa Pohl, Thomas Strerath, G?tz Ulmer Vorsitzender des Aufsichtsrates: Hans Hermann M?nchmeyer AG HH HRB 72893 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From nshalman at omniti.com Fri Jan 13 13:54:41 2017 From: nshalman at omniti.com (Nahum Shalman) Date: Fri, 13 Jan 2017 08:54:41 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: Message-ID: The short answer is yes. My experience debugging LX was on SmartOS and there are some notes on https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBrandedZones-Debugging Some of the details on that page are Specific to SmartOS, but some of it is generic to LX. -Nahum On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader wrote: > Is there anything that can be done to trace a program having issues on an > LX Zone. > > I am seeing: > > OSError: [Errno 2] No such file or directory: > > Again under certain conditions which I am trying to trace - unfortunately > this is a closed source program. Can DTrace be used to help track > something like this? > > Thanks! > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Fri Jan 13 14:24:01 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Fri, 13 Jan 2017 14:24:01 +0000 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: Message-ID: I followed these instructions prior to my post and my zone would not boot after doing the mod to add the flag to the file. On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman wrote: > The short answer is yes. > > My experience debugging LX was on SmartOS and there are some notes on > https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBrandedZones-Debugging > > Some of the details on that page are Specific to SmartOS, but some of it > is generic to LX. > > -Nahum > > On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader > wrote: > > Is there anything that can be done to trace a program having issues on an > LX Zone. > > I am seeing: > > OSError: [Errno 2] No such file or directory: > > Again under certain conditions which I am trying to trace - unfortunately > this is a closed source program. Can DTrace be used to help track > something like this? > > Thanks! > > > > _______________________________________________ > > > OmniOS-discuss mailing list > > > OmniOS-discuss at lists.omniti.com > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nshalman at omniti.com Fri Jan 13 14:30:35 2017 From: nshalman at omniti.com (Nahum Shalman) Date: Fri, 13 Jan 2017 09:30:35 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: Message-ID: Have you tried simply tracing the lx-syscall probes? On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader wrote: > I followed these instructions prior to my post and my zone would not boot > after doing the mod to add the flag to the file. > > > On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman wrote: > >> The short answer is yes. >> >> My experience debugging LX was on SmartOS and there are some notes on >> https://wiki.smartos.org/display/DOC/LX+Branded+Zones# >> LXBrandedZones-Debugging >> >> Some of the details on that page are Specific to SmartOS, but some of it >> is generic to LX. >> >> -Nahum >> >> On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader >> wrote: >> >> Is there anything that can be done to trace a program having issues on an >> LX Zone. >> >> I am seeing: >> >> OSError: [Errno 2] No such file or directory: >> >> Again under certain conditions which I am trying to trace - unfortunately >> this is a closed source program. Can DTrace be used to help track >> something like this? >> >> Thanks! >> >> >> >> _______________________________________________ >> >> >> OmniOS-discuss mailing list >> >> >> OmniOS-discuss at lists.omniti.com >> >> >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Jan 13 16:48:57 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 13 Jan 2017 11:48:57 -0500 Subject: [OmniOS-discuss] omniOS r018 crashed due to scsi/iSCSI issue In-Reply-To: References: Message-ID: 1.) I'm interested in the dump (even with no cycles to deeply inspect it currently). 2.) You should upgrade to 020 anyway, there were very few changes in SCSI and iSCSI (it's likely the bug is in iSCSI, not scsi_vhci... iSCSI probably prematurely freed or something-else an object that scsi_vhci just puked on, note it's a NULL pointer dereference). Thanks, Dan From miniflowtrader at gmail.com Fri Jan 13 20:12:04 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Fri, 13 Jan 2017 15:12:04 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: Message-ID: I have a small program that will reproduce the issue. Where should the bug be sent? It's pretty serious. The system is forgetting the location of the current working directory in a recursive call. On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman wrote: > Have you tried simply tracing the lx-syscall probes? > > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader > wrote: > >> I followed these instructions prior to my post and my zone would not boot >> after doing the mod to add the flag to the file. >> >> >> On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman >> wrote: >> >>> The short answer is yes. >>> >>> My experience debugging LX was on SmartOS and there are some notes on >>> https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXB >>> randedZones-Debugging >>> >>> Some of the details on that page are Specific to SmartOS, but some of it >>> is generic to LX. >>> >>> -Nahum >>> >>> On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader >>> wrote: >>> >>> Is there anything that can be done to trace a program having issues on >>> an LX Zone. >>> >>> I am seeing: >>> >>> OSError: [Errno 2] No such file or directory: >>> >>> Again under certain conditions which I am trying to trace - >>> unfortunately this is a closed source program. Can DTrace be used to help >>> track something like this? >>> >>> Thanks! >>> >>> >>> >>> _______________________________________________ >>> >>> >>> OmniOS-discuss mailing list >>> >>> >>> OmniOS-discuss at lists.omniti.com >>> >>> >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >>> >>> >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daleg at omniti.com Fri Jan 13 20:52:35 2017 From: daleg at omniti.com (Dale Ghent) Date: Fri, 13 Jan 2017 15:52:35 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: Message-ID: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> Could you provide some of your telemetry and background here? There might be a reasonable explanation, or a quick fix. /dale > On Jan 13, 2017, at 3:12 PM, Mini Trader wrote: > > I have a small program that will reproduce the issue. Where should the bug be sent? It's pretty serious. The system is forgetting the location of the current working directory in a recursive call. > > On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman wrote: > Have you tried simply tracing the lx-syscall probes? > > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader wrote: > I followed these instructions prior to my post and my zone would not boot after doing the mod to add the flag to the file. > > > On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman wrote: > The short answer is yes. > > My experience debugging LX was on SmartOS and there are some notes on https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBrandedZones-Debugging > > Some of the details on that page are Specific to SmartOS, but some of it is generic to LX. > > -Nahum > > On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader wrote: > Is there anything that can be done to trace a program having issues on an LX Zone. > > I am seeing: > > OSError: [Errno 2] No such file or directory: > > Again under certain conditions which I am trying to trace - unfortunately this is a closed source program. Can DTrace be used to help track something like this? > > Thanks! > > > > _______________________________________________ > > > 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 miniflowtrader at gmail.com Fri Jan 13 21:06:28 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Fri, 13 Jan 2017 16:06:28 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> References: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> Message-ID: Here is the code. It will run just fine with Debian 8.6 or OmniOS. It will fail on the LX zone with Debian. The only way for it to fail is for the stat call to fail and this seems to happen because the system doen't know what directory it is in. The files being looked at are static so not a race condition. Simple python script. # read a directory, stat all files import os import sys from stat import * def walk(d): os.chdir(d) working = os.getcwd() print working dirlist = os.listdir('.') dirlist.sort() for f in dirlist: try: s = os.lstat(f) if S_ISDIR(s.st_mode): walk(f) except OSError, err: print "CurrentDIR: " + working print "CurrentFile: " + f print err os.chdir('..') print "DONE" if len(sys.argv) != 2: print 'need 1 arg, directory to scan' cwd = os.getcwd() os.chdir(sys.argv[1]) walk('.') On Fri, Jan 13, 2017 at 3:52 PM, Dale Ghent wrote: > Could you provide some of your telemetry and background here? There might > be a reasonable explanation, or a quick fix. > > /dale > > > On Jan 13, 2017, at 3:12 PM, Mini Trader > wrote: > > > > I have a small program that will reproduce the issue. Where should the > bug be sent? It's pretty serious. The system is forgetting the location > of the current working directory in a recursive call. > > > > On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman > wrote: > > Have you tried simply tracing the lx-syscall probes? > > > > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader > wrote: > > I followed these instructions prior to my post and my zone would not > boot after doing the mod to add the flag to the file. > > > > > > On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman > wrote: > > The short answer is yes. > > > > My experience debugging LX was on SmartOS and there are some notes on > https://wiki.smartos.org/display/DOC/LX+Branded+Zones# > LXBrandedZones-Debugging > > > > Some of the details on that page are Specific to SmartOS, but some of it > is generic to LX. > > > > -Nahum > > > > On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader > wrote: > > Is there anything that can be done to trace a program having issues on > an LX Zone. > > > > I am seeing: > > > > OSError: [Errno 2] No such file or directory: > > > > Again under certain conditions which I am trying to trace - > unfortunately this is a closed source program. Can DTrace be used to help > track something like this? > > > > Thanks! > > > > > > > > _______________________________________________ > > > > > > 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 miniflowtrader at gmail.com Sat Jan 14 14:16:55 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Sat, 14 Jan 2017 09:16:55 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> Message-ID: Well the author at my request was able to remove the call to os.getcwd() which allows the program to operate. If anyone wants to tinker here is an example that will likely break on someones system. I don't know if this is an LX bug, libc bug, python bug etc. # read a directory, stat all files import os import sys from stat import * def chdir(d): global cwdlist if d != '.': os.chdir(d) if d == '..': cwdlist.pop() else: cwdlist.append(d) print repr('/'.join(cwdlist)) # Comment the line below to allow things to run os.getcwd() def walk(d): chdir(d) dirlist = os.listdir('.') dirlist.sort() for f in dirlist: try: s = os.lstat(f) if S_ISDIR(s.st_mode): walk(f) except OSError, err: print err chdir('..') if len(sys.argv) != 2: print 'need 1 arg, directory to scan' os.chdir(sys.argv[1]) cwd = os.getcwd() cwdlist = cwd.split('/') walk('.') On Fri, Jan 13, 2017 at 4:06 PM, Mini Trader wrote: > Here is the code. It will run just fine with Debian 8.6 or OmniOS. It > will fail on the LX zone with Debian. The only way for it to fail is for > the stat call to fail and this seems to happen because the system doen't > know what directory it is in. The files being looked at are static so not > a race condition. > > Simple python script. > > # read a directory, stat all files > > import os > import sys > from stat import * > > def walk(d): > os.chdir(d) > working = os.getcwd() > print working > dirlist = os.listdir('.') > dirlist.sort() > for f in dirlist: > try: > s = os.lstat(f) > if S_ISDIR(s.st_mode): > walk(f) > except OSError, err: > print "CurrentDIR: " + working > print "CurrentFile: " + f > print err > os.chdir('..') > print "DONE" > > if len(sys.argv) != 2: > print 'need 1 arg, directory to scan' > > cwd = os.getcwd() > os.chdir(sys.argv[1]) > walk('.') > > > On Fri, Jan 13, 2017 at 3:52 PM, Dale Ghent wrote: > >> Could you provide some of your telemetry and background here? There might >> be a reasonable explanation, or a quick fix. >> >> /dale >> >> > On Jan 13, 2017, at 3:12 PM, Mini Trader >> wrote: >> > >> > I have a small program that will reproduce the issue. Where should the >> bug be sent? It's pretty serious. The system is forgetting the location >> of the current working directory in a recursive call. >> > >> > On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman >> wrote: >> > Have you tried simply tracing the lx-syscall probes? >> > >> > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader >> wrote: >> > I followed these instructions prior to my post and my zone would not >> boot after doing the mod to add the flag to the file. >> > >> > >> > On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman >> wrote: >> > The short answer is yes. >> > >> > My experience debugging LX was on SmartOS and there are some notes on >> https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBran >> dedZones-Debugging >> > >> > Some of the details on that page are Specific to SmartOS, but some of >> it is generic to LX. >> > >> > -Nahum >> > >> > On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader >> wrote: >> > Is there anything that can be done to trace a program having issues on >> an LX Zone. >> > >> > I am seeing: >> > >> > OSError: [Errno 2] No such file or directory: >> > >> > Again under certain conditions which I am trying to trace - >> unfortunately this is a closed source program. Can DTrace be used to help >> track something like this? >> > >> > Thanks! >> > >> > >> > >> > _______________________________________________ >> > >> > >> > 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 natxo.asenjo at gmail.com Sat Jan 14 14:35:34 2017 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 14 Jan 2017 15:35:34 +0100 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> Message-ID: hi, On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader wrote: > Well the author at my request was able to remove the call to os.getcwd() > which allows the program to operate. > > > If anyone wants to tinker here is an example that will likely break on > someones system. I don't know if this is an LX bug, libc bug, python bug > etc. > > # read a directory, stat all files > > import os > import sys > from stat import * > > def chdir(d): > global cwdlist > > if d != '.': > os.chdir(d) > if d == '..': > cwdlist.pop() > else: > cwdlist.append(d) > print repr('/'.join(cwdlist)) > # Comment the line below to allow things to run > os.getcwd() > > def walk(d): > chdir(d) > dirlist = os.listdir('.') > dirlist.sort() > for f in dirlist: > try: > s = os.lstat(f) > if S_ISDIR(s.st_mode): > walk(f) > except OSError, err: > print err > chdir('..') > > if len(sys.argv) != 2: > print 'need 1 arg, directory to scan' > > os.chdir(sys.argv[1]) > cwd = os.getcwd() > cwdlist = cwd.split('/') > > walk('.') > > runs fine in a centos 6.8 container, no problem. I even have a couple of mount points with several thousand files and it walks everything without a hitch. -- regards, Natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Sat Jan 14 15:02:35 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Sat, 14 Jan 2017 10:02:35 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> Message-ID: I just tried on CentOS same error. The directory has to be from LOFS i.e. a ZFS pool. >From OmniOS can you output zfs get all zonefileset and /usr/bin/ls -lV zonedirectory and share your results. On Sat, Jan 14, 2017 at 9:35 AM, Natxo Asenjo wrote: > hi, > > > On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader > wrote: > >> Well the author at my request was able to remove the call to os.getcwd() >> which allows the program to operate. >> >> >> If anyone wants to tinker here is an example that will likely break on >> someones system. I don't know if this is an LX bug, libc bug, python bug >> etc. >> >> # read a directory, stat all files >> >> import os >> import sys >> from stat import * >> >> def chdir(d): >> global cwdlist >> >> if d != '.': >> os.chdir(d) >> if d == '..': >> cwdlist.pop() >> else: >> cwdlist.append(d) >> print repr('/'.join(cwdlist)) >> # Comment the line below to allow things to run >> os.getcwd() >> >> def walk(d): >> chdir(d) >> dirlist = os.listdir('.') >> dirlist.sort() >> for f in dirlist: >> try: >> s = os.lstat(f) >> if S_ISDIR(s.st_mode): >> walk(f) >> except OSError, err: >> print err >> chdir('..') >> >> if len(sys.argv) != 2: >> print 'need 1 arg, directory to scan' >> >> os.chdir(sys.argv[1]) >> cwd = os.getcwd() >> cwdlist = cwd.split('/') >> >> walk('.') >> >> > runs fine in a centos 6.8 container, no problem. > > I even have a couple of mount points with several thousand files and it > walks everything without a hitch. > > -- > regards, > Natxo > > > > _______________________________________________ > 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 matjaz85 at gmail.com Sat Jan 14 21:22:22 2017 From: matjaz85 at gmail.com (=?utf-8?B?TWF0amHFviBN?=) Date: Sat, 14 Jan 2017 22:22:22 +0100 Subject: [OmniOS-discuss] Zones problem after upgrade to latest Bloody Message-ID: Hi, there seems to be a problem with (LX?) zones in the newest Bloody. It worked flawlessly before the update, it does not work after I updated to the latest bloody. This is the error I got: matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot zone 'lxzone': "/usr/lib/fs/lofs/mount -o ro,nodevices,nosetuid,noexec /var/zonecontrol/lxzone /tank/zones/lxzone/root/native/.zonecontrol" failed with exit code 111 zoneadm: zone 'lxzone': call to zoneadmd failed It seems that some directories are missing. After I created them manually, it worked: matjaz at server:/export/home/matjaz$ sudo mkdir /var/zonecontrol matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot zone 'lxzone': "/usr/lib/fs/lofs/mount -o ro,nodevices,nosetuid,noexec /var/zonecontrol/lxzone /tank/zones/lxzone/root/native/.zonecontrol" failed with exit code 111 zoneadm: zone 'lxzone': call to zoneadmd failed matjaz at server:/export/home/matjaz$ sudo mkdir /var/zonecontrol/lxzone matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot Note, before creating the directoriesI tried to recreate the zone from scratch and the error appeared again ? My zone config: create -b set zonepath=/tank/zones/lxzone set brand=lx set autoboot=false set ip-type=exclusive add fs set dir=/data set special=/tank/data set type=lofs end add net set physical=lxzone0 add property (name=gateway,value=?192.168.1.1") add property (name=ips,value="192.168.1.77/24") add property (name=primary,value="true") end add attr set name=dns-domain set type=string set value=lxzone end add attr set name=resolvers set type=string set value=192.168.1.1 end add attr set name=kernel-version set type=string set value=4.3.0 end matjaz at server:/export/home/matjaz$ uname -a SunOS server 5.11 omnios-a1b878a i86pc i386 i86pc Best regards, Matjaz -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Sun Jan 15 03:10:14 2017 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 14 Jan 2017 22:10:14 -0500 Subject: [OmniOS-discuss] Zones problem after upgrade to latest Bloody In-Reply-To: References: Message-ID: Known problem. I thought it was fixed in the gate but not yet. See this commit: https://github.com/omniti-labs/illumos-omnios/commit/fb8fa9d90507920e5b8143fe668b175817d4ba1a I need to back that out. You can edit platform.xml by hand and patch it yourself too. Dan Sent from my iPhone (typos, autocorrect, and all) > On Jan 14, 2017, at 4:22 PM, Matja? M wrote: > > Hi, > > there seems to be a problem with (LX?) zones in the newest Bloody. It worked flawlessly before the update, it does not work after I updated to the latest bloody. > > This is the error I got: > > matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot > zone 'lxzone': "/usr/lib/fs/lofs/mount -o ro,nodevices,nosetuid,noexec /var/zonecontrol/lxzone /tank/zones/lxzone/root/native/.zonecontrol" failed with exit code 111 > zoneadm: zone 'lxzone': call to zoneadmd failed > > It seems that some directories are missing. After I created them manually, it worked: > > matjaz at server:/export/home/matjaz$ sudo mkdir /var/zonecontrol > matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot > zone 'lxzone': "/usr/lib/fs/lofs/mount -o ro,nodevices,nosetuid,noexec /var/zonecontrol/lxzone /tank/zones/lxzone/root/native/.zonecontrol" failed with exit code 111 > zoneadm: zone 'lxzone': call to zoneadmd failed > matjaz at server:/export/home/matjaz$ sudo mkdir /var/zonecontrol/lxzone > matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot > > Note, before creating the directoriesI tried to recreate the zone from scratch and the error appeared again ? > > My zone config: > > create -b > set zonepath=/tank/zones/lxzone > set brand=lx > set autoboot=false > set ip-type=exclusive > add fs > set dir=/data > set special=/tank/data > set type=lofs > end > add net > set physical=lxzone0 > add property (name=gateway,value=?192.168.1.1") > add property (name=ips,value="192.168.1.77/24") > add property (name=primary,value="true") > end > add attr > set name=dns-domain > set type=string > set value=lxzone > end > add attr > set name=resolvers > set type=string > set value=192.168.1.1 > end > add attr > set name=kernel-version > set type=string > set value=4.3.0 > end > > matjaz at server:/export/home/matjaz$ uname -a > SunOS server 5.11 omnios-a1b878a i86pc i386 i86pc > > > Best regards, > Matjaz > _______________________________________________ > 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 matjaz85 at gmail.com Sun Jan 15 12:05:40 2017 From: matjaz85 at gmail.com (=?utf-8?B?TWF0amHFviBN?=) Date: Sun, 15 Jan 2017 13:05:40 +0100 Subject: [OmniOS-discuss] Zones problem after upgrade to latest Bloody In-Reply-To: References: Message-ID: <352A9A3B-8728-4F71-8B28-5B8795D69E48@gmail.com> Thank you! Cheers, Matjaz > On 15. jan. 2017, at 04:10, Dan McDonald wrote: > > Known problem. I thought it was fixed in the gate but not yet. See this commit: > > https://github.com/omniti-labs/illumos-omnios/commit/fb8fa9d90507920e5b8143fe668b175817d4ba1a > > I need to back that out. You can edit platform.xml by hand and patch it yourself too. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Jan 14, 2017, at 4:22 PM, Matja? M > wrote: > >> Hi, >> >> there seems to be a problem with (LX?) zones in the newest Bloody. It worked flawlessly before the update, it does not work after I updated to the latest bloody. >> >> This is the error I got: >> >> matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot >> zone 'lxzone': "/usr/lib/fs/lofs/mount -o ro,nodevices,nosetuid,noexec /var/zonecontrol/lxzone /tank/zones/lxzone/root/native/.zonecontrol" failed with exit code 111 >> zoneadm: zone 'lxzone': call to zoneadmd failed >> >> It seems that some directories are missing. After I created them manually, it worked: >> >> matjaz at server:/export/home/matjaz$ sudo mkdir /var/zonecontrol >> matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot >> zone 'lxzone': "/usr/lib/fs/lofs/mount -o ro,nodevices,nosetuid,noexec /var/zonecontrol/lxzone /tank/zones/lxzone/root/native/.zonecontrol" failed with exit code 111 >> zoneadm: zone 'lxzone': call to zoneadmd failed >> matjaz at server:/export/home/matjaz$ sudo mkdir /var/zonecontrol/lxzone >> matjaz at server:/export/home/matjaz$ sudo zoneadm -z lxzone boot >> >> Note, before creating the directoriesI tried to recreate the zone from scratch and the error appeared again ? >> >> My zone config: >> >> create -b >> set zonepath=/tank/zones/lxzone >> set brand=lx >> set autoboot=false >> set ip-type=exclusive >> add fs >> set dir=/data >> set special=/tank/data >> set type=lofs >> end >> add net >> set physical=lxzone0 >> add property (name=gateway,value=?192.168.1.1") >> add property (name=ips,value="192.168.1.77/24") >> add property (name=primary,value="true") >> end >> add attr >> set name=dns-domain >> set type=string >> set value=lxzone >> end >> add attr >> set name=resolvers >> set type=string >> set value=192.168.1.1 >> end >> add attr >> set name=kernel-version >> set type=string >> set value=4.3.0 >> end >> >> matjaz at server:/export/home/matjaz$ uname -a >> SunOS server 5.11 omnios-a1b878a i86pc i386 i86pc >> >> >> Best regards, >> Matjaz >> _______________________________________________ >> 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 miniflowtrader at gmail.com Sun Jan 15 19:21:26 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Sun, 15 Jan 2017 14:21:26 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> Message-ID: Here is the strace. Which shows the underlying libc call failing. chdir would have failed if the directory was not there. Maybe a race condition going on here? Does this now become a Linux bug? I've even made a call to pwd in the exception and it does not fail. lstat("ParameterSet", {st_mode=S_IFDIR|0777, st_size=4, ...}) = 0 chdir("ParameterSet") = 0 write(1, "'/main/documents/oneofmydirectories"..., 101'/main/documents/oneofmydirectories/ParameterSet' ) = 101 getcwd(0x7fffffefebc0, 1026) = -1 ENOENT (No such file or directory) write(1, "[Errno 2] No such file or direct"..., 36[Errno 2] No such file or directory ) = 36 On Sat, Jan 14, 2017 at 10:02 AM, Mini Trader wrote: > I just tried on CentOS same error. The directory has to be from LOFS i.e. > a ZFS pool. > > From OmniOS can you output zfs get all zonefileset and /usr/bin/ls -lV > zonedirectory and share your results. > > On Sat, Jan 14, 2017 at 9:35 AM, Natxo Asenjo > wrote: > >> hi, >> >> >> On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader >> wrote: >> >>> Well the author at my request was able to remove the call to os.getcwd() >>> which allows the program to operate. >>> >>> >>> If anyone wants to tinker here is an example that will likely break on >>> someones system. I don't know if this is an LX bug, libc bug, python bug >>> etc. >>> >>> # read a directory, stat all files >>> >>> import os >>> import sys >>> from stat import * >>> >>> def chdir(d): >>> global cwdlist >>> >>> if d != '.': >>> os.chdir(d) >>> if d == '..': >>> cwdlist.pop() >>> else: >>> cwdlist.append(d) >>> print repr('/'.join(cwdlist)) >>> # Comment the line below to allow things to run >>> os.getcwd() >>> >>> def walk(d): >>> chdir(d) >>> dirlist = os.listdir('.') >>> dirlist.sort() >>> for f in dirlist: >>> try: >>> s = os.lstat(f) >>> if S_ISDIR(s.st_mode): >>> walk(f) >>> except OSError, err: >>> print err >>> chdir('..') >>> >>> if len(sys.argv) != 2: >>> print 'need 1 arg, directory to scan' >>> >>> os.chdir(sys.argv[1]) >>> cwd = os.getcwd() >>> cwdlist = cwd.split('/') >>> >>> walk('.') >>> >>> >> runs fine in a centos 6.8 container, no problem. >> >> I even have a couple of mount points with several thousand files and it >> walks everything without a hitch. >> >> -- >> regards, >> Natxo >> >> >> >> _______________________________________________ >> 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 Rouven_Weiler at gmx.net Mon Jan 16 08:17:23 2017 From: Rouven_Weiler at gmx.net (Rouven WEILER) Date: Mon, 16 Jan 2017 09:17:23 +0100 Subject: [OmniOS-discuss] Using system's with the pakaged gcc48 on omnios 151014. Message-ID: An HTML attachment was scrubbed... URL: From peter.tribble at gmail.com Mon Jan 16 11:33:40 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Mon, 16 Jan 2017 11:33:40 +0000 Subject: [OmniOS-discuss] Using system's with the pakaged gcc48 on omnios 151014. In-Reply-To: References: Message-ID: On Mon, Jan 16, 2017 at 8:17 AM, Rouven WEILER wrote: > Hi all, > > I want to compile something with gcc48 package in the omnios pkg repo. > Therefore it is necessary to use the PTHREAD_STACK_MIN type which is > defined in the system's . > The problem: gcc uses it's own one which does not include this type. > > Can anybody help me how to get that working? > I have to admit I did not get any (for me) working info from the gcc web > page. > Generally, gcc's notion of "fixed" includes is thoroughly broken. Even toxic. Whenever I build gcc myself these days I simply wipe out the erroneous files. (Dan - any chance of removing the include-fixed files from the package?) So the following will help rm -fr /opt/gcc-4.8.1/lib/gcc/i386-pc-solaris2.11/4.8.1/include-fixed You may choose to alternatively move them out of the way, although 'pkg fix' will put them back if you need them. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Mon Jan 16 15:40:59 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 16 Jan 2017 10:40:59 -0500 Subject: [OmniOS-discuss] LOFS LX chdir bug with steps to reproduce Message-ID: I spent a bit of time yesterday using dtrace and looking at the source. I believe I found why the system is falsely reporting that the current directory does not exist and have created a simple program to reproduce the problem. The problem seems to be related to when v_path in the vnode struct goes above a certain number of characters. This will only break on LOFS if inside the LX zone. Every time a program performs a chdir('..') and up to another dir the system stored working directory is falsely growing. Here are the steps to reproduce. 1. Mount a ZFS dataset via LOFS for your LX zone. 2. Create a directory in the dataset called test 3. In the test directory create another directory called 'Chdir Test' 4. Run the program below. All this is doing is going up a directory and dropping down a directory. We want to fill up v_path. 5. The program will bomb before iteration 1000. Really there should be no limit. import os import time #time.sleep(15) os.chdir('/tank/bigtest/test') for i in xrange(1000): print i os.chdir('Chdir Test') os.getcwd() os.chdir('..') I used the following dtrace to get insight into what was happening (ran it from global zone). dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482 Uncomment the sleep line so that you can determine the PID when running dtrace. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 16 16:58:34 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 16 Jan 2017 11:58:34 -0500 Subject: [OmniOS-discuss] Zones problem after upgrade to latest Bloody In-Reply-To: <352A9A3B-8728-4F71-8B28-5B8795D69E48@gmail.com> References: <352A9A3B-8728-4F71-8B28-5B8795D69E48@gmail.com> Message-ID: > On Jan 15, 2017, at 7:05 AM, Matja? M wrote: > > Thank you! Thank YOU for reminding me to push it back: https://github.com/omniti-labs/illumos-omnios/commit/827e9d7a912650928136d0f1748b34df7edbcfe8 It'll hit the repos this week with a large update (say goodbye to Python2.6) of bloody. Dan From danmcd at omniti.com Mon Jan 16 17:02:39 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 16 Jan 2017 12:02:39 -0500 Subject: [OmniOS-discuss] LX Zone DTrace In-Reply-To: References: <293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com> Message-ID: <693F7B53-C345-4BF6-BA7D-2DF88078CECE@omniti.com> > On Jan 15, 2017, at 2:21 PM, Mini Trader wrote: > > Here is the strace. Which shows the underlying libc call failing. chdir would have failed if the directory was not there. Maybe a race condition going on here? Does this now become a Linux bug? > > I've even made a call to pwd in the exception and it does not fail. > > lstat("ParameterSet", {st_mode=S_IFDIR|0777, st_size=4, ...}) = 0 > chdir("ParameterSet") = 0 > write(1, "'/main/documents/oneofmydirectories"..., 101'/main/documents/oneofmydirectories/ParameterSet' > ) = 101 > getcwd(0x7fffffefebc0, 1026) = -1 ENOENT (No such file or directory) > write(1, "[Errno 2] No such file or direct"..., 36[Errno 2] No such file or directory > ) = 36 > I see you have more on this later, but if this is something manifesting only in an LX zone, it's either a bug-for-bug compatibility with Linux, a bug in the LX code itself, or a bug in greater illumos that for some reason only LX zones expose. More when I get to the other mail you sent, Mini. Dan From danmcd at omniti.com Mon Jan 16 17:08:16 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 16 Jan 2017 12:08:16 -0500 Subject: [OmniOS-discuss] Using system's with the pakaged gcc48 on omnios 151014. In-Reply-To: References: Message-ID: <6FCE33A3-48C1-4914-876E-207EF363F906@omniti.com> > On Jan 16, 2017, at 6:33 AM, Peter Tribble wrote: > > (Dan - any chance of removing the include-fixed files from the package?) I'm afraid to touch these because doing so sometimes breaks other software installs. NOTE: that as of r151016 we're on gcc51, and that is what'll be shipping with the next LTS (r151022) as well. Dan From danmcd at omniti.com Mon Jan 16 17:13:11 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 16 Jan 2017 12:13:11 -0500 Subject: [OmniOS-discuss] LOFS LX chdir bug with steps to reproduce In-Reply-To: References: Message-ID: Thank you for doing this! Some questions in-line: > On Jan 16, 2017, at 10:40 AM, Mini Trader wrote: > > I spent a bit of time yesterday using dtrace and looking at the source. I believe I found why the system is falsely reporting that the current directory does not exist and have created a simple program to reproduce the problem. The problem seems to be related to when v_path in the vnode struct goes above a certain number of characters. This will only break on LOFS if inside the LX zone. Every time a program performs a chdir('..') and up to another dir the system stored working directory is falsely growing. Have you tried this on a native zone (just to make sure) as well? > Here are the steps to reproduce. > > 1. Mount a ZFS dataset via LOFS for your LX zone. > 2. Create a directory in the dataset called test > 3. In the test directory create another directory called 'Chdir Test' Does it matter where (global zone, inside LX zone) these directories gets created? > 4. Run the program below. All this is doing is going up a directory and dropping down a directory. We want to fill up v_path. Python... > 5. The program will bomb before iteration 1000. Really there should be no limit. > > import os > import time > > #time.sleep(15) > os.chdir('/tank/bigtest/test') > for i in xrange(1000): > print i > os.chdir('Chdir Test') > os.getcwd() > os.chdir('..') > > I used the following dtrace to get insight into what was happening (ran it from global zone). > > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482 > > Uncomment the sleep line so that you can determine the PID when running dtrace. I'm forwarding this note on to Joyent, so they can see what's going on. I think this may be an LX bug, but I'm not sure. Thanks, Dan From miniflowtrader at gmail.com Mon Jan 16 18:02:57 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 16 Jan 2017 13:02:57 -0500 Subject: [OmniOS-discuss] LOFS LX chdir bug with steps to reproduce In-Reply-To: References: Message-ID: 1. Does not happen on native. 2. My non-global zones are under /tank/zones/ 3. It uses python - but the calls are all stdlib calls, no magic they are going directly to C. You can reproduce with same calls on C the system will eventually return ENOENT/ERRNO=2. 4. Looks to be LX specific. I also tested in global zone with LOFS. No issue. Thanks! On Mon, Jan 16, 2017 at 12:13 PM, Dan McDonald wrote: > Thank you for doing this! Some questions in-line: > > > On Jan 16, 2017, at 10:40 AM, Mini Trader > wrote: > > > > I spent a bit of time yesterday using dtrace and looking at the source. > I believe I found why the system is falsely reporting that the current > directory does not exist and have created a simple program to reproduce the > problem. The problem seems to be related to when v_path in the vnode > struct goes above a certain number of characters. This will only break on > LOFS if inside the LX zone. Every time a program performs a chdir('..') > and up to another dir the system stored working directory is falsely > growing. > > Have you tried this on a native zone (just to make sure) as well? > > > Here are the steps to reproduce. > > > > 1. Mount a ZFS dataset via LOFS for your LX zone. > > 2. Create a directory in the dataset called test > > 3. In the test directory create another directory called 'Chdir Test' > > Does it matter where (global zone, inside LX zone) these directories gets > created? > > > 4. Run the program below. All this is doing is going up a directory and > dropping down a directory. We want to fill up v_path. > > Python... > > > 5. The program will bomb before iteration 1000. Really there should be > no limit. > > > > import os > > import time > > > > #time.sleep(15) > > os.chdir('/tank/bigtest/test') > > for i in xrange(1000): > > print i > > os.chdir('Chdir Test') > > os.getcwd() > > os.chdir('..') > > > > I used the following dtrace to get insight into what was happening (ran > it from global zone). > > > > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { > printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482 > > > > Uncomment the sleep line so that you can determine the PID when running > dtrace. > > I'm forwarding this note on to Joyent, so they can see what's going on. I > think this may be an LX bug, but I'm not sure. > > Thanks, > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 16 20:24:40 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 16 Jan 2017 15:24:40 -0500 Subject: [OmniOS-discuss] LOFS LX chdir bug with steps to reproduce In-Reply-To: References: Message-ID: Thank you. I've discussed with Joyent, and they couldn't reproduce it. They have a fix we don't, so between that and whether or not it's fixed on bloody (you're on r151020, right mini?), I'll have to try it myself. It's possible the Joyent fix (outside LX, not yet upstreamed) may cure what ails you. FYI, Dan Sent from my iPhone (typos, autocorrect, and all) > On Jan 16, 2017, at 1:02 PM, Mini Trader wrote: > > 1. Does not happen on native. > 2. My non-global zones are under /tank/zones/ > 3. It uses python - but the calls are all stdlib calls, no magic they are going directly to C. You can reproduce with same calls on C the system will eventually return ENOENT/ERRNO=2. > 4. Looks to be LX specific. I also tested in global zone with LOFS. No issue. > > Thanks! > >> On Mon, Jan 16, 2017 at 12:13 PM, Dan McDonald wrote: >> Thank you for doing this! Some questions in-line: >> >> > On Jan 16, 2017, at 10:40 AM, Mini Trader wrote: >> > >> > I spent a bit of time yesterday using dtrace and looking at the source. I believe I found why the system is falsely reporting that the current directory does not exist and have created a simple program to reproduce the problem. The problem seems to be related to when v_path in the vnode struct goes above a certain number of characters. This will only break on LOFS if inside the LX zone. Every time a program performs a chdir('..') and up to another dir the system stored working directory is falsely growing. >> >> Have you tried this on a native zone (just to make sure) as well? >> >> > Here are the steps to reproduce. >> > >> > 1. Mount a ZFS dataset via LOFS for your LX zone. >> > 2. Create a directory in the dataset called test >> > 3. In the test directory create another directory called 'Chdir Test' >> >> Does it matter where (global zone, inside LX zone) these directories gets created? >> >> > 4. Run the program below. All this is doing is going up a directory and dropping down a directory. We want to fill up v_path. >> >> Python... >> >> > 5. The program will bomb before iteration 1000. Really there should be no limit. >> > >> > import os >> > import time >> > >> > #time.sleep(15) >> > os.chdir('/tank/bigtest/test') >> > for i in xrange(1000): >> > print i >> > os.chdir('Chdir Test') >> > os.getcwd() >> > os.chdir('..') >> > >> > I used the following dtrace to get insight into what was happening (ran it from global zone). >> > >> > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482 >> > >> > Uncomment the sleep line so that you can determine the PID when running dtrace. >> >> I'm forwarding this note on to Joyent, so they can see what's going on. I think this may be an LX bug, but I'm not sure. >> >> Thanks, >> Dan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Mon Jan 16 20:38:28 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 16 Jan 2017 20:38:28 +0000 Subject: [OmniOS-discuss] LOFS LX chdir bug with steps to reproduce In-Reply-To: References: Message-ID: That is correct I am on 151020 just moved up from LTS for this feature. Just to be clear about one thing. If you run this on a regular directory in the LX zone there is no issue. It only takes place if the directory being read is from the LOFS mount of a ZFS dataset. My mount has a property of read only. I did not try without the readonly option. That would be awesome if there is already a fix. This feature is pretty amazing! On Mon, Jan 16, 2017 at 3:24 PM Dan McDonald wrote: > Thank you. I've discussed with Joyent, and they couldn't reproduce it. > They have a fix we don't, so between that and whether or not it's fixed on > bloody (you're on r151020, right mini?), I'll have to try it myself. It's > possible the Joyent fix (outside LX, not yet upstreamed) may cure what ails > you. > > FYI, > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Jan 16, 2017, at 1:02 PM, Mini Trader wrote: > > 1. Does not happen on native. > 2. My non-global zones are under /tank/zones/ > 3. It uses python - but the calls are all stdlib calls, no magic they are > going directly to C. You can reproduce with same calls on C the system > will eventually return ENOENT/ERRNO=2. > 4. Looks to be LX specific. I also tested in global zone with LOFS. No > issue. > > Thanks! > > On Mon, Jan 16, 2017 at 12:13 PM, Dan McDonald wrote: > > Thank you for doing this! Some questions in-line: > > > > > > > On Jan 16, 2017, at 10:40 AM, Mini Trader > wrote: > > > > > > > > I spent a bit of time yesterday using dtrace and looking at the source. > I believe I found why the system is falsely reporting that the current > directory does not exist and have created a simple program to reproduce the > problem. The problem seems to be related to when v_path in the vnode > struct goes above a certain number of characters. This will only break on > LOFS if inside the LX zone. Every time a program performs a chdir('..') > and up to another dir the system stored working directory is falsely > growing. > > > > > > Have you tried this on a native zone (just to make sure) as well? > > > > > > > Here are the steps to reproduce. > > > > > > > > 1. Mount a ZFS dataset via LOFS for your LX zone. > > > > 2. Create a directory in the dataset called test > > > > 3. In the test directory create another directory called 'Chdir Test' > > > > > > Does it matter where (global zone, inside LX zone) these directories gets > created? > > > > > > > 4. Run the program below. All this is doing is going up a directory and > dropping down a directory. We want to fill up v_path. > > > > > > Python... > > > > > > > 5. The program will bomb before iteration 1000. Really there should be > no limit. > > > > > > > > import os > > > > import time > > > > > > > > #time.sleep(15) > > > > os.chdir('/tank/bigtest/test') > > > > for i in xrange(1000): > > > > print i > > > > os.chdir('Chdir Test') > > > > os.getcwd() > > > > os.chdir('..') > > > > > > > > I used the following dtrace to get insight into what was happening (ran > it from global zone). > > > > > > > > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { > printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482 > > > > > > > > Uncomment the sleep line so that you can determine the PID when running > dtrace. > > > > > > I'm forwarding this note on to Joyent, so they can see what's going on. I > think this may be an LX bug, but I'm not sure. > > > > > > Thanks, > > > Dan > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaakko.linnosaari at polarshift.fi Mon Jan 16 20:42:00 2017 From: jaakko.linnosaari at polarshift.fi (Jaakko Linnosaari) Date: Mon, 16 Jan 2017 22:42:00 +0200 Subject: [OmniOS-discuss] LX chdir bug with steps to reproduce In-Reply-To: References: Message-ID: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi> > On 16 Jan 2017, at 17.40, Mini Trader wrote: > > I used the following dtrace to get insight into what was happening (ran it from global zone). > > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482 > I stumbled upon a similar bug (?) with Alpine 3.5 in LX zone and used this dtrace to see what is going on. No LOFS involved. I ran these commands: lxforum:~# cd /tmp lxforum:/tmp# mkdir foo lxforum:/tmp# mkdir foo/bar lxforum:/tmp# cd foo lxforum:/tmp/foo# cd bar lxforum:/tmp/foo/bar# cd .. lxforum:/tmp/foo# cd .. lxforum:/tmp# mv foo baz lxforum:/tmp# cd baz lxforum:/tmp/baz# cd bar -ash: getcwd: No such file or directory lxforum:(unknown)# dtrace looks like this: # pfexec dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 1100 /dpool/zones/lxforum/root/tmp /dpool/zones/lxforum/root/tmp /dpool/zones/lxforum/root/tmp/foo /dpool/zones/lxforum/root/tmp/foo/bar /dpool/zones/lxforum/root/tmp/foo /dpool/zones/lxforum/root/tmp /dpool/zones/lxforum/root/tmp /dpool/zones/lxforum/root/tmp/baz /dpool/zones/lxforum/root/tmp/foo/bar So it would seem that renaming/moving a directory doesn?t update all links appropriately. ? Jaakko -------------- next part -------------- An HTML attachment was scrubbed... URL: From miniflowtrader at gmail.com Mon Jan 16 22:01:42 2017 From: miniflowtrader at gmail.com (Mini Trader) Date: Mon, 16 Jan 2017 17:01:42 -0500 Subject: [OmniOS-discuss] LX chdir bug with steps to reproduce In-Reply-To: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi> References: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi> Message-ID: There are a 6 changes that have not been up streamed from: https://github.com/joyent/illumos-joyent/commits/master/usr/src/uts/common/fs/lookup.c We definitely need: https://smartos.org/bugview/OS-5167 (and probably whatever was done before it). On Mon, Jan 16, 2017 at 3:42 PM, Jaakko Linnosaari < jaakko.linnosaari at polarshift.fi> wrote: > > On 16 Jan 2017, at 17.40, Mini Trader wrote: > > I used the following dtrace to get insight into what was happening (ran it > from global zone). > > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ { > printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482 > > > I stumbled upon a similar bug (?) with Alpine 3.5 in LX zone and used this > dtrace to see what is going on. No LOFS involved. > > I ran these commands: > > lxforum:~# cd /tmp > lxforum:/tmp# mkdir foo > lxforum:/tmp# mkdir foo/bar > lxforum:/tmp# cd foo > lxforum:/tmp/foo# cd bar > lxforum:/tmp/foo/bar# cd .. > lxforum:/tmp/foo# cd .. > lxforum:/tmp# mv foo baz > lxforum:/tmp# cd baz > lxforum:/tmp/baz# cd bar > -ash: getcwd: No such file or directory > lxforum:(unknown)# > > dtrace looks like this: > > # pfexec dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ > { printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 1100 > /dpool/zones/lxforum/root/tmp > /dpool/zones/lxforum/root/tmp > /dpool/zones/lxforum/root/tmp/foo > /dpool/zones/lxforum/root/tmp/foo/bar > /dpool/zones/lxforum/root/tmp/foo > /dpool/zones/lxforum/root/tmp > /dpool/zones/lxforum/root/tmp > /dpool/zones/lxforum/root/tmp/baz > /dpool/zones/lxforum/root/tmp/foo/bar > > So it would seem that renaming/moving a directory doesn?t update all links > appropriately. > > ? Jaakko > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 16 22:36:54 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 16 Jan 2017 17:36:54 -0500 Subject: [OmniOS-discuss] LX chdir bug with steps to reproduce In-Reply-To: References: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi> Message-ID: <9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com> > On Jan 16, 2017, at 5:01 PM, Mini Trader wrote: > > We definitely need: > > https://smartos.org/bugview/OS-5167 (and probably whatever was done before it). Joyent mentioned that very bug to me earlier this afternoon. During the bringup of LX zones, I didn't cherrypick it from illumos-joyent, and now I remember why... it unravels a larger ball of yarn. To that end, I'm attempting that unravelling now. I doubt it'll be backported into r151020, though. LX is still considered "beta" in 020, and stability of the overall system is why I'm loathe to bring in non-LX fixes for LX problems (as these all are) into a Stable release. I'm going to cut a bloody release this week. It has lots of new things in it, and if I'm lucky, it may include these Joyent fixes as well. If you want to help, get a box up to bloody once I cut the release this week. Thanks, and sorry I can't be of IMMEDIATE assistance, Dan From stephan.budach at jvm.de Tue Jan 17 16:12:09 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Tue, 17 Jan 2017 17:12:09 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> Message-ID: Hi guys, I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From danmcd at omniti.com Tue Jan 17 16:22:10 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 17 Jan 2017 11:22:10 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> Message-ID: <09494D67-D741-4610-958F-FBED913F92FF@omniti.com> > On Jan 17, 2017, at 11:12 AM, Stephan Budach wrote: > > Hi guys, > > I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? X550 support went in June of 2016. Dale knows more about ixgbe than I do, since he did the work for X550. Dan From daleg at omniti.com Tue Jan 17 16:22:41 2017 From: daleg at omniti.com (Dale Ghent) Date: Tue, 17 Jan 2017 11:22:41 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> Message-ID: <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> > On Jan 17, 2017, at 11:12 AM, Stephan Budach wrote: > > Hi guys, > > I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? > > Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. /dale From stephan.budach at jvm.de Tue Jan 17 16:31:24 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Tue, 17 Jan 2017 17:31:24 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> Message-ID: Hi Dale, Am 17.01.17 um 17:22 schrieb Dale Ghent: >> On Jan 17, 2017, at 11:12 AM, Stephan Budach wrote: >> >> Hi guys, >> >> I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? >> >> Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? > Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. > > /dale do you know of any option to get to know, why three of my boxes are flapping their 10GbE ports? It's actually not only when in aggr mode, but on single use as well. Last week I presumeably had one of my RSF-1 nodes panic, since it couldn't get to it's iSCSI LUNs anymore. The thing ist, that somewhere doen the line, the ixgbe driver seems to be fine, to configure one port to 1GbE instead of 10GbE, which will stop the flapping, but wich will break the VPC on my Nexus nevertheless. In syslog, this looks like this: Jan 17 14:41:51 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:42:11 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:43:33 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe1 link down Jan 17 14:43:33 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 10000 Mbps, full duplex Jan 17 14:43:34 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe1 link down Jan 17 14:43:43 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 10000 Mbps, full duplex Jan 17 14:44:05 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe1 link down Jan 17 14:44:10 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 10000 Mbps, full duplex Jan 17 14:45:14 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe1 link down Jan 17 14:45:14 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 10000 Mbps, full duplex Jan 17 14:45:14 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe1 link down Jan 17 14:45:29 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 10000 Mbps, full duplex Jan 17 14:45:29 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe1 link down Jan 17 14:45:29 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 10000 Mbps, full duplex Jan 17 14:45:29 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe1 link down Jan 17 14:45:40 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:45:45 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:45:51 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:45:51 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:45:52 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:45:56 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:46:07 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 1000 Mbps, full duplex Jan 17 14:46:21 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:46:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:46:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:46:26 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:52:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:52:32 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:54:50 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:54:55 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:58:12 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Jan 17 14:58:16 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex Jan 17 14:59:46 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down Note on 14:46:07, where the system settles on a 1GbE connection? Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From danmcd at omniti.com Tue Jan 17 16:36:07 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 17 Jan 2017 11:36:07 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> Message-ID: I'd check your switch, though you're using 10GigBaseT, which shouldn't be as big of a problem. Hmmm, using cat6 or better cables? 5e isn't going to cut it for reliable 10Gig service. Dan From daleg at omniti.com Tue Jan 17 16:37:35 2017 From: daleg at omniti.com (Dale Ghent) Date: Tue, 17 Jan 2017 11:37:35 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> Message-ID: > On Jan 17, 2017, at 11:31 AM, Stephan Budach wrote: > > Hi Dale, > > Am 17.01.17 um 17:22 schrieb Dale Ghent: >>> On Jan 17, 2017, at 11:12 AM, Stephan Budach >>> wrote: >>> >>> Hi guys, >>> >>> I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? >>> >>> Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? >>> >> Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. >> >> /dale >> > > do you know of any option to get to know, why three of my boxes are flapping their 10GbE ports? It's actually not only when in aggr mode, but on single use as well. Last week I presumeably had one of my RSF-1 nodes panic, since it couldn't get to it's iSCSI LUNs anymore. The thing ist, that somewhere doen the line, the ixgbe driver seems to be fine, to configure one port to 1GbE instead of 10GbE, which will stop the flapping, but wich will break the VPC on my Nexus nevertheless. > > In syslog, this looks like this: > > ... > Jan 17 14:46:07 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 1000 Mbps, full duplex > Jan 17 14:46:21 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down > Jan 17 14:46:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex > Jan 17 14:46:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down > Jan 17 14:46:26 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex > Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down > Jan 17 14:52:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex > Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down > Jan 17 14:52:32 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex > Jan 17 14:54:50 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down > Jan 17 14:54:55 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex > Jan 17 14:58:12 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down > Jan 17 14:58:16 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex > Jan 17 14:59:46 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down > > Note on 14:46:07, where the system settles on a 1GbE connection? Sounds like a cabling issue? Are the runs too long or are you not using CAT6a? It flapping at 10Gb and then settling at 1Gb would indicate a cabling issue to me. The driver will always try to link at the fastest speed that the local controller and the remote peer will negotiate at... it will not proactively downgrade the link speed. If that happens, it is because that is what the controller managed to negotiate with the remote peer at. Are you using jumbo frames or anything outside of a normal 1500mtu link? /dale From stephan.budach at jvm.de Tue Jan 17 19:39:49 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Tue, 17 Jan 2017 20:39:49 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> Message-ID: Am 17.01.17 um 17:37 schrieb Dale Ghent: >> On Jan 17, 2017, at 11:31 AM, Stephan Budach wrote: >> >> Hi Dale, >> >> Am 17.01.17 um 17:22 schrieb Dale Ghent: >>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach >>>> wrote: >>>> >>>> Hi guys, >>>> >>>> I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? >>>> >>>> Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? >>>> >>> Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. >>> >>> /dale >>> >> do you know of any option to get to know, why three of my boxes are flapping their 10GbE ports? It's actually not only when in aggr mode, but on single use as well. Last week I presumeably had one of my RSF-1 nodes panic, since it couldn't get to it's iSCSI LUNs anymore. The thing ist, that somewhere doen the line, the ixgbe driver seems to be fine, to configure one port to 1GbE instead of 10GbE, which will stop the flapping, but wich will break the VPC on my Nexus nevertheless. >> >> In syslog, this looks like this: >> >> ... >> Jan 17 14:46:07 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 1000 Mbps, full duplex >> Jan 17 14:46:21 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >> Jan 17 14:46:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >> Jan 17 14:46:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >> Jan 17 14:46:26 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >> Jan 17 14:52:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >> Jan 17 14:52:32 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >> Jan 17 14:54:50 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >> Jan 17 14:54:55 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >> Jan 17 14:58:12 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >> Jan 17 14:58:16 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >> Jan 17 14:59:46 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >> >> Note on 14:46:07, where the system settles on a 1GbE connection? > Sounds like a cabling issue? Are the runs too long or are you not using CAT6a? It flapping at 10Gb and then settling at 1Gb would indicate a cabling issue to me. The driver will always try to link at the fastest speed that the local controller and the remote peer will negotiate at... it will not proactively downgrade the link speed. If that happens, it is because that is what the controller managed to negotiate with the remote peer at. > > Are you using jumbo frames or anything outside of a normal 1500mtu link? > > /dale The cables are actually specifically purchased cat6 cables. They run about 2m, not more. It could be tna cables, but I am running a couple of those and afaik, I only get these issues on these three nodes. I can try some other cables, but I hoped to be able to get maybe some kind of debug messages from the driver. Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From mir at miras.org Tue Jan 17 19:54:28 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 17 Jan 2017 20:54:28 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> Message-ID: <20170117205428.2959ffc4@sleipner.datanom.net> On Tue, 17 Jan 2017 20:39:49 +0100 Stephan Budach wrote: > The cables are actually specifically purchased cat6 cables. They run about 2m, not more. It could be tna cables, but I am running a couple of those and afaik, I only get these issues on these three nodes. I can try some other cables, but I hoped to be able to get maybe some kind of debug messages from the driver. > Should 10Gb not use cat 6a? BTW. Have you tried various settings for buffers and hardware offload? -- 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: The early bird gets the coffee left over from the night before. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From daleg at omniti.com Tue Jan 17 22:09:56 2017 From: daleg at omniti.com (Dale Ghent) Date: Tue, 17 Jan 2017 17:09:56 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> Message-ID: <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> > On Jan 17, 2017, at 2:39 PM, Stephan Budach wrote: > > Am 17.01.17 um 17:37 schrieb Dale Ghent: >>> On Jan 17, 2017, at 11:31 AM, Stephan Budach >>> wrote: >>> >>> Hi Dale, >>> >>> Am 17.01.17 um 17:22 schrieb Dale Ghent: >>> >>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach >>>>> >>>>> wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? >>>>> >>>>> Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? >>>>> >>>>> >>>> Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. >>>> >>>> /dale >>>> >>>> >>> do you know of any option to get to know, why three of my boxes are flapping their 10GbE ports? It's actually not only when in aggr mode, but on single use as well. Last week I presumeably had one of my RSF-1 nodes panic, since it couldn't get to it's iSCSI LUNs anymore. The thing ist, that somewhere doen the line, the ixgbe driver seems to be fine, to configure one port to 1GbE instead of 10GbE, which will stop the flapping, but wich will break the VPC on my Nexus nevertheless. >>> >>> In syslog, this looks like this: >>> >>> ... >>> Jan 17 14:46:07 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 1000 Mbps, full duplex >>> Jan 17 14:46:21 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>> Jan 17 14:46:26 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>> Jan 17 14:52:32 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>> Jan 17 14:54:50 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>> Jan 17 14:54:55 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>> Jan 17 14:58:12 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>> Jan 17 14:58:16 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>> Jan 17 14:59:46 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>> >>> Note on 14:46:07, where the system settles on a 1GbE connection? >>> >> Sounds like a cabling issue? Are the runs too long or are you not using CAT6a? It flapping at 10Gb and then settling at 1Gb would indicate a cabling issue to me. The driver will always try to link at the fastest speed that the local controller and the remote peer will negotiate at... it will not proactively downgrade the link speed. If that happens, it is because that is what the controller managed to negotiate with the remote peer at. >> >> Are you using jumbo frames or anything outside of a normal 1500mtu link? >> >> /dale >> > The cables are actually specifically purchased cat6 cables. They run about 2m, not more. It could be tna cables, but I am running a couple of those and afaik, I only get these issues on these three nodes. I can try some other cables, but I hoped to be able to get maybe some kind of debug messages from the driver. The chip provides no reason for a LoS or downgrade of the link. For configuration issues it interrupts only on a few things. "LSC" (Link Status Change) interrupts one of these things and are what tells the driver to interrogate the chip for its current speed, but beyond that, the hardware provides no further details. Any details regarding why the PHY had to re-train the link are completely hidden to the driver. Are these X540 interfaces actually built into the motherboard, or are they separate PCIe cards? Also, CAT6 alone might not be enough, and even the magnetics on the older X540 might not even be able to eek out a 10Gb connection, even at 2m. I would remove all doubt of cabling being an issue by replacing them with CAT6a. Beware of cable vendors who sell CAT6 cables as "CAT6a". It could also be an issue with the modular jacks on the ends. Since you mentioned "after 6/2016" for the ixgbe driver, have you tried the newer one yet? Large portions of it were re-written and re-factored, and many bugs fixed including portions that touch the X540 due to the new X550 also being copper and the two models needing to share some logic related to that. /dale From danmcd at omniti.com Wed Jan 18 01:33:43 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 17 Jan 2017 20:33:43 -0500 Subject: [OmniOS-discuss] New OmniOS bloody Message-ID: <068E8B44-1ADF-4763-88C5-75926CF52FED@omniti.com> Pardon the delay between this and the last one of late-November. We've been either on winter break, or trying to make some large progress. We managed both. There are new ISO and USB-DD files with this update. New with this update: * Python 2.6 has been obsoleted in favor of Python 2.7(.13). This affected illumos-omnios, caiman, and pkg5. The new ISOs have a Python2.7 version of caiman, but we aren't necessarily committing to that for the r151022 installer yet. There is no trace of Python 2.6 left in the "omnios" publisher. * Several changes from illumos have been merged in. Including most noticeably the obsolescence of the Solaris Volume Manager (SVM). With everyone using ZFS now, SVM was ripped out of illumos-gate, and hence illumos-omnios:master. * Some LX updates from illumos-joyent, plus a backout of a mismerge from the previous ISO, which caused LX zones to fail. The obsolescence of Python2.6 was the first of three major undertakings for this bloody cycle. I'm surprised how well it went, and we can thank the pkg5 test suite, as well as Dale Ghent with some big help from on the caiman front. The next major undertaking will be integrating the BSD Loader support into OmniOS. Our plan for Loader as it currently stands is: * Let people who use "pkg update" to move to bloody or r151022 when it ships to continue to use GRUB. * New ISO or Kayak installs will install with BSD Loader instead. * There will also be a command to move grub deployments over to BSD Loader for people who use "pkg update", but want to make the switch to loader. (This may render pre-loader BEs highly unstable.) That is the plan. We'll see how it stands up against reality. Thank you! Dan p.s. I plan on updating the USB3/xhci sub-repo too, once I can get it to build again. From stephan.budach at jvm.de Wed Jan 18 07:38:38 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 18 Jan 2017 08:38:38 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> Message-ID: <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> Am 17.01.17 um 23:09 schrieb Dale Ghent: >> On Jan 17, 2017, at 2:39 PM, Stephan Budach wrote: >> >> Am 17.01.17 um 17:37 schrieb Dale Ghent: >>>> On Jan 17, 2017, at 11:31 AM, Stephan Budach >>>> wrote: >>>> >>>> Hi Dale, >>>> >>>> Am 17.01.17 um 17:22 schrieb Dale Ghent: >>>> >>>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach >>>>>> >>>>>> wrote: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? >>>>>> >>>>>> Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? >>>>>> >>>>>> >>>>> Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. >>>>> >>>>> /dale >>>>> >>>>> >>>> do you know of any option to get to know, why three of my boxes are flapping their 10GbE ports? It's actually not only when in aggr mode, but on single use as well. Last week I presumeably had one of my RSF-1 nodes panic, since it couldn't get to it's iSCSI LUNs anymore. The thing ist, that somewhere doen the line, the ixgbe driver seems to be fine, to configure one port to 1GbE instead of 10GbE, which will stop the flapping, but wich will break the VPC on my Nexus nevertheless. >>>> >>>> In syslog, this looks like this: >>>> >>>> ... >>>> Jan 17 14:46:07 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 1000 Mbps, full duplex >>>> Jan 17 14:46:21 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>> Jan 17 14:46:26 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>> Jan 17 14:52:32 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>> Jan 17 14:54:50 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>> Jan 17 14:54:55 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>> Jan 17 14:58:12 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>> Jan 17 14:58:16 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>> Jan 17 14:59:46 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>> >>>> Note on 14:46:07, where the system settles on a 1GbE connection? >>>> >>> Sounds like a cabling issue? Are the runs too long or are you not using CAT6a? It flapping at 10Gb and then settling at 1Gb would indicate a cabling issue to me. The driver will always try to link at the fastest speed that the local controller and the remote peer will negotiate at... it will not proactively downgrade the link speed. If that happens, it is because that is what the controller managed to negotiate with the remote peer at. >>> >>> Are you using jumbo frames or anything outside of a normal 1500mtu link? >>> >>> /dale >>> >> The cables are actually specifically purchased cat6 cables. They run about 2m, not more. It could be tna cables, but I am running a couple of those and afaik, I only get these issues on these three nodes. I can try some other cables, but I hoped to be able to get maybe some kind of debug messages from the driver. > The chip provides no reason for a LoS or downgrade of the link. For configuration issues it interrupts only on a few things. "LSC" (Link Status Change) interrupts one of these things and are what tells the driver to interrogate the chip for its current speed, but beyond that, the hardware provides no further details. Any details regarding why the PHY had to re-train the link are completely hidden to the driver. > > Are these X540 interfaces actually built into the motherboard, or are they separate PCIe cards? Also, CAT6 alone might not be enough, and even the magnetics on the older X540 might not even be able to eek out a 10Gb connection, even at 2m. I would remove all doubt of cabling being an issue by replacing them with CAT6a. Beware of cable vendors who sell CAT6 cables as "CAT6a". It could also be an issue with the modular jacks on the ends. > > Since you mentioned "after 6/2016" for the ixgbe driver, have you tried the newer one yet? Large portions of it were re-written and re-factored, and many bugs fixed including portions that touch the X540 due to the new X550 also being copper and the two models needing to share some logic related to that. > > /dale Thanks for clarifying that. I just checked the cables and they classify as Cat6a and they are from a respectable german vendor, not that this would be any guarantee, but at least they're no bulkware from china. ;) The X540s are either onboard on some Supermicro X10 boards, but also on a genuine Intel PCI adaptor. I will check some other cables, maybe the ones I got were somewhat faulty. However, this leaves only a few options to the user, finding out, what is actually wrong with the connection, isn't it? Regarding the release of omniOS, I will update my RSF-1 node to the latest r18, the other two new nodes are actually on r20 and thus should already have the new driver installed. ?any suggestion on some good cables? ;) Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From daleg at omniti.com Wed Jan 18 08:01:20 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 18 Jan 2017 03:01:20 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> Message-ID: > On Jan 18, 2017, at 2:38 AM, Stephan Budach wrote: > > Am 17.01.17 um 23:09 schrieb Dale Ghent: >>> On Jan 17, 2017, at 2:39 PM, Stephan Budach >>> wrote: >>> >>> Am 17.01.17 um 17:37 schrieb Dale Ghent: >>> >>>>> On Jan 17, 2017, at 11:31 AM, Stephan Budach >>>>> >>>>> wrote: >>>>> >>>>> Hi Dale, >>>>> >>>>> Am 17.01.17 um 17:22 schrieb Dale Ghent: >>>>> >>>>> >>>>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach >>>>>>> >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? >>>>>>> >>>>>>> Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? >>>>>>> >>>>>>> >>>>>>> >>>>>> Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. >>>>>> >>>>>> /dale >>>>>> >>>>>> >>>>>> >>>>> do you know of any option to get to know, why three of my boxes are flapping their 10GbE ports? It's actually not only when in aggr mode, but on single use as well. Last week I presumeably had one of my RSF-1 nodes panic, since it couldn't get to it's iSCSI LUNs anymore. The thing ist, that somewhere doen the line, the ixgbe driver seems to be fine, to configure one port to 1GbE instead of 10GbE, which will stop the flapping, but wich will break the VPC on my Nexus nevertheless. >>>>> >>>>> In syslog, this looks like this: >>>>> >>>>> ... >>>>> Jan 17 14:46:07 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 1000 Mbps, full duplex >>>>> Jan 17 14:46:21 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>> Jan 17 14:46:26 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>> Jan 17 14:52:32 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>> Jan 17 14:54:50 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>> Jan 17 14:54:55 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>> Jan 17 14:58:12 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>> Jan 17 14:58:16 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>> Jan 17 14:59:46 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>> >>>>> Note on 14:46:07, where the system settles on a 1GbE connection? >>>>> >>>>> >>>> Sounds like a cabling issue? Are the runs too long or are you not using CAT6a? It flapping at 10Gb and then settling at 1Gb would indicate a cabling issue to me. The driver will always try to link at the fastest speed that the local controller and the remote peer will negotiate at... it will not proactively downgrade the link speed. If that happens, it is because that is what the controller managed to negotiate with the remote peer at. >>>> >>>> Are you using jumbo frames or anything outside of a normal 1500mtu link? >>>> >>>> /dale >>>> >>>> >>> The cables are actually specifically purchased cat6 cables. They run about 2m, not more. It could be tna cables, but I am running a couple of those and afaik, I only get these issues on these three nodes. I can try some other cables, but I hoped to be able to get maybe some kind of debug messages from the driver. >>> >> The chip provides no reason for a LoS or downgrade of the link. For configuration issues it interrupts only on a few things. "LSC" (Link Status Change) interrupts one of these things and are what tells the driver to interrogate the chip for its current speed, but beyond that, the hardware provides no further details. Any details regarding why the PHY had to re-train the link are completely hidden to the driver. >> >> Are these X540 interfaces actually built into the motherboard, or are they separate PCIe cards? Also, CAT6 alone might not be enough, and even the magnetics on the older X540 might not even be able to eek out a 10Gb connection, even at 2m. I would remove all doubt of cabling being an issue by replacing them with CAT6a. Beware of cable vendors who sell CAT6 cables as "CAT6a". It could also be an issue with the modular jacks on the ends. >> >> Since you mentioned "after 6/2016" for the ixgbe driver, have you tried the newer one yet? Large portions of it were re-written and re-factored, and many bugs fixed including portions that touch the X540 due to the new X550 also being copper and the two models needing to share some logic related to that. >> >> /dale >> > Thanks for clarifying that. I just checked the cables and they classify as Cat6a and they are from a respectable german vendor, not that this would be any guarantee, but at least they're no bulkware from china. ;) > > The X540s are either onboard on some Supermicro X10 boards, but also on a genuine Intel PCI adaptor. I will check some other cables, maybe the ones I got were somewhat faulty. However, this leaves only a few options to the user, finding out, what is actually wrong with the connection, isn't it? > > Regarding the release of omniOS, I will update my RSF-1 node to the latest r18, the other two new nodes are actually on r20 and thus should already have the new driver installed. I the ixgbe package installed on your systems has a time stamp after July 19 2016, it will have the updated code. Regarding the X540s which are integrated on some of your SMCI X10 boards, does a 10Gb link remain stable after you issue the following two commands in the shown order: dladm set-linkprop -p en_10gfdx_cap=0 ixgbeN dladm set-linkprop -p en_10gfdx_cap=1 ixgbeN Also, check flowctrl: dladm show-linkprop -p flowctrl For your ixgbe devices, this should be the default of "no" /dale From hasslerd at gmx.li Wed Jan 18 10:58:26 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Wed, 18 Jan 2017 11:58:26 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> Message-ID: <624d5049-c80d-71c4-b44b-7b5415f63a0f@gmx.li> > Thanks for clarifying that. I just checked the cables and they classify > as Cat6a and they are from a respectable german vendor, not that this > would be any guarantee, but at least they're no bulkware from china. ;) > > The X540s are either onboard on some Supermicro X10 boards, but also on > a genuine Intel PCI adaptor. I will check some other cables, maybe the > ones I got were somewhat faulty. However, this leaves only a few > options to the user, finding out, what is actually wrong with the > connection, isn't it? > > Regarding the release of omniOS, I will update my RSF-1 node to the > latest r18, the other two new nodes are actually on r20 and thus should > already have the new driver installed. > > ?any suggestion on some good cables? ;) D?twyler: http://www.cabling.datwyler.com/products/data-centres/copper-technology/patch-cords/product/rj45-patch-cords-cat6a-iec.html they provide detailed specs and test certificates for all of their cable types. > > Thanks, > Stephan > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From stephan.budach at jvm.de Wed Jan 18 16:16:25 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 18 Jan 2017 17:16:25 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> Message-ID: Am 18.01.17 um 09:01 schrieb Dale Ghent: >> On Jan 18, 2017, at 2:38 AM, Stephan Budach wrote: >> >> Am 17.01.17 um 23:09 schrieb Dale Ghent: >>>> On Jan 17, 2017, at 2:39 PM, Stephan Budach >>>> wrote: >>>> >>>> Am 17.01.17 um 17:37 schrieb Dale Ghent: >>>> >>>>>> On Jan 17, 2017, at 11:31 AM, Stephan Budach >>>>>> >>>>>> wrote: >>>>>> >>>>>> Hi Dale, >>>>>> >>>>>> Am 17.01.17 um 17:22 schrieb Dale Ghent: >>>>>> >>>>>> >>>>>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach >>>>>>>> >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> I am sorry, but I do have to undig this old topic, since I do now have three hosts running omniOS 018/020, which show these pesky issues with flapping their ixgbeN links on my Nexus FEXes? >>>>>>>> >>>>>>>> Does anyone know, if there has any change been made to the ixgbe drivers since 06/2016? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Since June 2016? Yes! A large update to the ixgbe driver happened in August. This added X550 support, and also brought the Intel Shared Code it uses from its 2012 vintage up to current. The updated driver is available in 014 and later. >>>>>>> >>>>>>> /dale >>>>>>> >>>>>>> >>>>>>> >>>>>> do you know of any option to get to know, why three of my boxes are flapping their 10GbE ports? It's actually not only when in aggr mode, but on single use as well. Last week I presumeably had one of my RSF-1 nodes panic, since it couldn't get to it's iSCSI LUNs anymore. The thing ist, that somewhere doen the line, the ixgbe driver seems to be fine, to configure one port to 1GbE instead of 10GbE, which will stop the flapping, but wich will break the VPC on my Nexus nevertheless. >>>>>> >>>>>> In syslog, this looks like this: >>>>>> >>>>>> ... >>>>>> Jan 17 14:46:07 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe1 link up, 1000 Mbps, full duplex >>>>>> Jan 17 14:46:21 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>>> Jan 17 14:46:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>>> Jan 17 14:46:26 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>>> Jan 17 14:52:22 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>>> Jan 17 14:52:32 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>>> Jan 17 14:54:50 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>>> Jan 17 14:54:55 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>>> Jan 17 14:58:12 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>>> Jan 17 14:58:16 zfsha02gh79 mac: [ID 435574 kern.info] NOTICE: ixgbe3 link up, 10000 Mbps, full duplex >>>>>> Jan 17 14:59:46 zfsha02gh79 mac: [ID 486395 kern.info] NOTICE: ixgbe3 link down >>>>>> >>>>>> Note on 14:46:07, where the system settles on a 1GbE connection? >>>>>> >>>>>> >>>>> Sounds like a cabling issue? Are the runs too long or are you not using CAT6a? It flapping at 10Gb and then settling at 1Gb would indicate a cabling issue to me. The driver will always try to link at the fastest speed that the local controller and the remote peer will negotiate at... it will not proactively downgrade the link speed. If that happens, it is because that is what the controller managed to negotiate with the remote peer at. >>>>> >>>>> Are you using jumbo frames or anything outside of a normal 1500mtu link? >>>>> >>>>> /dale >>>>> >>>>> >>>> The cables are actually specifically purchased cat6 cables. They run about 2m, not more. It could be tna cables, but I am running a couple of those and afaik, I only get these issues on these three nodes. I can try some other cables, but I hoped to be able to get maybe some kind of debug messages from the driver. >>>> >>> The chip provides no reason for a LoS or downgrade of the link. For configuration issues it interrupts only on a few things. "LSC" (Link Status Change) interrupts one of these things and are what tells the driver to interrogate the chip for its current speed, but beyond that, the hardware provides no further details. Any details regarding why the PHY had to re-train the link are completely hidden to the driver. >>> >>> Are these X540 interfaces actually built into the motherboard, or are they separate PCIe cards? Also, CAT6 alone might not be enough, and even the magnetics on the older X540 might not even be able to eek out a 10Gb connection, even at 2m. I would remove all doubt of cabling being an issue by replacing them with CAT6a. Beware of cable vendors who sell CAT6 cables as "CAT6a". It could also be an issue with the modular jacks on the ends. >>> >>> Since you mentioned "after 6/2016" for the ixgbe driver, have you tried the newer one yet? Large portions of it were re-written and re-factored, and many bugs fixed including portions that touch the X540 due to the new X550 also being copper and the two models needing to share some logic related to that. >>> >>> /dale >>> >> Thanks for clarifying that. I just checked the cables and they classify as Cat6a and they are from a respectable german vendor, not that this would be any guarantee, but at least they're no bulkware from china. ;) >> >> The X540s are either onboard on some Supermicro X10 boards, but also on a genuine Intel PCI adaptor. I will check some other cables, maybe the ones I got were somewhat faulty. However, this leaves only a few options to the user, finding out, what is actually wrong with the connection, isn't it? >> >> Regarding the release of omniOS, I will update my RSF-1 node to the latest r18, the other two new nodes are actually on r20 and thus should already have the new driver installed. > I the ixgbe package installed on your systems has a time stamp after July 19 2016, it will have the updated code. > > Regarding the X540s which are integrated on some of your SMCI X10 boards, does a 10Gb link remain stable after you issue the following two commands in the shown order: > > dladm set-linkprop -p en_10gfdx_cap=0 ixgbeN > dladm set-linkprop -p en_10gfdx_cap=1 ixgbeN > > Also, check flowctrl: > > dladm show-linkprop -p flowctrl > > For your ixgbe devices, this should be the default of "no" > > /dale I tried all of that on each of the four interfaces, but it doesn't seem to help. I will get me some new cables - Dominik suggested a brand, that I also know, and I will have my current cables be tested against the Cat6a spec. If that also should lead me nowhere, anyone can suggest a working 10GbE Dual-Port copper adaptor, that will work with omniOS, e.g. QLE3442-RJ-CK or some Broadcom stuff? Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From danmcd at omniti.com Wed Jan 18 16:32:05 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 18 Jan 2017 11:32:05 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> Message-ID: <474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com> Generally the X540 has had a good track record. I brought up the support for this a long time ago, and it worked alright then. I think Dale has an X540 in-house which works fine too (he should confirm this). Some other things to check: * Is your BIOS set to map the PCI-E space into the low-32 bits only? That's an illumos limitation. * Do you have other known-working 10GigBaseT chips to try? Dan From stephan.budach at jvm.de Wed Jan 18 16:38:44 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 18 Jan 2017 17:38:44 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: <474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com> References: <5730818B.6020909@jvm.de> <8485B303-9706-42C4-B1B1-EAF6DAC949A3@omniti.com> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> <474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com> Message-ID: <79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de> Am 18.01.17 um 17:32 schrieb Dan McDonald: > Generally the X540 has had a good track record. I brought up the support for this a long time ago, and it worked alright then. I think Dale has an X540 in-house which works fine too (he should confirm this). > > Some other things to check: > > * Is your BIOS set to map the PCI-E space into the low-32 bits only? That's an illumos limitation. > > * Do you have other known-working 10GigBaseT chips to try? > > Dan > I will check with the BIOS, altough I thought that this option would simply cause PCI adaptors to vanish from the system, if setup that way. Actually, I have been going with Intel all the time and it has been up to the X540 in 10GbE setups only, when I ever startet to experience issues at all, so Intel has been a natural choice for me ever? ;) Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From danmcd at omniti.com Wed Jan 18 17:31:28 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 18 Jan 2017 12:31:28 -0500 Subject: [OmniOS-discuss] Bloody's USB3/xhci counterpart now updated too Message-ID: <9FE9D7F4-222A-44C3-97E7-1EEFE5117121@omniti.com> Some of you bloody users have been using the bloody+USB3 repo: http://pkg.omniti.com/omnios/USB3/ It's now updated with all of the death-to-Python2.6 packages and other changes from regular bloody, AND one additional USB3/xhci bugfix from Joyent. Once xhci/USB3 is upstreamed to illumos-gate, and into illumos-omnios subsequently, this repo will disappear. Dan From danmcd at omniti.com Wed Jan 18 19:23:50 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 18 Jan 2017 14:23:50 -0500 Subject: [OmniOS-discuss] Building illumos on bloody Message-ID: <8757D587-5CE0-4629-8042-588F713B1B52@omniti.com> As of yesterday's bloody, you no longer need to set PYTHON_VERSION and PYTHON_PKGVERS in your env files to point back to 2.6. bloody(tools/env)[0]% git diff diff --git a/usr/src/tools/env/omnios-illumos-gate.sh b/usr/src/tools/env/omnios-illumos-gate.sh index 8e14d95..c1406d9 100644 --- a/usr/src/tools/env/omnios-illumos-gate.sh +++ b/usr/src/tools/env/omnios-illumos-gate.sh @@ -218,11 +218,6 @@ __GNUC=""; export __GNUC CW_NO_SHADOW=1; export CW_NO_SHADOW ONLY_LINT_DEFS=-I${SPRO_ROOT}/sunstudio12.1/prod/include/lint; export ONLY_LINT_DEFS -# Starting with illumos bug 5969, upstream defaults to Python2.7. We still -# use Python2.6 as of r151020 -export PYTHON_VERSION="2.6" -export PYTHON_PKGVERS="-26" - # This goes along with lint - it is a series of the form "A [y|n]" which # means "go to directory A and run 'make lint'" Then mail me (y) the # difference in the lint output. 'y' should only be used if the area you're bloody(tools/env)[0]% FYI, Dan From stephan.budach at jvm.de Thu Jan 19 09:27:45 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 19 Jan 2017 10:27:45 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: <79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de> References: <5730818B.6020909@jvm.de> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> <474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com> <79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de> Message-ID: Am 18.01.17 um 17:38 schrieb Stephan Budach: > Am 18.01.17 um 17:32 schrieb Dan McDonald: >> Generally the X540 has had a good track record. I brought up the support for this a long time ago, and it worked alright then. I think Dale has an X540 in-house which works fine too (he should confirm this). >> >> Some other things to check: >> >> * Is your BIOS set to map the PCI-E space into the low-32 bits only? That's an illumos limitation. >> >> * Do you have other known-working 10GigBaseT chips to try? >> >> Dan >> > I will check with the BIOS, altough I thought that this option would > simply cause PCI adaptors to vanish from the system, if setup that way. > Actually, I have been going with Intel all the time and it has been up > to the X540 in 10GbE setups only, when I ever startet to experience > issues at all, so Intel has been a natural choice for me ever? ;) > > Stephan I just checked the BIOS of my new Supermicros and I think that this is the BIOS option you were referring to? Above 4G Decoding: DISABLED So, this should be right, shouldn't it? Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From daleg at omniti.com Thu Jan 19 16:13:26 2017 From: daleg at omniti.com (Dale Ghent) Date: Thu, 19 Jan 2017 11:13:26 -0500 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: References: <5730818B.6020909@jvm.de> <5730D110.5080305@jvm.de> <91D2ADD2-19BB-422B-9723-1E7F34DB43FA@omniti.com> <5733192A.60506@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> <474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com> <79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de> Message-ID: <26637FD4-0792-47DB-BEA9-7D1FA7EE83D2@omniti.com> > On Jan 19, 2017, at 4:27 AM, Stephan Budach wrote: > > Am 18.01.17 um 17:38 schrieb Stephan Budach: >> Am 18.01.17 um 17:32 schrieb Dan McDonald: >>> Generally the X540 has had a good track record. I brought up the support for this a long time ago, and it worked alright then. I think Dale has an X540 in-house which works fine too (he should confirm this). >>> >>> Some other things to check: >>> >>> * Is your BIOS set to map the PCI-E space into the low-32 bits only? That's an illumos limitation. >>> >>> * Do you have other known-working 10GigBaseT chips to try? >>> >>> Dan >>> >>> >> I will check with the BIOS, altough I thought that this option would simply cause PCI adaptors to vanish from the system, if setup that way. >> Actually, I have been going with Intel all the time and it has been up to the X540 in 10GbE setups only, when I ever startet to experience issues at all, so Intel has been a natural choice for me ever? ;) >> >> Stephan > I just checked the BIOS of my new Supermicros and I think that this is the BIOS option you were referring to? > > Above 4G Decoding: DISABLED > > So, this should be right, shouldn't it? Correct, currently it should be disabled (however we hope by the time 022 is released, there will not be a reason to have that disabled) /dale From hasslerd at gmx.li Fri Jan 20 00:43:30 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Fri, 20 Jan 2017 01:43:30 +0100 Subject: [OmniOS-discuss] svcs -Z should ignore LX zones Message-ID: just cosmetics, but running 'svcs/svcadm -Z' on a host where LX zones are present throws the following warning for each LX zone due to the absence of SMF (the same applies for 'svcs/svcadm -z ', but here it is run against the zone intentionally, so a warning/error seems to be right): svcs: Could not bind to repository server for zone ...: repository server unavailable From danmcd at omniti.com Fri Jan 20 01:19:10 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 19 Jan 2017 20:19:10 -0500 Subject: [OmniOS-discuss] svcs -Z should ignore LX zones In-Reply-To: References: Message-ID: > On Jan 19, 2017, at 7:43 PM, Dominik Hassler wrote: > > just cosmetics, but running 'svcs/svcadm -Z' on a host where LX zones are present throws the following warning for each LX zone due to the absence of SMF (the same applies for 'svcs/svcadm -z ', but here it is run against the zone intentionally, so a warning/error seems to be right): > > svcs: Could not bind to repository server for zone ...: repository server unavailable Nahum just checked this out on SmartOS, and they don't have this problem. I'm not sure what precise solution they came up with, though. Thanks for finding this, we should fix it before 022 ships, if not sooner, Dan From danmcd at omniti.com Fri Jan 20 01:31:28 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 19 Jan 2017 20:31:28 -0500 Subject: [OmniOS-discuss] svcs -Z should ignore LX zones In-Reply-To: References: Message-ID: > On Jan 19, 2017, at 8:19 PM, Dan McDonald wrote: > > Thanks for finding this, we should fix it before 022 ships, if not sooner, Don't quite have the precise line numbers, but this: if (scf_handle_bind(h) == -1) { if (g_zonename != NULL) { - uu_warn(gettext("Could not bind to repository " + if (show_zones) + goto nextzone; + + uu_die(gettext("Could not bind to repository " "server for zone %s: %s\n"), g_zonename, scf_strerror(scf_error())); - - if (!show_zones) - return (UU_EXIT_FATAL); - - goto nextzone; } is a bit from SmartOS that appears to mitigate your problem, at the cost of skipping over a native zone with an SMF problem. You can, however, target those with "svcs -z ". I'll see if I can build it tomorrow. I'm in the middle of another Joyent merge, so I can't until tomorrow. Dan From hasslerd at gmx.li Fri Jan 20 01:54:19 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Fri, 20 Jan 2017 02:54:19 +0100 Subject: [OmniOS-discuss] svcs -Z should ignore LX zones In-Reply-To: References: Message-ID: <1c8ccf83-0a5b-d540-6a3d-9f22b61a8b80@gmx.li> i guess it is this one you mentioned: https://github.com/joyent/illumos-joyent/commit/32ce5b9ee70c2ead1e46c0fa82f724b4fe8fc54f and this ones might be worth merging, too: https://github.com/joyent/illumos-joyent/commit/31a2b4f9f0f4c1f93217bdfb5192d23ec361e414 https://github.com/joyent/illumos-joyent/commit/d07645b17dd983d7abe043763251310332d4c971 On 01/20/2017 02:31 AM, Dan McDonald wrote: > >> On Jan 19, 2017, at 8:19 PM, Dan McDonald wrote: >> >> Thanks for finding this, we should fix it before 022 ships, if not sooner, > > Don't quite have the precise line numbers, but this: > > if (scf_handle_bind(h) == -1) { > if (g_zonename != NULL) { > - uu_warn(gettext("Could not bind to repository " > + if (show_zones) > + goto nextzone; > + > + uu_die(gettext("Could not bind to repository " > "server for zone %s: %s\n"), g_zonename, > scf_strerror(scf_error())); > - > - if (!show_zones) > - return (UU_EXIT_FATAL); > - > - goto nextzone; > } > > > is a bit from SmartOS that appears to mitigate your problem, at the cost of skipping over a native zone with an SMF problem. You can, however, target those with "svcs -z ". > > I'll see if I can build it tomorrow. I'm in the middle of another Joyent merge, so I can't until tomorrow. > > Dan > From manuel at oetiker.ch Fri Jan 20 07:31:06 2017 From: manuel at oetiker.ch (Manuel Oetiker) Date: Fri, 20 Jan 2017 08:31:06 +0100 (CET) Subject: [OmniOS-discuss] upper/lower case of share names smb Message-ID: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch> Hi I have a Omnios 151020 with smb and ad connection. zfs create -p -o casesensitivity=mixed -o nbmand=on \ -o sharesmb=name=DataDB,description="Data DB" \ ssd-a/share/datadb I think the shares should show up on the windows side as DataDB and not as datadb. Is there a way to prevent the the upper/lower case on the sharename side? cheers Manuel From stephan.budach at jvm.de Fri Jan 20 15:01:01 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Fri, 20 Jan 2017 16:01:01 +0100 Subject: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2 In-Reply-To: <26637FD4-0792-47DB-BEA9-7D1FA7EE83D2@omniti.com> References: <5730818B.6020909@jvm.de> <0F866400-B276-4E81-A6CB-DB071A277F5F@omniti.com> <57335E9F.6080404@jvm.de> <3F300861-3541-4D3E-82D5-13FD061B8D9B@omniti.com> <573B0EC8.9090007@jvm.de> <90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de> <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com> <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com> <8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de> <474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com> <79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de> <26637FD4-0792-47DB-BEA9-7D1FA7EE83D2@omniti.com> Message-ID: Hi, after having messed around with quite a lot of Cat6a cables from different vendors, it seems that the 2m runs are too short. Maybe the Intel controllers are providing too much power to the jacks. I have now exchanged the 2m/3m cables with 5m ones and this seems to do the trick. I know, that there will be some crosstalk at the cables' either ends and I learned that even sophisticated measurement equipment will discard the results for the first 2m of a Cat6a 10GbE connection. However, having to deal with 5m runs is anything but convinient, if you do have quite a number of cables to deploy. I am still monitoring the NICs, though? ;) Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From danmcd at omniti.com Fri Jan 20 15:14:25 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 20 Jan 2017 10:14:25 -0500 Subject: [OmniOS-discuss] svcs -Z should ignore LX zones In-Reply-To: <1c8ccf83-0a5b-d540-6a3d-9f22b61a8b80@gmx.li> References: <1c8ccf83-0a5b-d540-6a3d-9f22b61a8b80@gmx.li> Message-ID: > On Jan 19, 2017, at 8:54 PM, Dominik Hassler wrote: > > i guess it is this one you mentioned: > > https://github.com/joyent/illumos-joyent/commit/32ce5b9ee70c2ead1e46c0fa82f724b4fe8fc54f > > > and this ones might be worth merging, too: > > https://github.com/joyent/illumos-joyent/commit/31a2b4f9f0f4c1f93217bdfb5192d23ec361e414 > > https://github.com/joyent/illumos-joyent/commit/d07645b17dd983d7abe043763251310332d4c971 One could make a solid argument for all of these going upstream, too. I'm going to engage the illumos list to see what they think. Thanks, Dan From danmcd at omniti.com Fri Jan 20 15:47:06 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 20 Jan 2017 10:47:06 -0500 Subject: [OmniOS-discuss] upper/lower case of share names smb In-Reply-To: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch> References: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch> Message-ID: <817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com> > On Jan 20, 2017, at 2:31 AM, Manuel Oetiker wrote: > > Hi > > I have a Omnios 151020 with smb and ad connection. > > zfs create -p -o casesensitivity=mixed -o nbmand=on \ > -o sharesmb=name=DataDB,description="Data DB" \ > ssd-a/share/datadb > > I think the shares should show up on the windows side as DataDB and not > as datadb. > > Is there a way to prevent the the upper/lower case on the sharename side? Ahhh, you want case-preservation on the share name. Can you please do me a favor and utter: zfs get all ssd-a/share/datadb I'd like to see what ZFS properties are. It'll help me figure out where the problem might be. If the properties have "DataDB" converted to "datadb", for example, it's likely in the ZFS property code. If it's not, it's likely in the SMB sharing code. Dan From hasslerd at gmx.li Fri Jan 20 16:02:35 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Fri, 20 Jan 2017 17:02:35 +0100 Subject: [OmniOS-discuss] upper/lower case of share names smb In-Reply-To: <817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com> References: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch> <817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com> Message-ID: <869ec615-c48e-3d59-ebbe-1194347a2b8c@gmx.li> just did a test: # $ zfs create -o casesensitivity=mixed -o nbmand=on -o sharesmb=name=TeSt,description="test share" tank/test # zfs get sharesmb tank/test NAME PROPERTY VALUE SOURCE tank/test sharesmb name=TeSt,description=test share local # sharemgr show -P smb -v |grep test zfs/tank/test TeSt=/tank/test "test share" so it likely is in the sharing code. On 01/20/2017 04:47 PM, Dan McDonald wrote: > >> On Jan 20, 2017, at 2:31 AM, Manuel Oetiker wrote: >> >> Hi >> >> I have a Omnios 151020 with smb and ad connection. >> >> zfs create -p -o casesensitivity=mixed -o nbmand=on \ >> -o sharesmb=name=DataDB,description="Data DB" \ >> ssd-a/share/datadb >> >> I think the shares should show up on the windows side as DataDB and not >> as datadb. >> >> Is there a way to prevent the the upper/lower case on the sharename side? > > Ahhh, you want case-preservation on the share name. > > Can you please do me a favor and utter: > > zfs get all ssd-a/share/datadb > > I'd like to see what ZFS properties are. It'll help me figure out where the problem might be. If the properties have "DataDB" converted to "datadb", for example, it's likely in the ZFS property code. If it's not, it's likely in the SMB sharing code. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From manuel at oetiker.ch Fri Jan 20 16:05:00 2017 From: manuel at oetiker.ch (Manuel Oetiker) Date: Fri, 20 Jan 2017 17:05:00 +0100 (CET) Subject: [OmniOS-discuss] upper/lower case of share names smb In-Reply-To: <817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com> References: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch> <817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com> Message-ID: <755488175.2187272.1484928300366.JavaMail.zimbra@oetiker.ch> > From: "Dan McDonald" > To: "Manuel Oetiker" > Cc: "omnios-discuss" , "Dan McDonald" > Sent: Friday, January 20, 2017 4:47:06 PM > Subject: Re: [OmniOS-discuss] upper/lower case of share names smb > > Ahhh, you want case-preservation on the share name. > > Can you please do me a favor and utter: > > zfs get all ssd-a/share/datadb > > I'd like to see what ZFS properties are. It'll help me figure out where the > problem might be. If the properties have "DataDB" converted to "datadb", for > example, it's likely in the ZFS property code. If it's not, it's likely in the > SMB sharing code. > > Dan NAME PROPERTY VALUE SOURCE ssd-a/share/bardatadb type filesystem - ssd-a/share/bardatadb creation Wed Jan 18 15:25 2017 - ssd-a/share/bardatadb used 324K - ssd-a/share/bardatadb available 4.78T - ssd-a/share/bardatadb referenced 205K - ssd-a/share/bardatadb compressratio 1.00x - ssd-a/share/bardatadb mounted yes - ssd-a/share/bardatadb quota none default ssd-a/share/bardatadb reservation none default ssd-a/share/bardatadb recordsize 128K default ssd-a/share/bardatadb mountpoint /ssd-a/share/bardatadb default ssd-a/share/bardatadb sharenfs off default ssd-a/share/bardatadb checksum on default ssd-a/share/bardatadb compression lz4 inherited from ssd-a ssd-a/share/bardatadb atime on default ssd-a/share/bardatadb devices on default ssd-a/share/bardatadb exec on default ssd-a/share/bardatadb setuid on default ssd-a/share/bardatadb readonly off default ssd-a/share/bardatadb zoned off default ssd-a/share/bardatadb snapdir hidden default ssd-a/share/bardatadb aclmode discard default ssd-a/share/bardatadb aclinherit restricted default ssd-a/share/bardatadb canmount on default ssd-a/share/bardatadb xattr on default ssd-a/share/bardatadb copies 1 default ssd-a/share/bardatadb version 5 - ssd-a/share/bardatadb utf8only off - ssd-a/share/bardatadb normalization none - ssd-a/share/bardatadb casesensitivity mixed - ssd-a/share/bardatadb vscan off default ssd-a/share/bardatadb nbmand on local ssd-a/share/bardatadb sharesmb name=BardataDB,description=BardataDB local ssd-a/share/bardatadb refquota none default ssd-a/share/bardatadb refreservation none default ssd-a/share/bardatadb primarycache all default ssd-a/share/bardatadb secondarycache all default ssd-a/share/bardatadb usedbysnapshots 119K - ssd-a/share/bardatadb usedbydataset 205K - ssd-a/share/bardatadb usedbychildren 0 - ssd-a/share/bardatadb usedbyrefreservation 0 - ssd-a/share/bardatadb logbias latency default ssd-a/share/bardatadb dedup off default ssd-a/share/bardatadb mlslabel none default ssd-a/share/bardatadb sync standard default ssd-a/share/bardatadb refcompressratio 1.00x - ssd-a/share/bardatadb written 119K - ssd-a/share/bardatadb logicalused 66.5K - ssd-a/share/bardatadb logicalreferenced 40.5K - ssd-a/share/bardatadb filesystem_limit none default ssd-a/share/bardatadb snapshot_limit none default ssd-a/share/bardatadb filesystem_count none default ssd-a/share/bardatadb snapshot_count none default ssd-a/share/bardatadb redundant_metadata all default cheers Manuel From danmcd at omniti.com Fri Jan 20 16:05:10 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 20 Jan 2017 11:05:10 -0500 Subject: [OmniOS-discuss] upper/lower case of share names smb In-Reply-To: <869ec615-c48e-3d59-ebbe-1194347a2b8c@gmx.li> References: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch> <817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com> <869ec615-c48e-3d59-ebbe-1194347a2b8c@gmx.li> Message-ID: > On Jan 20, 2017, at 11:02 AM, Dominik Hassler wrote: > > so it likely is in the sharing code. Good to know. It'll also be harder to find, and I may need to ping Gordon Ross about it. I'll go source-diving, and report back here in a bit. Dan From danmcd at omniti.com Fri Jan 20 16:23:22 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 20 Jan 2017 11:23:22 -0500 Subject: [OmniOS-discuss] upper/lower case of share names smb In-Reply-To: References: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch> <817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com> <869ec615-c48e-3d59-ebbe-1194347a2b8c@gmx.li> Message-ID: <00142031-1947-408F-9EA2-61689314A829@omniti.com> > On Jan 20, 2017, at 11:05 AM, Dan McDonald wrote: > > I'll go source-diving, and report back here in a bit. I'm finding where the share name is stored (which preserves case... as sharemgr reports). I'm going to forward this inquiry along to Gordon, in the hopes that it's an easy fix or workaround. Thanks, Dan From mtalbott at lji.org Fri Jan 20 19:36:45 2017 From: mtalbott at lji.org (Michael Talbott) Date: Fri, 20 Jan 2017 11:36:45 -0800 Subject: [OmniOS-discuss] flowadm stats Message-ID: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org> Hi, I've recently discovered flowadm and set up some flows and then was trying to see some usage statistics as indicated in the man page via: flowadm show-usage Sadly, that seems to have been pulled from the binary but not the man page as I discovered here: https://www.illumos.org/issues/7210 Are there any other ways to monitor traffic on a per port/protocol level basis? Or would digging out a previous versions binary work? I know dladm can show usage on per-interface, but, I'd like to see if flowadm is actually doing what it is supposed to be doing with a few simple rules I gave it (which are priority based, not maxbw). Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Jan 20 20:14:59 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 20 Jan 2017 15:14:59 -0500 Subject: [OmniOS-discuss] flowadm stats In-Reply-To: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org> References: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org> Message-ID: <514611B0-6B73-43DF-B573-317EA3A651B9@omniti.com> > On Jan 20, 2017, at 2:36 PM, Michael Talbott wrote: > > Are there any other ways to monitor traffic on a per port/protocol level basis? Or would digging out a previous versions binary work? I know dladm can show usage on per-interface, but, I'd like to see if flowadm is actually doing what it is supposed to be doing with a few simple rules I gave it (which are priority based, not maxbw). > The undocumented flowstat may do what you want. You specify a flow with flowadm(1M) and then you use flowstat to monitor that flow. The commit mentioned in 7210 goes back to the OpenSolaris days. The commit in question introduces both dlstat and flowstat, both of which are undocumented, but may be the better-encapsulated features that you desire. Dan From danmcd at omniti.com Fri Jan 20 20:16:15 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 20 Jan 2017 15:16:15 -0500 Subject: [OmniOS-discuss] flowadm stats In-Reply-To: <514611B0-6B73-43DF-B573-317EA3A651B9@omniti.com> References: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org> <514611B0-6B73-43DF-B573-317EA3A651B9@omniti.com> Message-ID: > On Jan 20, 2017, at 3:14 PM, Dan McDonald wrote: > > >> On Jan 20, 2017, at 2:36 PM, Michael Talbott wrote: >> >> Are there any other ways to monitor traffic on a per port/protocol level basis? Or would digging out a previous versions binary work? I know dladm can show usage on per-interface, but, I'd like to see if flowadm is actually doing what it is supposed to be doing with a few simple rules I gave it (which are priority based, not maxbw). >> > > The undocumented flowstat may do what you want. > > You specify a flow with flowadm(1M) and then you use flowstat to monitor that flow. > > The commit mentioned in 7210 goes back to the OpenSolaris days. The commit in question introduces both dlstat and flowstat, both of which are undocumented, but may be the better-encapsulated features that you desire. bloody(cmd/flowadm)[1]% flowstat --help bloody(cmd/flowadm)[0]% flowstat -3 flowstat: unrecognized option '-3' usage: flowstat [-r | -t] [-i interval] [-l link] [flow] flowstat [-A] [-i interval] [-p] [ -o field[,...]] [-u R|K|M|G|T|P] [-l link] [flow] flowstat -h [-a] [-d] [-F format] [-s
] [-e
] -f [] bloody(cmd/flowadm)[1]% Just so you can see the usage string. Dan From mtalbott at lji.org Fri Jan 20 20:22:50 2017 From: mtalbott at lji.org (Michael Talbott) Date: Fri, 20 Jan 2017 12:22:50 -0800 Subject: [OmniOS-discuss] flowadm stats In-Reply-To: References: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org> <514611B0-6B73-43DF-B573-317EA3A651B9@omniti.com> Message-ID: <343DB54D-F4BA-48CB-BE9B-91C8737D5B5A@lji.org> Perfect. Thanks. > On Jan 20, 2017, at 12:16 PM, Dan McDonald wrote: > >> >> On Jan 20, 2017, at 3:14 PM, Dan McDonald wrote: >> >> >>> On Jan 20, 2017, at 2:36 PM, Michael Talbott wrote: >>> >>> Are there any other ways to monitor traffic on a per port/protocol level basis? Or would digging out a previous versions binary work? I know dladm can show usage on per-interface, but, I'd like to see if flowadm is actually doing what it is supposed to be doing with a few simple rules I gave it (which are priority based, not maxbw). >>> >> >> The undocumented flowstat may do what you want. >> >> You specify a flow with flowadm(1M) and then you use flowstat to monitor that flow. >> >> The commit mentioned in 7210 goes back to the OpenSolaris days. The commit in question introduces both dlstat and flowstat, both of which are undocumented, but may be the better-encapsulated features that you desire. > > bloody(cmd/flowadm)[1]% flowstat --help > bloody(cmd/flowadm)[0]% flowstat -3 > flowstat: unrecognized option '-3' > usage: flowstat [-r | -t] [-i interval] [-l link] [flow] > flowstat [-A] [-i interval] [-p] [ -o field[,...]] > [-u R|K|M|G|T|P] [-l link] [flow] > flowstat -h [-a] [-d] [-F format] [-s
] > [-e
] -f [] > bloody(cmd/flowadm)[1]% > > > Just so you can see the usage string. > > Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Jan 20 20:23:35 2017 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 20 Jan 2017 15:23:35 -0500 Subject: [OmniOS-discuss] flowadm stats In-Reply-To: <343DB54D-F4BA-48CB-BE9B-91C8737D5B5A@lji.org> References: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org> <514611B0-6B73-43DF-B573-317EA3A651B9@omniti.com> <343DB54D-F4BA-48CB-BE9B-91C8737D5B5A@lji.org> Message-ID: <4BF97594-4C63-45F5-8F7F-3A890AA3F6F2@omniti.com> > On Jan 20, 2017, at 3:22 PM, Michael Talbott wrote: > > Perfect. Thanks. > If this indeed solves your problems, I think illumos 7210 should change to be "document flowstat and dlstat". :) Hope this helps, Dan From mtalbott at lji.org Fri Jan 20 20:37:31 2017 From: mtalbott at lji.org (Michael Talbott) Date: Fri, 20 Jan 2017 12:37:31 -0800 Subject: [OmniOS-discuss] flowadm stats In-Reply-To: <4BF97594-4C63-45F5-8F7F-3A890AA3F6F2@omniti.com> References: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org> <514611B0-6B73-43DF-B573-317EA3A651B9@omniti.com> <343DB54D-F4BA-48CB-BE9B-91C8737D5B5A@lji.org> <4BF97594-4C63-45F5-8F7F-3A890AA3F6F2@omniti.com> Message-ID: <77B0E6EB-E970-4579-8C47-A801B9FFC6E5@lji.org> Interesting. So it looks like when I create a flow, I can monitor that flow in flowstat which is fine and dandy. But.. It also appears that the same traffic is then removed from dlstat stats. Is that normal/intentional? I assumed that dlstat would give the overall interface I/O and flow would give just a detailed look at the traffic as defined in the flow. # flowstat -i1 nfs_vlan411 FLOW IPKTS RBYTES IERRS OPKTS OBYTES OERRS nfs_vlan411 56.59M 430.08G 0 51.82M 231.43G 0 nfs_vlan411 2.99K 287.62K 0 14.13K 119.09M 0 nfs_vlan411 5.49K 27.33M 0 14.02K 104.52M 0 nfs_vlan411 2.32K 224.67K 0 10.81K 90.58M 0 nfs_vlan411 4.71K 19.47M 0 13.30K 102.28M 0 nfs_vlan411 2.72K 298.12K 0 14.06K 119.10M 0 # dlstat -i1 vlan411 LINK IPKTS RBYTES OPKTS OBYTES vlan411 17.11G 125.35T 15.95G 67.24T vlan411 0 0 3 138 vlan411 0 0 0 0 vlan411 0 0 0 0 > On Jan 20, 2017, at 12:23 PM, Dan McDonald wrote: > > >> On Jan 20, 2017, at 3:22 PM, Michael Talbott wrote: >> >> Perfect. Thanks. >> > > If this indeed solves your problems, I think illumos 7210 should change to be "document flowstat and dlstat". :) > > Hope this helps, > Dan > From matej at zunaj.si Sat Jan 21 13:33:41 2017 From: matej at zunaj.si (=?utf-8?Q?Matej_=C5=BDerovnik?=) Date: Sat, 21 Jan 2017 14:33:41 +0100 Subject: [OmniOS-discuss] Backup script (one local, multiple remote snapshots) Message-ID: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si> Hello, I would like to implement backup for one of my servers with zfs send/recv. My scenario would be the following: For each dataset: - keep one daily snapshot on src server - copy daily snapshot from src server to backup server - on backup server, I would like to have one daily, one weekly and one monthly snapshots I checked out some ZFS backup scripts I found on GitHub, but non of them did that I wanted (znapzend came close, but it keeps too many snapshots for my case) Does anyone has anything like that implementented? If yes, would be willing to share? Thanks, Matej From daleg at omniti.com Sat Jan 21 16:07:29 2017 From: daleg at omniti.com (Dale Ghent) Date: Sat, 21 Jan 2017 11:07:29 -0500 Subject: [OmniOS-discuss] Backup script (one local, multiple remote snapshots) In-Reply-To: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si> References: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si> Message-ID: We developed Zetaback for this. As for how you exactly want your snapshots to be in number and how long they should stay around, you might be able to configure a backup policy which covers that. https://github.com/omniti-labs/zetaback The documentation is perdoc within the zetaback script. /dale > On Jan 21, 2017, at 8:33 AM, Matej ?erovnik wrote: > > Hello, > > I would like to implement backup for one of my servers with zfs send/recv. My scenario would be the following: > > For each dataset: > - keep one daily snapshot on src server > - copy daily snapshot from src server to backup server > - on backup server, I would like to have one daily, one weekly and one monthly snapshots > > I checked out some ZFS backup scripts I found on GitHub, but non of them did that I wanted (znapzend came close, but it keeps too many snapshots for my case) > > Does anyone has anything like that implementented? If yes, would be willing to share? > > Thanks, Matej > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From stephan.budach at jvm.de Sat Jan 21 16:48:25 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Sat, 21 Jan 2017 17:48:25 +0100 Subject: [OmniOS-discuss] Error updating R018 to R020 Message-ID: <1e15d6ab-baf5-2446-d732-29561d5cfdde@jvm.de> Hi, I just tried updating one of my 018 nides to 020 and got this: DOWNLOAD PAKETE DATEIEN ?BERTRAGUNG (MB) Geschwindigkeit Abgeschlossen 397/397 13177/13177 289.9/289.9 1.4M/s PHASE ELEMENTE Alte Aktionen werden entfernt 4421/4421 Neue Aktionen werden installiert 2354/4824Action install failed for 'usr/java/jre/lib/zi/Asia/Barnaul' (pkg://omnios/developer/java/jdk): ActionExecutionError: Angeforderter Vorgang f?r Paket pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151020:20161101T233853Z fehlgeschlagen: '/tmp/tmp4VWN53/usr/java/jre/lib/zi/Asia/Barnaul' kann nicht installiert werden; ?bergeordnetes Verzeichnis /tmp/tmp4VWN53/usr/java ist ein Link zu /tmp/tmp4VWN53/usr/java_1.7.0_11. Zum Fortsetzen verschieben Sie das Verzeichnis an seinen urspr?nglichen Speicherort und versuchen es erneut. Das derzeit ausgef?hrte System wurde nicht ver?ndert. Die ?nderungen wurden lediglich an einem Klon vorgenommen. Dieser Klon ist in /tmp/tmp4VWN53 geladen, falls Sie ihn pr?fen m?chten. pkg: Angeforderter Vorgang f?r Paket pkg://omnios/developer/java/jdk at 1.7.0.101.0,5.11-0.151020:20161101T233853Z fehlgeschlagen: '/tmp/tmp4VWN53/usr/java/jre/lib/zi/Asia/Barnaul' kann nicht installiert werden; ?bergeordnetes Verzeichnis /tmp/tmp4VWN53/usr/java ist ein Link zu /tmp/tmp4VWN53/usr/java_1.7.0_11. Zum Fortsetzen verschieben Sie das Verzeichnis an seinen urspr?nglichen Speicherort und versuchen es erneut. root at zfsha02gh79:/root# Basically, pkg complains about JDK.17.0.101.0 being a link instead of a real folder and wants me to move that one back to its original location. Well? seems, that I can't do that? ;) Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From richard.elling at richardelling.com Sat Jan 21 18:00:31 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Sat, 21 Jan 2017 10:00:31 -0800 Subject: [OmniOS-discuss] Backup script (one local, multiple remote snapshots) In-Reply-To: References: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si> Message-ID: <3552866E-48B0-4DA3-AABF-3C573A65FA1F@richardelling.com> > On Jan 21, 2017, at 8:07 AM, Dale Ghent wrote: > > We developed Zetaback for this. +1 for zetaback. There are perhaps hundreds of implementations of this over the years. I think you'll find that zetaback is one of the best designs. -- richard > As for how you exactly want your snapshots to be in number and how long they should stay around, you might be able to configure a backup policy which covers that. > > https://github.com/omniti-labs/zetaback > > The documentation is perdoc within the zetaback script. > > /dale > >> On Jan 21, 2017, at 8:33 AM, Matej ?erovnik wrote: >> >> Hello, >> >> I would like to implement backup for one of my servers with zfs send/recv. My scenario would be the following: >> >> For each dataset: >> - keep one daily snapshot on src server >> - copy daily snapshot from src server to backup server >> - on backup server, I would like to have one daily, one weekly and one monthly snapshots >> >> I checked out some ZFS backup scripts I found on GitHub, but non of them did that I wanted (znapzend came close, but it keeps too many snapshots for my case) >> >> Does anyone has anything like that implementented? If yes, would be willing to share? >> >> Thanks, Matej >> _______________________________________________ >> 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 tobi at oetiker.ch Sat Jan 21 20:06:03 2017 From: tobi at oetiker.ch (Tobi Oetiker) Date: Sat, 21 Jan 2017 21:06:03 +0100 Subject: [OmniOS-discuss] Backup script (one local, multiple remote snapshots) In-Reply-To: <3552866E-48B0-4DA3-AABF-3C573A65FA1F@richardelling.com> References: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si> <3552866E-48B0-4DA3-AABF-3C573A65FA1F@richardelling.com> Message-ID: <53EEBE8A-D521-4489-9A4C-602D8F9B20E5@oetiker.ch> try www.znapzend.org cheers tobi Tobias Oetiker tobi at oetiker.ch 062 775 9902 > On 21 Jan 2017, at 19:00, Richard Elling wrote: > > > >> On Jan 21, 2017, at 8:07 AM, Dale Ghent wrote: >> >> We developed Zetaback for this. > > +1 for zetaback. There are perhaps hundreds of implementations of this over the years. I think you'll find that zetaback is one of the best designs. > > -- richard > >> As for how you exactly want your snapshots to be in number and how long they should stay around, you might be able to configure a backup policy which covers that. >> >> https://github.com/omniti-labs/zetaback >> >> The documentation is perdoc within the zetaback script. >> >> /dale >> >>> On Jan 21, 2017, at 8:33 AM, Matej ?erovnik wrote: >>> >>> Hello, >>> >>> I would like to implement backup for one of my servers with zfs send/recv. My scenario would be the following: >>> >>> For each dataset: >>> - keep one daily snapshot on src server >>> - copy daily snapshot from src server to backup server >>> - on backup server, I would like to have one daily, one weekly and one monthly snapshots >>> >>> I checked out some ZFS backup scripts I found on GitHub, but non of them did that I wanted (znapzend came close, but it keeps too many snapshots for my case) >>> >>> Does anyone has anything like that implementented? If yes, would be willing to share? >>> >>> Thanks, Matej >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From stephan.budach at jvm.de Sun Jan 22 08:24:47 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Sun, 22 Jan 2017 09:24:47 +0100 Subject: [OmniOS-discuss] Error updating R018 to R020 In-Reply-To: <1e15d6ab-baf5-2446-d732-29561d5cfdde@jvm.de> References: <1e15d6ab-baf5-2446-d732-29561d5cfdde@jvm.de> Message-ID: ehhhh? I forgot, that I had some older JRE installed, due to some application which doesn't run with newer ones. Undone that and the update to 020 went just fine. Sorry for the noise? Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From bfriesen at simple.dallas.tx.us Sun Jan 22 22:02:17 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 22 Jan 2017 16:02:17 -0600 (CST) Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up Message-ID: I am configuring a new system based on OmniOS r151020. While running as root and attempting to cut-and-paste text into 'vi' using a Gnome terminal open on (via ssh) both a prior OmniOS r151020 system and the new one, I always get the error: "E353: Nothing in register "" and the paste fails. This is incredibly annoying. I notice that vim on the new system displays colorized text (it does not on the "old" r151020 system, which has been upgraded several times) and automatically inserts some additional text when I hit enter such as on a comment line. This is also behavior unsuitable for new system bring-up. Is there an easy way to bring back sane behavior? I do recall discussion on the mailing list of changing vim defaults but the implications were not clear. Thanks, Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From bfriesen at simple.dallas.tx.us Sun Jan 22 22:42:15 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sun, 22 Jan 2017 16:42:15 -0600 (CST) Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: References: Message-ID: On Sun, 22 Jan 2017, Bob Friesenhahn wrote: > I am configuring a new system based on OmniOS r151020. While running as root > and attempting to cut-and-paste text into 'vi' using a Gnome terminal open on > (via ssh) both a prior OmniOS r151020 system and the new one, I always get > the error: > > "E353: Nothing in register "" > > and the paste fails. This is incredibly annoying. It seems that this bad behavior occurs if 'vim' is not able to access the home directory indicated in the HOME environment variable. Vim seems to do automatic things (e.g. attempt to read/write files in the directory indicated by the inherited $HOME environment variable) which are counter-productive when running (via pfexec) as root and the system is in flux. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From matej at zunaj.si Mon Jan 23 13:14:26 2017 From: matej at zunaj.si (=?utf-8?Q?Matej_=C5=BDerovnik?=) Date: Mon, 23 Jan 2017 14:14:26 +0100 Subject: [OmniOS-discuss] Backup script (one local, multiple remote snapshots) In-Reply-To: <3552866E-48B0-4DA3-AABF-3C573A65FA1F@richardelling.com> References: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si> <3552866E-48B0-4DA3-AABF-3C573A65FA1F@richardelling.com> Message-ID: <07F8AD21-C584-4D03-8419-CEC1F34EB540@zunaj.si> Hey there, how come I didn?t find this earlier:) It does look good after initial testing. I like the option of saving datasets and zvols to files instead of zvol on dst system. Better space usage. Is it possible to run multiple instances of agents on one server? Currently I can transfer up to cca 200MB/s with aes128-gcm at openssh.com cipher and a single connection. I tried running multiple SSH connections to backup multiple datasets and I can get up to around 600MB/s. Is there a way for running multiple instances, each instance taking care of its own pool for instance. Matej > On 21 Jan 2017, at 19:00, Richard Elling wrote: > > > >> On Jan 21, 2017, at 8:07 AM, Dale Ghent wrote: >> >> We developed Zetaback for this. > > +1 for zetaback. There are perhaps hundreds of implementations of this over the years. I think you'll find that zetaback is one of the best designs. > > -- richard > >> As for how you exactly want your snapshots to be in number and how long they should stay around, you might be able to configure a backup policy which covers that. >> >> https://github.com/omniti-labs/zetaback >> >> The documentation is perdoc within the zetaback script. >> >> /dale >> >>> On Jan 21, 2017, at 8:33 AM, Matej ?erovnik wrote: >>> >>> Hello, >>> >>> I would like to implement backup for one of my servers with zfs send/recv. My scenario would be the following: >>> >>> For each dataset: >>> - keep one daily snapshot on src server >>> - copy daily snapshot from src server to backup server >>> - on backup server, I would like to have one daily, one weekly and one monthly snapshots >>> >>> I checked out some ZFS backup scripts I found on GitHub, but non of them did that I wanted (znapzend came close, but it keeps too many snapshots for my case) >>> >>> Does anyone has anything like that implementented? If yes, would be willing to share? >>> >>> Thanks, Matej >>> _______________________________________________ >>> 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 matej at zunaj.si Mon Jan 23 13:20:42 2017 From: matej at zunaj.si (=?utf-8?Q?Matej_=C5=BDerovnik?=) Date: Mon, 23 Jan 2017 14:20:42 +0100 Subject: [OmniOS-discuss] Backup script (one local, multiple remote snapshots) In-Reply-To: <53EEBE8A-D521-4489-9A4C-602D8F9B20E5@oetiker.ch> References: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si> <3552866E-48B0-4DA3-AABF-3C573A65FA1F@richardelling.com> <53EEBE8A-D521-4489-9A4C-602D8F9B20E5@oetiker.ch> Message-ID: <4E89E841-21FE-4DEF-B16B-BF790EE9BDB3@zunaj.si> I did have a look at it during the weekend. Nice tool and easy to use. It did, for some reason, kept too many snapshots (my retention was 1min=>1min on SRC and 1min=>1min,10min=>10min,1h=>1h on DST). What I got was 2 minute?s snapshots, 2 10 minutes?s snapshots and 1 hourly snapshot on the DST. Is this normal? Is it possible to not copy the whole dataset/zvol to dataset/zvol but unstead, do it like zetaback, copy dataset/zvol to file on dst? Thanks, Matej > On 21 Jan 2017, at 21:06, Tobi Oetiker wrote: > > try www.znapzend.org > > cheers > tobi > > Tobias Oetiker > tobi at oetiker.ch > 062 775 9902 > >> On 21 Jan 2017, at 19:00, Richard Elling wrote: >> >> >> >>> On Jan 21, 2017, at 8:07 AM, Dale Ghent wrote: >>> >>> We developed Zetaback for this. >> >> +1 for zetaback. There are perhaps hundreds of implementations of this over the years. I think you'll find that zetaback is one of the best designs. >> >> -- richard >> >>> As for how you exactly want your snapshots to be in number and how long they should stay around, you might be able to configure a backup policy which covers that. >>> >>> https://github.com/omniti-labs/zetaback >>> >>> The documentation is perdoc within the zetaback script. >>> >>> /dale >>> >>>> On Jan 21, 2017, at 8:33 AM, Matej ?erovnik wrote: >>>> >>>> Hello, >>>> >>>> I would like to implement backup for one of my servers with zfs send/recv. My scenario would be the following: >>>> >>>> For each dataset: >>>> - keep one daily snapshot on src server >>>> - copy daily snapshot from src server to backup server >>>> - on backup server, I would like to have one daily, one weekly and one monthly snapshots >>>> >>>> I checked out some ZFS backup scripts I found on GitHub, but non of them did that I wanted (znapzend came close, but it keeps too many snapshots for my case) >>>> >>>> Does anyone has anything like that implementented? If yes, would be willing to share? >>>> >>>> Thanks, Matej >>>> _______________________________________________ >>>> OmniOS-discuss mailing list >>>> OmniOS-discuss at lists.omniti.com >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Mon Jan 23 15:29:30 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 23 Jan 2017 10:29:30 -0500 Subject: [OmniOS-discuss] Error updating R018 to R020 In-Reply-To: References: <1e15d6ab-baf5-2446-d732-29561d5cfdde@jvm.de> Message-ID: > On Jan 22, 2017, at 3:24 AM, Stephan Budach wrote: > > Sorry for the noise? Hey, you found the problem yourself and reported back, this is now on the records, in case someone else has this problem in the future. Thanks! Dan From danmcd at omniti.com Mon Jan 23 15:48:47 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 23 Jan 2017 10:48:47 -0500 Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: References: Message-ID: > On Jan 22, 2017, at 5:02 PM, Bob Friesenhahn wrote: > > I do recall discussion on the mailing list of changing vim defaults but the implications were not clear. I did warn you. :) All of these new behaviors came out as part of the upgrade to VIM 8. If we want more sane defaults for, say, next-LTS, this would be the time to discuss them. Dan From steve at linuxsuite.org Mon Jan 23 15:53:27 2017 From: steve at linuxsuite.org (steve at linuxsuite.org) Date: Mon, 23 Jan 2017 10:53:27 -0500 Subject: [OmniOS-discuss] Corrupted file recovery and restoring pool to ONLINE Message-ID: Howdy! I had a corrupted file during resilvering after a drive failure/replacment, I replaced the file from a backup and the pool started to resilver again. If finished and is still in a state that shows DEGRADED with file errors. I can read the file fine and md5sum checks out. What do I need to do to put this pool into an ONLINE state and remove the error? Or is this pool still problematic?? thanx - steve pool: B-034 state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: resilvered 3.46T in 28h19m with 3 errors on Sun Jan 22 17:43:53 2017 config: NAME STATE READ WRITE CKSUM B-034 DEGRADED 0 0 3 raidz1-0 DEGRADED 0 0 6 c0t5000C500571D5D9Fd0s0 ONLINE 0 0 0 c0t5000C500571D69D3d0s0 ONLINE 0 0 0 c10t50000C0F01F82C82d0s0 ONLINE 0 0 0 c10t50000C0F01F84B6Ad0s0 ONLINE 0 0 0 replacing-4 DEGRADED 0 0 0 c10t50000C0F0132772Ed0s0 OFFLINE 0 0 0 c10t5000039578C8A83Ed0s0 ONLINE 0 0 0 c10t50000C0F0136989Ad0s0 ONLINE 0 0 0 c10t50000C0F01327226d0s0 ONLINE 0 0 0 c10t50000C0F01327316d0s0 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: B-034 at nov_5_2016:/51/17/1000621751.bkt From chip at innovates.com Mon Jan 23 16:01:57 2017 From: chip at innovates.com (Schweiss, Chip) Date: Mon, 23 Jan 2017 10:01:57 -0600 Subject: [OmniOS-discuss] Corrupted file recovery and restoring pool to ONLINE In-Reply-To: References: Message-ID: To get back to an online state you need to detach the offline disk: zpool detach B-034 c10t50000C0F0132772Ed0s0 If the corrupted file is in any snapshots those snapshots will have to be destroyed to stop it from being found as a corruption during a scrub. -Chip On Mon, Jan 23, 2017 at 9:53 AM, wrote: > > Howdy! > > I had a corrupted file during resilvering after a drive > failure/replacment, I replaced the file from a backup and the > pool started to resilver again. If finished and is still in a > state > that shows DEGRADED with file errors. I can read the file fine and md5sum > checks out. > > What do I need to do to put this pool into an ONLINE state and > remove the error? > Or is this pool still problematic?? > > thanx - steve > > pool: B-034 > state: DEGRADED > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://illumos.org/msg/ZFS-8000-8A > scan: resilvered 3.46T in 28h19m with 3 errors on Sun Jan 22 17:43:53 > 2017 > config: > > NAME STATE READ WRITE CKSUM > B-034 DEGRADED 0 0 3 > raidz1-0 DEGRADED 0 0 6 > c0t5000C500571D5D9Fd0s0 ONLINE 0 0 0 > c0t5000C500571D69D3d0s0 ONLINE 0 0 0 > c10t50000C0F01F82C82d0s0 ONLINE 0 0 0 > c10t50000C0F01F84B6Ad0s0 ONLINE 0 0 0 > replacing-4 DEGRADED 0 0 0 > c10t50000C0F0132772Ed0s0 OFFLINE 0 0 0 > c10t5000039578C8A83Ed0s0 ONLINE 0 0 0 > c10t50000C0F0136989Ad0s0 ONLINE 0 0 0 > c10t50000C0F01327226d0s0 ONLINE 0 0 0 > c10t50000C0F01327316d0s0 ONLINE 0 0 0 > > errors: Permanent errors have been detected in the following files: > > B-034 at nov_5_2016:/51/17/1000621751.bkt > > > _______________________________________________ > 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 rjahnel at ellipseinc.com Mon Jan 23 16:03:11 2017 From: rjahnel at ellipseinc.com (Richard Jahnel) Date: Mon, 23 Jan 2017 16:03:11 +0000 Subject: [OmniOS-discuss] Onboard LSI 3108 and R151020 Message-ID: <65DC5816D4BEE043885A89FD54E273FC71D4796E@MAIL101.Ellipseinc.com> It would appear the r151020 either doesn't like the onboard LSI3108 chipset or doesn't like the fact that there are no drives hooked up to it. It's working fine with r151016 right now and before I attempted the pkg update to r1510120. The symptoms are the system becomes unresponsive while enumerating services and after a long period of time (like 20 ish minutes) will pop the following message while remaining otherwise unresponsive: Warning: mr_sas0: could not initialize the low level driver After I finish evacuating the machine I will try disabling the onboard 3108 in bios and see what happens. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Mon Jan 23 16:17:46 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Mon, 23 Jan 2017 10:17:46 -0600 (CST) Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: References: Message-ID: On Mon, 23 Jan 2017, Dan McDonald wrote: > >> On Jan 22, 2017, at 5:02 PM, Bob Friesenhahn wrote: >> >> I do recall discussion on the mailing list of changing vim defaults but the implications were not clear. > > I did warn you. :) > > All of these new behaviors came out as part of the upgrade to VIM 8. > If we want more sane defaults for, say, next-LTS, this would be the > time to discuss them. The "fix" in my case for vim may actually be that when i re-logged in, I now did so for a user with an existing vim configuration file which would have been used and may have "cured" the vim behavior. The "cured" vim looked just like traditional vi without use of screen colors. Not being very smart about vim, this file must contain defaults saved by the older vim since I did not intentionally add any settings. I failed to mention that my administration terminal is on a Solaris 10 system using its Gnome2 desktop and the terminal output is set to UTF-8 mode. The ability to cut-and-paste into vi between two terminals is quite useful. Has anyone else encountered this problem with OmniOS? Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Mon Jan 23 16:20:49 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 23 Jan 2017 11:20:49 -0500 Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: References: Message-ID: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> > On Jan 23, 2017, at 11:17 AM, Bob Friesenhahn wrote: > > The ability to cut-and-paste into vi between two terminals is quite useful. Has anyone else encountered this problem with OmniOS? VIM 8 by default is too-clever for its own good. I cannot copy text out of a VIM8 window using MacOS Terminal.app, because VIM8 wants to be "mouse-friendly" on my terminal.app. Sheesh, at least EMACS has the good sense not to do that w/o a native windowing manager pane. I don't have time now, but the build.sh for VIM should probably do some hacking in its "configure" options. Community experimentation with this welcome. Dan From tim at multitalents.net Mon Jan 23 17:31:28 2017 From: tim at multitalents.net (Tim Rice) Date: Mon, 23 Jan 2017 09:31:28 -0800 (PST) Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> References: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> Message-ID: On Mon, 23 Jan 2017, Dan McDonald wrote: > > > On Jan 23, 2017, at 11:17 AM, Bob Friesenhahn wrote: > > > > The ability to cut-and-paste into vi between two terminals is quite useful. Has anyone else encountered this problem with OmniOS? > > VIM 8 by default is too-clever for its own good. I cannot copy text out of a VIM8 window using MacOS Terminal.app, because VIM8 wants to be "mouse-friendly" on my terminal.app. Sheesh, at least EMACS has the good sense not to do that w/o a native windowing manager pane. > > I don't have time now, but the build.sh for VIM should probably do some hacking in its "configure" options. Community experimentation with this welcome. > > Dan For what its worth, there is a similar thread on the freebsd ports list that starts here. https://lists.freebsd.org/pipermail/freebsd-ports/2017-January/106697.html -- Tim Rice Multitalents (707) 456-1146 tim at multitalents.net From danmcd at omniti.com Mon Jan 23 17:33:50 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 23 Jan 2017 12:33:50 -0500 Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> References: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> Message-ID: <9D51F2DF-F230-4319-AEBE-58CFC883A74B@omniti.com> > On Jan 23, 2017, at 11:20 AM, Dan McDonald wrote: > > VIM 8 by default is too-clever for its own good. I cannot copy text out of a VIM8 window using MacOS Terminal.app, because VIM8 wants to be "mouse-friendly" on my terminal.app. Sheesh, at least EMACS has the good sense not to do that w/o a native windowing manager pane. Protip for those who got bitten by this like me. Terminal.app has "Allow Mouse Reporting" checked, and you can uncheck it with Command-R. It's a decent-enough workaround. I don't, to be honest, see a quick way to eliminate this. I just saw Tim's mail arrive as I'm typing this, so I'll look at the FreeBSD thread too. Dan From danmcd at omniti.com Mon Jan 23 17:36:42 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 23 Jan 2017 12:36:42 -0500 Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: References: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> Message-ID: <2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com> > On Jan 23, 2017, at 12:31 PM, Tim Rice wrote: > > > For what its worth, there is a similar thread on the freebsd ports list > that starts here. > https://lists.freebsd.org/pipermail/freebsd-ports/2017-January/106697.html None of them point out for at least Terminal.app you can disable the transmission of mouse events. The whole thread focusses on modifying your .vimrc to disable it. I don't even see a "configure" option for this, which is annoying. Dan From danmcd at omniti.com Mon Jan 23 17:38:10 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 23 Jan 2017 12:38:10 -0500 Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: <2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com> References: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> <2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com> Message-ID: > On Jan 23, 2017, at 12:36 PM, Dan McDonald wrote: > > I don't even see a "configure" option for this, which is annoying. But I do see: /usr/share/vim/vim80/defaults.vim Where I could just disable "mouse" by default in things. Dan From tim at multitalents.net Mon Jan 23 17:43:46 2017 From: tim at multitalents.net (Tim Rice) Date: Mon, 23 Jan 2017 09:43:46 -0800 (PST) Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: <2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com> References: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> <2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com> Message-ID: On Mon, 23 Jan 2017, Dan McDonald wrote: > None of them point out for at least Terminal.app you can disable the transmission of mouse events. > > The whole thread focusses on modifying your .vimrc to disable it. > > I don't even see a "configure" option for this, which is annoying. > > Dan Brings to mind the phrase, "Improved beyond usability". -- Tim Rice Multitalents tim at multitalents.net From mir at miras.org Mon Jan 23 22:13:18 2017 From: mir at miras.org (Michael Rasmussen) Date: Mon, 23 Jan 2017 23:13:18 +0100 Subject: [OmniOS-discuss] PCI-e x8 only running x4 Message-ID: <20170123231318.0091abc6@sleipner.datanom.net> Hi all, I have a problem with a LSI 1068E HBA which supposedly should be capable of exhausting all 8 lanes in a x8 slot but it seems not to use more than 4 lanes: 06:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08) LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- MB: SuperMicro X10SLL-F Currently only disks (SATA disks through SATA break-out cabel) connected to one channel so is it therefore it only uses 4 lanes currently? -- 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: Is this going to involve RAW human ecstasy? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From rafapi at gmail.com Mon Jan 23 22:14:21 2017 From: rafapi at gmail.com (Rafael Pardinas) Date: Mon, 23 Jan 2017 22:14:21 +0000 Subject: [OmniOS-discuss] Annoying vim behavior for new system bring-up In-Reply-To: References: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com> <2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com> Message-ID: Based on my experience, it depends what configuration flags have been used when the vim binary has been compiled. For instance, in order to be able to copy and paste from a vim terminal to another you need to enable the 'clipboard' flag; that should also work for the 'mouse' flags (this can also be controlled from the .vimrc file, but it looks that is not the wanted method). Run: $ vim --version That'll tell you what defaults vim is compiled with. After that it is possible to compile vim with any speciffic './configuration' defaults to add/remove functionality. I hope this helps. On Mon, 23 Jan 2017 at 17:45 Tim Rice wrote: > On Mon, 23 Jan 2017, Dan McDonald wrote: > > > None of them point out for at least Terminal.app you can disable the > transmission of mouse events. > > > > The whole thread focusses on modifying your .vimrc to disable it. > > > > I don't even see a "configure" option for this, which is annoying. > > > > Dan > > Brings to mind the phrase, "Improved beyond usability". > > -- > Tim Rice Multitalents > tim at multitalents.net > > > _______________________________________________ > 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 daleg at omniti.com Tue Jan 24 00:27:51 2017 From: daleg at omniti.com (Dale Ghent) Date: Mon, 23 Jan 2017 19:27:51 -0500 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: <20170123231318.0091abc6@sleipner.datanom.net> References: <20170123231318.0091abc6@sleipner.datanom.net> Message-ID: > On Jan 23, 2017, at 5:13 PM, Michael Rasmussen wrote: > > Hi all, > > I have a problem with a LSI 1068E HBA which supposedly should be > capable of exhausting all 8 lanes in a x8 slot but it seems not to use > more than 4 lanes: > > 06:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08) > LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us > LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- > > MB: SuperMicro X10SLL-F > > Currently only disks (SATA disks through SATA break-out cabel) connected > to one channel so is it therefore it only uses 4 lanes currently? Check your BIOS settings for the slots, they might be limited there. I also note that this motherboard model has two physical x8 PCIe slots but one of them is wired for 4 lanes only. Is your card in that slot? Something not linking up like this is likely to be more of a hardware configuration issue. Also keep in mind that the 1068E card is quite old and its driver support in OmniOS/illumos is still the closed-source mpt driver binary, so there is not much room here. /dale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From mir at miras.org Tue Jan 24 01:17:32 2017 From: mir at miras.org (Michael Rasmussen) Date: Tue, 24 Jan 2017 02:17:32 +0100 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: References: <20170123231318.0091abc6@sleipner.datanom.net> Message-ID: <20170124021732.32473f65@sleipner.datanom.net> On Mon, 23 Jan 2017 19:27:51 -0500 Dale Ghent wrote: > > Check your BIOS settings for the slots, they might be limited there. I also note that this motherboard model has two physical x8 PCIe slots but one of them is wired for 4 lanes only. Is your card in that slot? Something not linking up like this is likely to be more of a hardware configuration issue. > Doesn't this proof an x8 slot? LnkCap: Port #0, Speed 2.5GT/s, Width x8 I was aware of that one of the x8 slot was actually a x4 slot so I am quite certain I have picked the right one. It couldn't be as simple as since there is no disks connected to the second channel so the 4 lanes for the second channel is not active? > Also keep in mind that the 1068E card is quite old and its driver support in OmniOS/illumos is still the closed-source mpt driver binary, so there is not much room here. > I am aware of that and an upgrade to a 2x08 is on the todo list. -- 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: Tis man's perdition to be safe, when for the truth he ought to die. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Tue Jan 24 01:22:43 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 23 Jan 2017 20:22:43 -0500 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: <20170124021732.32473f65@sleipner.datanom.net> References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> Message-ID: <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> > On Jan 23, 2017, at 8:17 PM, Michael Rasmussen wrote: > > I am aware of that and an upgrade to a 2x08 is on the todo list. Highly recommend x == 0 or 2, or also consider a 3008. All of these are mpt_sas boards. x == 1 or 3 are mr_sas boards, which have (eww) HW-RAID on them. Dan From richard.elling at richardelling.com Tue Jan 24 01:52:44 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 23 Jan 2017 17:52:44 -0800 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: <20170124021732.32473f65@sleipner.datanom.net> References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> Message-ID: <9611C0E4-D89E-43CB-A4A1-068C42EB8988@richardelling.com> > On Jan 23, 2017, at 5:17 PM, Michael Rasmussen wrote: > > On Mon, 23 Jan 2017 19:27:51 -0500 > Dale Ghent wrote: > >> >> Check your BIOS settings for the slots, they might be limited there. I also note that this motherboard model has two physical x8 PCIe slots but one of them is wired for 4 lanes only. Is your card in that slot? Something not linking up like this is likely to be more of a hardware configuration issue. >> > Doesn't this proof an x8 slot? LnkCap: Port #0, Speed 2.5GT/s, Width x8 > I was aware of that one of the x8 slot was actually a x4 slot so I am > quite certain I have picked the right one. > > It couldn't be as simple as since there is no disks connected to the > second channel so the 4 lanes for the second channel is not active? > >> Also keep in mind that the 1068E card is quite old and its driver support in OmniOS/illumos is still the closed-source mpt driver binary, so there is not much room here. >> > I am aware of that and an upgrade to a 2x08 is on the todo list. This card can?t saturate a modern x4, so you gain nothing going to x8. ? richard > > -- > 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: > Tis man's perdition to be safe, when for the truth he ought to die. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From svavar at pipar-tbwa.is Tue Jan 24 10:07:50 2017 From: svavar at pipar-tbwa.is (=?utf-8?Q?Svavar_=C3=96rn_Eysteinsson?=) Date: Tue, 24 Jan 2017 10:07:50 +0000 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> Message-ID: Which 16port internal controller would you guys recommend ? I'm totall lost in the catalog at LSI site... Thanks allot. Svavar > On 24 Jan 2017, at 01:22, Dan McDonald wrote: > > >> On Jan 23, 2017, at 8:17 PM, Michael Rasmussen wrote: >> >> I am aware of that and an upgrade to a 2x08 is on the todo list. > > Highly recommend x == 0 or 2, or also consider a 3008. All of these are mpt_sas boards. x == 1 or 3 are mr_sas boards, which have (eww) HW-RAID on them. > > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From bfriesen at simple.dallas.tx.us Tue Jan 24 14:50:56 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 24 Jan 2017 08:50:56 -0600 (CST) Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> Message-ID: On Tue, 24 Jan 2017, Svavar ?rn Eysteinsson wrote: > Which 16port internal controller would you guys recommend ? > I'm totall lost in the catalog at LSI site... I have a LSI 9300-16i 12Gb/s SAS controller which seems to be working fine here. I am still burn-in testing but it has been 3 days already. This is in a Supermicro SC836BA-R920B chassis which is a direct-connect chassis not rated for 12Gb/s duty but I have not yet seen any sign of a problem with 12Gb/s SAS drives in a (claimed) 6Gb/s backplane. Pool scrub peak rates reported by 'zpool iostat' are about 800MB/s (830M/s reported by 'zpool status') using 16 drives arranged in 2 RAIDz2 vdevs and with lz4 compression (on about half the data) and using skein checksums. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From matej at zunaj.si Tue Jan 24 17:32:10 2017 From: matej at zunaj.si (=?utf-8?Q?Matej_=C5=BDerovnik?=) Date: Tue, 24 Jan 2017 18:32:10 +0100 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> Message-ID: <0F5E32AC-DA7B-4EF8-B579-F8181BD643F0@zunaj.si> I?m running LSI 9300-8e for the last 6 months in producution without problems. I have Supermicro JBOD attached to it with SAS drives in it. So, 12Gb/s controller and drives and 6Gb/s backplace. lp, Matej > On 24 Jan 2017, at 15:50, Bob Friesenhahn wrote: > > On Tue, 24 Jan 2017, Svavar ?rn Eysteinsson wrote: > >> Which 16port internal controller would you guys recommend ? >> I'm totall lost in the catalog at LSI site... > > I have a LSI 9300-16i 12Gb/s SAS controller which seems to be working fine here. I am still burn-in testing but it has been 3 days already. > > This is in a Supermicro SC836BA-R920B chassis which is a direct-connect chassis not rated for 12Gb/s duty but I have not yet seen any sign of a problem with 12Gb/s SAS drives in a (claimed) 6Gb/s backplane. > > Pool scrub peak rates reported by 'zpool iostat' are about 800MB/s (830M/s reported by 'zpool status') using 16 drives arranged in 2 RAIDz2 vdevs and with lz4 compression (on about half the data) and using skein checksums. > > Bob > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/_______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From bfriesen at simple.dallas.tx.us Tue Jan 24 18:15:19 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 24 Jan 2017 12:15:19 -0600 (CST) Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: <0F5E32AC-DA7B-4EF8-B579-F8181BD643F0@zunaj.si> References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> <0F5E32AC-DA7B-4EF8-B579-F8181BD643F0@zunaj.si> Message-ID: On Tue, 24 Jan 2017, Matej ?erovnik wrote: > I?m running LSI 9300-8e for the last 6 months in producution without > problems. I have Supermicro JBOD attached to it with SAS drives in > it. So, 12Gb/s controller and drives and 6Gb/s backplace. Perhaps SuperMicro is not eager to re-qualify their existing passive hardware for 12Gb/s since they are mostly intent on selling expander-based hardware which does need to be updated for 12Gb/s. SAS is supposed to be good for something like 30 feet so only a poorly laid-out passive backplane would have problems due to the higher speed. Google and WikiPedia were not able to shed any light on this issue so I just took a chance. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From hasslerd at gmx.li Tue Jan 24 22:30:12 2017 From: hasslerd at gmx.li (Dominik Hassler) Date: Tue, 24 Jan 2017 23:30:12 +0100 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> Message-ID: On 01/24/2017 02:22 AM, Dan McDonald wrote: > >> On Jan 23, 2017, at 8:17 PM, Michael Rasmussen wrote: >> >> I am aware of that and an upgrade to a 2x08 is on the todo list. > > Highly recommend x == 0 or 2, or also consider a 3008. All of these are mpt_sas boards. x == 1 or 3 are mr_sas boards, which have (eww) HW-RAID on them. > are you sure? i have a 2308 flashed to IT firmware and the attached driver is mpt_sas not mr_sas # ./sas2ircu LIST LSI Corporation SAS2 IR Configuration Utility. Version 20.00.00.00 (2014.09.18) Copyright (c) 2008-2014 LSI Corporation. All rights reserved. Adapter Vendor Device SubSys SubSys Index Type ID ID Pci Address Ven ID Dev ID ----- ------------ ------ ------ ----------------- ------ ------ 0 SAS2308_1 1000h 86h 00h:02h:00h:00h 15d9h 0691h SAS2IRCU: Utility Completed Successfully. # dmesg |grep sas Jan 20 01:24:06 jupiter scsi: [ID 583861 kern.info] mpt_sas5 at mpt_sas0: scsi-iport v0 Jan 20 01:24:06 jupiter genunix: [ID 936769 kern.info] mpt_sas5 is /pci at 0,0/pci8086,c05 at 1,1/pci15d9,691 at 0/iport at v0 Jan 20 01:24:06 jupiter genunix: [ID 408114 kern.info] /pci at 0,0/pci8086,c05 at 1,1/pci15d9,691 at 0/iport at v0 (mpt_sas5) online > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From danmcd at omniti.com Tue Jan 24 22:32:17 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 24 Jan 2017 17:32:17 -0500 Subject: [OmniOS-discuss] PCI-e x8 only running x4 In-Reply-To: References: <20170123231318.0091abc6@sleipner.datanom.net> <20170124021732.32473f65@sleipner.datanom.net> <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com> Message-ID: <68A3A82C-AB39-4D8F-AC45-87C170398C76@omniti.com> DAMN. I swapped '2' and '3'. 2008, 2308, 3008 ==> mpt_sas 2108, 2208, 3108 ==> mr_sas Sorry about that folks! Dan From danmcd at omniti.com Tue Jan 24 22:56:52 2017 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 24 Jan 2017 17:56:52 -0500 Subject: [OmniOS-discuss] libldap security update Message-ID: <43B413FD-D4B4-4A9D-ABAF-E1CE73076731@omniti.com> If you're not an LDAP user, you can put off updating your system. If you are, prepare to create a new BE and reboot, because libldap is in system/library. This bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1310467 and this fix: https://hg.mozilla.org/releases/comm-aurora/rev/afcaac5233d09dd9b0d7235f9a408b581fda8b19 Neees to appear in our own libldap, which originates from Mozilla. I've updated all of the supported release (014, 018, 020), and the next release of bloody will naturally have it as well. Thanks, Dan From stephan.budach at jvm.de Wed Jan 25 13:54:59 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 25 Jan 2017 14:54:59 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs Message-ID: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> Hi guys, I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. When issueing a zpool import, it says this: root at solaris11atest2:~# zpool import pool: vsmPool10 id: 12653649504720395171 state: DEGRADED status: The pool was last accessed by another system. action: The pool can be imported despite missing or damaged devices. The fault tolerance of the pool may be compromised if imported. see: http://support.oracle.com/msg/ZFS-8000-EY config: vsmPool10 DEGRADED mirror-0 DEGRADED c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data device details: c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed status: ZFS detected errors on this device. The device is missing some data that is recoverable. c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed status: ZFS detected errors on this device. The device is missing some data that is recoverable. c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed status: ZFS detected errors on this device. The device is missing some data that is recoverable. However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: root at solaris11atest2:~# iostat -xeM 5 extended device statistics ---- errors --- device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 extended device statistics ---- errors --- device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 extended device statistics ---- errors --- device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 extended device statistics ---- errors --- device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 I have tried pulling data from the LUNs using dd to /dev/null and I didn't get any h/w error, this just started, when trying to actually import the zpool. As the h/w errors are constantly rising, I am wondering what could cause this and if there can something be done about this? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From bfriesen at simple.dallas.tx.us Wed Jan 25 14:35:17 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 25 Jan 2017 08:35:17 -0600 (CST) Subject: [OmniOS-discuss] OmniOS ntpd multicast client oddity Message-ID: Under Solaris 10 and OpenIndiana oi_151a9 I am successfully running ntp clients in multicast client mode using trusted keys for security. I tried to do the same on a fresh OmniOS r151020 install (on a ixgbe interface running at 1Gbit) but find that ntpd only works properly for a short while after being started or restarted (based on 'ntpq -p' output) but then something goes wrong. After a while there is no more output from 'ntpq -p' and I see this with debug enabled: ntpq -d -p 1 packets reassembled into response [12794] [12793] [12792] [12791] 4 associations total ::1 reversed to localhost remote refid st t when poll reach delay offset jitter ============================================================================== eliding [12791] eliding [12792] eliding [12793] eliding [12794] I see this on the OpenIndiana host which is attached to the same switch: % ntpq -n -d -p 1 packets reassembled into response [12482] [12481] [12480] [12479] [12478] 5 associations total remote refid st t when poll reach delay offset jitter ============================================================================== eliding [12478] 2 packets reassembled into response *65.66.246.73 204.9.54.119 2 b 43 64 376 0.000 0.422 0.087 2 packets reassembled into response +65.66.246.74 132.239.1.6 2 b 48 64 376 0.000 -1.064 0.176 eliding [12481] 2 packets reassembled into response +65.66.246.91 204.9.54.119 2 b 43 64 376 0.000 0.426 0.078 and this is what I see on the OmniOS host shortly after ntpd has been started/re-started: ntpq -n -d -p 1 packets reassembled into response [62163] [62162] [62161] [62160] 4 associations total remote refid st t when poll reach delay offset jitter ============================================================================== 2 packets reassembled into response +65.66.246.74 132.239.1.6 2 b 12 64 1 0.862 -1.652 0.167 eliding [62161] 2 packets reassembled into response *65.66.246.91 204.9.54.119 2 b 8 64 1 0.272 -0.554 0.035 2 packets reassembled into response +65.66.246.73 204.9.54.119 2 b 11 64 1 0.272 -0.535 0.023 The key statement in the ntp.conf file is this: # Passively wait for a server to provide NTP packets on the ntp multicast net. multicastclient 224.0.1.1 I am wondering why all of the peer entries are being 'elided' after some time (maybe minutes). Is multicast reception only working for a few packets and then ceases or is something else going on? Thanks, Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From danmcd at omniti.com Wed Jan 25 15:45:11 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 25 Jan 2017 10:45:11 -0500 Subject: [OmniOS-discuss] OmniOS ntpd multicast client oddity In-Reply-To: References: Message-ID: <90C1E228-EED5-4E2A-868A-BFAB1D8AF501@omniti.com> I noticed you don't have "-n" on your first batch of output. Probably a nit, though. What version(s) of NTP are you running? 020 ships 4.2.8p9 (all OmniOS supported releases use this version, BTW) with some patches shown here: https://github.com/omniti-labs/omnios-build/tree/r151020/build/ntp/patches Are S10 and OI running the same version? With or without patches? Dan From daleg at omniti.com Wed Jan 25 17:07:18 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 25 Jan 2017 12:07:18 -0500 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> Message-ID: ZFS as implemented in Oracle Solaris is *not* OpenZFS, which is what illumos (and all illumos distros), FreeBSD, and the ZFS on Linux/macOS projects use. Up to a level of features, the two are compatible - but then they diverge in features. If one pool has features the zfs driver does not understand, you could run the risk of refusal to import as indicated here. Seeing as how Oracle itself does not include OpenZFS features in its ZFS implementation, and Oracle does not provide any information to OpenZFS regarding features it invents, this will unfortunately be the state of things unless Oracle changes its open source or information sharing policies. Unfortunate but that's just the way things are. /dale > On Jan 25, 2017, at 8:54 AM, Stephan Budach wrote: > > Hi guys, > > I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. > > This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. > > When issueing a zpool import, it says this: > > root at solaris11atest2:~# zpool import > pool: vsmPool10 > id: 12653649504720395171 > state: DEGRADED > status: The pool was last accessed by another system. > action: The pool can be imported despite missing or damaged devices. The > fault tolerance of the pool may be compromised if imported. > see: http://support.oracle.com/msg/ZFS-8000-EY > config: > > vsmPool10 DEGRADED > mirror-0 DEGRADED > c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data > c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data > c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data > > device details: > > c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed > status: ZFS detected errors on this device. > The device is missing some data that is recoverable. > > c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed > status: ZFS detected errors on this device. > The device is missing some data that is recoverable. > > c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed > status: ZFS detected errors on this device. > The device is missing some data that is recoverable. > > However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: > > root at solaris11atest2:~# iostat -xeM 5 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 > sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 > sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 > sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 > sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 > sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 > sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 > sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 > sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 > sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 > sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 > sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 > sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 > > > I have tried pulling data from the LUNs using dd to /dev/null and I didn't get any h/w error, this just started, when trying to actually import the zpool. As the h/w errors are constantly rising, I am wondering what could cause this and if there can something be done about this? > > Cheers, > Stephan > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From stephan.budach at jvm.de Wed Jan 25 17:14:41 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 25 Jan 2017 18:14:41 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> Message-ID: Hi Dale, I know that and it's not that I am trying to import a S11.1 zpool on omniOS or vice versa. It's that the targets are omniOS and the initiator is S11.1. I am still trying to import the zpool on S11.1. My question was more directed at COMSTAR, which both still should have some fair overlapping, no? I am in contact with Oracle and he mentioned some issues with zvols over iSCSI targets, which may be present for both systems, so I thought, that I'd give it a shot, that's all. Cheers Stephan Am 25.01.17 um 18:07 schrieb Dale Ghent: > ZFS as implemented in Oracle Solaris is *not* OpenZFS, which is what illumos (and all illumos distros), FreeBSD, and the ZFS on Linux/macOS projects use. Up to a level of features, the two are compatible - but then they diverge in features. If one pool has features the zfs driver does not understand, you could run the risk of refusal to import as indicated here. > > Seeing as how Oracle itself does not include OpenZFS features in its ZFS implementation, and Oracle does not provide any information to OpenZFS regarding features it invents, this will unfortunately be the state of things unless Oracle changes its open source or information sharing policies. Unfortunate but that's just the way things are. > > /dale > >> On Jan 25, 2017, at 8:54 AM, Stephan Budach wrote: >> >> Hi guys, >> >> I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. >> >> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. >> >> When issueing a zpool import, it says this: >> >> root at solaris11atest2:~# zpool import >> pool: vsmPool10 >> id: 12653649504720395171 >> state: DEGRADED >> status: The pool was last accessed by another system. >> action: The pool can be imported despite missing or damaged devices. The >> fault tolerance of the pool may be compromised if imported. >> see: http://support.oracle.com/msg/ZFS-8000-EY >> config: >> >> vsmPool10 DEGRADED >> mirror-0 DEGRADED >> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >> >> device details: >> >> c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed >> status: ZFS detected errors on this device. >> The device is missing some data that is recoverable. >> >> c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed >> status: ZFS detected errors on this device. >> The device is missing some data that is recoverable. >> >> c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed >> status: ZFS detected errors on this device. >> The device is missing some data that is recoverable. >> >> However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: >> >> root at solaris11atest2:~# iostat -xeM 5 >> extended device statistics ---- errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 >> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >> extended device statistics ---- errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 >> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 >> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 >> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 >> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 >> extended device statistics ---- errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 >> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 >> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 >> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 >> extended device statistics ---- errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 >> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 >> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 >> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 >> >> >> I have tried pulling data from the LUNs using dd to /dev/null and I didn't get any h/w error, this just started, when trying to actually import the zpool. As the h/w errors are constantly rising, I am wondering what could cause this and if there can something be done about this? >> >> Cheers, >> Stephan >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Krebs's 3 Basic Rules for Online Safety 1st - "If you didn't go looking for it, don't install it!" 2nd - "If you installed it, update it." 3rd - "If you no longer need it, remove it." http://krebsonsecurity.com/2011/05/krebss-3-basic-rules-for-online-safety Stephan Budach Head of IT Jung von Matt AG Glash?ttenstra?e 79 20357 Hamburg Tel: +49 40-4321-1353 Fax: +49 40-4321-1114 E-Mail: stephan.budach at jvm.de Internet: http://www.jvm.com CiscoJabber Video: https://exp-e2.jvm.de/call/stephan.budach Vorstand: Dr. Peter Figge, Jean-Remy von Matt, Larissa Pohl, Thomas Strerath, G?tz Ulmer Vorsitzender des Aufsichtsrates: Hans Hermann M?nchmeyer AG HH HRB 72893 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From daleg at omniti.com Wed Jan 25 17:37:31 2017 From: daleg at omniti.com (Dale Ghent) Date: Wed, 25 Jan 2017 12:37:31 -0500 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> Message-ID: <6CAA70F1-E8B5-4C76-9F41-7EE20BC5A594@omniti.com> Oh, ok, I misunderstood you as trying to import illumos vdevs directly onto a Oracle Solaris server. This line: >>> status: The pool was last accessed by another system. indicates that the zpool was uncleanly exported (or not exported at all) on the previous system it was imported on and the hostid of that system is still imprinted in the vdev labels for the zpool (not the hostid of the system you are trying to import on) Have you tried 'zpool import -f vsmPool10' ? /dale > On Jan 25, 2017, at 12:14 PM, Stephan Budach wrote: > > Hi Dale, > > I know that and it's not that I am trying to import a S11.1 zpool on omniOS or vice versa. It's that the targets are omniOS and the initiator is S11.1. I am still trying to import the zpool on S11.1. My question was more directed at COMSTAR, which both still should have some fair overlapping, no? > > I am in contact with Oracle and he mentioned some issues with zvols over iSCSI targets, which may be present for both systems, so I thought, that I'd give it a shot, that's all. > > Cheers > Stephan > > Am 25.01.17 um 18:07 schrieb Dale Ghent: >> ZFS as implemented in Oracle Solaris is *not* OpenZFS, which is what illumos (and all illumos distros), FreeBSD, and the ZFS on Linux/macOS projects use. Up to a level of features, the two are compatible - but then they diverge in features. If one pool has features the zfs driver does not understand, you could run the risk of refusal to import as indicated here. >> >> Seeing as how Oracle itself does not include OpenZFS features in its ZFS implementation, and Oracle does not provide any information to OpenZFS regarding features it invents, this will unfortunately be the state of things unless Oracle changes its open source or information sharing policies. Unfortunate but that's just the way things are. >> >> /dale >> >> >>> On Jan 25, 2017, at 8:54 AM, Stephan Budach >>> wrote: >>> >>> Hi guys, >>> >>> I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. >>> >>> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. >>> >>> When issueing a zpool import, it says this: >>> >>> root at solaris11atest2:~# zpool import >>> pool: vsmPool10 >>> id: 12653649504720395171 >>> state: DEGRADED >>> status: The pool was last accessed by another system. >>> action: The pool can be imported despite missing or damaged devices. The >>> fault tolerance of the pool may be compromised if imported. >>> see: >>> http://support.oracle.com/msg/ZFS-8000-EY >>> >>> config: >>> >>> vsmPool10 DEGRADED >>> mirror-0 DEGRADED >>> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >>> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >>> >>> device details: >>> >>> c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed >>> status: ZFS detected errors on this device. >>> The device is missing some data that is recoverable. >>> >>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed >>> status: ZFS detected errors on this device. >>> The device is missing some data that is recoverable. >>> >>> c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed >>> status: ZFS detected errors on this device. >>> The device is missing some data that is recoverable. >>> >>> However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: >>> >>> root at solaris11atest2:~# iostat -xeM 5 >>> extended device statistics ---- errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 >>> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>> extended device statistics ---- errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 >>> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 >>> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 >>> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 >>> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 >>> extended device statistics ---- errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 >>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 >>> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 >>> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 >>> extended device statistics ---- errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 >>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 >>> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 >>> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 >>> >>> >>> I have tried pulling data from the LUNs using dd to /dev/null and I didn't get any h/w error, this just started, when trying to actually import the zpool. As the h/w errors are constantly rising, I am wondering what could cause this and if there can something be done about this? >>> >>> Cheers, >>> Stephan >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > -- > Krebs's 3 Basic Rules for Online Safety > 1st - "If you didn't go looking for it, don't install it!" > 2nd - "If you installed it, update it." > 3rd - "If you no longer need it, remove it." > > http://krebsonsecurity.com/2011/05/krebss-3-basic-rules-for-online-safety > > > > Stephan Budach > Head of IT > Jung von Matt AG > Glash?ttenstra?e 79 > 20357 Hamburg > > > Tel: +49 40-4321-1353 > Fax: +49 40-4321-1114 > E-Mail: > stephan.budach at jvm.de > > Internet: > http://www.jvm.com > > CiscoJabber Video: > https://exp-e2.jvm.de/call/stephan.budach > > > Vorstand: Dr. Peter Figge, Jean-Remy von Matt, Larissa Pohl, Thomas Strerath, G?tz Ulmer > Vorsitzender des Aufsichtsrates: Hans Hermann M?nchmeyer > AG HH HRB 72893 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From stephan.budach at jvm.de Wed Jan 25 18:43:47 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 25 Jan 2017 19:43:47 +0100 (CET) Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <6CAA70F1-E8B5-4C76-9F41-7EE20BC5A594@omniti.com> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <6CAA70F1-E8B5-4C76-9F41-7EE20BC5A594@omniti.com> Message-ID: <3A58D47B-A899-45A9-A0CF-0F383961CE61@jvm.de> Hi Dale, this is exactly, what I am currently trying and the iostat errors are from that import run. Stephan Von meinem iPhone gesendet > Am 25.01.2017 um 18:38 schrieb Dale Ghent : > > > Oh, ok, I misunderstood you as trying to import illumos vdevs directly onto a Oracle Solaris server. > > This line: > >>>> status: The pool was last accessed by another system. > > indicates that the zpool was uncleanly exported (or not exported at all) on the previous system it was imported on and the hostid of that system is still imprinted in the vdev labels for the zpool (not the hostid of the system you are trying to import on) > > Have you tried 'zpool import -f vsmPool10' ? > > /dale > >> On Jan 25, 2017, at 12:14 PM, Stephan Budach wrote: >> >> Hi Dale, >> >> I know that and it's not that I am trying to import a S11.1 zpool on omniOS or vice versa. It's that the targets are omniOS and the initiator is S11.1. I am still trying to import the zpool on S11.1. My question was more directed at COMSTAR, which both still should have some fair overlapping, no? >> >> I am in contact with Oracle and he mentioned some issues with zvols over iSCSI targets, which may be present for both systems, so I thought, that I'd give it a shot, that's all. >> >> Cheers >> Stephan >> >>> Am 25.01.17 um 18:07 schrieb Dale Ghent: >>> ZFS as implemented in Oracle Solaris is *not* OpenZFS, which is what illumos (and all illumos distros), FreeBSD, and the ZFS on Linux/macOS projects use. Up to a level of features, the two are compatible - but then they diverge in features. If one pool has features the zfs driver does not understand, you could run the risk of refusal to import as indicated here. >>> >>> Seeing as how Oracle itself does not include OpenZFS features in its ZFS implementation, and Oracle does not provide any information to OpenZFS regarding features it invents, this will unfortunately be the state of things unless Oracle changes its open source or information sharing policies. Unfortunate but that's just the way things are. >>> >>> /dale >>> >>> >>>> On Jan 25, 2017, at 8:54 AM, Stephan Budach >>>> wrote: >>>> >>>> Hi guys, >>>> >>>> I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. >>>> >>>> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. >>>> >>>> When issueing a zpool import, it says this: >>>> >>>> root at solaris11atest2:~# zpool import >>>> pool: vsmPool10 >>>> id: 12653649504720395171 >>>> state: DEGRADED >>>> status: The pool was last accessed by another system. >>>> action: The pool can be imported despite missing or damaged devices. The >>>> fault tolerance of the pool may be compromised if imported. >>>> see: >>>> http://support.oracle.com/msg/ZFS-8000-EY >>>> >>>> config: >>>> >>>> vsmPool10 DEGRADED >>>> mirror-0 DEGRADED >>>> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >>>> >>>> device details: >>>> >>>> c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed >>>> status: ZFS detected errors on this device. >>>> The device is missing some data that is recoverable. >>>> >>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed >>>> status: ZFS detected errors on this device. >>>> The device is missing some data that is recoverable. >>>> >>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed >>>> status: ZFS detected errors on this device. >>>> The device is missing some data that is recoverable. >>>> >>>> However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: >>>> >>>> root at solaris11atest2:~# iostat -xeM 5 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 >>>> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 >>>> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 >>>> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 >>>> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 >>>> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 >>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 >>>> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 >>>> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 >>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 >>>> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 >>>> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 >>>> >>>> >>>> I have tried pulling data from the LUNs using dd to /dev/null and I didn't get any h/w error, this just started, when trying to actually import the zpool. As the h/w errors are constantly rising, I am wondering what could cause this and if there can something be done about this? >>>> >>>> Cheers, >>>> Stephan >>>> _______________________________________________ >>>> OmniOS-discuss mailing list >>>> >>>> OmniOS-discuss at lists.omniti.com >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> -- >> Krebs's 3 Basic Rules for Online Safety >> 1st - "If you didn't go looking for it, don't install it!" >> 2nd - "If you installed it, update it." >> 3rd - "If you no longer need it, remove it." >> >> http://krebsonsecurity.com/2011/05/krebss-3-basic-rules-for-online-safety >> >> >> >> Stephan Budach >> Head of IT >> Jung von Matt AG >> Glash?ttenstra?e 79 >> 20357 Hamburg >> >> >> Tel: +49 40-4321-1353 >> Fax: +49 40-4321-1114 >> E-Mail: >> stephan.budach at jvm.de >> >> Internet: >> http://www.jvm.com >> >> CiscoJabber Video: >> https://exp-e2.jvm.de/call/stephan.budach >> >> >> Vorstand: Dr. Peter Figge, Jean-Remy von Matt, Larissa Pohl, Thomas Strerath, G?tz Ulmer >> Vorsitzender des Aufsichtsrates: Hans Hermann M?nchmeyer >> AG HH HRB 72893 >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From richard.elling at richardelling.com Wed Jan 25 19:27:05 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Wed, 25 Jan 2017 11:27:05 -0800 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> Message-ID: <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> Hi Stephan, > On Jan 25, 2017, at 5:54 AM, Stephan Budach wrote: > > Hi guys, > > I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. > > This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. > > When issueing a zpool import, it says this: > > root at solaris11atest2:~# zpool import > pool: vsmPool10 > id: 12653649504720395171 > state: DEGRADED > status: The pool was last accessed by another system. > action: The pool can be imported despite missing or damaged devices. The > fault tolerance of the pool may be compromised if imported. > see: http://support.oracle.com/msg/ZFS-8000-EY > config: > > vsmPool10 DEGRADED > mirror-0 DEGRADED > c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data > c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data > c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data > > device details: > > c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed > status: ZFS detected errors on this device. > The device is missing some data that is recoverable. > > c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed > status: ZFS detected errors on this device. > The device is missing some data that is recoverable. > > c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed > status: ZFS detected errors on this device. > The device is missing some data that is recoverable. > > However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: > > root at solaris11atest2:~# iostat -xeM 5 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 > sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 > sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 > sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 > sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 > sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 > sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 > sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 > sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 > sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 > extended device statistics ---- errors --- > device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot > sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 > sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 > sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 > sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 > sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 > sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 h/w errors are a classification of other errors. The full error list is available from "iostat -E" and will be important to tracking this down. A better, more detailed analysis can be gleaned from the "fmdump -e" ereports that should be associated with each h/w error. However, there are dozens of causes of these so we don?t have enough info here to fully understand. ? richard > > > I have tried pulling data from the LUNs using dd to /dev/null and I didn't get any h/w error, this just started, when trying to actually import the zpool. As the h/w errors are constantly rising, I am wondering what could cause this and if there can something be done about this? > > Cheers, > Stephan > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Wed Jan 25 20:43:39 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 25 Jan 2017 12:43:39 -0800 Subject: [OmniOS-discuss] libldap security update In-Reply-To: <43B413FD-D4B4-4A9D-ABAF-E1CE73076731@omniti.com> References: <43B413FD-D4B4-4A9D-ABAF-E1CE73076731@omniti.com> Message-ID: <143401d2774b$b57d3560$2077a020$@acm.org> > From: Dan McDonald > Sent: Tuesday, January 24, 2017 2:57 PM > > https://bugzilla.mozilla.org/show_bug.cgi?id=1310467 This bug isn't public yet, so referring to it isn't particularly useful :). > https://hg.mozilla.org/releases/comm- > aurora/rev/afcaac5233d09dd9b0d7235f9a408b581fda8b19 However, from the fix, it would appear this vulnerability only exists if you feed the LDAP library untrusted configuration data (such as an LDAP server URL), so presumably if you are only using the system LDAP libraries for internal purposes such as nsswitch naming services integration this would not be a critical update. Please correct me if the secret bug indicates otherwise :). Thanks. From danmcd at omniti.com Wed Jan 25 20:47:59 2017 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 25 Jan 2017 15:47:59 -0500 Subject: [OmniOS-discuss] libldap security update In-Reply-To: <143401d2774b$b57d3560$2077a020$@acm.org> References: <43B413FD-D4B4-4A9D-ABAF-E1CE73076731@omniti.com> <143401d2774b$b57d3560$2077a020$@acm.org> Message-ID: <919DDD53-FCBA-45D3-90DD-C498222A397C@omniti.com> > On Jan 25, 2017, at 3:43 PM, Paul B. Henson wrote: > > However, from the fix, it would appear this vulnerability only exists if you > feed the LDAP library untrusted configuration data (such as an LDAP server > URL), so presumably if you are only using the system LDAP libraries for > internal purposes such as nsswitch naming services integration this would > not be a critical update. Please correct me if the secret bug indicates > otherwise :). That sounds correct. The secret bug didn't have much else beyond embargo considerations, from what I remember seeing. Dan From stephan.budach at jvm.de Wed Jan 25 22:41:19 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Wed, 25 Jan 2017 23:41:19 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> Message-ID: Hi Richard, Am 25.01.17 um 20:27 schrieb Richard Elling: > Hi Stephan, > >> On Jan 25, 2017, at 5:54 AM, Stephan Budach > > wrote: >> >> Hi guys, >> >> I have been trying to import a zpool, based on a 3way-mirror provided >> by three omniOS boxes via iSCSI. This zpool had been working >> flawlessly until some random reboot of the S11.1 host. Since then, >> S11.1 has been importing this zpool without success. >> >> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? >> yeah I know, we shouldn't have done that in the first place, but >> performance was not the primary goal for that, as this one is a >> backup/archive pool. >> >> When issueing a zpool import, it says this: >> >> root at solaris11atest2:~# zpool import >> pool: vsmPool10 >> id: 12653649504720395171 >> state: DEGRADED >> status: The pool was last accessed by another system. >> action: The pool can be imported despite missing or damaged devices. The >> fault tolerance of the pool may be compromised if imported. >> see: http://support.oracle.com/msg/ZFS-8000-EY >> config: >> >> vsmPool10 DEGRADED >> mirror-0 DEGRADED >> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >> >> device details: >> >> c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver >> needed >> status: ZFS detected errors on this device. >> The device is missing some data that is recoverable. >> >> c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver >> needed >> status: ZFS detected errors on this device. >> The device is missing some data that is recoverable. >> >> c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver >> needed >> status: ZFS detected errors on this device. >> The device is missing some data that is recoverable. >> >> However, when actually running zpool import -f vsmPool10, the system >> starts to perform a lot of writes on the LUNs and iostat report an >> alarming increase in h/w errors: >> >> root at solaris11atest2:~# iostat -xeM 5 >> extended device statistics ---- >> errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >> trn tot >> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >> 0 0 >> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >> 0 0 >> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 >> 0 71 >> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >> 0 0 >> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >> 0 0 >> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >> 0 0 >> extended device statistics ---- >> errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >> trn tot >> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 >> 0 0 >> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 >> 0 0 >> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >> 0 92 >> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 >> 0 30 >> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 >> 0 40 >> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 >> 0 88 >> extended device statistics ---- >> errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >> trn tot >> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 >> 0 0 >> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >> 0 0 >> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >> 0 92 >> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 >> 0 235 >> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 >> 0 298 >> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 >> 0 406 >> extended device statistics ---- >> errors --- >> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >> trn tot >> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 >> 0 0 >> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >> 0 0 >> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >> 0 92 >> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 >> 0 384 >> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 >> 0 519 >> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 >> 0 727 > > h/w errors are a classification of other errors. The full error list > is available from "iostat -E" and will > be important to tracking this down. > > A better, more detailed analysis can be gleaned from the "fmdump -e" > ereports that should be > associated with each h/w error. However, there are dozens of causes of > these so we don?t have > enough info here to fully understand. > ? richard > Well? I can't provide you with the output of fmdump -e (since I am currently unable to get the '-' typed in to the console, due to some fancy keyboard layout issues and nit being able to login via ssh as well (can authenticate, but I don't get to the shell, which may be due to the running zpool import), but I can confirm that fmdump does show nothing at all. I could just reset the S11.1 host, after removing the zpool.cache file, such as that the system will not try to import the zpool upon restart right away? ?plus I might get the option to set the keyboard right, after reboot, but that's another issue? Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From stephan.budach at jvm.de Wed Jan 25 23:01:14 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 26 Jan 2017 00:01:14 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> Message-ID: Ooops? should have waited with sending that message after I rebootet the S11.1 host? Am 25.01.17 um 23:41 schrieb Stephan Budach: > Hi Richard, > > Am 25.01.17 um 20:27 schrieb Richard Elling: >> Hi Stephan, >> >>> On Jan 25, 2017, at 5:54 AM, Stephan Budach >> > wrote: >>> >>> Hi guys, >>> >>> I have been trying to import a zpool, based on a 3way-mirror >>> provided by three omniOS boxes via iSCSI. This zpool had been >>> working flawlessly until some random reboot of the S11.1 host. Since >>> then, S11.1 has been importing this zpool without success. >>> >>> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? >>> yeah I know, we shouldn't have done that in the first place, but >>> performance was not the primary goal for that, as this one is a >>> backup/archive pool. >>> >>> When issueing a zpool import, it says this: >>> >>> root at solaris11atest2:~# zpool import >>> pool: vsmPool10 >>> id: 12653649504720395171 >>> state: DEGRADED >>> status: The pool was last accessed by another system. >>> action: The pool can be imported despite missing or damaged >>> devices. The >>> fault tolerance of the pool may be compromised if imported. >>> see: http://support.oracle.com/msg/ZFS-8000-EY >>> config: >>> >>> vsmPool10 DEGRADED >>> mirror-0 DEGRADED >>> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >>> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >>> >>> device details: >>> >>> c0t600144F07A3506580000569398F60001d0 DEGRADED >>> scrub/resilver needed >>> status: ZFS detected errors on this device. >>> The device is missing some data that is recoverable. >>> >>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED >>> scrub/resilver needed >>> status: ZFS detected errors on this device. >>> The device is missing some data that is recoverable. >>> >>> c0t600144F07A35001A00005693A2810001d0 DEGRADED >>> scrub/resilver needed >>> status: ZFS detected errors on this device. >>> The device is missing some data that is recoverable. >>> >>> However, when actually running zpool import -f vsmPool10, the >>> system starts to perform a lot of writes on the LUNs and iostat >>> report an alarming increase in h/w errors: >>> >>> root at solaris11atest2:~# iostat -xeM 5 >>> extended device statistics ---- >>> errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>> trn tot >>> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >>> 0 0 >>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >>> 0 0 >>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 >>> 0 71 >>> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >>> 0 0 >>> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >>> 0 0 >>> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >>> 0 0 >>> extended device statistics ---- >>> errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>> trn tot >>> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 >>> 0 0 >>> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 >>> 0 0 >>> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >>> 0 92 >>> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 >>> 0 30 >>> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 >>> 0 40 >>> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 >>> 0 88 >>> extended device statistics ---- >>> errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>> trn tot >>> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 >>> 0 0 >>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >>> 0 0 >>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >>> 0 92 >>> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 >>> 0 235 >>> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 >>> 0 298 >>> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 >>> 0 406 >>> extended device statistics ---- >>> errors --- >>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>> trn tot >>> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 >>> 0 0 >>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 >>> 0 0 >>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >>> 0 92 >>> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 >>> 0 384 >>> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 >>> 0 519 >>> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 >>> 0 727 >> >> h/w errors are a classification of other errors. The full error list >> is available from "iostat -E" and will >> be important to tracking this down. >> >> A better, more detailed analysis can be gleaned from the "fmdump -e" >> ereports that should be >> associated with each h/w error. However, there are dozens of causes >> of these so we don?t have >> enough info here to fully understand. >> ? richard >> > Well? I can't provide you with the output of fmdump -e (since I am > currently unable to get the '-' typed in to the console, due to some > fancy keyboard layout issues and nit being able to login via ssh as > well (can authenticate, but I don't get to the shell, which may be due > to the running zpool import), but I can confirm that fmdump does show > nothing at all. I could just reset the S11.1 host, after removing the > zpool.cache file, such as that the system will not try to import the > zpool upon restart right away? > > ?plus I might get the option to set the keyboard right, after reboot, > but that's another issue? > After resetting the S11.1 host and getting the keyboard layout right, I issued a fmdump -e and there they are? lots of: Jan 25 23:25:13.5643 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.8944 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.8945 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.8946 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9274 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9275 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9276 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9277 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9282 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9284 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9285 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9286 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9287 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9288 ereport.fs.zfs.dev.merr.write Jan 25 23:25:13.9290 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9294 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9301 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:25:13.9306 ereport.io.scsi.cmd.disk.dev.rqs.merr.write Jan 25 23:50:44.7195 ereport.io.scsi.cmd.disk.dev.rqs.derr Jan 25 23:50:44.7306 ereport.io.scsi.cmd.disk.dev.rqs.derr Jan 25 23:50:44.7434 ereport.io.scsi.cmd.disk.dev.rqs.derr Jan 25 23:53:31.4386 ereport.io.scsi.cmd.disk.dev.rqs.derr Jan 25 23:53:31.4579 ereport.io.scsi.cmd.disk.dev.rqs.derr Jan 25 23:53:31.4710 ereport.io.scsi.cmd.disk.dev.rqs.derr These seem to be media errors and disk errors on the zpools/zvols that make up the LUNs for this zpool? I am wondering, why this happens. Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From richard.elling at richardelling.com Wed Jan 25 23:43:40 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Wed, 25 Jan 2017 15:43:40 -0800 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> Message-ID: <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> more below? > On Jan 25, 2017, at 3:01 PM, Stephan Budach wrote: > > Ooops? should have waited with sending that message after I rebootet the S11.1 host? > > > Am 25.01.17 um 23:41 schrieb Stephan Budach: >> Hi Richard, >> >> Am 25.01.17 um 20:27 schrieb Richard Elling: >>> Hi Stephan, >>> >>>> On Jan 25, 2017, at 5:54 AM, Stephan Budach > wrote: >>>> >>>> Hi guys, >>>> >>>> I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. >>>> >>>> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. >>>> >>>> When issueing a zpool import, it says this: >>>> >>>> root at solaris11atest2:~# zpool import >>>> pool: vsmPool10 >>>> id: 12653649504720395171 >>>> state: DEGRADED >>>> status: The pool was last accessed by another system. >>>> action: The pool can be imported despite missing or damaged devices. The >>>> fault tolerance of the pool may be compromised if imported. >>>> see: http://support.oracle.com/msg/ZFS-8000-EY >>>> config: >>>> >>>> vsmPool10 DEGRADED >>>> mirror-0 DEGRADED >>>> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >>>> >>>> device details: >>>> >>>> c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed >>>> status: ZFS detected errors on this device. >>>> The device is missing some data that is recoverable. >>>> >>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed >>>> status: ZFS detected errors on this device. >>>> The device is missing some data that is recoverable. >>>> >>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed >>>> status: ZFS detected errors on this device. >>>> The device is missing some data that is recoverable. >>>> >>>> However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: >>>> >>>> root at solaris11atest2:~# iostat -xeM 5 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 >>>> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 >>>> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 >>>> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 >>>> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 >>>> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 >>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 >>>> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 >>>> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 >>>> extended device statistics ---- errors --- >>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 >>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 >>>> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 >>>> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 >>> >>> h/w errors are a classification of other errors. The full error list is available from "iostat -E" and will >>> be important to tracking this down. >>> >>> A better, more detailed analysis can be gleaned from the "fmdump -e" ereports that should be >>> associated with each h/w error. However, there are dozens of causes of these so we don?t have >>> enough info here to fully understand. >>> ? richard >>> >> Well? I can't provide you with the output of fmdump -e (since I am currently unable to get the '-' typed in to the console, due to some fancy keyboard layout issues and nit being able to login via ssh as well (can authenticate, but I don't get to the shell, which may be due to the running zpool import), but I can confirm that fmdump does show nothing at all. I could just reset the S11.1 host, after removing the zpool.cache file, such as that the system will not try to import the zpool upon restart right away? >> >> ?plus I might get the option to set the keyboard right, after reboot, but that's another issue? >> > After resetting the S11.1 host and getting the keyboard layout right, I issued a fmdump -e and there they are? lots of: > > Jan 25 23:25:13.5643 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.8944 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.8945 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.8946 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9274 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9275 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9276 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9277 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9282 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9284 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9285 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9286 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9287 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9288 ereport.fs.zfs.dev.merr.write > Jan 25 23:25:13.9290 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9294 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9301 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:25:13.9306 ereport.io.scsi.cmd.disk.dev.rqs.merr.write > Jan 25 23:50:44.7195 ereport.io.scsi.cmd.disk.dev.rqs.derr > Jan 25 23:50:44.7306 ereport.io.scsi.cmd.disk.dev.rqs.derr > Jan 25 23:50:44.7434 ereport.io.scsi.cmd.disk.dev.rqs.derr > Jan 25 23:53:31.4386 ereport.io.scsi.cmd.disk.dev.rqs.derr > Jan 25 23:53:31.4579 ereport.io.scsi.cmd.disk.dev.rqs.derr > Jan 25 23:53:31.4710 ereport.io.scsi.cmd.disk.dev.rqs.derr > > > These seem to be media errors and disk errors on the zpools/zvols that make up the LUNs for this zpool? I am wondering, why this happens. yes, good question That we get media errors "merr" on write is one clue. To find out more details, "fmdump -eV" will show in gory details the exact SCSI asc/ascq codes, LBAs, etc. ZFS is COW, so if the LUs are backed by ZFS and there isn?t enough free space, then this is the sort of error we expect. But there could be other reasons. ? richard > > Stephan > _______________________________________________ > 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 Thu Jan 26 02:51:43 2017 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 25 Jan 2017 20:51:43 -0600 (CST) Subject: [OmniOS-discuss] OmniOS ntpd multicast client oddity In-Reply-To: <90C1E228-EED5-4E2A-868A-BFAB1D8AF501@omniti.com> References: <90C1E228-EED5-4E2A-868A-BFAB1D8AF501@omniti.com> Message-ID: On Wed, 25 Jan 2017, Dan McDonald wrote: > I noticed you don't have "-n" on your first batch of output. Probably a nit, though. > > What version(s) of NTP are you running? 020 ships 4.2.8p9 (all OmniOS supported releases use this version, BTW) with some patches shown here: > > https://github.com/omniti-labs/omnios-build/tree/r151020/build/ntp/patches > > Are S10 and OI running the same version? With or without patches? Working Multicast Clients ------------------------- S10 (AMD-64): 4.2.5p172 OI: 4.2.7p411 Working Unicast Clients (same two servers) ----------------------- Ubuntu 16.04: 4.2.8p4 Multicast Servers ----------------- S10 (SPARC): 4.2.5p172 OmniOS r151020: 4.2.8p9 Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From stephan.budach at jvm.de Thu Jan 26 08:20:20 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 26 Jan 2017 09:20:20 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> Message-ID: <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> Hi Richard, gotcha? read on, below? Am 26.01.17 um 00:43 schrieb Richard Elling: > more below? > >> On Jan 25, 2017, at 3:01 PM, Stephan Budach > > wrote: >> >> Ooops? should have waited with sending that message after I rebootet >> the S11.1 host? >> >> >> Am 25.01.17 um 23:41 schrieb Stephan Budach: >>> Hi Richard, >>> >>> Am 25.01.17 um 20:27 schrieb Richard Elling: >>>> Hi Stephan, >>>> >>>>> On Jan 25, 2017, at 5:54 AM, Stephan Budach >>>> > wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> I have been trying to import a zpool, based on a 3way-mirror >>>>> provided by three omniOS boxes via iSCSI. This zpool had been >>>>> working flawlessly until some random reboot of the S11.1 host. >>>>> Since then, S11.1 has been importing this zpool without success. >>>>> >>>>> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? >>>>> yeah I know, we shouldn't have done that in the first place, but >>>>> performance was not the primary goal for that, as this one is a >>>>> backup/archive pool. >>>>> >>>>> When issueing a zpool import, it says this: >>>>> >>>>> root at solaris11atest2:~# zpool import >>>>> pool: vsmPool10 >>>>> id: 12653649504720395171 >>>>> state: DEGRADED >>>>> status: The pool was last accessed by another system. >>>>> action: The pool can be imported despite missing or damaged >>>>> devices. The >>>>> fault tolerance of the pool may be compromised if imported. >>>>> see: http://support.oracle.com/msg/ZFS-8000-EY >>>>> config: >>>>> >>>>> vsmPool10 DEGRADED >>>>> mirror-0 DEGRADED >>>>> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >>>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >>>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >>>>> >>>>> device details: >>>>> >>>>> c0t600144F07A3506580000569398F60001d0 DEGRADED >>>>> scrub/resilver needed >>>>> status: ZFS detected errors on this device. >>>>> The device is missing some data that is recoverable. >>>>> >>>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED >>>>> scrub/resilver needed >>>>> status: ZFS detected errors on this device. >>>>> The device is missing some data that is recoverable. >>>>> >>>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED >>>>> scrub/resilver needed >>>>> status: ZFS detected errors on this device. >>>>> The device is missing some data that is recoverable. >>>>> >>>>> However, when actually running zpool import -f vsmPool10, the >>>>> system starts to perform a lot of writes on the LUNs and iostat >>>>> report an alarming increase in h/w errors: >>>>> >>>>> root at solaris11atest2:~# iostat -xeM 5 >>>>> extended device statistics ---- errors --- >>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>>>> trn tot >>>>> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 >>>>> 0 71 >>>>> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>> extended device statistics ---- errors --- >>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>>>> trn tot >>>>> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 >>>>> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 >>>>> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >>>>> 0 92 >>>>> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 >>>>> 0 30 >>>>> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 >>>>> 0 40 >>>>> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 >>>>> 0 88 >>>>> extended device statistics ---- errors --- >>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>>>> trn tot >>>>> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 >>>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >>>>> 0 92 >>>>> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 >>>>> 0 235 >>>>> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 >>>>> 0 298 >>>>> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 >>>>> 0 406 >>>>> extended device statistics ---- errors --- >>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w >>>>> trn tot >>>>> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 >>>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 >>>>> 0 92 >>>>> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 >>>>> 0 384 >>>>> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 >>>>> 0 519 >>>>> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 >>>>> 0 727 >>>> >>>> h/w errors are a classification of other errors. The full error >>>> list is available from "iostat -E" and will >>>> be important to tracking this down. >>>> >>>> A better, more detailed analysis can be gleaned from the "fmdump >>>> -e" ereports that should be >>>> associated with each h/w error. However, there are dozens of causes >>>> of these so we don?t have >>>> enough info here to fully understand. >>>> ? richard >>>> >>> Well? I can't provide you with the output of fmdump -e (since I am >>> currently unable to get the '-' typed in to the console, due to some >>> fancy keyboard layout issues and nit being able to login via ssh as >>> well (can authenticate, but I don't get to the shell, which may be >>> due to the running zpool import), but I can confirm that fmdump does >>> show nothing at all. I could just reset the S11.1 host, after >>> removing the zpool.cache file, such as that the system will not try >>> to import the zpool upon restart right away? >>> >>> ?plus I might get the option to set the keyboard right, after >>> reboot, but that's another issue? >>> >> After resetting the S11.1 host and getting the keyboard layout right, >> I issued a fmdump -e and there they are? lots of: >> >> Jan 25 23:25:13.5643 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.8944 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.8945 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.8946 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9274 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9275 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9276 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9277 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9282 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9284 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9285 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9286 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9287 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9288 ereport.fs.zfs.dev.merr.write >> Jan 25 23:25:13.9290 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9294 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9301 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:25:13.9306 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >> Jan 25 23:50:44.7195 ereport.io.scsi.cmd.disk.dev.rqs.derr >> Jan 25 23:50:44.7306 ereport.io.scsi.cmd.disk.dev.rqs.derr >> Jan 25 23:50:44.7434 ereport.io.scsi.cmd.disk.dev.rqs.derr >> Jan 25 23:53:31.4386 ereport.io.scsi.cmd.disk.dev.rqs.derr >> Jan 25 23:53:31.4579 ereport.io.scsi.cmd.disk.dev.rqs.derr >> Jan 25 23:53:31.4710 ereport.io.scsi.cmd.disk.dev.rqs.derr >> >> >> These seem to be media errors and disk errors on the zpools/zvols >> that make up the LUNs for this zpool? I am wondering, why this happens. > > yes, good question > That we get media errors "merr" on write is one clue. To find out more > details, "fmdump -eV" > will show in gory details the exact SCSI asc/ascq codes, LBAs, etc. > > ZFS is COW, so if the LUs are backed by ZFS and there isn?t enough > free space, then this is > the sort of error we expect. But there could be other reasons. > ? richard > Oh Lord? I really think, that this is it? this is what the zpool/zvol looks like on one of the three targets: root at tr1206900:/root# zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT rpool 29,8G 21,5G 8,27G - 45% 72% 1.00x ONLINE - tr1206900data 109T 106T 3,41T - 51% 96% 1.00x ONLINE - root at tr1206900:/root# zfs list -r tr1206900data NAME USED AVAIL REFER MOUNTPOINT tr1206900data 86,6T 0 236K /tr1206900data tr1206900data/vsmPool10 86,6T 0 86,6T - root at tr1206900:/root# zfs get all tr1206900data/vsmPool10 NAME PROPERTY VALUE SOURCE tr1206900data/vsmPool10 type volume - tr1206900data/vsmPool10 creation Mo. Jan 11 12:57 2016 - tr1206900data/vsmPool10 used 86,6T - tr1206900data/vsmPool10 available 0 - tr1206900data/vsmPool10 referenced 86,6T - tr1206900data/vsmPool10 compressratio 1.00x - tr1206900data/vsmPool10 reservation none default tr1206900data/vsmPool10 volsize 109T local tr1206900data/vsmPool10 volblocksize 128K - tr1206900data/vsmPool10 checksum on default tr1206900data/vsmPool10 compression off default tr1206900data/vsmPool10 readonly off default tr1206900data/vsmPool10 copies 1 default tr1206900data/vsmPool10 refreservation none default tr1206900data/vsmPool10 primarycache all local tr1206900data/vsmPool10 secondarycache all default tr1206900data/vsmPool10 usedbysnapshots 0 - tr1206900data/vsmPool10 usedbydataset 86,6T - tr1206900data/vsmPool10 usedbychildren 0 - tr1206900data/vsmPool10 usedbyrefreservation 0 - tr1206900data/vsmPool10 logbias latency default tr1206900data/vsmPool10 dedup off default tr1206900data/vsmPool10 mlslabel none default tr1206900data/vsmPool10 sync standard default tr1206900data/vsmPool10 refcompressratio 1.00x - tr1206900data/vsmPool10 written 86,6T - tr1206900data/vsmPool10 logicalused 86,5T - tr1206900data/vsmPool10 logicalreferenced 86,5T - tr1206900data/vsmPool10 snapshot_limit none default tr1206900data/vsmPool10 snapshot_count none default tr1206900data/vsmPool10 redundant_metadata all default This must be the dumbest failure one can possibly have, when setting up a zvol iSCSI target. So, someone - no, it wasn't me, actually, but this doesn't do me any good anyway, created a zvol equal the size to the zpool and now it is as you suspected: the zvol has run out of space. So, the only chance would be to add additional space to these zpools, such as that the zvol actually can occupy the space the claim to have? Should be manageable? I could provide some iSCSI LUNs to the targets themselves and add another vdev. There will be some serious cleanup needed afterwards? What about the "free" 3,41T in zpool itself? Could those be somehow utilised? Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From stephan.budach at jvm.de Thu Jan 26 10:24:53 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 26 Jan 2017 11:24:53 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> Message-ID: <18989ef6-32ef-e97a-339a-53a537703468@jvm.de> Just for sanity? these are a couple of errors fmdump outputs using -eV root at solaris11atest2:~# fmdump -eV TIME CLASS Jan 25 2017 10:10:45.011761190 ereport.io.pciex.rc.tmp nvlist version: 0 class = ereport.io.pciex.rc.tmp ena = 0xff37bc9a8600001 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev device-path = /intel-iommu at 0,fbffe000 (end detector) epkt_ver = 0x1 desc = 0x21152014 size = 0x0 addr = 0xca000 hdr1 = 0x6000000000d70000 hdr2 = 0x32800000000000 reserved = 0x10000 count = 0x1 total = 0x1 event_name = The Write field in a page-table entry is Clear when DMA write VID = 0x8086 DID = 0x0 RID = 0x0 SID = 0x0 SVID = 0x0 reg_ver = 0x1 platform-specific = (embedded nvlist) nvlist version: 0 VER_REG = 0x10 CAP_REG = 0x106f0462 ECAP_REG = 0xf020fe GCMD_REG = 0x86800000 GSTS_REG = 0xc7800000 FSTS_REG = 0x100 FECTL_REG = 0x0 FEDATA_REG = 0xf2 FEADDR_REG = 0xfee00000 FEUADDR_REG = 0x0 FRCD_REG_LOW = 0xca000 FRCD_REG_HIGH = 0x80000005000000d7 PMEN_REG = 0x64 PLMBASE_REG = 0x68 PLMLIMIT_REG = 0x6c PHMBASE_REG = 0x70 PHMLIMIT_REG = 0x78 (end platform-specific) __ttl = 0x1 __tod = 0x58886b95 0xb37626 Jan 25 2017 12:28:55.712580014 ereport.io.scsi.cmd.disk.dev.rqs.derr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.rqs.derr ena = 0x88985751a4a02c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a0000001f device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206900:vsmpool100002,0 (end detector) devid = unknown driver-assessment = info op-code = 0x15 cdb = 0x15 0x10 0x0 0x0 0x18 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 key = 0x5 asc = 0x1a ascq = 0x0 sense-data = 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x1a 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888bf7 0x2a791bae Jan 25 2017 12:32:35.072413593 ereport.io.scsi.cmd.disk.dev.rqs.derr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.rqs.derr ena = 0x8bc98528b5c00801 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000024 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 (end detector) devid = unknown driver-assessment = info op-code = 0x15 cdb = 0x15 0x10 0x0 0x0 0x18 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 key = 0x5 asc = 0x1a ascq = 0x0 sense-data = 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x1a 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888cd3 0x450f199 Jan 25 2017 12:32:52.661439798 ereport.io.scsi.cmd.disk.dev.rqs.derr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.rqs.derr ena = 0x8c0b0b5c71e00401 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206902:vsmpool100002,0 (end detector) devid = unknown driver-assessment = info op-code = 0x15 cdb = 0x15 0x10 0x0 0x0 0x18 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 key = 0x5 asc = 0x1a ascq = 0x0 sense-data = 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x1a 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888ce4 0x276cc536 Jan 25 2017 12:35:48.187562523 ereport.io.scsi.cmd.disk.dev.uderr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.uderr ena = 0x8e98ee1dd5c00401 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a0000002e device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206902:vsmpool100002,0 devid = id1,sd at n600144f07a35001a00005693a2810001 (end detector) devid = id1,sd at n600144f07a35001a00005693a2810001 driver-assessment = retry op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x21 0x7f 0x0 0x0 0x0 0x1 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 un-decode-info = invalid-sense-data un-decode-value = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888d94 0xb2dfa1b Jan 25 2017 12:35:48.188103577 ereport.io.scsi.cmd.disk.dev.rqs.merr.write nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.rqs.merr.write ena = 0x8e98ee1dd5c00405 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a0000002e device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206902:vsmpool100002,0 devid = id1,sd at n600144f07a35001a00005693a2810001 (end detector) devid = id1,sd at n600144f07a35001a00005693a2810001 driver-assessment = fault op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x21 0x7f 0x0 0x0 0x0 0x1 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 key = 0x3 asc = 0xc ascq = 0x0 sense-data = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 lba = 0x2b8000217f __ttl = 0x1 __tod = 0x58888d94 0xb363b99 Jan 25 2017 12:35:48.188181359 ereport.fs.zfs.dev.merr.write nvlist version: 0 class = ereport.fs.zfs.dev.merr.write ena = 0x8e98eeb4d1203c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev device-path = /scsi_vhci/disk at g600144f07a35001a00005693a2810001:a devid = id1,sd at n600144f07a35001a00005693a2810001 (end detector) pool = vsmPool10 pool_guid = 0xaf9acb2ec1281ba3 pool_context = 2 pool_failmode = wait vdev_guid = 0xcdb535ed2f9dc575 vdev_type = disk vdev_path = /dev/dsk/c0t600144F07A35001A00005693A2810001d0s0 vdev_devid = id1,sd at n600144f07a35001a00005693a2810001/a parent_guid = 0xd69b0e8882d06eb1 parent_type = mirror zio_err = 5 zio_txg = 0x5a7fce zio_offset = 0x57000040fe00 zio_size = 0x200 zfs-lba = 0x2b8000207f zio_objset = 0x0 zio_object = 0x43 zio_level = 0 zio_blkid = 0x0 fs-assessment = fault final-diagnostics = 66 __ttl = 0x1 __tod = 0x58888d94 0xb376b6f Jan 25 2017 12:35:48.299270091 ereport.io.scsi.cmd.disk.dev.uderr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.uderr ena = 0x8e9958a635601c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) devid = id1,sd at n600144f07a35066c00005693a0d90001 driver-assessment = retry op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x2a 0xb8 0x0 0x0 0x0 0x20 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 un-decode-info = invalid-sense-data un-decode-value = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888d94 0x11d67fcb Jan 25 2017 12:35:48.299321501 ereport.io.scsi.cmd.disk.dev.uderr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.uderr ena = 0x8e9958b29a601c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) devid = id1,sd at n600144f07a35066c00005693a0d90001 driver-assessment = retry op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x22 0x52 0x0 0x0 0x0 0x6 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 un-decode-info = invalid-sense-data un-decode-value = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888d94 0x11d7489d Jan 25 2017 12:35:48.299367233 ereport.io.scsi.cmd.disk.dev.uderr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.uderr ena = 0x8e9958bdfa201c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) devid = id1,sd at n600144f07a35066c00005693a0d90001 driver-assessment = retry op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x22 0x58 0x0 0x0 0x0 0x4 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 un-decode-info = invalid-sense-data un-decode-value = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888d94 0x11d7fb41 Jan 25 2017 12:35:48.299379663 ereport.io.scsi.cmd.disk.dev.uderr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.uderr ena = 0x8e9958c0e9a01c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) devid = id1,sd at n600144f07a35066c00005693a0d90001 driver-assessment = retry op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x27 0x5e 0x0 0x0 0x0 0x20 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 un-decode-info = invalid-sense-data un-decode-value = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888d94 0x11d82bcf Jan 25 2017 12:35:48.299437766 ereport.io.scsi.cmd.disk.dev.uderr nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.uderr ena = 0x8e9958cf11c01c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) devid = id1,sd at n600144f07a35066c00005693a0d90001 driver-assessment = retry op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x26 0xc3 0x0 0x0 0x0 0x1b 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 un-decode-info = invalid-sense-data un-decode-value = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 __ttl = 0x1 __tod = 0x58888d94 0x11d90ec6 Jan 25 2017 12:35:48.299676092 ereport.io.scsi.cmd.disk.dev.rqs.merr.write nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.rqs.merr.write ena = 0x8e9958a635601c05 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) devid = id1,sd at n600144f07a35066c00005693a0d90001 driver-assessment = fault op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x2a 0xb8 0x0 0x0 0x0 0x20 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 key = 0x3 asc = 0xc ascq = 0x0 sense-data = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 lba = 0x2b80002ab8 __ttl = 0x1 __tod = 0x58888d94 0x11dcb1bc Jan 25 2017 12:35:48.188181570 ereport.fs.zfs.dev.merr.write nvlist version: 0 class = ereport.fs.zfs.dev.merr.write ena = 0x8e98eeb4d1203c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev device-path = /scsi_vhci/disk at g600144f07a35066c00005693a0d90001:a devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) pool = vsmPool10 pool_guid = 0xaf9acb2ec1281ba3 pool_context = 2 pool_failmode = wait vdev_guid = 0xbfd955c4da17b8d6 vdev_type = disk vdev_path = /dev/dsk/c0t600144F07A35066C00005693A0D90001d0s0 vdev_devid = id1,sd at n600144f07a35066c00005693a0d90001/a parent_guid = 0xd69b0e8882d06eb1 parent_type = mirror zio_err = 5 zio_txg = 0x5a7fce zio_offset = 0x570000537000 zio_size = 0x4000 zfs-lba = 0x2b800029b8 zio_objset = 0x0 zio_object = 0x0 zio_level = 1 zio_blkid = 0x0 fs-assessment = fault final-diagnostics = 66 __ttl = 0x1 __tod = 0x58888d94 0xb376c42 Jan 25 2017 12:35:48.299882294 ereport.io.scsi.cmd.disk.dev.rqs.merr.write nvlist version: 0 class = ereport.io.scsi.cmd.disk.dev.rqs.merr.write ena = 0x8e9958b29a601c05 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev cna_dev = 0x5888879a00000029 device-path = /iscsi/disk at 0000iqn.2016-01.de.jvm.tr1206901:vsmpool100002,0 devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) devid = id1,sd at n600144f07a35066c00005693a0d90001 driver-assessment = fault op-code = 0x8a cdb = 0x8a 0x0 0x0 0x0 0x0 0x2b 0x80 0x0 0x22 0x52 0x0 0x0 0x0 0x6 0x0 0x0 pkt-reason = 0x0 pkt-state = 0x3f pkt-stats = 0x0 stat-code = 0x2 key = 0x3 asc = 0xc ascq = 0x0 sense-data = 0x70 0x0 0x3 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 lba = 0x2b80002252 __ttl = 0x1 __tod = 0x58888d94 0x11dfd736 Jan 25 2017 12:35:48.188181617 ereport.fs.zfs.dev.merr.write nvlist version: 0 class = ereport.fs.zfs.dev.merr.write ena = 0x8e98eeb4d1203c01 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = dev device-path = /scsi_vhci/disk at g600144f07a35066c00005693a0d90001:a devid = id1,sd at n600144f07a35066c00005693a0d90001 (end detector) pool = vsmPool10 pool_guid = 0xaf9acb2ec1281ba3 pool_context = 2 pool_failmode = wait vdev_guid = 0xbfd955c4da17b8d6 vdev_type = disk vdev_path = /dev/dsk/c0t600144F07A35066C00005693A0D90001d0s0 vdev_devid = id1,sd at n600144f07a35066c00005693a0d90001/a parent_guid = 0xd69b0e8882d06eb1 parent_type = mirror zio_err = 5 zio_txg = 0x5a7fce zio_offset = 0x57000042a400 zio_size = 0xc00 zfs-lba = 0x2b80002152 zio_objset = 0x0 zio_object = 0x1 zio_level = 0 zio_blkid = 0x1 fs-assessment = fault final-diagnostics = 66 __ttl = 0x1 __tod = 0x58888d94 0xb376c71 Regards, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From fabio at fabiorabelo.wiki.br Thu Jan 26 10:52:49 2017 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Thu, 26 Jan 2017 08:52:49 -0200 Subject: [OmniOS-discuss] Install on Supermicro DOM=low space left Message-ID: Hi to all I've just installed OmniOS on a Supermicro Motherboard with a DOM device for boot . It is working fine, no issues ... But, the 64GB DOM has just 9GB of space left Can I delete something ( temp files, compacted installed packages, etc ) to free some space ? I thing this 9GB free space may become an issue in the future . Thanks in advance for any help ... F?bio Rabelo From vab at bb-c.de Thu Jan 26 11:06:06 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 26 Jan 2017 12:06:06 +0100 Subject: [OmniOS-discuss] Install on Supermicro DOM=low space left In-Reply-To: References: Message-ID: <22665.55326.378723.508075@shelob.bb-c.de> Hi F?bio! > I've just installed OmniOS on a Supermicro Motherboard with a DOM > device for boot . > > It is working fine, no issues ... > > But, the 64GB DOM has just 9GB of space left > > Can I delete something ( temp files, compacted installed packages, etc > ) to free some space ? You might have oversized swap and/or dump volumes. Do a zfs list -t volume What volume sizes are shown? Regarsd -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From fabio at fabiorabelo.wiki.br Thu Jan 26 11:22:49 2017 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Thu, 26 Jan 2017 09:22:49 -0200 Subject: [OmniOS-discuss] Fwd: Install on Supermicro DOM=low space left In-Reply-To: References: <22665.55326.378723.508075@shelob.bb-c.de> Message-ID: sorry, I forgot to change address to all list before send ... ---------- Forwarded message ---------- From: F?bio Rabelo Date: 2017-01-26 9:21 GMT-02:00 Subject: Re: [OmniOS-discuss] Install on Supermicro DOM=low space left To: "Volker A. Brandt" 2017-01-26 9:06 GMT-02:00 Volker A. Brandt : > Hi F?bio! > > >> I've just installed OmniOS on a Supermicro Motherboard with a DOM >> device for boot . >> >> It is working fine, no issues ... >> >> But, the 64GB DOM has just 9GB of space left >> >> Can I delete something ( temp files, compacted installed packages, etc >> ) to free some space ? > > You might have oversized swap and/or dump volumes. Do a > > zfs list -t volume > > What volume sizes are shown NAME USED AVAIL REFER MOUNTPOINT rpool/dump 41.5G 9.15G 41.5G - rpool/swap 4.13G 13.0G 276M - I did not changed anything during instalation proccess, I've just accepted all defaults F?bio Rabelo From stephan.budach at jvm.de Thu Jan 26 11:24:53 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 26 Jan 2017 12:24:53 +0100 Subject: [OmniOS-discuss] Install on Supermicro DOM=low space left In-Reply-To: <22665.55326.378723.508075@shelob.bb-c.de> References: <22665.55326.378723.508075@shelob.bb-c.de> Message-ID: <62a05ae7-4423-a3db-581d-e1559d36c095@jvm.de> Hi, Am 26.01.17 um 12:06 schrieb Volker A. Brandt: > Hi F?bio! > > >> I've just installed OmniOS on a Supermicro Motherboard with a DOM >> device for boot . >> >> It is working fine, no issues ... >> >> But, the 64GB DOM has just 9GB of space left >> >> Can I delete something ( temp files, compacted installed packages, etc >> ) to free some space ? > You might have oversized swap and/or dump volumes. Do a > > zfs list -t volume > > What volume sizes are shown? > > > Regarsd -- Volker ?it's the dump volume, that's for sure. I always have to mess around with it, after installing omniOS on a DOM, what is way smaller than the physical RAM size? Thank god, it's an easy task. ;) Cheers, Stephan ?on the other hand? 9GB is probably more then enough for a regular use, anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From vab at bb-c.de Thu Jan 26 11:38:27 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Thu, 26 Jan 2017 12:38:27 +0100 Subject: [OmniOS-discuss] Fwd: Install on Supermicro DOM=low space left In-Reply-To: References: <22665.55326.378723.508075@shelob.bb-c.de> Message-ID: <22665.57267.919068.568577@shelob.bb-c.de> > NAME USED AVAIL REFER MOUNTPOINT > rpool/dump 41.5G 9.15G 41.5G - > rpool/swap 4.13G 13.0G 276M - The "dump" volume is much too big. Do a dumpadm -e This will print the "estimated" dump size. Then add a bit, and set the new dump volume size with: zfs set volsize= rpool/dump For example, on my OmniOS file server: # dumpadm -e Estimated dump size: 4.63G # zfs set volsize=6G rpool/dump # zfs list rpool/dump NAME USED AVAIL REFER MOUNTPOINT rpool/dump 6.00G 24.1G 6.00G - > I did not changed anything during instalation proccess, I've just > accepted all defaults Yes. The "traditional" installation usually sizes dump too big. That is why I asked. :-) Hope this helps -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From stephan.budach at jvm.de Thu Jan 26 11:40:28 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Thu, 26 Jan 2017 12:40:28 +0100 Subject: [OmniOS-discuss] Fwd: Install on Supermicro DOM=low space left In-Reply-To: References: <22665.55326.378723.508075@shelob.bb-c.de> Message-ID: <3ca3c14a-9f18-89f9-77dd-ca31cc715789@jvm.de> Hi F?bio, Am 26.01.17 um 12:22 schrieb F?bio Rabelo: > sorry, I forgot to change address to all list before send ... > > ---------- Forwarded message ---------- > From: F?bio Rabelo > Date: 2017-01-26 9:21 GMT-02:00 > Subject: Re: [OmniOS-discuss] Install on Supermicro DOM=low space left > To: "Volker A. Brandt" > > > 2017-01-26 9:06 GMT-02:00 Volker A. Brandt : >> Hi F?bio! >> >> >>> I've just installed OmniOS on a Supermicro Motherboard with a DOM >>> device for boot . >>> >>> It is working fine, no issues ... >>> >>> But, the 64GB DOM has just 9GB of space left >>> >>> Can I delete something ( temp files, compacted installed packages, etc >>> ) to free some space ? >> You might have oversized swap and/or dump volumes. Do a >> >> zfs list -t volume >> >> What volume sizes are shown > NAME USED AVAIL REFER MOUNTPOINT > rpool/dump 41.5G 9.15G 41.5G - > rpool/swap 4.13G 13.0G 276M - > > I did not changed anything during instalation proccess, I've just > accepted all defaults > > If you still want to change the size of the dump volume: zfs set volsize=16g rpool/dump The size depends of course on the estimated size of a core dump, but 16G should ne way over the top. Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From davide.poletto at gmail.com Thu Jan 26 11:41:24 2017 From: davide.poletto at gmail.com (Davide Poletto) Date: Thu, 26 Jan 2017 12:41:24 +0100 Subject: [OmniOS-discuss] Fwd: Install on Supermicro DOM=low space left In-Reply-To: References: <22665.55326.378723.508075@shelob.bb-c.de> Message-ID: I recall an interesting post by Chris Siebenmann about dump/swap sizes (surprise) on OmniOS, here it is (the only one comment at time was mine :-) ): https://utcc.utoronto.ca/~cks/space/blog/solaris/OmniOSDiskSizing?showcomments#comments Cheers, Davide On Thu, Jan 26, 2017 at 12:22 PM, F?bio Rabelo wrote: > sorry, I forgot to change address to all list before send ... > > ---------- Forwarded message ---------- > From: F?bio Rabelo > Date: 2017-01-26 9:21 GMT-02:00 > Subject: Re: [OmniOS-discuss] Install on Supermicro DOM=low space left > To: "Volker A. Brandt" > > > 2017-01-26 9:06 GMT-02:00 Volker A. Brandt : > > Hi F?bio! > > > > > >> I've just installed OmniOS on a Supermicro Motherboard with a DOM > >> device for boot . > >> > >> It is working fine, no issues ... > >> > >> But, the 64GB DOM has just 9GB of space left > >> > >> Can I delete something ( temp files, compacted installed packages, etc > >> ) to free some space ? > > > > You might have oversized swap and/or dump volumes. Do a > > > > zfs list -t volume > > > > What volume sizes are shown > > NAME USED AVAIL REFER MOUNTPOINT > rpool/dump 41.5G 9.15G 41.5G - > rpool/swap 4.13G 13.0G 276M - > > I did not changed anything during instalation proccess, I've just > accepted all defaults > > > F?bio Rabelo > _______________________________________________ > 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 Thu Jan 26 14:12:28 2017 From: lists at marzocchi.net (Olaf Marzocchi) Date: Thu, 26 Jan 2017 15:12:28 +0100 Subject: [OmniOS-discuss] Fwd: Install on Supermicro DOM=low space left In-Reply-To: <22665.57267.919068.568577@shelob.bb-c.de> References: <22665.55326.378723.508075@shelob.bb-c.de> <22665.57267.919068.568577@shelob.bb-c.de> Message-ID: <4ECFFE87-89D1-46C9-905B-8C93586FA02D@marzocchi.net> But dumps can also be saved as files on a normal dataset, right? provided enough space is left for them. Olaf Il 26 gennaio 2017 12:38:27 CET, vab at bb-c.de ha scritto: >> NAME USED AVAIL REFER MOUNTPOINT >> rpool/dump 41.5G 9.15G 41.5G - >> rpool/swap 4.13G 13.0G 276M - > >The "dump" volume is much too big. Do a > > dumpadm -e > >This will print the "estimated" dump size. Then add a bit, and >set the new dump volume size with: > > zfs set volsize= rpool/dump > >For example, on my OmniOS file server: > ># dumpadm -e >Estimated dump size: 4.63G > ># zfs set volsize=6G rpool/dump > ># zfs list rpool/dump >NAME USED AVAIL REFER MOUNTPOINT >rpool/dump 6.00G 24.1G 6.00G - > >> I did not changed anything during instalation proccess, I've just >> accepted all defaults > >Yes. The "traditional" installation usually sizes dump too big. >That is why I asked. :-) > > >Hope this helps -- Volker >-- >------------------------------------------------------------------------ >Volker A. Brandt Consulting and Support for Oracle >Solaris >Brandt & Brandt Computer GmbH WWW: >http://www.bb-c.de/ >Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: >vab at bb-c.de >Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: >46 >Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt > >"When logic and proportion have fallen sloppy dead" >_______________________________________________ >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 peter.tribble at gmail.com Thu Jan 26 14:36:25 2017 From: peter.tribble at gmail.com (Peter Tribble) Date: Thu, 26 Jan 2017 14:36:25 +0000 Subject: [OmniOS-discuss] Fwd: Install on Supermicro DOM=low space left In-Reply-To: <4ECFFE87-89D1-46C9-905B-8C93586FA02D@marzocchi.net> References: <22665.55326.378723.508075@shelob.bb-c.de> <22665.57267.919068.568577@shelob.bb-c.de> <4ECFFE87-89D1-46C9-905B-8C93586FA02D@marzocchi.net> Message-ID: On Thu, Jan 26, 2017 at 2:12 PM, Olaf Marzocchi wrote: > But dumps can also be saved as files on a normal dataset, right? provided > enough space is left for them. > No. The dump is a two-stage process. When the system panics, it simply drops memory into the dump volume. (Traditionally, it used to use the swap partition.) Then, when the system is back up, you save that dump into regular files for subsequent analysis. If you're really tight for space, and aren't worried about debugging a panic, then disabling dumps entirely (dupadm -d none) might be appropriate in this case. (As an aside, I note that current OmniOS LTS - r151014 - doesn't understand dumpadm -e, which is a shame.) > Olaf > > > > Il 26 gennaio 2017 12:38:27 CET, vab at bb-c.de ha scritto: >> >> NAME USED AVAIL REFER MOUNTPOINT >>> rpool/dump 41.5G 9.15G 41.5G - >>> rpool/swap 4.13G 13.0G 276M - >>> >> >> The "dump" volume is much too big. Do a >> >> dumpadm -e >> >> This will print the "estimated" dump size. Then add a bit, and >> set the new dump volume size with: >> >> zfs set volsize= rpool/dump >> >> For example, on my OmniOS file server: >> >> # dumpadm -e >> Estimated dump size: 4.63G >> >> # zfs set volsize=6G rpool/dump >> >> # zfs list rpool/dump >> NAME USED AVAIL REFER MOUNTPOINT >> rpool/dump 6.00G 24.1G 6.00G - >> >> I did not changed anything during instalation proccess, I've just >>> accepted all defaults >>> >> >> Yes. The "traditional" installation usually sizes dump too big. >> That is why I asked. :-) >> >> >> Hope this helps -- Volker >> >> > _______________________________________________ > 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 danmcd at omniti.com Thu Jan 26 16:47:53 2017 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 26 Jan 2017 11:47:53 -0500 Subject: [OmniOS-discuss] OpenSSL now updated to 1.0.2k Message-ID: <7C1AC370-2F33-4F51-A3BE-00A805002B1F@omniti.com> All supported releases (r151014, r151018, r151020) now have updated OpenSSL from this morning's 1.0.2k update. Please "pkg update" your supported OmniOS deployments. This is a non-reboot update, but you may, depending, have to manually restart your openssl-using services. Dan From richard.elling at richardelling.com Thu Jan 26 19:18:27 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Thu, 26 Jan 2017 11:18:27 -0800 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> Message-ID: <4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com> > On Jan 26, 2017, at 12:20 AM, Stephan Budach wrote: > > Hi Richard, > > gotcha? read on, below? "thin provisioning" bit you. For "thick provisioning" you?ll have a refreservation and/or reservation. ? richard > > Am 26.01.17 um 00:43 schrieb Richard Elling: >> more below? >> >>> On Jan 25, 2017, at 3:01 PM, Stephan Budach > wrote: >>> >>> Ooops? should have waited with sending that message after I rebootet the S11.1 host? >>> >>> >>> Am 25.01.17 um 23:41 schrieb Stephan Budach: >>>> Hi Richard, >>>> >>>> Am 25.01.17 um 20:27 schrieb Richard Elling: >>>>> Hi Stephan, >>>>> >>>>>> On Jan 25, 2017, at 5:54 AM, Stephan Budach > wrote: >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> I have been trying to import a zpool, based on a 3way-mirror provided by three omniOS boxes via iSCSI. This zpool had been working flawlessly until some random reboot of the S11.1 host. Since then, S11.1 has been importing this zpool without success. >>>>>> >>>>>> This zpool consists of three 108TB LUNs, based on a raidz-2 zvols? yeah I know, we shouldn't have done that in the first place, but performance was not the primary goal for that, as this one is a backup/archive pool. >>>>>> >>>>>> When issueing a zpool import, it says this: >>>>>> >>>>>> root at solaris11atest2:~# zpool import >>>>>> pool: vsmPool10 >>>>>> id: 12653649504720395171 >>>>>> state: DEGRADED >>>>>> status: The pool was last accessed by another system. >>>>>> action: The pool can be imported despite missing or damaged devices. The >>>>>> fault tolerance of the pool may be compromised if imported. >>>>>> see: http://support.oracle.com/msg/ZFS-8000-EY >>>>>> config: >>>>>> >>>>>> vsmPool10 DEGRADED >>>>>> mirror-0 DEGRADED >>>>>> c0t600144F07A3506580000569398F60001d0 DEGRADED corrupted data >>>>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED corrupted data >>>>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED corrupted data >>>>>> >>>>>> device details: >>>>>> >>>>>> c0t600144F07A3506580000569398F60001d0 DEGRADED scrub/resilver needed >>>>>> status: ZFS detected errors on this device. >>>>>> The device is missing some data that is recoverable. >>>>>> >>>>>> c0t600144F07A35066C00005693A0D90001d0 DEGRADED scrub/resilver needed >>>>>> status: ZFS detected errors on this device. >>>>>> The device is missing some data that is recoverable. >>>>>> >>>>>> c0t600144F07A35001A00005693A2810001d0 DEGRADED scrub/resilver needed >>>>>> status: ZFS detected errors on this device. >>>>>> The device is missing some data that is recoverable. >>>>>> >>>>>> However, when actually running zpool import -f vsmPool10, the system starts to perform a lot of writes on the LUNs and iostat report an alarming increase in h/w errors: >>>>>> >>>>>> root at solaris11atest2:~# iostat -xeM 5 >>>>>> extended device statistics ---- errors --- >>>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>>>> sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 71 0 71 >>>>>> sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>>> sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>>> sd5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>>> extended device statistics ---- errors --- >>>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>>>> sd0 14.2 147.3 0.7 0.4 0.2 0.1 2.0 6 9 0 0 0 0 >>>>>> sd1 14.2 8.4 0.4 0.0 0.0 0.0 0.3 0 0 0 0 0 0 >>>>>> sd2 0.0 4.2 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>>>> sd3 157.3 46.2 2.1 0.2 0.0 0.7 3.7 0 14 0 30 0 30 >>>>>> sd4 123.9 29.4 1.6 0.1 0.0 1.7 10.9 0 36 0 40 0 40 >>>>>> sd5 142.5 43.0 2.0 0.1 0.0 1.9 10.2 0 45 0 88 0 88 >>>>>> extended device statistics ---- errors --- >>>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>>>> sd0 0.0 234.5 0.0 0.6 0.2 0.1 1.4 6 10 0 0 0 0 >>>>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>>>> sd3 3.6 64.0 0.0 0.5 0.0 4.3 63.2 0 63 0 235 0 235 >>>>>> sd4 3.0 67.0 0.0 0.6 0.0 4.2 60.5 0 68 0 298 0 298 >>>>>> sd5 4.2 59.6 0.0 0.4 0.0 5.2 81.0 0 72 0 406 0 406 >>>>>> extended device statistics ---- errors --- >>>>>> device r/s w/s Mr/s Mw/s wait actv svc_t %w %b s/w h/w trn tot >>>>>> sd0 0.0 234.8 0.0 0.7 0.4 0.1 2.2 11 10 0 0 0 0 >>>>>> sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 0 0 0 >>>>>> sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 0 92 0 92 >>>>>> sd3 5.4 54.4 0.0 0.3 0.0 2.9 48.5 0 67 0 384 0 384 >>>>>> sd4 6.0 53.4 0.0 0.3 0.0 4.6 77.7 0 87 0 519 0 519 >>>>>> sd5 6.0 60.8 0.0 0.3 0.0 4.8 72.5 0 87 0 727 0 727 >>>>> >>>>> h/w errors are a classification of other errors. The full error list is available from "iostat -E" and will >>>>> be important to tracking this down. >>>>> >>>>> A better, more detailed analysis can be gleaned from the "fmdump -e" ereports that should be >>>>> associated with each h/w error. However, there are dozens of causes of these so we don?t have >>>>> enough info here to fully understand. >>>>> ? richard >>>>> >>>> Well? I can't provide you with the output of fmdump -e (since I am currently unable to get the '-' typed in to the console, due to some fancy keyboard layout issues and nit being able to login via ssh as well (can authenticate, but I don't get to the shell, which may be due to the running zpool import), but I can confirm that fmdump does show nothing at all. I could just reset the S11.1 host, after removing the zpool.cache file, such as that the system will not try to import the zpool upon restart right away? >>>> >>>> ?plus I might get the option to set the keyboard right, after reboot, but that's another issue? >>>> >>> After resetting the S11.1 host and getting the keyboard layout right, I issued a fmdump -e and there they are? lots of: >>> >>> Jan 25 23:25:13.5643 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.8944 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.8945 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.8946 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9274 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9275 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9276 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9277 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9282 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9284 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9285 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9286 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9287 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9288 ereport.fs.zfs.dev.merr.write >>> Jan 25 23:25:13.9290 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9294 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9301 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:25:13.9306 ereport.io.scsi.cmd.disk.dev.rqs.merr.write >>> Jan 25 23:50:44.7195 ereport.io.scsi.cmd.disk.dev.rqs.derr >>> Jan 25 23:50:44.7306 ereport.io.scsi.cmd.disk.dev.rqs.derr >>> Jan 25 23:50:44.7434 ereport.io.scsi.cmd.disk.dev.rqs.derr >>> Jan 25 23:53:31.4386 ereport.io.scsi.cmd.disk.dev.rqs.derr >>> Jan 25 23:53:31.4579 ereport.io.scsi.cmd.disk.dev.rqs.derr >>> Jan 25 23:53:31.4710 ereport.io.scsi.cmd.disk.dev.rqs.derr >>> >>> >>> These seem to be media errors and disk errors on the zpools/zvols that make up the LUNs for this zpool? I am wondering, why this happens. >> >> yes, good question >> That we get media errors "merr" on write is one clue. To find out more details, "fmdump -eV" >> will show in gory details the exact SCSI asc/ascq codes, LBAs, etc. >> >> ZFS is COW, so if the LUs are backed by ZFS and there isn?t enough free space, then this is >> the sort of error we expect. But there could be other reasons. >> ? richard >> > Oh Lord? I really think, that this is it? this is what the zpool/zvol looks like on one of the three targets: > > root at tr1206900:/root# zpool list > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > rpool 29,8G 21,5G 8,27G - 45% 72% 1.00x ONLINE - > tr1206900data 109T 106T 3,41T - 51% 96% 1.00x ONLINE - > > root at tr1206900:/root# zfs list -r tr1206900data > NAME USED AVAIL REFER MOUNTPOINT > tr1206900data 86,6T 0 236K /tr1206900data > tr1206900data/vsmPool10 86,6T 0 86,6T - > > root at tr1206900:/root# zfs get all tr1206900data/vsmPool10 > NAME PROPERTY VALUE SOURCE > tr1206900data/vsmPool10 type volume - > tr1206900data/vsmPool10 creation Mo. Jan 11 12:57 2016 - > tr1206900data/vsmPool10 used 86,6T - > tr1206900data/vsmPool10 available 0 - > tr1206900data/vsmPool10 referenced 86,6T - > tr1206900data/vsmPool10 compressratio 1.00x - > tr1206900data/vsmPool10 reservation none default > tr1206900data/vsmPool10 volsize 109T local > tr1206900data/vsmPool10 volblocksize 128K - > tr1206900data/vsmPool10 checksum on default > tr1206900data/vsmPool10 compression off default > tr1206900data/vsmPool10 readonly off default > tr1206900data/vsmPool10 copies 1 default > tr1206900data/vsmPool10 refreservation none default > tr1206900data/vsmPool10 primarycache all local > tr1206900data/vsmPool10 secondarycache all default > tr1206900data/vsmPool10 usedbysnapshots 0 - > tr1206900data/vsmPool10 usedbydataset 86,6T - > tr1206900data/vsmPool10 usedbychildren 0 - > tr1206900data/vsmPool10 usedbyrefreservation 0 - > tr1206900data/vsmPool10 logbias latency default > tr1206900data/vsmPool10 dedup off default > tr1206900data/vsmPool10 mlslabel none default > tr1206900data/vsmPool10 sync standard default > tr1206900data/vsmPool10 refcompressratio 1.00x - > tr1206900data/vsmPool10 written 86,6T - > tr1206900data/vsmPool10 logicalused 86,5T - > tr1206900data/vsmPool10 logicalreferenced 86,5T - > tr1206900data/vsmPool10 snapshot_limit none default > tr1206900data/vsmPool10 snapshot_count none default > tr1206900data/vsmPool10 redundant_metadata all default > > This must be the dumbest failure one can possibly have, when setting up a zvol iSCSI target. So, someone - no, it wasn't me, actually, but this doesn't do me any good anyway, created a zvol equal the size to the zpool and now it is as you suspected: the zvol has run out of space. > > So, the only chance would be to add additional space to these zpools, such as that the zvol actually can occupy the space the claim to have? Should be manageable? I could provide some iSCSI LUNs to the targets themselves and add another vdev. There will be some serious cleanup needed afterwards? > > What about the "free" 3,41T in zpool itself? Could those be somehow utilised? > > > Thanks, > Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.budach at jvm.de Sat Jan 28 08:34:16 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Sat, 28 Jan 2017 09:34:16 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> <4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com> Message-ID: Hi Richard, Am 26.01.17 um 20:18 schrieb Richard Elling: > >> On Jan 26, 2017, at 12:20 AM, Stephan Budach > > wrote: >> >> Hi Richard, >> >> gotcha? read on, below? > > "thin provisioning" bit you. For "thick provisioning" you?ll have a > refreservation and/or reservation. > ? richard yes, it was? Now, yesterday I was able to shove in three new Supermicro storage servers. Since I wanted to re-setup that whole zpool anyway, I thought it would be enough just to provide a big enough LUNs (22TB) to the currently exhausted zpool. This 22TB LUN is provided from the new systems via iSCSI. When I tried to add that LUN as a new vdev to the pool, zpool naturally complained about the replication mismatch. Is it safe to do that anyway? I mean, the backing zpool of that LUN is also made up from 2 raidz-1 and I wanted to avoid actual triple-double redundancy? I will have to overhaul the whole setup anyway? Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From mir at miras.org Sat Jan 28 19:39:54 2017 From: mir at miras.org (Michael Rasmussen) Date: Sat, 28 Jan 2017 20:39:54 +0100 Subject: [OmniOS-discuss] Problems with smartd Message-ID: <20170128203954.5a6fb63d@sleipner.datanom.net> Hi all, Today I switch storage controller in my Omnios 151014: sas1068e -> sas2008 and smartd now refuses to start: svcs -xv svc:/site/smartd:default svc:/site/smartd:default (SMART monitoring service (smartd)) State: maintenance since January 28, 2017 05:56:12 PM CET Reason: Restarting too quickly. See: http://illumos.org/msg/SMF-8000-L5 See: man -M /usr/share/man -s 1M smartd See: /var/svc/log/site-smartd:default.log Impact: This service is not running. New controller: sas2ircu 0 display Read configuration has been initiated for controller 0 ------------------------------------------------------------------------ Controller information ------------------------------------------------------------------------ Controller type : SAS2008 BIOS version : 0.00.00.00 Firmware version : 20.00.07.00 Channel description : 1 Serial Attached SCSI Initiator ID : 0 Maximum physical devices : 255 Concurrent commands supported : 3432 Slot : Unknown Segment : 0 Bus : 1 Device : 0 Function : 0 RAID Support : No ..... Information from each disk ------------------------------------------------------------------------ Enclosure information ------------------------------------------------------------------------ Enclosure# : 1 Logical ID : 590b11c0:18609700 Numslots : 8 StartSlot : 0 ------------------------------------------------------------------------ Procedure used for the switch: 1) reboot into single user mode 2) zpool export tank 3) poweroff 4) switch controller and connect disks identical 5) boot into single user mode 6) zpool import tank 7) some tests which showed everything was working 8) reboot Any advice? -- 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: If Bill Gates is the Devil then Linus Torvalds must be the Messiah. -- Unknown source -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mir at miras.org Sat Jan 28 19:55:20 2017 From: mir at miras.org (Michael Rasmussen) Date: Sat, 28 Jan 2017 20:55:20 +0100 Subject: [OmniOS-discuss] Problems with smartd In-Reply-To: <20170128203954.5a6fb63d@sleipner.datanom.net> References: <20170128203954.5a6fb63d@sleipner.datanom.net> Message-ID: <20170128205520.45f99da1@sleipner.datanom.net> On Sat, 28 Jan 2017 20:39:54 +0100 Michael Rasmussen wrote: > > Any advice? > Forgot to mention that running smartctl works as expected. smartctl -i -d sat,12 /dev/rdsk/c10t50014EE262D3DA79d0s0 smartctl 6.3 2014-07-26 r3976 [i386-pc-solaris2.11] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red (AF) Device Model: WDC WD10EFRX-68FYTN0 Serial Number: WD-WCC4J4JLPZP3 LU WWN Device Id: 5 0014ee 262d3da79 Firmware Version: 82.00A82 User Capacity: 1,000,204,886,016 bytes [1.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Jan 28 20:54:03 2017 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled -- 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: If you talk to God, you are praying; if God talks to you, you have schizophrenia. -- Thomas Szasz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mir at miras.org Sat Jan 28 20:55:46 2017 From: mir at miras.org (Michael Rasmussen) Date: Sat, 28 Jan 2017 21:55:46 +0100 Subject: [OmniOS-discuss] Problems with smartd In-Reply-To: <20170128203954.5a6fb63d@sleipner.datanom.net> References: <20170128203954.5a6fb63d@sleipner.datanom.net> Message-ID: <20170128215546.61eae27e@sleipner.datanom.net> On Sat, 28 Jan 2017 20:39:54 +0100 Michael Rasmussen wrote: > > Any advice? > Fix it myself. Was not related to the controller switch but because some of the disks needed to flag '-T permissive'. So handcrafted a smartd.conf file instead of relaying on 'DEVICESCAN' adding the flag to the needed disks solved the problem. Error from smartd when this is needed: Device: /dev/rdsk/c8t2d0s0 [SAT], ATA IDENTIFY DEVICE words 82-83 don't specify if SMART capable. Device: /dev/rdsk/c8t2d0s0 [SAT], proceeding since '-T permissive' Directive given. -- 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: It's multiple choice time... What is FORTRAN? a: Between thre and fiv tran. b: What two computers engage in before they interface. c: Ridiculous. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stephan.budach at jvm.de Sun Jan 29 11:10:47 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Sun, 29 Jan 2017 12:10:47 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> <4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com> Message-ID: <9d7ee062-37dc-06e0-d9cb-2655c4011dd4@jvm.de> Hi, just to wrap this up? I decided to go with 15 additional LUNs on each storage zpool, to avoid zfs complainign about replication mismatches. I know, I cluld have done otherwise, but it somehow felt better this way. After all three underlying zpools were "pimped", I was able to mount the problematic zpool in my S11.1 host without any issue. It just took a coulpe of seconds and zfs reported approx 2.53MB resilvered? Now, there's a scrub running on that zpool tnat is just happily humming away on the data. Thanks for all the input, everyone. Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: From danmcd at omniti.com Mon Jan 30 19:20:23 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 30 Jan 2017 14:20:23 -0500 Subject: [OmniOS-discuss] (was bounce) USB3 chipset? References: Message-ID: <17D0BB2C-E043-4028-9D4C-C5BD170F4765@omniti.com> I got a bounce notification, so I'm sending this myself. Dan From: vab at bb-c.de (Volker A. Brandt) Subject: Recommended USB3 chipset? Date: January 30, 2017 at 2:17:56 PM EST To: "OmniOS-discuss" Hello all! I want to play with bloody and USB3, so I am in the market for a PCIe low-profile single or dual port add-on card. Are there any specific chips or chipsets I should look for? Which ones should I avoid? Can I expect decent throughput in a PCIe 2.0 x1 slot (HP G7 N54L)? Thanks -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" -------------- next part -------------- An HTML attachment was scrubbed... URL: From vab at bb-c.de Mon Jan 30 19:58:02 2017 From: vab at bb-c.de (Volker A. Brandt) Date: Mon, 30 Jan 2017 20:58:02 +0100 Subject: [OmniOS-discuss] (was bounce) USB3 chipset? In-Reply-To: <17D0BB2C-E043-4028-9D4C-C5BD170F4765@omniti.com> References: <17D0BB2C-E043-4028-9D4C-C5BD170F4765@omniti.com> Message-ID: <22671.39626.609756.289566@shelob.bb-c.de> > I got a bounce notification, so I'm sending this myself. Thanks Dan! I was too stupid to properly address the list. :-/ > From: vab at bb-c.de (Volker A. Brandt) > Subject: Recommended USB3 chipset? > Date: January 30, 2017 at 2:17:56 PM EST > To: "OmniOS-discuss" > > > Hello all! > > > I want to play with bloody and USB3, so I am in the market for a PCIe > low-profile single or dual port add-on card. Are there any specific > chips or chipsets I should look for? Which ones should I avoid? > > Can I expect decent throughput in a PCIe 2.0 x1 slot (HP G7 N54L)? > > > Thanks -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Oracle Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANY Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 46 Gesch?ftsf?hrer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" From ericbardes at gmail.com Mon Jan 30 21:41:40 2017 From: ericbardes at gmail.com (Eric Bardes) Date: Mon, 30 Jan 2017 16:41:40 -0500 Subject: [OmniOS-discuss] OmniOS on Dual CPU Mac Pro Message-ID: I'm running into an interesting situation. I have an older "Cheese Grater" style Mac Pro (mid-2012 - MacPro5,1) with Dual Xeon 6-Core CPUs and 64GB ECC RAM. (24 execution threads) that I'm trying to install OmniOS onto. It's been crashing on installation of OmniOS (also on OpenIndiana too) and I think I've narrowed it down to the ZFS file system creation. Has anyone else run into this? Is there something in the kernel debugger I can look at? it's sister, a 2010 or 2009 Mac Pro with one Xeon 4 core (8 threads) has been running OpenIndiana Hipster flawlessly. -- Eric Bardes ?Love all, trust a few. Do wrong to none? - *All's Well That Ends Well*, Act 1, Sc 1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 30 22:05:11 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 30 Jan 2017 17:05:11 -0500 Subject: [OmniOS-discuss] OmniOS on Dual CPU Mac Pro In-Reply-To: References: Message-ID: <667C4A5C-BBCA-4247-8F82-808160AF1BF9@omniti.com> > On Jan 30, 2017, at 4:41 PM, Eric Bardes wrote: > > I'm running into an interesting situation. > > I have an older "Cheese Grater" style Mac Pro (mid-2012 - MacPro5,1) with Dual Xeon 6-Core CPUs and 64GB ECC RAM. (24 execution threads) that I'm trying to install OmniOS onto. It's been crashing on installation of OmniOS (also on OpenIndiana too) and I think I've narrowed it down to the ZFS file system creation. Has anyone else run into this? Is there something in the kernel debugger I can look at? So the newer HW panics, but... > it's sister, a 2010 or 2009 Mac Pro with one Xeon 4 core (8 threads) has been running OpenIndiana Hipster flawlessly. ... the older HW runs without a hitch, huh? One thing you can do is get to the grub menu, edit the "unix" line to include "-k" in its arguments. You'll drop into kmdb upon panic, and you can utter things like: $c (see stack) ::msgbuf (scroll through kernel printf backlog, including more info on the panic itself). Hope this helps, Dan From ericbardes at gmail.com Mon Jan 30 22:49:55 2017 From: ericbardes at gmail.com (Eric Bardes) Date: Mon, 30 Jan 2017 17:49:55 -0500 Subject: [OmniOS-discuss] OmniOS on Dual CPU Mac Pro In-Reply-To: <667C4A5C-BBCA-4247-8F82-808160AF1BF9@omniti.com> References: <667C4A5C-BBCA-4247-8F82-808160AF1BF9@omniti.com> Message-ID: It appears that it's crashing in the intel_nhm section of the kernel. The dimm_to_addr function. I think this is probably the interesting part ... trap+0xce5(ffffff007acf8790, cc4000000, 3) intel_nhm`dimm_to_addr+0x43f(0, 2, 0, 82800000, ffffff007acf89f0, ffffff007acf89e8) I wonder if it's to something about how Apple distributes the 8 DIMM slots between the two CPUs. I want to clarify what I say ZFS file system creation, zpool create tank zpool import -f tank crashes too. On Mon, Jan 30, 2017 at 5:05 PM, Dan McDonald wrote: > > > On Jan 30, 2017, at 4:41 PM, Eric Bardes wrote: > > > > I'm running into an interesting situation. > > > > I have an older "Cheese Grater" style Mac Pro (mid-2012 - MacPro5,1) > with Dual Xeon 6-Core CPUs and 64GB ECC RAM. (24 execution threads) that > I'm trying to install OmniOS onto. It's been crashing on installation of > OmniOS (also on OpenIndiana too) and I think I've narrowed it down to the > ZFS file system creation. Has anyone else run into this? Is there something > in the kernel debugger I can look at? > > So the newer HW panics, but... > > > it's sister, a 2010 or 2009 Mac Pro with one Xeon 4 core (8 threads) has > been running OpenIndiana Hipster flawlessly. > > ... the older HW runs without a hitch, huh? > > One thing you can do is get to the grub menu, edit the "unix" line to > include "-k" in its arguments. You'll drop into kmdb upon panic, and you > can utter things like: > > $c (see stack) > > ::msgbuf (scroll through kernel printf backlog, including more > info on the panic itself). > > Hope this helps, > Dan > > -- Eric Bardes ?Love all, trust a few. Do wrong to none? - *All's Well That Ends Well*, Act 1, Sc 1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Jan 30 22:58:20 2017 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 30 Jan 2017 17:58:20 -0500 Subject: [OmniOS-discuss] OmniOS on Dual CPU Mac Pro In-Reply-To: References: <667C4A5C-BBCA-4247-8F82-808160AF1BF9@omniti.com> Message-ID: <10422520-A8B4-4410-B202-B02CAE9EDB57@omniti.com> > On Jan 30, 2017, at 5:49 PM, Eric Bardes wrote: > > It appears that it's crashing in the intel_nhm section of the kernel. The dimm_to_addr function. > > I think this is probably the interesting part ... > > trap+0xce5(ffffff007acf8790, cc4000000, 3) > intel_nhm`dimm_to_addr+0x43f(0, 2, 0, 82800000, ffffff007acf89f0, ffffff007acf89e8) > > I wonder if it's to something about how Apple distributes the 8 DIMM slots between the two CPUs. > > I want to clarify what I say ZFS file system creation, zpool create tank > zpool import -f tank crashes too. You really need to share the whole stack. That's hardly enough context. The ::msgbuf gives further information too, like what actual pointer (if it's a NULL pointer dereference) values, so you can see the offset (helps with source diving). Thanks, Dan From richard.elling at richardelling.com Mon Jan 30 23:15:59 2017 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 30 Jan 2017 15:15:59 -0800 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <9d7ee062-37dc-06e0-d9cb-2655c4011dd4@jvm.de> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> <4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com> <9d7ee062-37dc-06e0-d9cb-2655c4011dd4@jvm.de> Message-ID: <4634E48A-8DEA-4A48-8844-297AA14E37BF@richardelling.com> > On Jan 29, 2017, at 3:10 AM, Stephan Budach wrote: > > Hi, > > just to wrap this up? I decided to go with 15 additional LUNs on each storage zpool, to avoid zfs complainign about replication mismatches. I know, I cluld have done otherwise, but it somehow felt better this way. > > After all three underlying zpools were "pimped", I was able to mount the problematic zpool in my S11.1 host without any issue. It just took a coulpe of seconds and zfs reported approx 2.53MB resilvered? > > Now, there's a scrub running on that zpool tnat is just happily humming away on the data. > > Thanks for all the input, everyone. may all your scrubs complete cleanly :-) ? richard > > Stephan > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From stephan.budach at jvm.de Tue Jan 31 04:56:45 2017 From: stephan.budach at jvm.de (Stephan Budach) Date: Tue, 31 Jan 2017 05:56:45 +0100 Subject: [OmniOS-discuss] issue importing zpool on S11.1 from omniOS LUNs In-Reply-To: <4634E48A-8DEA-4A48-8844-297AA14E37BF@richardelling.com> References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de> <36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com> <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com> <9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de> <4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com> <9d7ee062-37dc-06e0-d9cb-2655c4011dd4@jvm.de> <4634E48A-8DEA-4A48-8844-297AA14E37BF@richardelling.com> Message-ID: Am 31.01.17 um 00:15 schrieb Richard Elling: >> On Jan 29, 2017, at 3:10 AM, Stephan Budach wrote: >> >> Hi, >> >> just to wrap this up? I decided to go with 15 additional LUNs on each storage zpool, to avoid zfs complainign about replication mismatches. I know, I cluld have done otherwise, but it somehow felt better this way. >> >> After all three underlying zpools were "pimped", I was able to mount the problematic zpool in my S11.1 host without any issue. It just took a coulpe of seconds and zfs reported approx 2.53MB resilvered? >> >> Now, there's a scrub running on that zpool tnat is just happily humming away on the data. >> >> Thanks for all the input, everyone. > may all your scrubs complete cleanly :-) > ? richard > >> Stephan I'm on it! ;) So far it has been running smoothly, only giving a couple of read errors for a ZFS that is encrypted and to which ZFS I hadn't the keys at hand, but otherwise, it's running fine. It will take another 9 days, though to finish, running at 3x100MB/s? Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5546 bytes Desc: not available URL: