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: <A50B0DB0-A92D-4825-B6F5-869C541886A7@omniti.com>
References: <B9D9271554C34B41866AA2801A8FD279AC5FDB04@XCH-MBX1.ipk-gatersleben.de>
	<A50B0DB0-A92D-4825-B6F5-869C541886A7@omniti.com>
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: <alpine.GSO.2.20.1701021551410.15887@freddy.simplesystems.org>

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: <alpine.GSO.2.20.1701021551410.15887@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1701021551410.15887@freddy.simplesystems.org>
Message-ID: <alpine.GSO.2.20.1701021703300.15887@freddy.simplesystems.org>

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>
	<B4BED540-E685-47B7-859F-D974A93AB215@omniti.com>
	<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. <info.fmo at gmx.de> 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: <alpine.GSO.2.20.1701021703300.15887@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1701021551410.15887@freddy.simplesystems.org>
	<alpine.GSO.2.20.1701021703300.15887@freddy.simplesystems.org>
Message-ID: <D3BAA89D-6B42-43D5-A7F8-7C5184DFE6F7@omniti.com>


> On Jan 2, 2017, at 6:07 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <D3BAA89D-6B42-43D5-A7F8-7C5184DFE6F7@omniti.com>
References: <alpine.GSO.2.20.1701021551410.15887@freddy.simplesystems.org>
	<alpine.GSO.2.20.1701021703300.15887@freddy.simplesystems.org>
	<D3BAA89D-6B42-43D5-A7F8-7C5184DFE6F7@omniti.com>
Message-ID: <BFA38FC5-2A57-40D4-8F57-EC899360A2CA@omniti.com>


> On Jan 3, 2017, at 8:45 PM, Dan McDonald <danmcd at omniti.com> 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: <alpine.GSO.2.00.1701040858001.3148@erncre.pvgehf-vg.arg>

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: <alpine.GSO.2.00.1701040858001.3148@erncre.pvgehf-vg.arg>
References: <alpine.GSO.2.00.1701040858001.3148@erncre.pvgehf-vg.arg>
Message-ID: <B4D98BFE-EEE9-4ADA-A642-24F1ED18B65B@omniti.com>

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 <omnios at citrus-it.net> 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: <CAO8hXRD-ksOfvsqFRo-4pgpEbQjMA-ZjPyVg1cc9-z6Kft75Lw@mail.gmail.com>

On Wed, Jan 4, 2017 at 1:04 PM, Chris Siebenmann <cks at cs.toronto.edu> 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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/5e197b8b/attachment.html>

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 <cks at cs.toronto.edu> 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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
References: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
Message-ID: <BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>


> On Jan 4, 2017, at 1:19 PM, Mini Trader <miniflowtrader at gmail.com> 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<mailto: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<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>

k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/501177f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3504 bytes
Desc: image001.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/501177f1/attachment-0001.png>

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: <B3A838D3-8612-4F2E-B61C-732F989C1583@omniti.com>


> On Jan 4, 2017, at 3:02 PM, John Barfield <john.barfield at bissinc.com> 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: <B3A838D3-8612-4F2E-B61C-732F989C1583@omniti.com>
References: <98073E57-E323-4F2C-9AE3-C09E032D3812@bissinc.com>
	<B3A838D3-8612-4F2E-B61C-732F989C1583@omniti.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" <danmcd at omniti.com> wrote:

    
    > On Jan 4, 2017, at 3:02 PM, John Barfield <john.barfield at bissinc.com> 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<mailto: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<http://support.bissinc.com/> or support at bissinc.com<mailto:support at bissinc.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/3986061f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3504 bytes
Desc: image001.png
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/3986061f/attachment-0001.png>

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>
	<B3A838D3-8612-4F2E-B61C-732F989C1583@omniti.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 <john.barfield at bissinc.com> 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>
	<B3A838D3-8612-4F2E-B61C-732F989C1583@omniti.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" <danmcd at omniti.com> wrote:

    
    > On Jan 4, 2017, at 3:21 PM, John Barfield <john.barfield at bissinc.com> 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>
	<B3A838D3-8612-4F2E-B61C-732F989C1583@omniti.com>
	<17B21797-734A-4177-88B4-E50F9E3387D9@bissinc.com>
	<8040EC47-1CF4-4001-95B5-1096EDF2CA45@omniti.com>
	<69124AF3-2C15-404B-9375-EABD40711401@bissinc.com>
Message-ID: <D398433E-5981-49FB-8E8C-6B831FC558E4@omniti.com>


> On Jan 4, 2017, at 3:35 PM, John Barfield <john.barfield at bissinc.com> 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
<Snip>

and much much more along the above lines.

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

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: <CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>

On 4 January 2017 at 12:29, John Barfield <john.barfield at bissinc.com> 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: <E9402CA7-1A59-4517-B650-175EA996F660@omniti.com>

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: <CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>
References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com>
	<CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.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" <josh at sysmgr.org> wrote:

    On 4 January 2017 at 12:29, John Barfield <john.barfield at bissinc.com> 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>
	<CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>
	<2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com>
Message-ID: <CAEwA5nLYbhvDs9W4jww3z2K9T-quLbb2sR6gB7Q69vRgFiBV0g@mail.gmail.com>

On 4 January 2017 at 12:57, John Barfield <john.barfield at bissinc.com> 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: <CAEwA5nLYbhvDs9W4jww3z2K9T-quLbb2sR6gB7Q69vRgFiBV0g@mail.gmail.com>
References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com>
	<CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>
	<2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com>
	<CAEwA5nLYbhvDs9W4jww3z2K9T-quLbb2sR6gB7Q69vRgFiBV0g@mail.gmail.com>
Message-ID: <B1B0CBD9-B210-4E36-A612-EFCCD60EA741@bissinc.com>

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" <josh at sysmgr.org> wrote:

    On 4 January 2017 at 12:57, John Barfield <john.barfield at bissinc.com> 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 <richard.elling at richardelling.com> wrote:
> 
>> 
>> On Jan 4, 2017, at 10:04 AM, Chris Siebenmann <cks at cs.toronto.edu> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/64a95d4e/attachment-0001.html>

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: <B1B0CBD9-B210-4E36-A612-EFCCD60EA741@bissinc.com>
References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com>
	<CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>
	<2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com>
	<CAEwA5nLYbhvDs9W4jww3z2K9T-quLbb2sR6gB7Q69vRgFiBV0g@mail.gmail.com>
	<B1B0CBD9-B210-4E36-A612-EFCCD60EA741@bissinc.com>
Message-ID: <CAEwA5nKEHX4=c5bygQbg5CM=S4B6syOFF3=6hzpbPVMP7wBG3g@mail.gmail.com>

On 4 January 2017 at 13:09, John Barfield <john.barfield at bissinc.com> 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: <CAEwA5nKEHX4=c5bygQbg5CM=S4B6syOFF3=6hzpbPVMP7wBG3g@mail.gmail.com>
References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com>
	<CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>
	<2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com>
	<CAEwA5nLYbhvDs9W4jww3z2K9T-quLbb2sR6gB7Q69vRgFiBV0g@mail.gmail.com>
	<B1B0CBD9-B210-4E36-A612-EFCCD60EA741@bissinc.com>
	<CAEwA5nKEHX4=c5bygQbg5CM=S4B6syOFF3=6hzpbPVMP7wBG3g@mail.gmail.com>
Message-ID: <B3C485A8-BEC2-4EAF-89BC-1C54BEA0866A@bissinc.com>

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" <josh at sysmgr.org> wrote:

    On 4 January 2017 at 13:09, John Barfield <john.barfield at bissinc.com> 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: <E9402CA7-1A59-4517-B650-175EA996F660@omniti.com>
References: <65DC5816D4BEE043885A89FD54E273FC71D388C4@MAIL101.Ellipseinc.com>
	<E9402CA7-1A59-4517-B650-175EA996F660@omniti.com>
Message-ID: <20170104222102.17086412@sleipner.datanom.net>

On Wed, 4 Jan 2017 15:56:17 -0500
Dan McDonald <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/57990b4b/attachment.bin>

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: <CAEwA5nKEHX4=c5bygQbg5CM=S4B6syOFF3=6hzpbPVMP7wBG3g@mail.gmail.com>
References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com>
	<CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>
	<2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com>
	<CAEwA5nLYbhvDs9W4jww3z2K9T-quLbb2sR6gB7Q69vRgFiBV0g@mail.gmail.com>
	<B1B0CBD9-B210-4E36-A612-EFCCD60EA741@bissinc.com>
	<CAEwA5nKEHX4=c5bygQbg5CM=S4B6syOFF3=6hzpbPVMP7wBG3g@mail.gmail.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" <josh at sysmgr.org> wrote:

    On 4 January 2017 at 13:09, John Barfield <john.barfield at bissinc.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/ee833622/attachment.bin>

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>
	<E9402CA7-1A59-4517-B650-175EA996F660@omniti.com>
	<20170104222102.17086412@sleipner.datanom.net>
Message-ID: <A2AFA901-C8C7-4CCD-8535-13EB158F0623@omniti.com>


> On Jan 4, 2017, at 4:21 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Wed, 4 Jan 2017 15:56:17 -0500
> Dan McDonald <danmcd at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/1534227a/attachment.bin>

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: <CALBem1aH36jToMeLeM22a_tQ0LjKhKk5FCXPFjbQq0R31EMbkA@mail.gmail.com>

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" <danmcd at omniti.com> wrote:
>
>
>     > On Jan 4, 2017, at 3:02 PM, John Barfield <john.barfield at bissinc.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/3d11d756/attachment.html>

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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/b44fcc88/attachment.bin>

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: <B3C485A8-BEC2-4EAF-89BC-1C54BEA0866A@bissinc.com>
References: <1906D8BD-AEEB-4EC4-B5DA-1B1C5B7E46E6@bissinc.com>
	<CAEwA5nKycYdZg2CBrx8gnf+DzPC0as_1x4GF_TW_cONrrQ=eiQ@mail.gmail.com>
	<2BA21510-975F-4249-8471-21E6C4B09AD2@bissinc.com>
	<CAEwA5nLYbhvDs9W4jww3z2K9T-quLbb2sR6gB7Q69vRgFiBV0g@mail.gmail.com>
	<B1B0CBD9-B210-4E36-A612-EFCCD60EA741@bissinc.com>
	<CAEwA5nKEHX4=c5bygQbg5CM=S4B6syOFF3=6hzpbPVMP7wBG3g@mail.gmail.com>
	<B3C485A8-BEC2-4EAF-89BC-1C54BEA0866A@bissinc.com>
Message-ID: <DDA48FC8-5EEE-49F0-8B8D-64F9242787BA@bissinc.com>

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" <john.barfield at bissinc.com> 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" <josh at sysmgr.org> wrote:
    
        On 4 January 2017 at 13:09, John Barfield <john.barfield at bissinc.com> 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 <mir at miras.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/2f1ba0bd/attachment.bin>

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: <BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
References: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
Message-ID: <CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
>
> > On Jan 4, 2017, at 1:19 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170104/55f82147/attachment.html>

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: <CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
References: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
Message-ID: <20170105011518.76311089@sleipner.datanom.net>

On Wed, 04 Jan 2017 23:59:15 +0000
Mini Trader <miniflowtrader at gmail.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
"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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/8deefff0/attachment.bin>

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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<20170105011518.76311089@sleipner.datanom.net>
Message-ID: <20170105012546.72d2bf34@sleipner.datanom.net>

On Thu, 5 Jan 2017 01:15:18 +0100
Michael Rasmussen <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/fc0097db/attachment.bin>

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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<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 <mir at miras.org> wrote:
> 
> On Wed, 04 Jan 2017 23:59:15 +0000
> Mini Trader <miniflowtrader at gmail.com> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> "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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<20170105011518.76311089@sleipner.datanom.net>
Message-ID: <CACFEqhttN1JxpCm3B+1s8pDiFRqN5e2OT2s3O=ytvZ+j6AW0jA@mail.gmail.com>

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 <mir at miras.org> wrote:

> On Wed, 04 Jan 2017 23:59:15 +0000
>
> Mini Trader <miniflowtrader at gmail.com> 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 <at> rasmussen <dot> cc
>
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>
> mir <at> datanom <dot> net
>
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>
> mir <at> miras <dot> org
>
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
>
> --------------------------------------------------------------
>
> /usr/games/fortune -es says:
>
> "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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/05e0e316/attachment-0001.html>

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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<20170105011518.76311089@sleipner.datanom.net>
	<20170105012546.72d2bf34@sleipner.datanom.net>
Message-ID: <CACFEqhu+BmVkW6wkcrGz308971HHkCDTPA=2gz3J0dNQkuEHKw@mail.gmail.com>

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 <mir at miras.org> wrote:

> On Thu, 5 Jan 2017 01:15:18 +0100
> Michael Rasmussen <mir at miras.org> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/c31d0c69/attachment.html>

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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<20170105011518.76311089@sleipner.datanom.net>
	<112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org>
Message-ID: <CACFEqhvdmOCe+gBb1EJ6-SFX7-td98ZDBFQLudOsOXTZYUHOow@mail.gmail.com>

This could work :)  Thank you.

On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott <mtalbott at lji.org> 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 <mir at miras.org> wrote:
> >
> > On Wed, 04 Jan 2017 23:59:15 +0000
> > Mini Trader <miniflowtrader at gmail.com> 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 <at> rasmussen <dot> cc
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> > mir <at> datanom <dot> net
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> > mir <at> miras <dot> org
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> > --------------------------------------------------------------
> > /usr/games/fortune -es says:
> > "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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/d224eb17/attachment.html>

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: <CACFEqhvdmOCe+gBb1EJ6-SFX7-td98ZDBFQLudOsOXTZYUHOow@mail.gmail.com>
References: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<20170105011518.76311089@sleipner.datanom.net>
	<112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org>
	<CACFEqhvdmOCe+gBb1EJ6-SFX7-td98ZDBFQLudOsOXTZYUHOow@mail.gmail.com>
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 <miniflowtrader at gmail.com> ha scritto:
>This could work :)  Thank you.
>
>On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott <mtalbott at lji.org>
>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 <mir at miras.org>
>wrote:
>> >
>> > On Wed, 04 Jan 2017 23:59:15 +0000
>> > Mini Trader <miniflowtrader at gmail.com> 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 <at> rasmussen <dot> cc
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>> > mir <at> datanom <dot> net
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>> > mir <at> miras <dot> org
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
>> > --------------------------------------------------------------
>> > /usr/games/fortune -es says:
>> > "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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/20a82772/attachment.html>

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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/04d640ce/attachment-0001.html>

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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<20170105011518.76311089@sleipner.datanom.net>
	<112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org>
	<CACFEqhvdmOCe+gBb1EJ6-SFX7-td98ZDBFQLudOsOXTZYUHOow@mail.gmail.com>
	<2DFC19B6-19DA-43CA-9F20-BD44DF720EE4@marzocchi.net>
Message-ID: <CAHBEJzXmEdzrV4rtqGRYbkx=aaHwD_EGBMSs9f4_yKTN_9P-4A@mail.gmail.com>

On Thu, Jan 5, 2017 at 3:56 PM, Olaf Marzocchi <lists at marzocchi.net> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/dfeb28bc/attachment.html>

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: <CACFEqhveqY_A-2K5HyKCOumpHFCY4KTz2PQb95SAUgEQ3n=udA@mail.gmail.com>
	<BFBCF30C-35AF-48DB-AB57-B811A84DED52@omniti.com>
	<CACFEqhs5UWvSQssXY6aduxWcJ9WCv6iho9aPG7DQBUMot3Pojg@mail.gmail.com>
	<20170105011518.76311089@sleipner.datanom.net>
	<112447B4-26FC-4CEA-AF27-79B288AF1DE0@lji.org>
	<CACFEqhvdmOCe+gBb1EJ6-SFX7-td98ZDBFQLudOsOXTZYUHOow@mail.gmail.com>
	<2DFC19B6-19DA-43CA-9F20-BD44DF720EE4@marzocchi.net>
Message-ID: <CACFEqhsx4Dx_aZmy7YPQaOtwMwAL9MHqjH3Hoto0F=9Ucj4tSg@mail.gmail.com>

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 <lists at marzocchi.net> 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 <miniflowtrader at gmail.com> ha
> scritto:
>
>
>
> This could work :)  Thank you.
>
> On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott <mtalbott at lji.org> 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 <mir at miras.org> wrote:
>
>
> >
>
>
> > On Wed, 04 Jan 2017 23:59:15 +0000
>
>
> > Mini Trader <miniflowtrader at gmail.com> 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 <at> rasmussen <dot> cc
>
>
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
>
>
> > mir <at> datanom <dot> net
>
>
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
>
>
> > mir <at> miras <dot> org
>
>
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
>
>
> > --------------------------------------------------------------
>
>
> > /usr/games/fortune -es says:
>
>
> > "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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/b90ef234/attachment.html>

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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
Message-ID: <CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>

>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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/f9b0db65/attachment.html>

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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
Message-ID: <DF467697-850D-448E-A05F-BA2F5EA7284D@omniti.com>


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 <miniflowtrader at gmail.com> 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: <CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
Message-ID: <CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>

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 <rafapi at gmail.com> 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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/303bb5b9/attachment-0001.html>

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: <CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
Message-ID: <CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>

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 <miniflowtrader at gmail.com>
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 <rafapi at gmail.com> 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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/008e788d/attachment.html>

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: <CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
Message-ID: <CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>

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 <miniflowtrader at gmail.com> 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 <miniflowtrader at gmail.com>
> 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 <rafapi at gmail.com> 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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/354e4f8d/attachment.html>

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: <CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
Message-ID: <CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>

Yes.  Doesn't seem to make a difference.

On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas <rafapi at gmail.com> 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 <miniflowtrader at gmail.com> 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 <miniflowtrader at gmail.com>
>> 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 <rafapi at gmail.com>
>> 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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/0821470e/attachment-0001.html>

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: <CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
Message-ID: <CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>

It may be useful to take a look at your config file then.

On Thu, 5 Jan 2017 at 15:51 Mini Trader <miniflowtrader at gmail.com> wrote:

> Yes.  Doesn't seem to make a difference.
>
> On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas <rafapi at gmail.com> 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 <miniflowtrader at gmail.com> 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 <miniflowtrader at gmail.com>
> 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 <rafapi at gmail.com> 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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/019fb1f8/attachment.html>

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: <CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
Message-ID: <CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>

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 <rafapi at gmail.com> wrote:

> It may be useful to take a look at your config file then.
>
> On Thu, 5 Jan 2017 at 15:51 Mini Trader <miniflowtrader at gmail.com> wrote:
>
>> Yes.  Doesn't seem to make a difference.
>>
>> On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas <rafapi at gmail.com>
>> 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 <miniflowtrader at gmail.com> 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 <miniflowtrader at gmail.com>
>> 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 <rafapi at gmail.com>
>> 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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/34cba642/attachment-0001.html>

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: <CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
Message-ID: <BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>

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: <BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
Message-ID: <CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>

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 <danmcd at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/c36ddb6e/attachment.html>

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: <CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
Message-ID: <DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>

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: <DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
Message-ID: <CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>

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 <danmcd at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/3ec18277/attachment.html>

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: <CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com>
Message-ID: <CACFEqhtqZMcHxfqSabLTZ14Z69ZNPb0HuEt0oObg7vg9vDg6Ug@mail.gmail.com>

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 <danmcd at omniti.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/2b0eba94/attachment.html>

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: <CACFEqhtqZMcHxfqSabLTZ14Z69ZNPb0HuEt0oObg7vg9vDg6Ug@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com>
	<CACFEqhtqZMcHxfqSabLTZ14Z69ZNPb0HuEt0oObg7vg9vDg6Ug@mail.gmail.com>
Message-ID: <DC4D559E-1155-4548-A436-287A4D7931FC@omniti.com>


> On Jan 5, 2017, at 1:37 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<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 <danmcd at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/d925fa8d/attachment.bin>

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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<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 <mir at miras.org> 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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com>
	<20170105194440.0ea6ff45@sleipner.datanom.net>
	<0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com>
Message-ID: <CACFEqhtP9HZAJKBw6_x1dPXyTVaMhXLe71Xn9+FDOGhZWLb4Aw@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
> > On Jan 5, 2017, at 1:44 PM, Michael Rasmussen <mir at miras.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/210419f1/attachment-0001.html>

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: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<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 <danmcd at omniti.com> wrote:

> > On Jan 5, 2017, at 1:44 PM, Michael Rasmussen <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170105/c2c02d52/attachment.bin>

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: <CACFEqhtP9HZAJKBw6_x1dPXyTVaMhXLe71Xn9+FDOGhZWLb4Aw@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com>
	<20170105194440.0ea6ff45@sleipner.datanom.net>
	<0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com>
	<CACFEqhtP9HZAJKBw6_x1dPXyTVaMhXLe71Xn9+FDOGhZWLb4Aw@mail.gmail.com>
Message-ID: <36B91AB4-8E12-4093-84F3-F1B3BD99973B@omniti.com>


> On Jan 5, 2017, at 2:03 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhsKz0WJ+RUdUpkh_c8gDth6yW++Yu84MWWUf=9F0PT9Cg@mail.gmail.com>
References: <CACFEqhu0ef-ovYXJ_Evyd1ZCXM0KMmQ5vsCCDpcAbDW4KBMOHg@mail.gmail.com>
	<CABMTExhxgBMGqe3prQdgaUaK4D4SH3eKz++zhXpJE8p+P=d9qA@mail.gmail.com>
	<CACFEqhsEKMO+WQavDJKCDQmVc_uMnbFunys_eJEcyxERs95eJA@mail.gmail.com>
	<CACFEqhsPZJ8FQc6B8BT+e+NZQewk5ee-ka_kO48NCOWTis6KUA@mail.gmail.com>
	<CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com>
	<20170105194440.0ea6ff45@sleipner.datanom.net>
	<0C67AE84-2F89-4201-89A4-E95FCB999DC4@omniti.com>
	<CACFEqhtP9HZAJKBw6_x1dPXyTVaMhXLe71Xn9+FDOGhZWLb4Aw@mail.gmail.com>
	<36B91AB4-8E12-4093-84F3-F1B3BD99973B@omniti.com>
	<CACFEqhsKz0WJ+RUdUpkh_c8gDth6yW++Yu84MWWUf=9F0PT9Cg@mail.gmail.com>
Message-ID: <BDED2011-094E-44EF-AB49-3965DC52CB34@omniti.com>


> On Jan 5, 2017, at 2:14 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CABMTExgN_Q4Yz2t_ge7WJ=0Mx-YBmm7YPgsSOfB1-yeNOkiHpQ@mail.gmail.com>
	<CACFEqhvZzQMumX_oV90aC8DKo=8YiN=ctZsXBq4hO+YAcTBZCw@mail.gmail.com>
	<CABMTExjpD44tUVKVcBzNX=1_D7iZnr42sB6MEa_ZAaPH4ehnPA@mail.gmail.com>
	<CACFEqhuBW3SEgP6CoMVSS29ZmaZiUVLWtoj9G4cVJc6kv-Pu0Q@mail.gmail.com>
	<BC8BF418-691D-40DB-890B-F40518AEE807@omniti.com>
	<CACFEqht-4Nri8ttruL+3NoJXZy0E29xRe-T7EFhPOzx2jYc0Dg@mail.gmail.com>
	<DCDADD6F-D56A-4A2E-BABF-4A25014EC62E@omniti.com>
	<CACFEqhv6W1shJCax39DRmxVTBwoQK-URC2Rs+Hg-MWN4u5NR5w@mail.gmail.com>
	<8847E1B1-05CD-4078-988E-C86353CB5791@omniti.com>
	<20170105194440.0ea6ff45@sleipner.datanom.net>
Message-ID: <20170105202054.GA17590@linux.gyakg.u-szeged.hu>

Hi,

"Michael Rasmussen" <mir at miras.org> ?rta 2017-01-05 19:44-kor:
> On Thu, 5 Jan 2017 13:34:40 -0500
> Dan McDonald <danmcd at omniti.com> 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: <B4D98BFE-EEE9-4ADA-A642-24F1ED18B65B@omniti.com>
References: <alpine.GSO.2.00.1701040858001.3148@erncre.pvgehf-vg.arg>
	<B4D98BFE-EEE9-4ADA-A642-24F1ED18B65B@omniti.com>
Message-ID: <alpine.GSO.2.00.1701052338370.9241@erncre.pvgehf-vg.arg>


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 <omnios at citrus-it.net> 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: <A50B0DB0-A92D-4825-B6F5-869C541886A7@omniti.com>
References: <B9D9271554C34B41866AA2801A8FD279AC5FDB04@XCH-MBX1.ipk-gatersleben.de>
	<A50B0DB0-A92D-4825-B6F5-869C541886A7@omniti.com>
Message-ID: <B9D9271554C34B41866AA2801A8FD279AC602A10@XCH-MBX1.ipk-gatersleben.de>

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 <bauernfeind at ipk-gatersleben.de>
Cc: "OmniOS-discuss ?[omnios-discuss at lists.omniti.com]?" <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 <bauernfeind at ipk-gatersleben.de> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170106/9427be48/attachment-0001.bin>

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: <B9D9271554C34B41866AA2801A8FD279AC602A10@XCH-MBX1.ipk-gatersleben.de>
References: <B9D9271554C34B41866AA2801A8FD279AC5FDB04@XCH-MBX1.ipk-gatersleben.de>
	<A50B0DB0-A92D-4825-B6F5-869C541886A7@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC602A10@XCH-MBX1.ipk-gatersleben.de>
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: <B9D9271554C34B41866AA2801A8FD279AC5FDB04@XCH-MBX1.ipk-gatersleben.de>
	<A50B0DB0-A92D-4825-B6F5-869C541886A7@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC602A10@XCH-MBX1.ipk-gatersleben.de>
	<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: <B9D9271554C34B41866AA2801A8FD279AC5FDB04@XCH-MBX1.ipk-gatersleben.de>
	<A50B0DB0-A92D-4825-B6F5-869C541886A7@omniti.com>
	<B9D9271554C34B41866AA2801A8FD279AC602A10@XCH-MBX1.ipk-gatersleben.de>
	<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
<fs>/.zfs/snapshots or in 'zfs list -r -t all <fs>', 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 <cks at cs.toronto.edu> 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 <fs>/.zfs/snapshot/<snapshot-name>

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/<snapname> 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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/02ebc33e/attachment.html>

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: <D32FAB4A-8C67-4D5A-8EC9-2FAFFCD5E433@omniti.com>


> On Jan 9, 2017, at 11:13 AM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
> 
> The answer to my question turns out to be 'yes'. If you do:
> 	rmdir <fs>/.zfs/snapshot/<snapshot-name>
> 
> 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.
	<D32FAB4A-8C67-4D5A-8EC9-2FAFFCD5E433@omniti.com>
Message-ID: <20170109163916.808C25A06C3@apps1.cs.toronto.edu>

> > On Jan 9, 2017, at 11:13 AM, Chris Siebenmann <cks at cs.toronto.edu> wrote:
> > 
> > The answer to my question turns out to be 'yes'. If you do:
> > 	rmdir <fs>/.zfs/snapshot/<snapshot-name>
> > 
> > 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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
Message-ID: <8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>


> On Jan 9, 2017, at 11:25 AM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
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 <miniflowtrader at gmail.com> 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: <A0D981A9-6FCE-4018-88A0-2042AD31DF04@omniti.com>

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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com>
Message-ID: <CACFEqhtm24tTMFSCjddsP7=CVpv-QwHcg=uojapnh4eGneMD3Q@mail.gmail.com>

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 <daleg at omniti.com> 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 <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/27c4f731/attachment.html>

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: <CACFEqhtm24tTMFSCjddsP7=CVpv-QwHcg=uojapnh4eGneMD3Q@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com>
	<CACFEqhtm24tTMFSCjddsP7=CVpv-QwHcg=uojapnh4eGneMD3Q@mail.gmail.com>
Message-ID: <CACFEqhujKHbQV1LeRSE5gPB_j+zBpN4DBRNG4J3BdzUsue+9+A@mail.gmail.com>

The above was tested with Debian 8.6 SmartOS image.

On Mon, Jan 9, 2017 at 12:35 PM Mini Trader <miniflowtrader at gmail.com>
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 <daleg at omniti.com> 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 <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/ec333b64/attachment.html>

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 <skeltonr at btconnect.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/1d11f2e6/attachment.bin>

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 <skeltonr at btconnect.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/4fb46c7d/attachment.html>

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 <skeltonr at btconnect.com> 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 <skeltonr at btconnect.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/334b43ab/attachment.html>

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 <skeltonr at btconnect.com> 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 <skeltonr at btconnect.com>
>>>  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: <CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
Message-ID: <CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>

The test case was in my previous post.

On Mon, Jan 9, 2017 at 1:53 PM Jerry Jelinek <jerry.jelinek at joyent.com>
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 <danmcd at omniti.com> wrote:
>
>
>
>
> > On Jan 9, 2017, at 11:25 AM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/6f88aea3/attachment.html>

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: <CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
Message-ID: <BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>


> On Jan 9, 2017, at 2:31 PM, Mini Trader <miniflowtrader at gmail.com> 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 <skeltonr at btconnect.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/f0c9c19c/attachment.html>

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: <BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
Message-ID: <CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>

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 <danmcd at omniti.com> wrote:



> On Jan 9, 2017, at 2:31 PM, Mini Trader <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/bbd9b4bf/attachment-0001.html>

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: <CACFEqhujKHbQV1LeRSE5gPB_j+zBpN4DBRNG4J3BdzUsue+9+A@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<308D2FAB-ED56-4C75-984A-EB9BDD382366@omniti.com>
	<CACFEqhtm24tTMFSCjddsP7=CVpv-QwHcg=uojapnh4eGneMD3Q@mail.gmail.com>
	<CACFEqhujKHbQV1LeRSE5gPB_j+zBpN4DBRNG4J3BdzUsue+9+A@mail.gmail.com>
Message-ID: <43DC5C73-6B1D-4707-9EE3-E7138413131C@omniti.com>


> On Jan 9, 2017, at 12:36 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
Message-ID: <31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>


> On Jan 9, 2017, at 2:58 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
Message-ID: <CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
>
> > On Jan 9, 2017, at 2:58 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/406be8b6/attachment.html>

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: <CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
Message-ID: <7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>


> On Jan 9, 2017, at 3:22 PM, Mini Trader <miniflowtrader at gmail.com> 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 <skeltonr at btconnect.com> 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 <skeltonr at btconnect.com>
>>>  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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
Message-ID: <CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
> > On Jan 9, 2017, at 3:22 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/e49d76ce/attachment-0001.html>

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: <CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
Message-ID: <2044EEC2-68B2-4748-AA76-4EF388DFDEEA@omniti.com>


> On Jan 9, 2017, at 8:09 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<2044EEC2-68B2-4748-AA76-4EF388DFDEEA@omniti.com>
Message-ID: <CACFEqhvw5Cr42_8Ugmwm4MEUZfyEeUEzTiYMF0tJeECFHa8-kw@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
> > On Jan 9, 2017, at 8:09 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/e561d9aa/attachment.html>

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: <CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
Message-ID: <CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>

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 <miniflowtrader at gmail.com>
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 <danmcd at omniti.com> wrote:
>
>>
>> > On Jan 9, 2017, at 3:22 PM, Mini Trader <miniflowtrader at gmail.com>
>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/d1096857/attachment.html>

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: <CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
Message-ID: <3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>


> On Jan 9, 2017, at 9:51 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
	<3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>
Message-ID: <CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>

# 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 <danmcd at omniti.com> wrote:

>
> > On Jan 9, 2017, at 9:51 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/d0a86b84/attachment-0001.html>

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: <CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
	<3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>
	<CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>
Message-ID: <698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com>


> On Jan 9, 2017, at 10:01 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
	<3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>
	<CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>
	<698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com>
Message-ID: <CACFEqht-PrwzCNWy0EaCRteXT9QhUOiUHKMvMX35KJXNJKhD7g@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
> > On Jan 9, 2017, at 10:01 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170109/acaa835c/attachment.html>

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: <CACFEqht-PrwzCNWy0EaCRteXT9QhUOiUHKMvMX35KJXNJKhD7g@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
	<3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>
	<CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>
	<698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com>
	<CACFEqht-PrwzCNWy0EaCRteXT9QhUOiUHKMvMX35KJXNJKhD7g@mail.gmail.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 <danmcd at omniti.com 
> <mailto:danmcd at omniti.com>> wrote:
>
>
>     > On Jan 9, 2017, at 10:01 PM, Mini Trader
>     <miniflowtrader at gmail.com <mailto:miniflowtrader at gmail.com>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/bbfe9530/attachment.html>

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: <CACFEqht-PrwzCNWy0EaCRteXT9QhUOiUHKMvMX35KJXNJKhD7g@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
	<3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>
	<CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>
	<698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com>
	<CACFEqht-PrwzCNWy0EaCRteXT9QhUOiUHKMvMX35KJXNJKhD7g@mail.gmail.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 <danmcd at omniti.com
> <mailto:danmcd at omniti.com>> wrote:
>
>
>     > On Jan 9, 2017, at 10:01 PM, Mini Trader
>     <miniflowtrader at gmail.com <mailto:miniflowtrader at gmail.com>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/12a35ada/attachment-0001.html>
-------------- 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/12a35ada/attachment-0001.bin>

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: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/8e575501/attachment.html>

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: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<8234CA17-AC0F-4920-B485-D686C7F67F78@omniti.com>
	<CACPQ5Fq1got2EutuKW1zQTmBhNk-Qh+c7=tHNVRPSV507HcfNw@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
	<3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>
	<CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>
	<698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com>
	<CACFEqht-PrwzCNWy0EaCRteXT9QhUOiUHKMvMX35KJXNJKhD7g@mail.gmail.com>
	<9694c37d-818b-1c8c-64c8-5d6ee8e919bc@kiv.pp.ru>
Message-ID: <CACFEqhv-mDWifPOk7nRZhpur_oB8oT9kCyVYFAasBRgVRE5fdg@mail.gmail.com>

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, ???? ??????? <kiv at kiv.pp.ru> 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 <danmcd at omniti.com> wrote:
>
>>
>> > On Jan 9, 2017, at 10:01 PM, Mini Trader <miniflowtrader at gmail.com>
>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/148d2476/attachment-0001.html>

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: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>
References: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>
Message-ID: <e818b032-ecc9-3964-2a6d-276d75f9b657@will.to>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/eeab4b74/attachment.html>

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: <CACFEqhv-mDWifPOk7nRZhpur_oB8oT9kCyVYFAasBRgVRE5fdg@mail.gmail.com>
References: <CACFEqhuCSGGyWAVW_TbzAu38TDiy_o1J=s2c-V2YEEw--P0Y3w@mail.gmail.com>
	<CACFEqhunT15KNtsLa77da0k4pHozbBMsoKrT=HsaWJvmpC7iOw@mail.gmail.com>
	<BBE18323-01ED-4156-907B-6AFCA74700FD@omniti.com>
	<CACFEqhvFYeNrZrnHJgmyesGuwM_enx-SBAX4ygX2swsHDdbSfg@mail.gmail.com>
	<31ECA0D2-C7F9-4793-8F91-0BDD3835A82F@omniti.com>
	<CACFEqhsXx_9=OHgnY_3RocsZqS1fYqtR4d0PQQRM6QbhviLH_Q@mail.gmail.com>
	<7EABAF61-370C-450B-9667-6E3715A160FE@omniti.com>
	<CACFEqhuuC-xbwHwVFCZ6DJB4OtQZ+=+HGn5D7BN+YvfdUXPE=Q@mail.gmail.com>
	<CACFEqhungHP-WcXzCSdaY-TeSHbUYTJuFW7iMEtJ32RmbZLEDA@mail.gmail.com>
	<3BE95B6A-A197-4BD4-81E5-5CC595C8C662@omniti.com>
	<CACFEqhtOKoA+NfqJaseyZJDLJ=dMy6bkgxXvc51aYF-AWEzCNQ@mail.gmail.com>
	<698B5BFA-479C-4A56-82A5-6C4975DD95A3@omniti.com>
	<CACFEqht-PrwzCNWy0EaCRteXT9QhUOiUHKMvMX35KJXNJKhD7g@mail.gmail.com>
	<9694c37d-818b-1c8c-64c8-5d6ee8e919bc@kiv.pp.ru>
	<CACFEqhv-mDWifPOk7nRZhpur_oB8oT9kCyVYFAasBRgVRE5fdg@mail.gmail.com>
Message-ID: <e32fe1f1-5220-f77a-274e-be71f646ae9a@kiv.pp.ru>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/b6fc643a/attachment.html>
-------------- 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/b6fc643a/attachment.bin>

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: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>
References: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>
Message-ID: <B68DE441-8AFA-42D4-863C-AE63B78459CE@omniti.com>


> On Jan 10, 2017, at 8:41 AM, Schweiss, Chip <chip at innovates.com> 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: <B68DE441-8AFA-42D4-863C-AE63B78459CE@omniti.com>
References: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>
	<B68DE441-8AFA-42D4-863C-AE63B78459CE@omniti.com>
Message-ID: <CALeZrrRDeyD5KG70DUNDEpq1eQsWHSnoqwLZ+34wDk19icr4ag@mail.gmail.com>

On Tue, Jan 10, 2017 at 9:58 AM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Jan 10, 2017, at 8:41 AM, Schweiss, Chip <chip at innovates.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/8e57954e/attachment.html>

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: <CALeZrrRDeyD5KG70DUNDEpq1eQsWHSnoqwLZ+34wDk19icr4ag@mail.gmail.com>
References: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>
	<B68DE441-8AFA-42D4-863C-AE63B78459CE@omniti.com>
	<CALeZrrRDeyD5KG70DUNDEpq1eQsWHSnoqwLZ+34wDk19icr4ag@mail.gmail.com>
Message-ID: <955F208B-CA50-45FC-948F-FBF46082B235@omniti.com>


> On Jan 10, 2017, at 11:10 AM, Schweiss, Chip <chip at innovates.com> 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: <CALeZrrRDeyD5KG70DUNDEpq1eQsWHSnoqwLZ+34wDk19icr4ag@mail.gmail.com>
References: <CALeZrrTr4vFfcq0J3ZrD1qrKs6rfcPOu6bd436nTSGpxMLi=Cw@mail.gmail.com>
	<B68DE441-8AFA-42D4-863C-AE63B78459CE@omniti.com>
	<CALeZrrRDeyD5KG70DUNDEpq1eQsWHSnoqwLZ+34wDk19icr4ag@mail.gmail.com>
Message-ID: <CAPJtH1iyepmqPAG9H_fJAs5s+kBZ3xBSE0-g_c_eZ2zdX5vJuA@mail.gmail.com>

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 <chip at innovates.com> wrote:

>
> On Tue, Jan 10, 2017 at 9:58 AM, Dan McDonald <danmcd at omniti.com> wrote:
>
>>
>> > On Jan 10, 2017, at 8:41 AM, Schweiss, Chip <chip at innovates.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/314e8e1d/attachment.html>

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 <fs>/.zfs/snapshot/<snapshot-name>
> 
> 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/<snapname> 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/<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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>

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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
Message-ID: <CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>


> On Jan 10, 2017, at 5:04 PM, Dominik Hassler <hasslerd at gmx.li> 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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
Message-ID: <9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com>


> On Jan 10, 2017, at 5:04 PM, Dominik Hassler <hasslerd at gmx.li> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/223a1486/attachment.bin>

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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com>
Message-ID: <e3eacc4b-d7ad-48a2-db77-0b53260812a6@gmx.li>

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 <hasslerd at gmx.li> 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: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/d75d53bb/attachment.html>

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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com>
Message-ID: <CACFEqhuo6vZ4t27Ogu9Romyjg=9QFzrLJd2va7x6DxhiDnSrEw@mail.gmail.com>

No Python 3.x ?

On Tue, Jan 10, 2017 at 6:04 PM, Dale Ghent <daleg at omniti.com> wrote:

>
> > On Jan 10, 2017, at 5:04 PM, Dominik Hassler <hasslerd at gmx.li> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170110/8e26a525/attachment.html>

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: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
References: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
Message-ID: <BE480A8F-D74F-41FB-B40F-1F84F063A0EE@omniti.com>


> On Jan 10, 2017, at 6:49 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhuo6vZ4t27Ogu9Romyjg=9QFzrLJd2va7x6DxhiDnSrEw@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<9B32A7D6-8C5C-4FAA-A78A-36123E4CCB7B@omniti.com>
	<CACFEqhuo6vZ4t27Ogu9Romyjg=9QFzrLJd2va7x6DxhiDnSrEw@mail.gmail.com>
Message-ID: <FD730E50-1F1E-45AB-B953-A6672331FE1A@omniti.com>


> On Jan 10, 2017, at 6:50 PM, Mini Trader <miniflowtrader at gmail.com> 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: <BE480A8F-D74F-41FB-B40F-1F84F063A0EE@omniti.com>
References: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
	<BE480A8F-D74F-41FB-B40F-1F84F063A0EE@omniti.com>
Message-ID: <CACFEqhs+h+JH96Vsy9mAB0VF=nj+_wZWh4vGcYdgV9bzpKgsmw@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
>
> > On Jan 10, 2017, at 6:49 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/7971f8ab/attachment-0001.html>

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: <CACFEqhs+h+JH96Vsy9mAB0VF=nj+_wZWh4vGcYdgV9bzpKgsmw@mail.gmail.com>
References: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
	<BE480A8F-D74F-41FB-B40F-1F84F063A0EE@omniti.com>
	<CACFEqhs+h+JH96Vsy9mAB0VF=nj+_wZWh4vGcYdgV9bzpKgsmw@mail.gmail.com>
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: <CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
Message-ID: <alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>


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: <CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/46d75676/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/46d75676/attachment.bin>

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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch>
Message-ID: <CAOc1FHhaYJbznP6R_T21zOmv4mru7Y=8LGFnhgsbC_VthhS-gQ@mail.gmail.com>

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 <tobi at oetiker.ch> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/d8831339/attachment.html>

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 <stephan.budach at jvm.de> 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: <E76A7F98-B1F0-4F67-A13C-51B45633E918@omniti.com>


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 <daleg at omniti.com> 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 <stephan.budach at jvm.de> 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: <E76A7F98-B1F0-4F67-A13C-51B45633E918@omniti.com>
References: <7249d0d7-a96c-6a82-e8e7-5fe20274e4d7@jvm.de>
	<921B63AC-0749-4157-AEDE-7B600100AB9C@omniti.com>
	<E76A7F98-B1F0-4F67-A13C-51B45633E918@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 <daleg at omniti.com> 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 <stephan.budach at jvm.de> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/26ba01ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/26ba01ab/attachment.bin>

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: <CAOc1FHhaYJbznP6R_T21zOmv4mru7Y=8LGFnhgsbC_VthhS-gQ@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch>
	<CAOc1FHhaYJbznP6R_T21zOmv4mru7Y=8LGFnhgsbC_VthhS-gQ@mail.gmail.com>
Message-ID: <CACFEqhvnD5daNDa9yTrArmu6eSswo=xHUtAayxkyDMvj=f-xkw@mail.gmail.com>

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 <nshalman at omniti.com> 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 <tobi at oetiker.ch> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/9be7c755/attachment-0001.html>

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: <CACFEqhvnD5daNDa9yTrArmu6eSswo=xHUtAayxkyDMvj=f-xkw@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch>
	<CAOc1FHhaYJbznP6R_T21zOmv4mru7Y=8LGFnhgsbC_VthhS-gQ@mail.gmail.com>
	<CACFEqhvnD5daNDa9yTrArmu6eSswo=xHUtAayxkyDMvj=f-xkw@mail.gmail.com>
Message-ID: <CAOc1FHiop8Nvfna1T81mGWmWi=o2sq4+kVP-g5rkFKhcwt788w@mail.gmail.com>

On Wed, Jan 11, 2017 at 11:01 AM, Mini Trader <miniflowtrader at gmail.com>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/a3e7a29f/attachment.html>

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: <CAOc1FHiop8Nvfna1T81mGWmWi=o2sq4+kVP-g5rkFKhcwt788w@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch>
	<CAOc1FHhaYJbznP6R_T21zOmv4mru7Y=8LGFnhgsbC_VthhS-gQ@mail.gmail.com>
	<CACFEqhvnD5daNDa9yTrArmu6eSswo=xHUtAayxkyDMvj=f-xkw@mail.gmail.com>
	<CAOc1FHiop8Nvfna1T81mGWmWi=o2sq4+kVP-g5rkFKhcwt788w@mail.gmail.com>
Message-ID: <CACFEqhtAGWrgtsrE4YzPrvWveQhQ8k3cvgNmG_O7SsHWGRCZKw@mail.gmail.com>

If the hardware is there will it be used?

On Wed, Jan 11, 2017 at 11:33 AM Nahum Shalman <nshalman at omniti.com> wrote:

> On Wed, Jan 11, 2017 at 11:01 AM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/ab41ea1f/attachment.html>

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: <CACFEqhtAGWrgtsrE4YzPrvWveQhQ8k3cvgNmG_O7SsHWGRCZKw@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<1784006870.1542154.1484129325832.JavaMail.zimbra@oetiker.ch>
	<CAOc1FHhaYJbznP6R_T21zOmv4mru7Y=8LGFnhgsbC_VthhS-gQ@mail.gmail.com>
	<CACFEqhvnD5daNDa9yTrArmu6eSswo=xHUtAayxkyDMvj=f-xkw@mail.gmail.com>
	<CAOc1FHiop8Nvfna1T81mGWmWi=o2sq4+kVP-g5rkFKhcwt788w@mail.gmail.com>
	<CACFEqhtAGWrgtsrE4YzPrvWveQhQ8k3cvgNmG_O7SsHWGRCZKw@mail.gmail.com>
Message-ID: <C6152882-EBA8-4BD8-9595-C72BF3A6B489@omniti.com>


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 <miniflowtrader at gmail.com> wrote:
> 
> If the hardware is there will it be used?
> 
> On Wed, Jan 11, 2017 at 11:33 AM Nahum Shalman <nshalman at omniti.com> wrote:
> On Wed, Jan 11, 2017 at 11:01 AM, Mini Trader <miniflowtrader at gmail.com> 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: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
References: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
Message-ID: <20170111172737.GC13272@linux.gyakg.u-szeged.hu>

Hi,

"Mini Trader" <miniflowtrader at gmail.com> ?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: <alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
Message-ID: <78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>


> On Jan 11, 2017, at 5:04 AM, Andy Fiddaman <omnios at citrus-it.net> 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: <CACFEqhs+h+JH96Vsy9mAB0VF=nj+_wZWh4vGcYdgV9bzpKgsmw@mail.gmail.com>
References: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
	<BE480A8F-D74F-41FB-B40F-1F84F063A0EE@omniti.com>
	<CACFEqhs+h+JH96Vsy9mAB0VF=nj+_wZWh4vGcYdgV9bzpKgsmw@mail.gmail.com>
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 <danmcd at omniti.com 
> <mailto:danmcd at omniti.com>> wrote:
>
>
>
>     > On Jan 10, 2017, at 6:49 PM, Mini Trader
>     <miniflowtrader at gmail.com <mailto:miniflowtrader at gmail.com>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/f46abc2f/attachment-0001.html>

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: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
	<BE480A8F-D74F-41FB-B40F-1F84F063A0EE@omniti.com>
	<CACFEqhs+h+JH96Vsy9mAB0VF=nj+_wZWh4vGcYdgV9bzpKgsmw@mail.gmail.com>
	<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 <lkateley at kateley.com> 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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
Message-ID: <CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
>
> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman <omnios at citrus-it.net> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/c1644a5c/attachment.html>

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: <CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
Message-ID: <A2E0F4AB-70BA-484C-85AF-D17C6358D664@omniti.com>


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 <miniflowtrader at gmail.com> 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 <danmcd at omniti.com> wrote:
> 
> 
> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman <omnios at citrus-it.net> 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: <CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
Message-ID: <F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>

12 ?????? 2017??. 0:13:39 CET, Mini Trader <miniflowtrader at gmail.com> ?????:
>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 <danmcd at omniti.com> wrote:
>
>>
>>
>> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman <omnios at citrus-it.net>
>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: <CACFEqhu72LiUyZttG6b5rgVgHSHGuxmkm2zD+yXuup7+H1ccTA@mail.gmail.com>
	<BE480A8F-D74F-41FB-B40F-1F84F063A0EE@omniti.com>
	<CACFEqhs+h+JH96Vsy9mAB0VF=nj+_wZWh4vGcYdgV9bzpKgsmw@mail.gmail.com>
	<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 <danmcd at omniti.com> ?????:
>
>> On Jan 11, 2017, at 2:57 PM, Linda Kateley <lkateley at kateley.com>
>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: <F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
Message-ID: <CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>

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 <jimklimov at cos.ru> wrote:

> 12 ?????? 2017 ?. 0:13:39 CET, Mini Trader <miniflowtrader at gmail.com>
> ?????:
> >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 <danmcd at omniti.com> wrote:
> >
> >>
> >>
> >> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman <omnios at citrus-it.net>
> >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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/85c8aad3/attachment-0001.html>

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: <CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
Message-ID: <5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>


> On Jan 11, 2017, at 8:15 PM, Mini Trader <miniflowtrader at gmail.com> 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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
Message-ID: <CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
> > On Jan 11, 2017, at 8:15 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/4135240f/attachment.html>

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: <CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
Message-ID: <E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>


> On Jan 11, 2017, at 8:25 PM, Mini Trader <miniflowtrader at gmail.com> 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: <E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
	<E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
Message-ID: <CACFEqhukaWQaDjeRajmAoZhxik-0n4ULcDM6W8ZZKDODP9nQSA@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
> > On Jan 11, 2017, at 8:25 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/618945bc/attachment.html>

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: <E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
	<E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@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 <danmcd at omniti.com> wrote:
> 
> 
>> On Jan 11, 2017, at 8:25 PM, Mini Trader <miniflowtrader at gmail.com> 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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
	<E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
	<1873BA18-38D1-4D68-A1B8-0E6046B02264@avsquad.com>
Message-ID: <CACFEqhu7SsyxXUVo2M3gM6imBvxLCqzK=Z+7aJMVA2qer=kNXw@mail.gmail.com>

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 <ergi.thanasko at avsquad.com>
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 <danmcd at omniti.com> wrote:
> >
> >
> >> On Jan 11, 2017, at 8:25 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/750a6d81/attachment-0001.html>

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: <CACFEqhukaWQaDjeRajmAoZhxik-0n4ULcDM6W8ZZKDODP9nQSA@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
	<E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
	<CACFEqhukaWQaDjeRajmAoZhxik-0n4ULcDM6W8ZZKDODP9nQSA@mail.gmail.com>
Message-ID: <39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com>


> On Jan 11, 2017, at 8:32 PM, Mini Trader <miniflowtrader at gmail.com> 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: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
	<E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
	<CACFEqhukaWQaDjeRajmAoZhxik-0n4ULcDM6W8ZZKDODP9nQSA@mail.gmail.com>
	<39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com>
Message-ID: <CACFEqhsSqCEVdasD0MXz0xpD9-dtuVspdLO6Gt10W82X5xubsQ@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

>
> > On Jan 11, 2017, at 8:32 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170111/5cddb0f3/attachment.html>

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: <CACFEqhsSqCEVdasD0MXz0xpD9-dtuVspdLO6Gt10W82X5xubsQ@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
	<E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
	<CACFEqhukaWQaDjeRajmAoZhxik-0n4ULcDM6W8ZZKDODP9nQSA@mail.gmail.com>
	<39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com>
	<CACFEqhsSqCEVdasD0MXz0xpD9-dtuVspdLO6Gt10W82X5xubsQ@mail.gmail.com>
Message-ID: <0CB52D32-5F9E-49CD-8510-A5AD6B40D301@omniti.com>


> On Jan 11, 2017, at 9:15 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CAN0RhANJrneQvrBZjXN7jQ4n8aFiDHavd1iPoJMVxgO8gFd5Ug@mail.gmail.com>

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.<ifname> 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: <CACFEqhsSqCEVdasD0MXz0xpD9-dtuVspdLO6Gt10W82X5xubsQ@mail.gmail.com>
References: <dcf69504-cb86-284d-05b1-aa378724e5e4@gmx.li>
	<CB48B92C-B671-4B5C-842B-C254BB4CA8AB@omniti.com>
	<alpine.GSO.2.00.1701111003060.12696@erncre.pvgehf-vg.arg>
	<78AF3DAF-596A-4F29-9880-0A7BF7D43525@omniti.com>
	<CACFEqhuLrnHCRVWQgVJQDGGdg018=5yFKdugOusPg5RRU7TBAQ@mail.gmail.com>
	<F9B94799-21F8-4E5E-A2AD-EA7F193DD242@cos.ru>
	<CACFEqht5kFj+bbFa-xLn056TZ9PXh34UVQPgz8i45hv_TbS14w@mail.gmail.com>
	<5DB05BAE-468E-4D02-A898-97D8758E0E9A@omniti.com>
	<CACFEqhvzaZBmTLPQswZKP_YPjoaePsVYzwLda_VrGaf4rupDHg@mail.gmail.com>
	<E2832E1C-4DA0-4DC6-94AE-BC5B6AB98724@omniti.com>
	<CACFEqhukaWQaDjeRajmAoZhxik-0n4ULcDM6W8ZZKDODP9nQSA@mail.gmail.com>
	<39B9641C-5EDB-455C-AAF6-92CA5DC12F8A@omniti.com>
	<CACFEqhsSqCEVdasD0MXz0xpD9-dtuVspdLO6Gt10W82X5xubsQ@mail.gmail.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 <danmcd at omniti.com 
> <mailto:danmcd at omniti.com>> wrote:
>
>
>     > On Jan 11, 2017, at 8:32 PM, Mini Trader
>     <miniflowtrader at gmail.com <mailto:miniflowtrader at gmail.com>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170112/2bb7746a/attachment-0001.html>

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: <CAESZ+__GF7sUsDeMKBetE++wrL-oRCYrpRLj0o9HRWzx-Km2Kw@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170112/86c04164/attachment.html>

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: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/478cb3d5/attachment.html>

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: <d0fe2347-cc99-f79b-09b1-7778c51e0149@jvm.de>

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<pg,wp,ne,et,ts,mp,pe> cr4: 
1426f8<smep,osxsav,vmxe,xmme,fxsr,pge,mce,pae,pse,de>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/905a30eb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/905a30eb/attachment-0001.bin>

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: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
Message-ID: <CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>

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 <miniflowtrader at gmail.com>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/62640c54/attachment.html>

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: <CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
Message-ID: <CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>

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 <nshalman at omniti.com> 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 <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/e48de3d2/attachment.html>

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: <CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
Message-ID: <CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>

Have you tried simply tracing the lx-syscall probes?

On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader <miniflowtrader at gmail.com>
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 <nshalman at omniti.com> 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 <miniflowtrader at gmail.com>
>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/d1e5d7c9/attachment.html>

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: <d0fe2347-cc99-f79b-09b1-7778c51e0149@jvm.de>
References: <d0fe2347-cc99-f79b-09b1-7778c51e0149@jvm.de>
Message-ID: <AC3BEE8A-51D7-48D7-BBD1-FCC6BFA7A551@omniti.com>

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: <CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
Message-ID: <CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>

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 <nshalman at omniti.com> wrote:

> Have you tried simply tracing the lx-syscall probes?
>
> On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader <miniflowtrader at gmail.com>
> 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 <nshalman at omniti.com>
>> 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 <miniflowtrader at gmail.com>
>>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/fffc1638/attachment-0001.html>

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: <CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
	<CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
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 <miniflowtrader at gmail.com> 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 <nshalman at omniti.com> wrote:
> Have you tried simply tracing the lx-syscall probes?
> 
> On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader <miniflowtrader at gmail.com> 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 <nshalman at omniti.com> 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 <miniflowtrader at gmail.com> 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: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
	<CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
	<293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com>
Message-ID: <CACFEqhteoNW6d5ttfWEYdw7KCqg-VO+KJbBk+xSSOm3WpZ_Axg@mail.gmail.com>

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 <daleg at omniti.com> 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 <miniflowtrader at gmail.com>
> 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 <nshalman at omniti.com>
> wrote:
> > Have you tried simply tracing the lx-syscall probes?
> >
> > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader <miniflowtrader at gmail.com>
> 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 <nshalman at omniti.com>
> 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 <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170113/7f79fea0/attachment.html>

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: <CACFEqhteoNW6d5ttfWEYdw7KCqg-VO+KJbBk+xSSOm3WpZ_Axg@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
	<CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
	<293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com>
	<CACFEqhteoNW6d5ttfWEYdw7KCqg-VO+KJbBk+xSSOm3WpZ_Axg@mail.gmail.com>
Message-ID: <CACFEqhtkoBnGUusmobspvSGbFJFJhYXnLK0cHBfHCgjH3uZ1+w@mail.gmail.com>

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 <miniflowtrader at gmail.com>
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 <daleg at omniti.com> 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 <miniflowtrader at gmail.com>
>> 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 <nshalman at omniti.com>
>> wrote:
>> > Have you tried simply tracing the lx-syscall probes?
>> >
>> > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader <miniflowtrader at gmail.com>
>> 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 <nshalman at omniti.com>
>> 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 <miniflowtrader at gmail.com>
>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170114/9f4aefda/attachment-0001.html>

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: <CACFEqhtkoBnGUusmobspvSGbFJFJhYXnLK0cHBfHCgjH3uZ1+w@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
	<CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
	<293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com>
	<CACFEqhteoNW6d5ttfWEYdw7KCqg-VO+KJbBk+xSSOm3WpZ_Axg@mail.gmail.com>
	<CACFEqhtkoBnGUusmobspvSGbFJFJhYXnLK0cHBfHCgjH3uZ1+w@mail.gmail.com>
Message-ID: <CAHBEJzXSv4dCsmKK5=p09OCc5a+aCKWncBzUUJLYRgxUsfOraQ@mail.gmail.com>

hi,

On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader <miniflowtrader at gmail.com>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170114/fdb5e0b2/attachment.html>

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: <CAHBEJzXSv4dCsmKK5=p09OCc5a+aCKWncBzUUJLYRgxUsfOraQ@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
	<CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
	<293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com>
	<CACFEqhteoNW6d5ttfWEYdw7KCqg-VO+KJbBk+xSSOm3WpZ_Axg@mail.gmail.com>
	<CACFEqhtkoBnGUusmobspvSGbFJFJhYXnLK0cHBfHCgjH3uZ1+w@mail.gmail.com>
	<CAHBEJzXSv4dCsmKK5=p09OCc5a+aCKWncBzUUJLYRgxUsfOraQ@mail.gmail.com>
Message-ID: <CACFEqhvVPAHik+XBd=mGeyfbLDTH2QT3aq2h8DCR+FCYKcU2zg@mail.gmail.com>

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 <natxo.asenjo at gmail.com>
wrote:

> hi,
>
>
> On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170114/43e5a352/attachment.html>

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: <ED64EFFA-C8CD-4C6E-BD12-F1720279F20C@gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170114/4b4ec36e/attachment-0001.html>

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: <ED64EFFA-C8CD-4C6E-BD12-F1720279F20C@gmail.com>
References: <ED64EFFA-C8CD-4C6E-BD12-F1720279F20C@gmail.com>
Message-ID: <D6E0AA47-C025-49B9-8714-E783786EA279@omniti.com>

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 <matjaz85 at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170114/8d259950/attachment.html>

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: <D6E0AA47-C025-49B9-8714-E783786EA279@omniti.com>
References: <ED64EFFA-C8CD-4C6E-BD12-F1720279F20C@gmail.com>
	<D6E0AA47-C025-49B9-8714-E783786EA279@omniti.com>
Message-ID: <352A9A3B-8728-4F71-8B28-5B8795D69E48@gmail.com>

Thank you!

Cheers,
Matjaz

> On 15. jan. 2017, at 04:10, Dan McDonald <danmcd at omniti.com> 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 <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 <matjaz85 at gmail.com <mailto:matjaz85 at gmail.com>> 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 <mailto:OmniOS-discuss at lists.omniti.com>
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss <http://lists.omniti.com/mailman/listinfo/omnios-discuss>

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

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: <CACFEqhvVPAHik+XBd=mGeyfbLDTH2QT3aq2h8DCR+FCYKcU2zg@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
	<CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
	<293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com>
	<CACFEqhteoNW6d5ttfWEYdw7KCqg-VO+KJbBk+xSSOm3WpZ_Axg@mail.gmail.com>
	<CACFEqhtkoBnGUusmobspvSGbFJFJhYXnLK0cHBfHCgjH3uZ1+w@mail.gmail.com>
	<CAHBEJzXSv4dCsmKK5=p09OCc5a+aCKWncBzUUJLYRgxUsfOraQ@mail.gmail.com>
	<CACFEqhvVPAHik+XBd=mGeyfbLDTH2QT3aq2h8DCR+FCYKcU2zg@mail.gmail.com>
Message-ID: <CACFEqhsOYcX2j1YviVBe-UtFikKpsUXFWOodg78k+a17sJcbXA@mail.gmail.com>

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 <miniflowtrader at gmail.com>
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 <natxo.asenjo at gmail.com>
> wrote:
>
>> hi,
>>
>>
>> On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader <miniflowtrader at gmail.com>
>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170115/caba5cf0/attachment.html>

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 <limits.h> with the pakaged gcc48
	on omnios 151014.
Message-ID: <trinity-41b7a4be-c113-45df-8ada-54a348e1f8a9-1484554643768@3capp-gmx-bs04>

An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/8621c3ba/attachment.html>

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 <limits.h> with the pakaged
 gcc48 on omnios 151014.
In-Reply-To: <trinity-41b7a4be-c113-45df-8ada-54a348e1f8a9-1484554643768@3capp-gmx-bs04>
References: <trinity-41b7a4be-c113-45df-8ada-54a348e1f8a9-1484554643768@3capp-gmx-bs04>
Message-ID: <CAEgYsbHcipvwP-pKRiNZrzao657CsAz-qcH=f0rJC5iU+NgvTg@mail.gmail.com>

On Mon, Jan 16, 2017 at 8:17 AM, Rouven WEILER <Rouven_Weiler at gmx.net>
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 <limits.h>.
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/6744e1a4/attachment.html>

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: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/6b8e8520/attachment.html>

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: <ED64EFFA-C8CD-4C6E-BD12-F1720279F20C@gmail.com>
	<D6E0AA47-C025-49B9-8714-E783786EA279@omniti.com>
	<352A9A3B-8728-4F71-8B28-5B8795D69E48@gmail.com>
Message-ID: <ABE55E1E-05CD-4CFF-BE20-847C4742EA21@omniti.com>


> On Jan 15, 2017, at 7:05 AM, Matja? M <matjaz85 at gmail.com> 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: <CACFEqhsOYcX2j1YviVBe-UtFikKpsUXFWOodg78k+a17sJcbXA@mail.gmail.com>
References: <CACFEqhudLwOpH-hP2o=EWLfu0p04qqhAOiORy1fCtBSdF17Z-A@mail.gmail.com>
	<CAOc1FHjZRgbig2a3coTDStQ0+MDRG5bJ4UyW-jw63bwkdCP91g@mail.gmail.com>
	<CACFEqht1-58VKf1E7PnN=etT4yOU-XWk2run0dsPU3xr_cc5Xw@mail.gmail.com>
	<CAOc1FHiF9Z20oYJF0BkVBU3rOpkSaa7tJLLgNxfPaLEe+5Q6Bg@mail.gmail.com>
	<CACFEqhsNHDw7haNDmjUF6548O+q9Pnd5D0uz2P=H_XJHS=ntEQ@mail.gmail.com>
	<293EE06A-9E8C-4D64-BDA2-D24D7C6CA19E@omniti.com>
	<CACFEqhteoNW6d5ttfWEYdw7KCqg-VO+KJbBk+xSSOm3WpZ_Axg@mail.gmail.com>
	<CACFEqhtkoBnGUusmobspvSGbFJFJhYXnLK0cHBfHCgjH3uZ1+w@mail.gmail.com>
	<CAHBEJzXSv4dCsmKK5=p09OCc5a+aCKWncBzUUJLYRgxUsfOraQ@mail.gmail.com>
	<CACFEqhvVPAHik+XBd=mGeyfbLDTH2QT3aq2h8DCR+FCYKcU2zg@mail.gmail.com>
	<CACFEqhsOYcX2j1YviVBe-UtFikKpsUXFWOodg78k+a17sJcbXA@mail.gmail.com>
Message-ID: <693F7B53-C345-4BF6-BA7D-2DF88078CECE@omniti.com>


> On Jan 15, 2017, at 2:21 PM, Mini Trader <miniflowtrader at gmail.com> 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 <limits.h> with the pakaged
 gcc48 on omnios 151014.
In-Reply-To: <CAEgYsbHcipvwP-pKRiNZrzao657CsAz-qcH=f0rJC5iU+NgvTg@mail.gmail.com>
References: <trinity-41b7a4be-c113-45df-8ada-54a348e1f8a9-1484554643768@3capp-gmx-bs04>
	<CAEgYsbHcipvwP-pKRiNZrzao657CsAz-qcH=f0rJC5iU+NgvTg@mail.gmail.com>
Message-ID: <6FCE33A3-48C1-4914-876E-207EF363F906@omniti.com>


> On Jan 16, 2017, at 6:33 AM, Peter Tribble <peter.tribble at gmail.com> 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: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
Message-ID: <B1C31236-B707-491C-B1C4-9A98CC82FD47@omniti.com>

Thank you for doing this!  Some questions in-line:

> On Jan 16, 2017, at 10:40 AM, Mini Trader <miniflowtrader at gmail.com> 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: <B1C31236-B707-491C-B1C4-9A98CC82FD47@omniti.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<B1C31236-B707-491C-B1C4-9A98CC82FD47@omniti.com>
Message-ID: <CACFEqhtma2uZbjKSge+UJHGiGcZOqkC95pwtD3iVueZ=RxxrGg@mail.gmail.com>

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 <danmcd at omniti.com> wrote:

> Thank you for doing this!  Some questions in-line:
>
> > On Jan 16, 2017, at 10:40 AM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/e97f2b67/attachment.html>

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: <CACFEqhtma2uZbjKSge+UJHGiGcZOqkC95pwtD3iVueZ=RxxrGg@mail.gmail.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<B1C31236-B707-491C-B1C4-9A98CC82FD47@omniti.com>
	<CACFEqhtma2uZbjKSge+UJHGiGcZOqkC95pwtD3iVueZ=RxxrGg@mail.gmail.com>
Message-ID: <FAA1D82B-41CF-462B-9AD9-14C13A30B9D6@omniti.com>

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 <miniflowtrader at gmail.com> 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 <danmcd at omniti.com> wrote:
>> Thank you for doing this!  Some questions in-line:
>> 
>> > On Jan 16, 2017, at 10:40 AM, Mini Trader <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/3abd82de/attachment-0001.html>

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: <FAA1D82B-41CF-462B-9AD9-14C13A30B9D6@omniti.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<B1C31236-B707-491C-B1C4-9A98CC82FD47@omniti.com>
	<CACFEqhtma2uZbjKSge+UJHGiGcZOqkC95pwtD3iVueZ=RxxrGg@mail.gmail.com>
	<FAA1D82B-41CF-462B-9AD9-14C13A30B9D6@omniti.com>
Message-ID: <CACFEqhvffJwQN3-V_-ACF6=JTDhavjV3Kj7NXBeEn4iH98sisw@mail.gmail.com>

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 <danmcd at omniti.com> 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 <miniflowtrader at gmail.com> 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 <danmcd at omniti.com> wrote:
>
> Thank you for doing this!  Some questions in-line:
>
>
>
>
>
> > On Jan 16, 2017, at 10:40 AM, Mini Trader <miniflowtrader at gmail.com>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/7df8d28c/attachment.html>

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: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
Message-ID: <7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi>


> On 16 Jan 2017, at 17.40, Mini Trader <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/5d7f5ad2/attachment.html>

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: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi>
Message-ID: <CACFEqhsx4znecKwb6qRi-L8VRddr3mtZun5dmjayAWebPuyEQw@mail.gmail.com>

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 <miniflowtrader at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170116/b4802f34/attachment-0001.html>

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: <CACFEqhsx4znecKwb6qRi-L8VRddr3mtZun5dmjayAWebPuyEQw@mail.gmail.com>
References: <CACFEqht3yo2Z_4AU2Q02mz8k7VRFavDC8sVehMZOia6Nv_xP2g@mail.gmail.com>
	<7F4B9DB7-3E2C-4BDC-A2F6-107BFA934EB6@polarshift.fi>
	<CACFEqhsx4znecKwb6qRi-L8VRddr3mtZun5dmjayAWebPuyEQw@mail.gmail.com>
Message-ID: <9012C25D-BD6D-4619-9748-C0C66753EC86@omniti.com>


> On Jan 16, 2017, at 5:01 PM, Mini Trader <miniflowtrader at gmail.com> 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: <CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
Message-ID: <cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170117/1b96fffb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170117/1b96fffb/attachment.bin>

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: <cccfd91f-6164-f9a4-fdfa-a26645e954eb@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
Message-ID: <09494D67-D741-4610-958F-FBED913F92FF@omniti.com>


> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at jvm.de> 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: <cccfd91f-6164-f9a4-fdfa-a26645e954eb@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
Message-ID: <6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>


> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE> 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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
Message-ID: <b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>

Hi Dale,

Am 17.01.17 um 17:22 schrieb Dale Ghent:
>> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170117/e40cac3e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170117/e40cac3e/attachment-0001.bin>

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: <b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
Message-ID: <D36B7C43-B2CC-4250-B7F5-276772B4B038@omniti.com>

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: <b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
Message-ID: <A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>


> On Jan 17, 2017, at 11:31 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
> 
> Hi Dale,
> 
> Am 17.01.17 um 17:22 schrieb Dale Ghent:
>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>  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: <A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
Message-ID: <ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>

Am 17.01.17 um 17:37 schrieb Dale Ghent:
>> On Jan 17, 2017, at 11:31 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
>>
>> Hi Dale,
>>
>> Am 17.01.17 um 17:22 schrieb Dale Ghent:
>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>   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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170117/dd578ada/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170117/dd578ada/attachment-0001.bin>

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: <ef6d70ce-9452-e40b-268e-341191d029be@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
Message-ID: <20170117205428.2959ffc4@sleipner.datanom.net>

On Tue, 17 Jan 2017 20:39:49 +0100
Stephan Budach <stephan.budach at jvm.de> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170117/1500ad41/attachment.bin>

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: <ef6d70ce-9452-e40b-268e-341191d029be@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
Message-ID: <7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>


> On Jan 17, 2017, at 2:39 PM, Stephan Budach <stephan.budach at JVM.DE> wrote:
> 
> Am 17.01.17 um 17:37 schrieb Dale Ghent:
>>> On Jan 17, 2017, at 11:31 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>  wrote:
>>> 
>>> Hi Dale,
>>> 
>>> Am 17.01.17 um 17:22 schrieb Dale Ghent:
>>> 
>>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>> 
>>>>>  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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<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 <stephan.budach at JVM.DE> wrote:
>>
>> Am 17.01.17 um 17:37 schrieb Dale Ghent:
>>>> On Jan 17, 2017, at 11:31 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>   wrote:
>>>>
>>>> Hi Dale,
>>>>
>>>> Am 17.01.17 um 17:22 schrieb Dale Ghent:
>>>>
>>>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>>>
>>>>>>   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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170118/0aa2e882/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170118/0aa2e882/attachment-0001.bin>

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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>
	<8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de>
Message-ID: <ACBED270-C0A6-4649-8081-C4882CD6412F@omniti.com>


> On Jan 18, 2017, at 2:38 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
> 
> Am 17.01.17 um 23:09 schrieb Dale Ghent:
>>> On Jan 17, 2017, at 2:39 PM, Stephan Budach <stephan.budach at JVM.DE>
>>>  wrote:
>>> 
>>> Am 17.01.17 um 17:37 schrieb Dale Ghent:
>>> 
>>>>> On Jan 17, 2017, at 11:31 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>> 
>>>>>  wrote:
>>>>> 
>>>>> Hi Dale,
>>>>> 
>>>>> Am 17.01.17 um 17:22 schrieb Dale Ghent:
>>>>> 
>>>>> 
>>>>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>>>> 
>>>>>>> 
>>>>>>>  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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<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: <ACBED270-C0A6-4649-8081-C4882CD6412F@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>
	<8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de>
	<ACBED270-C0A6-4649-8081-C4882CD6412F@omniti.com>
Message-ID: <aa4d05f4-94ae-c2f5-2fa3-a791e9d6d767@jvm.de>

Am 18.01.17 um 09:01 schrieb Dale Ghent:
>> On Jan 18, 2017, at 2:38 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
>>
>> Am 17.01.17 um 23:09 schrieb Dale Ghent:
>>>> On Jan 17, 2017, at 2:39 PM, Stephan Budach <stephan.budach at JVM.DE>
>>>>   wrote:
>>>>
>>>> Am 17.01.17 um 17:37 schrieb Dale Ghent:
>>>>
>>>>>> On Jan 17, 2017, at 11:31 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>>>
>>>>>>   wrote:
>>>>>>
>>>>>> Hi Dale,
>>>>>>
>>>>>> Am 17.01.17 um 17:22 schrieb Dale Ghent:
>>>>>>
>>>>>>
>>>>>>>> On Jan 17, 2017, at 11:12 AM, Stephan Budach <stephan.budach at JVM.DE>
>>>>>>>>
>>>>>>>>
>>>>>>>>   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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170118/41fa7e69/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170118/41fa7e69/attachment-0001.bin>

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: <aa4d05f4-94ae-c2f5-2fa3-a791e9d6d767@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>
	<8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de>
	<ACBED270-C0A6-4649-8081-C4882CD6412F@omniti.com>
	<aa4d05f4-94ae-c2f5-2fa3-a791e9d6d767@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>
	<8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de>
	<ACBED270-C0A6-4649-8081-C4882CD6412F@omniti.com>
	<aa4d05f4-94ae-c2f5-2fa3-a791e9d6d767@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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170118/24b55caf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170118/24b55caf/attachment.bin>

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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>
	<8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de>
	<ACBED270-C0A6-4649-8081-C4882CD6412F@omniti.com>
	<aa4d05f4-94ae-c2f5-2fa3-a791e9d6d767@jvm.de>
	<474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com>
	<79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de>
Message-ID: <adb3397b-4a17-e31b-dc6d-00188204e038@jvm.de>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170119/ec9528f5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170119/ec9528f5/attachment-0001.bin>

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: <adb3397b-4a17-e31b-dc6d-00188204e038@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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>
	<8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de>
	<ACBED270-C0A6-4649-8081-C4882CD6412F@omniti.com>
	<aa4d05f4-94ae-c2f5-2fa3-a791e9d6d767@jvm.de>
	<474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com>
	<79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de>
	<adb3397b-4a17-e31b-dc6d-00188204e038@jvm.de>
Message-ID: <26637FD4-0792-47DB-BEA9-7D1FA7EE83D2@omniti.com>


> On Jan 19, 2017, at 4:27 AM, Stephan Budach <stephan.budach at JVM.DE> 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: <e9f9f3bd-b17b-3cea-7b91-bb5f7676ed0a@gmx.li>

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 <lx-zone>', 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: <e9f9f3bd-b17b-3cea-7b91-bb5f7676ed0a@gmx.li>
References: <e9f9f3bd-b17b-3cea-7b91-bb5f7676ed0a@gmx.li>
Message-ID: <EBE58DC9-85E9-4E32-95D0-646D787D418F@omniti.com>


> On Jan 19, 2017, at 7:43 PM, Dominik Hassler <hasslerd at gmx.li> 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 <lx-zone>', 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: <EBE58DC9-85E9-4E32-95D0-646D787D418F@omniti.com>
References: <e9f9f3bd-b17b-3cea-7b91-bb5f7676ed0a@gmx.li>
	<EBE58DC9-85E9-4E32-95D0-646D787D418F@omniti.com>
Message-ID: <EF59ABC9-ADB4-4EA6-A5D6-CDC945568C09@omniti.com>


> On Jan 19, 2017, at 8:19 PM, Dan McDonald <danmcd at omniti.com> 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 <problem>".

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: <EF59ABC9-ADB4-4EA6-A5D6-CDC945568C09@omniti.com>
References: <e9f9f3bd-b17b-3cea-7b91-bb5f7676ed0a@gmx.li>
	<EBE58DC9-85E9-4E32-95D0-646D787D418F@omniti.com>
	<EF59ABC9-ADB4-4EA6-A5D6-CDC945568C09@omniti.com>
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 <danmcd at omniti.com> 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 <problem>".
>
> 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>
	<DDDC4D69-75C1-4B13-9DE8-EF20D8074632@omniti.com>
	<90e5048d-55a8-707d-4721-7e064ea2e054@jvm.de>
	<CAEekY65qKAw=M8Lp86hOjL=20CdXTNPh3xtU_Emcq2A-kZomrw@mail.gmail.com>
	<cccfd91f-6164-f9a4-fdfa-a26645e954eb@jvm.de>
	<6BE20CFF-A05B-41C8-9B00-4858884FD069@omniti.com>
	<b7b3d8a6-6311-4b4f-38b1-fe5a36d6041b@jvm.de>
	<A5DE7D1A-2629-48FB-9BB8-FA1EFF8F9E17@omniti.com>
	<ef6d70ce-9452-e40b-268e-341191d029be@jvm.de>
	<7D4B4F33-7AE2-49A1-9FC9-17231CB27A47@omniti.com>
	<8520cdc4-88f9-7122-fe86-02e48a1bf2df@jvm.de>
	<ACBED270-C0A6-4649-8081-C4882CD6412F@omniti.com>
	<aa4d05f4-94ae-c2f5-2fa3-a791e9d6d767@jvm.de>
	<474982A8-8850-4CE9-9592-5EEA4028C0CC@omniti.com>
	<79507f94-7f2a-bd3f-d022-28a652f91f35@jvm.de>
	<adb3397b-4a17-e31b-dc6d-00188204e038@jvm.de>
	<26637FD4-0792-47DB-BEA9-7D1FA7EE83D2@omniti.com>
Message-ID: <aa54c791-353e-f55d-e373-a708a0efe00a@jvm.de>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170120/e5dccec8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170120/e5dccec8/attachment-0001.bin>

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: <e9f9f3bd-b17b-3cea-7b91-bb5f7676ed0a@gmx.li>
	<EBE58DC9-85E9-4E32-95D0-646D787D418F@omniti.com>
	<EF59ABC9-ADB4-4EA6-A5D6-CDC945568C09@omniti.com>
	<1c8ccf83-0a5b-d540-6a3d-9f22b61a8b80@gmx.li>
Message-ID: <B5BE5140-B342-4566-A205-F5A42A8B2916@omniti.com>


> On Jan 19, 2017, at 8:54 PM, Dominik Hassler <hasslerd at gmx.li> 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 <manuel at oetiker.ch> 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 <manuel at oetiker.ch> 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" <danmcd at omniti.com>
> To: "Manuel Oetiker" <manuel at oetiker.ch>
> Cc: "omnios-discuss" <omnios-discuss at lists.omniti.com>, "Dan McDonald" <danmcd at omniti.com>
> 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: <C66CD59C-6CAD-45DA-B0C8-BBDAFED7B018@omniti.com>


> On Jan 20, 2017, at 11:02 AM, Dominik Hassler <hasslerd at gmx.li> 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: <C66CD59C-6CAD-45DA-B0C8-BBDAFED7B018@omniti.com>
References: <1922774730.2117005.1484897466171.JavaMail.zimbra@oetiker.ch>
	<817E6635-E809-4E4A-939D-C432FC4B0E41@omniti.com>
	<869ec615-c48e-3d59-ebbe-1194347a2b8c@gmx.li>
	<C66CD59C-6CAD-45DA-B0C8-BBDAFED7B018@omniti.com>
Message-ID: <00142031-1947-408F-9EA2-61689314A829@omniti.com>


> On Jan 20, 2017, at 11:05 AM, Dan McDonald <danmcd at omniti.com> 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 <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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170120/fac9bab7/attachment.html>

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 <mtalbott at lji.org> 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: <C67D0DE1-CB81-4B67-BFC5-E46EB6D4FD1B@omniti.com>


> On Jan 20, 2017, at 3:14 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> 
>> On Jan 20, 2017, at 2:36 PM, Michael Talbott <mtalbott at lji.org> 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 <DD/MM/YYYY,HH:MM:SS>]
                [-e <DD/MM/YYYY,HH:MM:SS>] -f <logfile> [<flow>]
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: <C67D0DE1-CB81-4B67-BFC5-E46EB6D4FD1B@omniti.com>
References: <0D3ECF7B-53BB-487E-A5D6-B68A65B4C70D@lji.org>
	<514611B0-6B73-43DF-B573-317EA3A651B9@omniti.com>
	<C67D0DE1-CB81-4B67-BFC5-E46EB6D4FD1B@omniti.com>
Message-ID: <343DB54D-F4BA-48CB-BE9B-91C8737D5B5A@lji.org>

Perfect. Thanks.


> On Jan 20, 2017, at 12:16 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
>> 
>> On Jan 20, 2017, at 3:14 PM, Dan McDonald <danmcd at omniti.com> wrote:
>> 
>> 
>>> On Jan 20, 2017, at 2:36 PM, Michael Talbott <mtalbott at lji.org> 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 <DD/MM/YYYY,HH:MM:SS>]
>                [-e <DD/MM/YYYY,HH:MM:SS>] -f <logfile> [<flow>]
> bloody(cmd/flowadm)[1]% 
> 
> 
> Just so you can see the usage string.
> 
> Dan

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

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>
	<C67D0DE1-CB81-4B67-BFC5-E46EB6D4FD1B@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 <mtalbott at lji.org> 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>
	<C67D0DE1-CB81-4B67-BFC5-E46EB6D4FD1B@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 <danmcd at omniti.com> wrote:
> 
> 
>> On Jan 20, 2017, at 3:22 PM, Michael Talbott <mtalbott at lji.org> 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: <BE20BC79-7079-4BB7-95C0-F5F0C4D7D6A4@omniti.com>

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 <matej at zunaj.si> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170121/3ab94805/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170121/3ab94805/attachment-0001.bin>

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: <BE20BC79-7079-4BB7-95C0-F5F0C4D7D6A4@omniti.com>
References: <83CC5FF9-4F50-4CEB-A648-9AA6D629D5A6@zunaj.si>
	<BE20BC79-7079-4BB7-95C0-F5F0C4D7D6A4@omniti.com>
Message-ID: <3552866E-48B0-4DA3-AABF-3C573A65FA1F@richardelling.com>



> On Jan 21, 2017, at 8:07 AM, Dale Ghent <daleg at omniti.com> 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 <matej at zunaj.si> 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>
	<BE20BC79-7079-4BB7-95C0-F5F0C4D7D6A4@omniti.com>
	<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 <richard.elling at richardelling.com> wrote:
> 
> 
> 
>> On Jan 21, 2017, at 8:07 AM, Dale Ghent <daleg at omniti.com> 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 <matej at zunaj.si> 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: <f29d3730-00c8-bcc8-f7b4-62447fac5e7c@jvm.de>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170122/7e228338/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170122/7e228338/attachment.bin>

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: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>

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: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
Message-ID: <alpine.GSO.2.20.1701221638160.8886@freddy.simplesystems.org>

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>
	<BE20BC79-7079-4BB7-95C0-F5F0C4D7D6A4@omniti.com>
	<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 <mailto: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 <richard.elling at richardelling.com> wrote:
> 
> 
> 
>> On Jan 21, 2017, at 8:07 AM, Dale Ghent <daleg at omniti.com> 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 <matej at zunaj.si> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170123/7aa6a599/attachment-0001.html>

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>
	<BE20BC79-7079-4BB7-95C0-F5F0C4D7D6A4@omniti.com>
	<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 <tobi at oetiker.ch> 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 <richard.elling at richardelling.com> wrote:
>> 
>> 
>> 
>>> On Jan 21, 2017, at 8:07 AM, Dale Ghent <daleg at omniti.com> 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 <matej at zunaj.si> 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: <f29d3730-00c8-bcc8-f7b4-62447fac5e7c@jvm.de>
References: <1e15d6ab-baf5-2446-d732-29561d5cfdde@jvm.de>
	<f29d3730-00c8-bcc8-f7b4-62447fac5e7c@jvm.de>
Message-ID: <A33B26F0-A5B7-4E33-AB00-2E6C61038C95@omniti.com>


> On Jan 22, 2017, at 3:24 AM, Stephan Budach <stephan.budach at jvm.de> 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: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
Message-ID: <F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>


> On Jan 22, 2017, at 5:02 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <f1afa6c1224e641bfe6db3d5a1323450.squirrel@emailmg.netfirms.com>


  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: <f1afa6c1224e641bfe6db3d5a1323450.squirrel@emailmg.netfirms.com>
References: <f1afa6c1224e641bfe6db3d5a1323450.squirrel@emailmg.netfirms.com>
Message-ID: <CALeZrrQgdOGWgYpBJmHoo0jYGqj-zr+KyRLRKa+bB3JdMpp18w@mail.gmail.com>

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, <steve at linuxsuite.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170123/2d8d1f5f/attachment.html>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170123/aea7537f/attachment-0001.html>

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: <F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
References: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
Message-ID: <alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>

On Mon, 23 Jan 2017, Dan McDonald wrote:

>
>> On Jan 22, 2017, at 5:02 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
	<alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
Message-ID: <79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com>


> On Jan 23, 2017, at 11:17 AM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
	<alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
	<79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com>
Message-ID: <alpine.UW2.2.11.1701230927240.969@server01.int.multitalents.net>

On Mon, 23 Jan 2017, Dan McDonald wrote:

> 
> > On Jan 23, 2017, at 11:17 AM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
	<alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
	<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 <danmcd at omniti.com> 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: <alpine.UW2.2.11.1701230927240.969@server01.int.multitalents.net>
References: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
	<alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
	<79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com>
	<alpine.UW2.2.11.1701230927240.969@server01.int.multitalents.net>
Message-ID: <2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com>


> On Jan 23, 2017, at 12:31 PM, Tim Rice <tim at multitalents.net> 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: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
	<alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
	<79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com>
	<alpine.UW2.2.11.1701230927240.969@server01.int.multitalents.net>
	<2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com>
Message-ID: <A4B54925-5356-4D72-B71D-A195BB6D5D72@omniti.com>


> On Jan 23, 2017, at 12:36 PM, Dan McDonald <danmcd at omniti.com> 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: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
	<alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
	<79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com>
	<alpine.UW2.2.11.1701230927240.969@server01.int.multitalents.net>
	<2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com>
Message-ID: <alpine.UW2.2.11.1701230940430.969@server01.int.multitalents.net>

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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170123/c30a7664/attachment-0001.bin>

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: <alpine.UW2.2.11.1701230940430.969@server01.int.multitalents.net>
References: <alpine.GSO.2.20.1701221550020.8886@freddy.simplesystems.org>
	<F8D36FFC-A2B6-42CB-8D2B-E9C783B8817E@omniti.com>
	<alpine.GSO.2.20.1701231006520.2884@freddy.simplesystems.org>
	<79E6285B-4ACE-4E82-8828-82F22E90A6FB@omniti.com>
	<alpine.UW2.2.11.1701230927240.969@server01.int.multitalents.net>
	<2518BF47-6BE4-42B9-920A-FFE6E9D3FCDB@omniti.com>
	<alpine.UW2.2.11.1701230940430.969@server01.int.multitalents.net>
Message-ID: <CABMTExi86-1iRoxjkNAbterhsF2dTAexUcKT5ZPU-J8V1Tgu_A@mail.gmail.com>

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 <tim at multitalents.net> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170123/26b15d41/attachment.html>

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: <B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>


> On Jan 23, 2017, at 5:13 PM, Michael Rasmussen <mir at miras.org> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170123/5ac5d31f/attachment.bin>

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: <B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
References: <20170123231318.0091abc6@sleipner.datanom.net>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
Message-ID: <20170124021732.32473f65@sleipner.datanom.net>

On Mon, 23 Jan 2017 19:27:51 -0500
Dale Ghent <daleg at omniti.com> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170124/f51a0a2e/attachment.bin>

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>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
Message-ID: <2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com>


> On Jan 23, 2017, at 8:17 PM, Michael Rasmussen <mir at miras.org> 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>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
Message-ID: <9611C0E4-D89E-43CB-A4A1-068C42EB8988@richardelling.com>


> On Jan 23, 2017, at 5:17 PM, Michael Rasmussen <mir at miras.org> wrote:
> 
> On Mon, 23 Jan 2017 19:27:51 -0500
> Dale Ghent <daleg at omniti.com> 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 <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> 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>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
	<2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com>
Message-ID: <FA5A5E60-7585-43BC-AA1B-77B2053D305E@pipar-tbwa.is>

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 <danmcd at omniti.com> wrote:
> 
> 
>> On Jan 23, 2017, at 8:17 PM, Michael Rasmussen <mir at miras.org> 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: <FA5A5E60-7585-43BC-AA1B-77B2053D305E@pipar-tbwa.is>
References: <20170123231318.0091abc6@sleipner.datanom.net>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
	<2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com>
	<FA5A5E60-7585-43BC-AA1B-77B2053D305E@pipar-tbwa.is>
Message-ID: <alpine.GSO.2.20.1701240837430.8886@freddy.simplesystems.org>

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: <alpine.GSO.2.20.1701240837430.8886@freddy.simplesystems.org>
References: <20170123231318.0091abc6@sleipner.datanom.net>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
	<2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com>
	<FA5A5E60-7585-43BC-AA1B-77B2053D305E@pipar-tbwa.is>
	<alpine.GSO.2.20.1701240837430.8886@freddy.simplesystems.org>
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 <bfriesen at simple.dallas.tx.us> 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>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
	<2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com>
	<FA5A5E60-7585-43BC-AA1B-77B2053D305E@pipar-tbwa.is>
	<alpine.GSO.2.20.1701240837430.8886@freddy.simplesystems.org>
	<0F5E32AC-DA7B-4EF8-B579-F8181BD643F0@zunaj.si>
Message-ID: <alpine.GSO.2.20.1701241210100.6466@freddy.simplesystems.org>

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>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
	<2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com>
Message-ID: <ae45622e-a28d-66c6-0ea7-b33fdb0cbedd@gmx.li>



On 01/24/2017 02:22 AM, Dan McDonald wrote:
>
>> On Jan 23, 2017, at 8:17 PM, Michael Rasmussen <mir at miras.org> 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: <ae45622e-a28d-66c6-0ea7-b33fdb0cbedd@gmx.li>
References: <20170123231318.0091abc6@sleipner.datanom.net>
	<B6C819D0-70C6-4D43-A7A8-5DE3E680EA4A@omniti.com>
	<20170124021732.32473f65@sleipner.datanom.net>
	<2D82DDFE-497E-454C-8631-EAD1C1BC1337@omniti.com>
	<ae45622e-a28d-66c6-0ea7-b33fdb0cbedd@gmx.li>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/24a45e10/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/24a45e10/attachment-0001.bin>

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: <alpine.GSO.2.20.1701250816330.8886@freddy.simplesystems.org>

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: <alpine.GSO.2.20.1701250816330.8886@freddy.simplesystems.org>
References: <alpine.GSO.2.20.1701250816330.8886@freddy.simplesystems.org>
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: <BA5E4434-7BA0-4167-8BBF-166F96A4DFFE@omniti.com>

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 <stephan.budach at JVM.DE> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/c9f15a60/attachment.bin>

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: <BA5E4434-7BA0-4167-8BBF-166F96A4DFFE@omniti.com>
References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de>
	<BA5E4434-7BA0-4167-8BBF-166F96A4DFFE@omniti.com>
Message-ID: <bbc98299-e0fd-80ea-36ef-5a3bcdbbf3bb@jvm.de>

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 <stephan.budach at JVM.DE> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/c36046e4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/c36046e4/attachment-0001.bin>

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: <bbc98299-e0fd-80ea-36ef-5a3bcdbbf3bb@jvm.de>
References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de>
	<BA5E4434-7BA0-4167-8BBF-166F96A4DFFE@omniti.com>
	<bbc98299-e0fd-80ea-36ef-5a3bcdbbf3bb@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 <stephan.budach at jvm.de> 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 <stephan.budach at JVM.DE>
>>>  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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/b7f1dfe9/attachment.bin>

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>
	<BA5E4434-7BA0-4167-8BBF-166F96A4DFFE@omniti.com>
	<bbc98299-e0fd-80ea-36ef-5a3bcdbbf3bb@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 <daleg at 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 <stephan.budach at jvm.de> 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 <stephan.budach at JVM.DE>
>>>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/f8c7725b/attachment-0001.bin>

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 <stephan.budach at JVM.DE> 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 <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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/eb8a6d24/attachment.html>

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 <henson at acm.org> 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: <d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>

Hi Richard,

Am 25.01.17 um 20:27 schrieb Richard Elling:
> Hi Stephan,
>
>> On Jan 25, 2017, at 5:54 AM, Stephan Budach <stephan.budach at JVM.DE 
>> <mailto:stephan.budach at jvm.de>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/fb93ee4f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/fb93ee4f/attachment-0001.bin>

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: <d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de>
	<36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
Message-ID: <ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>

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 <stephan.budach at JVM.DE 
>>> <mailto:stephan.budach at jvm.de>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/bed6b1ea/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/bed6b1ea/attachment-0001.bin>

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: <ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de>
	<36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
Message-ID: <452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com>

more below?

> On Jan 25, 2017, at 3:01 PM, Stephan Budach <stephan.budach at JVM.DE> 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 <stephan.budach at JVM.DE <mailto:stephan.budach at jvm.de>> 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 <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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170125/99b0bbeb/attachment-0001.html>

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: <alpine.GSO.2.20.1701250816330.8886@freddy.simplesystems.org>
	<90C1E228-EED5-4E2A-868A-BFAB1D8AF501@omniti.com>
Message-ID: <alpine.GSO.2.20.1701252023250.8886@freddy.simplesystems.org>

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>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
	<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 <stephan.budach at JVM.DE 
>> <mailto:stephan.budach at jvm.de>> 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 <stephan.budach at JVM.DE 
>>>>> <mailto:stephan.budach at jvm.de>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/c722cbd4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/c722cbd4/attachment-0001.bin>

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>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
	<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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/1ae40912/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/1ae40912/attachment-0001.bin>

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: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>

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: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
References: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
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: <CAEekY66QkaJbYGLqR+TezwgQ4F04DtD1b6UpvGZZLZaM-O6gEQ@mail.gmail.com>
References: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
	<22665.55326.378723.508075@shelob.bb-c.de>
	<CAEekY66QkaJbYGLqR+TezwgQ4F04DtD1b6UpvGZZLZaM-O6gEQ@mail.gmail.com>
Message-ID: <CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>

sorry, I forgot to change address to all list before send ...

---------- Forwarded message ----------
From: F?bio Rabelo <fabio at fabiorabelo.wiki.br>
Date: 2017-01-26 9:21 GMT-02:00
Subject: Re: [OmniOS-discuss] Install on Supermicro DOM=low space left
To: "Volker A. Brandt" <vab at bb-c.de>


2017-01-26 9:06 GMT-02:00 Volker A. Brandt <vab at 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

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: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
	<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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/d1fc5100/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/d1fc5100/attachment.bin>

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: <CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
References: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
	<22665.55326.378723.508075@shelob.bb-c.de>
	<CAEekY66QkaJbYGLqR+TezwgQ4F04DtD1b6UpvGZZLZaM-O6gEQ@mail.gmail.com>
	<CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
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=<new size> 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: <CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
References: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
	<22665.55326.378723.508075@shelob.bb-c.de>
	<CAEekY66QkaJbYGLqR+TezwgQ4F04DtD1b6UpvGZZLZaM-O6gEQ@mail.gmail.com>
	<CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
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 <fabio at fabiorabelo.wiki.br>
> Date: 2017-01-26 9:21 GMT-02:00
> Subject: Re: [OmniOS-discuss] Install on Supermicro DOM=low space left
> To: "Volker A. Brandt" <vab at bb-c.de>
>
>
> 2017-01-26 9:06 GMT-02:00 Volker A. Brandt <vab at 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
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/842b60d9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/842b60d9/attachment-0001.bin>

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: <CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
References: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
	<22665.55326.378723.508075@shelob.bb-c.de>
	<CAEekY66QkaJbYGLqR+TezwgQ4F04DtD1b6UpvGZZLZaM-O6gEQ@mail.gmail.com>
	<CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
Message-ID: <CANKMAMYUhKdPRPU6X+HW9bSkeiCD_A34PjQryb9ZS5-PKvwcuA@mail.gmail.com>

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 <fabio at fabiorabelo.wiki.br>
wrote:

> sorry, I forgot to change address to all list before send ...
>
> ---------- Forwarded message ----------
> From: F?bio Rabelo <fabio at fabiorabelo.wiki.br>
> Date: 2017-01-26 9:21 GMT-02:00
> Subject: Re: [OmniOS-discuss] Install on Supermicro DOM=low space left
> To: "Volker A. Brandt" <vab at bb-c.de>
>
>
> 2017-01-26 9:06 GMT-02:00 Volker A. Brandt <vab at 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
>
> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/d628baf0/attachment.html>

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: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
	<22665.55326.378723.508075@shelob.bb-c.de>
	<CAEekY66QkaJbYGLqR+TezwgQ4F04DtD1b6UpvGZZLZaM-O6gEQ@mail.gmail.com>
	<CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
	<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=<new size> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/18b2e6e5/attachment.html>

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: <CAEekY67QMzUSNFt_3UyMf41PJg623exFFaYF6jyvkQ8x_BUyHQ@mail.gmail.com>
	<22665.55326.378723.508075@shelob.bb-c.de>
	<CAEekY66QkaJbYGLqR+TezwgQ4F04DtD1b6UpvGZZLZaM-O6gEQ@mail.gmail.com>
	<CAEekY66xrvgh2s3Oeue6h-HR-_10-8D63asVfj+MXHh6TX2Fig@mail.gmail.com>
	<22665.57267.919068.568577@shelob.bb-c.de>
	<4ECFFE87-89D1-46C9-905B-8C93586FA02D@marzocchi.net>
Message-ID: <CAEgYsbE1Jb44fUq7rDWJB=v+tPtWL-+3xniABS=o1FXkof7NDA@mail.gmail.com>

On Thu, Jan 26, 2017 at 2:12 PM, Olaf Marzocchi <lists at marzocchi.net> 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=<new size> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/30871db2/attachment.html>

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>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
	<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 <stephan.budach at JVM.DE> 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 <stephan.budach at JVM.DE <mailto:stephan.budach at jvm.de>> 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 <stephan.budach at JVM.DE <mailto:stephan.budach at jvm.de>> 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 <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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170126/1062d854/attachment-0001.html>

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>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
	<452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com>
	<9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de>
	<4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com>
Message-ID: <bf3898f4-007d-cab2-1491-d296727bec2e@jvm.de>

Hi Richard,

Am 26.01.17 um 20:18 schrieb Richard Elling:
>
>> On Jan 26, 2017, at 12:20 AM, Stephan Budach <stephan.budach at JVM.DE 
>> <mailto:stephan.budach at jvm.de>> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170128/7d057bcd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170128/7d057bcd/attachment.bin>

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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170128/dbc8f1df/attachment.bin>

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 <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170128/49914506/attachment.bin>

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 <mir at miras.org> 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 <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170128/32735f49/attachment-0001.bin>

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: <bf3898f4-007d-cab2-1491-d296727bec2e@jvm.de>
References: <7c53adc7-8b39-332c-ee76-21f91d2fedb2@jvm.de>
	<36C501AD-8AF8-49F1-960C-E7A2C0F0B85F@richardelling.com>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
	<452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com>
	<9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de>
	<4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com>
	<bf3898f4-007d-cab2-1491-d296727bec2e@jvm.de>
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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170129/8d329081/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170129/8d329081/attachment.bin>

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: <mailman.33.1485803880.56985.omnios-discuss@lists.omniti.com>
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" <omnios-discuss-bounces at lists.omniti.com>


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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170130/948d8720/attachment.html>

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: <mailman.33.1485803880.56985.omnios-discuss@lists.omniti.com>
	<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" <omnios-discuss-bounces at lists.omniti.com>
> 
> 
> 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: <CAFsN5PyV-MSsKZ9UXVcKBzL0-dDa0oN56Mkc82OEQ9w7scuENg@mail.gmail.com>

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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170130/4e000fa4/attachment.html>

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: <CAFsN5PyV-MSsKZ9UXVcKBzL0-dDa0oN56Mkc82OEQ9w7scuENg@mail.gmail.com>
References: <CAFsN5PyV-MSsKZ9UXVcKBzL0-dDa0oN56Mkc82OEQ9w7scuENg@mail.gmail.com>
Message-ID: <667C4A5C-BBCA-4247-8F82-808160AF1BF9@omniti.com>


> On Jan 30, 2017, at 4:41 PM, Eric Bardes <ericbardes at gmail.com> 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: <CAFsN5PyV-MSsKZ9UXVcKBzL0-dDa0oN56Mkc82OEQ9w7scuENg@mail.gmail.com>
	<667C4A5C-BBCA-4247-8F82-808160AF1BF9@omniti.com>
Message-ID: <CAFsN5PxoKL1Vrx_HZtEP8S_z8Owd6aB9BWpJwD-Mp233PybA4Q@mail.gmail.com>

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
<disk>
zpool import -f tank crashes too.

On Mon, Jan 30, 2017 at 5:05 PM, Dan McDonald <danmcd at omniti.com> wrote:

>
> > On Jan 30, 2017, at 4:41 PM, Eric Bardes <ericbardes at gmail.com> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170130/539865db/attachment.html>

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: <CAFsN5PxoKL1Vrx_HZtEP8S_z8Owd6aB9BWpJwD-Mp233PybA4Q@mail.gmail.com>
References: <CAFsN5PyV-MSsKZ9UXVcKBzL0-dDa0oN56Mkc82OEQ9w7scuENg@mail.gmail.com>
	<667C4A5C-BBCA-4247-8F82-808160AF1BF9@omniti.com>
	<CAFsN5PxoKL1Vrx_HZtEP8S_z8Owd6aB9BWpJwD-Mp233PybA4Q@mail.gmail.com>
Message-ID: <10422520-A8B4-4410-B202-B02CAE9EDB57@omniti.com>


> On Jan 30, 2017, at 5:49 PM, Eric Bardes <ericbardes at gmail.com> 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 <disk>
> 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>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
	<452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com>
	<9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de>
	<4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com>
	<bf3898f4-007d-cab2-1491-d296727bec2e@jvm.de>
	<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 <stephan.budach at JVM.DE> 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>
	<d0e0e202-0233-8c58-d7a5-2ba107c6a133@jvm.de>
	<ffcbc602-f735-89ac-82e5-c0b7f9b64824@jvm.de>
	<452380B3-F384-496B-BA7A-A653C9432B19@richardelling.com>
	<9f8f26e8-8fc4-bd4d-3709-3302d9c2c20f@jvm.de>
	<4A2A5A3B-0BE5-4182-9738-E7510F57AD80@richardelling.com>
	<bf3898f4-007d-cab2-1491-d296727bec2e@jvm.de>
	<9d7ee062-37dc-06e0-d9cb-2655c4011dd4@jvm.de>
	<4634E48A-8DEA-4A48-8844-297AA14E37BF@richardelling.com>
Message-ID: <fbe908a2-bfe5-e39d-48f8-3b512d161f94@jvm.de>

Am 31.01.17 um 00:15 schrieb Richard Elling:
>> On Jan 29, 2017, at 3:10 AM, Stephan Budach <stephan.budach at JVM.DE> 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: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170131/0a6ab320/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20170131/0a6ab320/attachment-0001.bin>

