Re: [OmniOS-discuss] LX chdir bug with steps to reproduce
This simple python code will break on an LX zone (LTS)
import os
import time
os.chdir('/main/documents/test')
for i in xrange(2000):
print i
os.chdir('a')
print os.getcwd()
os.chdir('..')
On Fri, Mar 9, 2018 at 1:01 PM, Mini Trader
wrote:
> Would this bug have been fixed in the latest stable version of OmniOS CE?
>
> On Mon, Jan 16, 2017 at 5:36 PM, Dan McDonald wrote:
>
>>
>> > On Jan 16, 2017, at 5:01 PM, Mini Trader
>> wrote:
>> >
>> > We definitely need:
>> >
>> > https://smartos.org/bugview/OS-5167 (and probably whatever was done
>> before it).
>>
>> Joyent mentioned that very bug to me earlier this afternoon. During the
>> bringup of LX zones, I didn't cherrypick it from illumos-joyent, and now I
>> remember why... it unravels a larger ball of yarn.
>>
>> To that end, I'm attempting that unravelling now. I doubt it'll be
>> backported into r151020, though. LX is still considered "beta" in 020, and
>> stability of the overall system is why I'm loathe to bring in non-LX fixes
>> for LX problems (as these all are) into a Stable release.
>>
>> I'm going to cut a bloody release this week. It has lots of new things
>> in it, and if I'm lucky, it may include these Joyent fixes as well. If you
>> want to help, get a box up to bloody once I cut the release this week.
>>
>> Thanks, and sorry I can't be of IMMEDIATE assistance,
>> Dan
>>
>>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX chdir bug with steps to reproduce
Would this bug have been fixed in the latest stable version of OmniOS CE? On Mon, Jan 16, 2017 at 5:36 PM, Dan McDonald wrote: > > > On Jan 16, 2017, at 5:01 PM, Mini Trader > wrote: > > > > We definitely need: > > > > https://smartos.org/bugview/OS-5167 (and probably whatever was done > before it). > > Joyent mentioned that very bug to me earlier this afternoon. During the > bringup of LX zones, I didn't cherrypick it from illumos-joyent, and now I > remember why... it unravels a larger ball of yarn. > > To that end, I'm attempting that unravelling now. I doubt it'll be > backported into r151020, though. LX is still considered "beta" in 020, and > stability of the overall system is why I'm loathe to bring in non-LX fixes > for LX problems (as these all are) into a Stable release. > > I'm going to cut a bloody release this week. It has lots of new things in > it, and if I'm lucky, it may include these Joyent fixes as well. If you > want to help, get a box up to bloody once I cut the release this week. > > Thanks, and sorry I can't be of IMMEDIATE assistance, > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Loader On Mirrored Setup
Is this the suggested command to use because it wasn't mentioned anywhere on the loader wiki. On Mon, Jul 31, 2017 at 11:15 AM Peter Tribble wrote: > > > On Sun, Jul 30, 2017 at 9:14 PM, Mini Trader > wrote: > >> Hello all, >> >> If moving to Loader and using a mirrored setup is there anything that >> must be done to ensure that Loader is installed on both drives? >> > > This should be automatic. Note that the bootadm install-bootloader > command works on pools, not disks, so if you have a mirrored pool > it will do all sides of the mirror. > > If you replace one of the drives then you'll have to run bootadm > install-bootloader > on the pool again and it will put the loader on the replacement drive for > you. > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Loader On Mirrored Setup
Hello all, If moving to Loader and using a mirrored setup is there anything that must be done to ensure that Loader is installed on both drives? Thanks! ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h
Sweet! This is all great news. On Fri, Jul 14, 2017 at 4:59 AM Tobias Oetiker wrote: > Our first release only contained userland updates (careful as we are) > the next one (r151022i) will also feature actual illumos things like > the loader. > > cheers > tobi > > - On Jul 14, 2017, at 3:48 AM, Paul B. Henson hen...@acm.org wrote: > > > On Fri, Jul 14, 2017 at 01:31:51AM +, Mini Trader wrote: > > > >> Can the new boot loader handle 4K drives with this release? > > > > The fix for illumos issue 8303 appears to have been commited to the > > r151022 branch of the omniosorg illumos-omnios repo on 7/8, and r151022h > > was released 7/12, so I'd guess yes. But it's just a guess :). Great to > > see backports hitting r151022 LTS code... > > > >> > > ## OmniOSce r151022h, 12th July 2017 > > > > ___ > > OmniOS-discuss mailing list > > OmniOS-discuss@lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -- > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland > www.oetiker.ch t...@oetiker.ch +41 62 775 9902 > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] ANNOUNCEMENT OmniOS Community Edition - OmniOSce r151022h
Cool! Can the new boot loader handle 4K drives with this release? On Thu, Jul 13, 2017 at 6:51 PM Gary Gendel wrote: > This is very exciting. Thanks for the hard work to get things going. > > Gary > On 7/12/2017 11:32 AM, Tobias Oetiker wrote: > > # OmniOS Community Edition > > > > On April 21st 2017, OmniTI announced that they would suspend active > development of OmniOS and support contracts would not be renewed. > > > > While this announcement left many users stunned, others focused more on > the fact that OmniTI in their announcement also expressed the hope that > "the community" would take up further development of the OS. 14 weeks > later, OmniOS Community Edition is a reality. > > > > Andy Fiddaman (www.citrus-it.net), Tobias Oetiker (www.oetiker.ch) and > Dominik Hassler have spent some quality time setting up the systems and > procedures allowing us to take over maintenance and development of OmniOS. > In this endeavour we were supported by many. Special thanks to Stefan Husch > (www.qutic.com), Peter Tribble (www.petertribble.co.uk), Dan McDonald and > Theo Schlossnagle (www.circonus.com). > > > > We have forked the OmniOS repos and pulled in bugfixes and security > fixes that have been published since the release of OmniOS r151022. After > setting up our own package repository and updating the build > infrastructure, we are finally ready to go public. We are following the > established OmniOS release naming scheme by releasing > > > > > > ## OmniOSce r151022h, 12th July 2017 > > > > The new release contains the following fixes: > > > > - expat updated to version 2.2.1 (fixes CVE-2017-9233) > > - openssl updated to version 1.0.2l > > - curl updated to version 7.54.1 > > - bind updated to version 9.10.5-P3 > > - p7zip updated to fix CVE-2016-9296 > > - web/ca-bundle updated to include OmniOSce Certificate Authority > certificate > > > > `uname -a` shows omnios-r151022-f9693432c2 (no change in this release) > > > > Our work does not stop here though. First we are committed to quickly > releasing updates for r151022 as the need arises. We are also working > towards releasing r151024 on schedule. To that end, we have already updated > the bloody environment with all the latest goodies from upstream illumos > and joyent-lx repositories. > > > > OmniOS community edition hosts its sources on > https://github.com/omniosorg/ and if you want to get in touch, you can > find us on https://gitter.im/omniosorg/Lobby > > > > > > ## Release Schedule > > > > The intention is for new stable releases to continue to come out every > 26 weeks. Interim, "weekly" updates to stable follow a fixed schedule > denoted by letters, one per week. Weekly releases are made as needed, so > there may not be a release each week. The first release of a new stable > version is synonymous with weekly release "a", though the letter is not > used. > > > > During the intervals between stable releases, Bloody moves forward > rapidly, picking up changes from upstream illumos-gate and illumos-joyent > as well as updating various userland packages. In general, upstream merges > will be performed on a Thursday/Friday each week and weekly releases will > be published on a Monday. > > > > Bloody releases will be published on an ad-hoc basis but may be as > frequent as every week. > > > > Security fixes are excluded from the schedule and handled with priority > as they occur. > > > > > > ## How to Upgrade > > > > All OmniOS packages are signed and the pkg installer is configured to > only allow trusted sources for the core packages. In order to upgrade to > the new OmniOS community edition, you have to let your box know that the > updates will be coming from a new trusted source. This means you will have > to import our CA certificate into your system. > > > > 1. Get a copy of the new certificate > > > > ``` > > # /usr/bin/wget -P /etc/ssl/pkg \ > > https://downloads.omniosce.org/ssl/omniosce-ca.cert.pem > > ``` > > > > 2. Check the certificate fingerprint > > > > ``` > > # /usr/bin/openssl x509 -fingerprint \ > > -in /etc/ssl/pkg/omniosce-ca.cert.pem -noout > > ``` > > > > `8D:CD:F9:D0:76:CD:AF:C1:62:AF:89:51:AF:8A:0E:35:24:4C:66:6D` > > > > > > 3. Change the publisher to our new repo > > > > ``` > > # /usr/bin/pkg set-publisher -P \ > > -G https://pkg.omniti.com/omnios/r151022/ \ > > -g https://pkg.omniosce.org/r151022/core/ omnios > > ``` > > > > 4. For each native zone (if you have any), run > > > > ``` > > # /usr/bin/pkg -R set-publisher -P \ > > -G https://pkg.omniti.com/omnios/r151022/ \ > > -g https://pkg.omniosce.org/r151022/core/ omnios > > ``` > > > > (get a list of all your zones by running `zoneadm list -cv` for the > ``, add `/root` to the PATH given in the list.) > > > > > > 5. Install the new ca-bundle containing our new CA > > > > ``` > > # /usr/bin/pkg update -rv web/ca-bundle > > ``` > > > > 6. Remove the CA file imported by hand > > > > ``` > > # rm /etc/ssl/pkg/omniosce-ca.cert.pem > > ``` >
Re: [OmniOS-discuss] Bug ?
Is it going to be FreeBSD or Linux? On Thu, Jun 29, 2017 at 3:16 AM Oliver Weinmann < oliver.weinm...@telespazio-vega.de> wrote: > Ohh that is bad news. > > > > I have a productions system that somehow fails to join AD and I don’t know > what is causing this. We had a similar issue on our nexenta system and > they provided us a patch that solved it. > > > > Idmap: > > > > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Client not found in > Kerberos database) > > adutils: ldap_lookup_init failed > > > > > > > > > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinm...@telespazio-vega.de > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller > > *From:* Paul B. Henson [mailto:hen...@acm.org] > *Sent:* Donnerstag, 29. Juni 2017 08:51 > *To:* Oliver Weinmann > *Cc:* omnios-discuss > *Subject:* Re: [OmniOS-discuss] Bug ? > > > > Unfortunately OmniTI no longer offers support contracts for OmniOS. We > actually have a contract that's still good through I think November, but > given their main support engineer is no longer with the company and the OS > appears to be in limbo at the moment I'm not sure what good that does us ;). > > > > If you think you've found a bug, your best bet at the moment is to just > report it to this list, possibly to the upstream illumos developer list if > you can detail it reasonably technically, and perhaps open an issue on the > illumos issue tracker. > > > On Jun 28, 2017, at 11:29 PM, Oliver Weinmann < > oliver.weinm...@telespazio-vega.de> wrote: > > Hi, > > > > What if I would like to report a possible bug? Do I need a valid support > contract for this? > > > > Best Regards, > > Oliver > > > > > > > *Oliver Weinmann* > Senior Unix VMWare, Storage Engineer > > Telespazio VEGA Deutschland GmbH > Europaplatz 5 - 64293 Darmstadt - Germany > Ph: + 49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799 > oliver.weinm...@telespazio-vega.de > http://www.telespazio-vega.de > > Registered office/Sitz: Darmstadt, Register court/Registergericht: > Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller > > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!!
Has the bug we found been fixed? On Wed, Feb 1, 2017 at 11:04 AM Dan McDonald wrote: > We do try to keep up with LX from Joyent. The README.OmniOS file tracks > this: > > https://github.com/omniti-labs/illumos-omnios/blob/master/README.OmniOS > > By recording the last illumos-Joyent commit we inspected. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > > On Feb 1, 2017, at 7:02 AM, Mini Trader wrote: > > Thanks Dan. Have the LX zone patches been added in? > > On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler wrote: > > Dan, > > updated according to your instructions and switched to loader > afterwards. Everything went smooth. > > Thanks! > Dominik > > On 02/01/2017 01:34 AM, Dan McDonald wrote: > > Hello! > > > > PLEASE READ THIS CAREFULLY BEFORE UPDATING!!! (And pardon any shouting, > there are important things to read here.) > > > > Progress on our work for this bloody is going smoother than expected, > thanks to the good work others have been doing upstream in illumos-gate. > The Python2.7 switch has gone well (I'm seeing no complaints from bloody > users). The new bits we're about to push on to > http://pkg.omniti.com/omnios/bloody/ will enable another upstream > innovation: BSD Loader. Unlike previous updates, I want this mail on the > list before I push packages out to the repo server. > > > > The BSD Loader provides a replacement for GRUB. Its biggest upfront > improvements over GRUB 0.97 are that it's an active Open Source project > (GRUB went to 2.0), and that it eliminates the number-of-boot-environment > limits that GRUB had. Furthermore, BSD Loader provides a more stable > foundation for future improvements such as EFI boot (vs. BIOS boot) and the > possibility of booting off of raidZ pools. > > > > The official arrival of BSD Loader constitutes an operational flag day > for bloody users. This is a substantial enough change to merit its own new > wiki page to accompany r151022's release. Current users of bloody may > notice the presence of this file: /etc/default/be. This file has been in > place to PREVENT the use of loader. As of this upcoming update, that file > disappears, but it can be reconstituted. > > > > Before updating, you, the administrator, must make a decision: Stick > with GRUB, or move to loader. The /etc/default/be file, specifically the > "BE_HAS_GRUB=true" line, tells beadm(1M) what boot loader you wish to use > going forward. > > > > I WANT TO MOVE TO LOADER > > > > - This is the default after updating, but Loader does not get installed > until you "beadm activate" a loader-friendly BE (including the current > one). Reboots after an update without the invocation of "beadm activate" or > "installboot" will mean your machine stays with grub. You should notice an > extra message about /rpool/boot/menu.lst being created. > > > > - If you have bloody BE from 2017, it is loader-friendly, so long as you > remove /etc/default/be from that BE's root filesystem. > > > > - If you have a pre-2017 bloody BE, or an older OmniOS release BE, you > can not "beadm activate" it, beadm(1M) will fail. > > > > - An old BE CAN be booted from the new Loader menu, but beadm will not > work properly in that pre-Loader boot environment once booted. > > > > > > I WANT TO STICK WITH GRUB > > > > - Put "BE_HAS_GRUB=true" into /etc/default/be. This will instruct > beadm(1M) and libbe that you wish to continue with GRUB. > > > > - Technically this has been happening since the first bloody release of > 2017. The difference now is that "pkg update" removes this file from a > system-installed image. > > > > - Old BEs will work fine, and you can "beadm activate" between all of > them. > > > > > > I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB) > > > > - Remove /etc/default/be on an active 2017 bloody BE. > > > > - "beadm activate " -- you should see a message about > /rpool/boot/menu.lst being created. > > > > - You are now on loader. > > > > - If the "beadm activate" fails, or you still are booting with GRUB > afterwards, explicitly install loader by: > > > > rm /etc/default/be (or at least remove the BE_HAS_GRUB line if you > have multiple lines for some reason) > > installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/ > > rm /rpool/boot/menu.lst > > beadm activate (should reconstruct /rpool/boot/menu.lst) > > > > If you have mirrored roots, do the above install
Re: [OmniOS-discuss] New OmniOS bloody very soon -- READ CAREFULLY!!!
Thanks Dan. Have the LX zone patches been added in? On Wed, Feb 1, 2017 at 6:58 AM Dominik Hassler wrote: > Dan, > > updated according to your instructions and switched to loader > afterwards. Everything went smooth. > > Thanks! > Dominik > > On 02/01/2017 01:34 AM, Dan McDonald wrote: > > Hello! > > > > PLEASE READ THIS CAREFULLY BEFORE UPDATING!!! (And pardon any shouting, > there are important things to read here.) > > > > Progress on our work for this bloody is going smoother than expected, > thanks to the good work others have been doing upstream in illumos-gate. > The Python2.7 switch has gone well (I'm seeing no complaints from bloody > users). The new bits we're about to push on to > http://pkg.omniti.com/omnios/bloody/ will enable another upstream > innovation: BSD Loader. Unlike previous updates, I want this mail on the > list before I push packages out to the repo server. > > > > The BSD Loader provides a replacement for GRUB. Its biggest upfront > improvements over GRUB 0.97 are that it's an active Open Source project > (GRUB went to 2.0), and that it eliminates the number-of-boot-environment > limits that GRUB had. Furthermore, BSD Loader provides a more stable > foundation for future improvements such as EFI boot (vs. BIOS boot) and the > possibility of booting off of raidZ pools. > > > > The official arrival of BSD Loader constitutes an operational flag day > for bloody users. This is a substantial enough change to merit its own new > wiki page to accompany r151022's release. Current users of bloody may > notice the presence of this file: /etc/default/be. This file has been in > place to PREVENT the use of loader. As of this upcoming update, that file > disappears, but it can be reconstituted. > > > > Before updating, you, the administrator, must make a decision: Stick > with GRUB, or move to loader. The /etc/default/be file, specifically the > "BE_HAS_GRUB=true" line, tells beadm(1M) what boot loader you wish to use > going forward. > > > > I WANT TO MOVE TO LOADER > > > > - This is the default after updating, but Loader does not get installed > until you "beadm activate" a loader-friendly BE (including the current > one). Reboots after an update without the invocation of "beadm activate" or > "installboot" will mean your machine stays with grub. You should notice an > extra message about /rpool/boot/menu.lst being created. > > > > - If you have bloody BE from 2017, it is loader-friendly, so long as you > remove /etc/default/be from that BE's root filesystem. > > > > - If you have a pre-2017 bloody BE, or an older OmniOS release BE, you > can not "beadm activate" it, beadm(1M) will fail. > > > > - An old BE CAN be booted from the new Loader menu, but beadm will not > work properly in that pre-Loader boot environment once booted. > > > > > > I WANT TO STICK WITH GRUB > > > > - Put "BE_HAS_GRUB=true" into /etc/default/be. This will instruct > beadm(1M) and libbe that you wish to continue with GRUB. > > > > - Technically this has been happening since the first bloody release of > 2017. The difference now is that "pkg update" removes this file from a > system-installed image. > > > > - Old BEs will work fine, and you can "beadm activate" between all of > them. > > > > > > I WANT TO MOVE FROM GRUB TO LOADER NOW (after sticking with GRUB) > > > > - Remove /etc/default/be on an active 2017 bloody BE. > > > > - "beadm activate " -- you should see a message about > /rpool/boot/menu.lst being created. > > > > - You are now on loader. > > > > - If the "beadm activate" fails, or you still are booting with GRUB > afterwards, explicitly install loader by: > > > > rm /etc/default/be (or at least remove the BE_HAS_GRUB line if you > have multiple lines for some reason) > > installboot -m /boot/pmbr /boot/gptzfsboot /dev/rdsk/ > > rm /rpool/boot/menu.lst > > beadm activate (should reconstruct /rpool/boot/menu.lst) > > > > If you have mirrored roots, do the above installboot for each > . > > > > > > I WANT TO MOVE FROM LOADER BACK TO GRUB (after being on Loader) > > > > - You will need to be in an active 2017 bloody BE. > > > > - Invoke the following: > > > > rm /rpool/boot/menu.lst > > echo "BE_HAS_GRUB=true" > /etc/default/be > > installgrub -m /boot/grub/stage1 /boot/grub/stage2 > /dev/rdsk/ > > > > If you have mirrored roots, use "installgrub -M > /dev/rdsk/ /dev/rdsk/ > > > > > > This update does NOT include an update to the ISO or USB install media > yet (that's a problem we're still solving). It WILL, however, include an > update to kayak software a day or two after, and the Kayak .zfs.bz2 media. > With this update, Kayak will now install both Loader AND use whole-disk GPT > partitioning for rpools. We'd appreciate additional feedback on the Kayak > changes. > > > > The repo will be updated within 24 hours of the sending of this mail. > The Kayak bits, 24 hours after that. > > > > Thanks for your patience as we move forward during this bloody cycle. > > > > Dan > >
Re: [OmniOS-discuss] LX chdir bug with steps to reproduce
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.linnosa...@polarshift.fi> wrote:
>
> On 16 Jan 2017, at 17.40, Mini Trader wrote:
>
> I used the following dtrace to get insight into what was happening (ran it
> from global zone).
>
> dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ {
> printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482
>
>
> I stumbled upon a similar bug (?) with Alpine 3.5 in LX zone and used this
> dtrace to see what is going on. No LOFS involved.
>
> I ran these commands:
>
> lxforum:~# cd /tmp
> lxforum:/tmp# mkdir foo
> lxforum:/tmp# mkdir foo/bar
> lxforum:/tmp# cd foo
> lxforum:/tmp/foo# cd bar
> lxforum:/tmp/foo/bar# cd ..
> lxforum:/tmp/foo# cd ..
> lxforum:/tmp# mv foo baz
> lxforum:/tmp# cd baz
> lxforum:/tmp/baz# cd bar
> -ash: getcwd: No such file or directory
> lxforum:(unknown)#
>
> dtrace looks like this:
>
> # pfexec dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/
> { printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 1100
> /dpool/zones/lxforum/root/tmp
> /dpool/zones/lxforum/root/tmp
> /dpool/zones/lxforum/root/tmp/foo
> /dpool/zones/lxforum/root/tmp/foo/bar
> /dpool/zones/lxforum/root/tmp/foo
> /dpool/zones/lxforum/root/tmp
> /dpool/zones/lxforum/root/tmp
> /dpool/zones/lxforum/root/tmp/baz
> /dpool/zones/lxforum/root/tmp/foo/bar
>
> So it would seem that renaming/moving a directory doesn’t update all links
> appropriately.
>
> — Jaakko
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LOFS LX chdir bug with steps to reproduce
That is correct I am on 151020 just moved up from LTS for this feature.
Just to be clear about one thing.
If you run this on a regular directory in the LX zone there is no issue. It
only takes place if the directory being read is from the LOFS mount of a
ZFS dataset. My mount has a property of read only. I did not try without
the readonly option.
That would be awesome if there is already a fix. This feature is pretty
amazing!
On Mon, Jan 16, 2017 at 3:24 PM Dan McDonald wrote:
> Thank you. I've discussed with Joyent, and they couldn't reproduce it.
> They have a fix we don't, so between that and whether or not it's fixed on
> bloody (you're on r151020, right mini?), I'll have to try it myself. It's
> possible the Joyent fix (outside LX, not yet upstreamed) may cure what ails
> you.
>
> FYI,
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
> On Jan 16, 2017, at 1:02 PM, Mini Trader wrote:
>
> 1. Does not happen on native.
> 2. My non-global zones are under /tank/zones/
> 3. It uses python - but the calls are all stdlib calls, no magic they are
> going directly to C. You can reproduce with same calls on C the system
> will eventually return ENOENT/ERRNO=2.
> 4. Looks to be LX specific. I also tested in global zone with LOFS. No
> issue.
>
> Thanks!
>
> On Mon, Jan 16, 2017 at 12:13 PM, Dan McDonald wrote:
>
> Thank you for doing this! Some questions in-line:
>
>
>
>
>
> > On Jan 16, 2017, at 10:40 AM, Mini Trader
> wrote:
>
>
> >
>
>
> > I spent a bit of time yesterday using dtrace and looking at the source.
> I believe I found why the system is falsely reporting that the current
> directory does not exist and have created a simple program to reproduce the
> problem. The problem seems to be related to when v_path in the vnode
> struct goes above a certain number of characters. This will only break on
> LOFS if inside the LX zone. Every time a program performs a chdir('..')
> and up to another dir the system stored working directory is falsely
> growing.
>
>
>
>
>
> Have you tried this on a native zone (just to make sure) as well?
>
>
>
>
>
> > Here are the steps to reproduce.
>
>
> >
>
>
> > 1. Mount a ZFS dataset via LOFS for your LX zone.
>
>
> > 2. Create a directory in the dataset called test
>
>
> > 3. In the test directory create another directory called 'Chdir Test'
>
>
>
>
>
> Does it matter where (global zone, inside LX zone) these directories gets
> created?
>
>
>
>
>
> > 4. Run the program below. All this is doing is going up a directory and
> dropping down a directory. We want to fill up v_path.
>
>
>
>
>
> Python...
>
>
>
>
>
> > 5. The program will bomb before iteration 1000. Really there should be
> no limit.
>
>
> >
>
>
> > import os
>
>
> > import time
>
>
> >
>
>
> > #time.sleep(15)
>
>
> > os.chdir('/tank/bigtest/test')
>
>
> > for i in xrange(1000):
>
>
> > print i
>
>
> > os.chdir('Chdir Test')
>
>
> > os.getcwd()
>
>
> > os.chdir('..')
>
>
> >
>
>
> > I used the following dtrace to get insight into what was happening (ran
> it from global zone).
>
>
> >
>
>
> > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ {
> printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482
>
>
> >
>
>
> > Uncomment the sleep line so that you can determine the PID when running
> dtrace.
>
>
>
>
>
> I'm forwarding this note on to Joyent, so they can see what's going on. I
> think this may be an LX bug, but I'm not sure.
>
>
>
>
>
> Thanks,
>
>
> Dan
>
>
>
>
>
>
>
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LOFS LX chdir bug with steps to reproduce
1. Does not happen on native.
2. My non-global zones are under /tank/zones/
3. It uses python - but the calls are all stdlib calls, no magic they are
going directly to C. You can reproduce with same calls on C the system
will eventually return ENOENT/ERRNO=2.
4. Looks to be LX specific. I also tested in global zone with LOFS. No
issue.
Thanks!
On Mon, Jan 16, 2017 at 12:13 PM, Dan McDonald wrote:
> Thank you for doing this! Some questions in-line:
>
> > On Jan 16, 2017, at 10:40 AM, Mini Trader
> wrote:
> >
> > I spent a bit of time yesterday using dtrace and looking at the source.
> I believe I found why the system is falsely reporting that the current
> directory does not exist and have created a simple program to reproduce the
> problem. The problem seems to be related to when v_path in the vnode
> struct goes above a certain number of characters. This will only break on
> LOFS if inside the LX zone. Every time a program performs a chdir('..')
> and up to another dir the system stored working directory is falsely
> growing.
>
> Have you tried this on a native zone (just to make sure) as well?
>
> > Here are the steps to reproduce.
> >
> > 1. Mount a ZFS dataset via LOFS for your LX zone.
> > 2. Create a directory in the dataset called test
> > 3. In the test directory create another directory called 'Chdir Test'
>
> Does it matter where (global zone, inside LX zone) these directories gets
> created?
>
> > 4. Run the program below. All this is doing is going up a directory and
> dropping down a directory. We want to fill up v_path.
>
> Python...
>
> > 5. The program will bomb before iteration 1000. Really there should be
> no limit.
> >
> > import os
> > import time
> >
> > #time.sleep(15)
> > os.chdir('/tank/bigtest/test')
> > for i in xrange(1000):
> > print i
> > os.chdir('Chdir Test')
> > os.getcwd()
> > os.chdir('..')
> >
> > I used the following dtrace to get insight into what was happening (ran
> it from global zone).
> >
> > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ {
> printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482
> >
> > Uncomment the sleep line so that you can determine the PID when running
> dtrace.
>
> I'm forwarding this note on to Joyent, so they can see what's going on. I
> think this may be an LX bug, but I'm not sure.
>
> Thanks,
> Dan
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] LOFS LX chdir bug with steps to reproduce
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.
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zone DTrace
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(0x7fefebc0, 1026)= -1 ENOENT (No such file or
directory)
write(1, "[Errno 2] No such file or direct"..., 36[Errno 2] No such file or
directory
) = 36
On Sat, Jan 14, 2017 at 10:02 AM, Mini Trader
wrote:
> I just tried on CentOS same error. The directory has to be from LOFS i.e.
> a ZFS pool.
>
> From OmniOS can you output zfs get all zonefileset and /usr/bin/ls -lV
> zonedirectory and share your results.
>
> On Sat, Jan 14, 2017 at 9:35 AM, Natxo Asenjo
> wrote:
>
>> hi,
>>
>>
>> On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader
>> wrote:
>>
>>> Well the author at my request was able to remove the call to os.getcwd()
>>> which allows the program to operate.
>>>
>>>
>>> If anyone wants to tinker here is an example that will likely break on
>>> someones system. I don't know if this is an LX bug, libc bug, python bug
>>> etc.
>>>
>>> # read a directory, stat all files
>>>
>>> import os
>>> import sys
>>> from stat import *
>>>
>>> def chdir(d):
>>> global cwdlist
>>>
>>> if d != '.':
>>> os.chdir(d)
>>> if d == '..':
>>> cwdlist.pop()
>>> else:
>>> cwdlist.append(d)
>>> print repr('/'.join(cwdlist))
>>> # Comment the line below to allow things to run
>>> os.getcwd()
>>>
>>> def walk(d):
>>> chdir(d)
>>> dirlist = os.listdir('.')
>>> dirlist.sort()
>>> for f in dirlist:
>>> try:
>>> s = os.lstat(f)
>>> if S_ISDIR(s.st_mode):
>>> walk(f)
>>> except OSError, err:
>>> print err
>>> chdir('..')
>>>
>>> if len(sys.argv) != 2:
>>> print 'need 1 arg, directory to scan'
>>>
>>> os.chdir(sys.argv[1])
>>> cwd = os.getcwd()
>>> cwdlist = cwd.split('/')
>>>
>>> walk('.')
>>>
>>>
>> runs fine in a centos 6.8 container, no problem.
>>
>> I even have a couple of mount points with several thousand files and it
>> walks everything without a hitch.
>>
>> --
>> regards,
>> Natxo
>>
>>
>>
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zone DTrace
I just tried on CentOS same error. The directory has to be from LOFS i.e.
a ZFS pool.
>From OmniOS can you output zfs get all zonefileset and /usr/bin/ls -lV
zonedirectory and share your results.
On Sat, Jan 14, 2017 at 9:35 AM, Natxo Asenjo
wrote:
> hi,
>
>
> On Sat, Jan 14, 2017 at 3:16 PM, Mini Trader
> wrote:
>
>> Well the author at my request was able to remove the call to os.getcwd()
>> which allows the program to operate.
>>
>>
>> If anyone wants to tinker here is an example that will likely break on
>> someones system. I don't know if this is an LX bug, libc bug, python bug
>> etc.
>>
>> # read a directory, stat all files
>>
>> import os
>> import sys
>> from stat import *
>>
>> def chdir(d):
>> global cwdlist
>>
>> if d != '.':
>> os.chdir(d)
>> if d == '..':
>> cwdlist.pop()
>> else:
>> cwdlist.append(d)
>> print repr('/'.join(cwdlist))
>> # Comment the line below to allow things to run
>> os.getcwd()
>>
>> def walk(d):
>> chdir(d)
>> dirlist = os.listdir('.')
>> dirlist.sort()
>> for f in dirlist:
>> try:
>> s = os.lstat(f)
>> if S_ISDIR(s.st_mode):
>> walk(f)
>> except OSError, err:
>> print err
>> chdir('..')
>>
>> if len(sys.argv) != 2:
>> print 'need 1 arg, directory to scan'
>>
>> os.chdir(sys.argv[1])
>> cwd = os.getcwd()
>> cwdlist = cwd.split('/')
>>
>> walk('.')
>>
>>
> runs fine in a centos 6.8 container, no problem.
>
> I even have a couple of mount points with several thousand files and it
> walks everything without a hitch.
>
> --
> regards,
> Natxo
>
>
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zone DTrace
Well the author at my request was able to remove the call to os.getcwd()
which allows the program to operate.
If anyone wants to tinker here is an example that will likely break on
someones system. I don't know if this is an LX bug, libc bug, python bug
etc.
# read a directory, stat all files
import os
import sys
from stat import *
def chdir(d):
global cwdlist
if d != '.':
os.chdir(d)
if d == '..':
cwdlist.pop()
else:
cwdlist.append(d)
print repr('/'.join(cwdlist))
# Comment the line below to allow things to run
os.getcwd()
def walk(d):
chdir(d)
dirlist = os.listdir('.')
dirlist.sort()
for f in dirlist:
try:
s = os.lstat(f)
if S_ISDIR(s.st_mode):
walk(f)
except OSError, err:
print err
chdir('..')
if len(sys.argv) != 2:
print 'need 1 arg, directory to scan'
os.chdir(sys.argv[1])
cwd = os.getcwd()
cwdlist = cwd.split('/')
walk('.')
On Fri, Jan 13, 2017 at 4:06 PM, Mini Trader
wrote:
> Here is the code. It will run just fine with Debian 8.6 or OmniOS. It
> will fail on the LX zone with Debian. The only way for it to fail is for
> the stat call to fail and this seems to happen because the system doen't
> know what directory it is in. The files being looked at are static so not
> a race condition.
>
> Simple python script.
>
> # read a directory, stat all files
>
> import os
> import sys
> from stat import *
>
> def walk(d):
> os.chdir(d)
> working = os.getcwd()
> print working
> dirlist = os.listdir('.')
> dirlist.sort()
> for f in dirlist:
> try:
> s = os.lstat(f)
> if S_ISDIR(s.st_mode):
> walk(f)
> except OSError, err:
> print "CurrentDIR: " + working
> print "CurrentFile: " + f
> print err
> os.chdir('..')
> print "DONE"
>
> if len(sys.argv) != 2:
> print 'need 1 arg, directory to scan'
>
> cwd = os.getcwd()
> os.chdir(sys.argv[1])
> walk('.')
>
>
> On Fri, Jan 13, 2017 at 3:52 PM, Dale Ghent wrote:
>
>> Could you provide some of your telemetry and background here? There might
>> be a reasonable explanation, or a quick fix.
>>
>> /dale
>>
>> > On Jan 13, 2017, at 3:12 PM, Mini Trader
>> wrote:
>> >
>> > I have a small program that will reproduce the issue. Where should the
>> bug be sent? It's pretty serious. The system is forgetting the location
>> of the current working directory in a recursive call.
>> >
>> > On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman
>> wrote:
>> > Have you tried simply tracing the lx-syscall probes?
>> >
>> > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader
>> wrote:
>> > I followed these instructions prior to my post and my zone would not
>> boot after doing the mod to add the flag to the file.
>> >
>> >
>> > On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman
>> wrote:
>> > The short answer is yes.
>> >
>> > My experience debugging LX was on SmartOS and there are some notes on
>> https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBran
>> dedZones-Debugging
>> >
>> > Some of the details on that page are Specific to SmartOS, but some of
>> it is generic to LX.
>> >
>> > -Nahum
>> >
>> > On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader
>> wrote:
>> > Is there anything that can be done to trace a program having issues on
>> an LX Zone.
>> >
>> > I am seeing:
>> >
>> > OSError: [Errno 2] No such file or directory:
>> >
>> > Again under certain conditions which I am trying to trace -
>> unfortunately this is a closed source program. Can DTrace be used to help
>> track something like this?
>> >
>> > Thanks!
>> >
>> >
>> >
>> > ___
>> >
>> >
>> > OmniOS-discuss mailing list
>> >
>> >
>> > OmniOS-discuss@lists.omniti.com
>> >
>> >
>> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > OmniOS-discuss mailing list
>> > OmniOS-discuss@lists.omniti.com
>> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zone DTrace
Here is the code. It will run just fine with Debian 8.6 or OmniOS. It
will fail on the LX zone with Debian. The only way for it to fail is for
the stat call to fail and this seems to happen because the system doen't
know what directory it is in. The files being looked at are static so not
a race condition.
Simple python script.
# read a directory, stat all files
import os
import sys
from stat import *
def walk(d):
os.chdir(d)
working = os.getcwd()
print working
dirlist = os.listdir('.')
dirlist.sort()
for f in dirlist:
try:
s = os.lstat(f)
if S_ISDIR(s.st_mode):
walk(f)
except OSError, err:
print "CurrentDIR: " + working
print "CurrentFile: " + f
print err
os.chdir('..')
print "DONE"
if len(sys.argv) != 2:
print 'need 1 arg, directory to scan'
cwd = os.getcwd()
os.chdir(sys.argv[1])
walk('.')
On Fri, Jan 13, 2017 at 3:52 PM, Dale Ghent wrote:
> Could you provide some of your telemetry and background here? There might
> be a reasonable explanation, or a quick fix.
>
> /dale
>
> > On Jan 13, 2017, at 3:12 PM, Mini Trader
> wrote:
> >
> > I have a small program that will reproduce the issue. Where should the
> bug be sent? It's pretty serious. The system is forgetting the location
> of the current working directory in a recursive call.
> >
> > On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman
> wrote:
> > Have you tried simply tracing the lx-syscall probes?
> >
> > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader
> wrote:
> > I followed these instructions prior to my post and my zone would not
> boot after doing the mod to add the flag to the file.
> >
> >
> > On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman
> wrote:
> > The short answer is yes.
> >
> > My experience debugging LX was on SmartOS and there are some notes on
> https://wiki.smartos.org/display/DOC/LX+Branded+Zones#
> LXBrandedZones-Debugging
> >
> > Some of the details on that page are Specific to SmartOS, but some of it
> is generic to LX.
> >
> > -Nahum
> >
> > On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader
> wrote:
> > Is there anything that can be done to trace a program having issues on
> an LX Zone.
> >
> > I am seeing:
> >
> > OSError: [Errno 2] No such file or directory:
> >
> > Again under certain conditions which I am trying to trace -
> unfortunately this is a closed source program. Can DTrace be used to help
> track something like this?
> >
> > Thanks!
> >
> >
> >
> > ___
> >
> >
> > OmniOS-discuss mailing list
> >
> >
> > OmniOS-discuss@lists.omniti.com
> >
> >
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > OmniOS-discuss mailing list
> > OmniOS-discuss@lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zone DTrace
I have a small program that will reproduce the issue. Where should the bug be sent? It's pretty serious. The system is forgetting the location of the current working directory in a recursive call. On Fri, Jan 13, 2017 at 9:30 AM, Nahum Shalman wrote: > Have you tried simply tracing the lx-syscall probes? > > On Fri, Jan 13, 2017 at 9:24 AM, Mini Trader > wrote: > >> I followed these instructions prior to my post and my zone would not boot >> after doing the mod to add the flag to the file. >> >> >> On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman >> wrote: >> >>> The short answer is yes. >>> >>> My experience debugging LX was on SmartOS and there are some notes on >>> https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXB >>> randedZones-Debugging >>> >>> Some of the details on that page are Specific to SmartOS, but some of it >>> is generic to LX. >>> >>> -Nahum >>> >>> On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader >>> wrote: >>> >>> Is there anything that can be done to trace a program having issues on >>> an LX Zone. >>> >>> I am seeing: >>> >>> OSError: [Errno 2] No such file or directory: >>> >>> Again under certain conditions which I am trying to trace - >>> unfortunately this is a closed source program. Can DTrace be used to help >>> track something like this? >>> >>> Thanks! >>> >>> >>> >>> ___ >>> >>> >>> OmniOS-discuss mailing list >>> >>> >>> OmniOS-discuss@lists.omniti.com >>> >>> >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >>> >>> >>> >>> >>> >>> > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zone DTrace
I followed these instructions prior to my post and my zone would not boot after doing the mod to add the flag to the file. On Fri, Jan 13, 2017 at 8:55 AM Nahum Shalman wrote: > The short answer is yes. > > My experience debugging LX was on SmartOS and there are some notes on > https://wiki.smartos.org/display/DOC/LX+Branded+Zones#LXBrandedZones-Debugging > > Some of the details on that page are Specific to SmartOS, but some of it > is generic to LX. > > -Nahum > > On Fri, Jan 13, 2017 at 12:46 AM, Mini Trader > wrote: > > Is there anything that can be done to trace a program having issues on an > LX Zone. > > I am seeing: > > OSError: [Errno 2] No such file or directory: > > Again under certain conditions which I am trying to trace - unfortunately > this is a closed source program. Can DTrace be used to help track > something like this? > > Thanks! > > > > ___ > > > OmniOS-discuss mailing list > > > OmniOS-discuss@lists.omniti.com > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] LX Zone DTrace
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@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
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@storage1:/root# flowadm add-flow -l backup0 -a transport=tcp tcpflow root@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@storage1:/root# flowadm remove-flow -l backup0 desktop-amd64.iso?_ 1%[ ] 18.24M 1.00MB/s eta 85m 54s # It appears our download speed is running at 8 MEGABIT or 1MEGABYTE without any flow. So why would a restriction of half of our download rate cause it to run at 1/10th the maximum speed! On Wed, Jan 11, 2017 at 8:52 PM, Dan McDonald wrote: > > > On Jan 11, 2017, at 8:32 PM, Mini Trader > wrote: > > > > This does not work. Simple example. Ran wget on an ubuntu ISO. Was > downloading at over 1 mega byte per sec. Set adapter to 4000K. I would > expect the download to peak at around 500 Kilo Bytes. Was in the 100 > range. 16000K put it in the 500kb range. Doesn't add up. Also didn't > persist across reboot of zone. > > 1.) flowadm works in units of bits/sec, not bytes. 4000kbit == 4mbit == > 500kbytes. Please RTFM carefully. > > 2.) Use it in the global zone for the NIC you're assigning. Then it'll > persist. Persistence of /native commands in LX zones is an open problem > right now. We aren't planning on doing it for flowadm, only for ipadm. > > Dan > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
Running it right now with 15M and it seems to have capped it at 400 kilo bytes/sec. Whatever is being used to calculate is not correct at least on the driver for this NIC - VMXNET3S. Another thing. I realize that you said that you can limit this to ports. But what if you are downloading and uploading to the same port e.g. 80 but only want to limit on the upload? On Wed, Jan 11, 2017 at 8:34 PM, Ergi Thanasko wrote: > We were using flowadm on a source ip basis. Not easy to keep track of the > ip in a big product environment and also want to throttle in or out and > the bidirectional was not clean way of doing it > > > > > On Jan 11, 2017, at 5:28 PM, Dan McDonald wrote: > > > > > >> On Jan 11, 2017, at 8:25 PM, Mini Trader > wrote: > >> > >> Is it possible to limit flow control on uploads? flowadm - the numbers > don't seem to add up. I'm not sure what its doing. > > > > From the manual: > > > > maxbw > > > > Sets the full duplex bandwidth for the flow. The bandwidth is > > specified as an integer with one of the scale suffixes(K, M, > or G > > for Kbps, Mbps, and Gbps). If no units are specified, the input > > value will be read as Mbps. The default is no bandwidth limit. > > > > Flowadm bandwidth is bidirectional. You can, though, limit uploads > based on port number. See the examples section for https, e.g. > > > > Dan > > > > ___ > > OmniOS-discuss mailing list > > OmniOS-discuss@lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
This does not work. Simple example. Ran wget on an ubuntu ISO. Was downloading at over 1 mega byte per sec. Set adapter to 4000K. I would expect the download to peak at around 500 Kilo Bytes. Was in the 100 range. 16000K put it in the 500kb range. Doesn't add up. Also didn't persist across reboot of zone. On Wed, Jan 11, 2017 at 8:28 PM, Dan McDonald wrote: > > > On Jan 11, 2017, at 8:25 PM, Mini Trader > wrote: > > > > Is it possible to limit flow control on uploads? flowadm - the numbers > don't seem to add up. I'm not sure what its doing. > > From the manual: > >maxbw > >Sets the full duplex bandwidth for the flow. The bandwidth is >specified as an integer with one of the scale suffixes(K, M, or > G >for Kbps, Mbps, and Gbps). If no units are specified, the input >value will be read as Mbps. The default is no bandwidth limit. > > Flowadm bandwidth is bidirectional. You can, though, limit uploads based > on port number. See the examples section for https, e.g. > > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
Is it possible to limit flow control on uploads? flowadm - the numbers don't seem to add up. I'm not sure what its doing. On Wed, Jan 11, 2017 at 8:16 PM, Dan McDonald wrote: > > > On Jan 11, 2017, at 8:15 PM, Mini Trader > wrote: > > > > The values set in flowadm seem odd. They don't align with download > speed. Also it is up and down not up or down. > > > > wondershaper does not work. > > It won't because it expects kernel interfaces LX zones don't provide. > > You will have to use /native/ tools for things like this. > > Sorry, > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
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@debian-8:~# wondershaper backup0 4000 4000
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
We have an error talking to the kernel
RTNETLINK answers: Unknown error -122
We have an error talking to the kernel
RTNETLINK answers: Unknown error -122
We have an error talking to the kernel
RTNETLINK answers: Unknown error -122
We have an error talking to the kernel
RTNETLINK answers: Unknown error -122
We have an error talking to the kernel
RTNETLINK answers: Unknown error -122
RTNETLINK answers: Unknown error -122
We have an error talking to the kernel
On Wed, Jan 11, 2017 at 6:41 PM, Jim Klimov wrote:
> 12 января 2017 г. 0:13:39 CET, Mini Trader
> пишет:
> >Is it possible for me to add inputs into the interface config for my
> >adapters.
> >
> >I use a utility to restrict uplink speed called wondershaper.
> >
> >Normally my /etc/network/interfaces has something like:
> >
> >up /sbin/wondershaper eth0 X Y
> >
> >Would like to do the same if possible in the zone config.
> >
> >On Wed, Jan 11, 2017 at 1:56 PM Dan McDonald wrote:
> >
> >>
> >>
> >> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman
> >wrote:
> >>
> >> >
> >>
> >> > Will we still be able to to configure the networking under zonecfg?
> >>
> >>
> >>
> >> Yes.
> >>
> >>
> >>
> >> > Basically what I'm asking is can we stop our zones from being able
> >to
> >> change
> >>
> >> > their IP address?
> >>
> >>
> >>
> >> That's a different question, and the answer is going to be no going
> >> forward, as it is no today.
> >>
> >>
> >>
> >> I have LX zones using zonecfg(1M) to set DHCP. I can go in as
> >root@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@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
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
Is it possible for me to add inputs into the interface config for my
adapters.
I use a utility to restrict uplink speed called wondershaper.
Normally my /etc/network/interfaces has something like:
up /sbin/wondershaper eth0 X Y
Would like to do the same if possible in the zone config.
On Wed, Jan 11, 2017 at 1:56 PM Dan McDonald wrote:
>
>
> > On Jan 11, 2017, at 5:04 AM, Andy Fiddaman wrote:
>
> >
>
> > Will we still be able to to configure the networking under zonecfg?
>
>
>
> Yes.
>
>
>
> > Basically what I'm asking is can we stop our zones from being able to
> change
>
> > their IP address?
>
>
>
> That's a different question, and the answer is going to be no going
> forward, as it is no today.
>
>
>
> I have LX zones using zonecfg(1M) to set DHCP. I can go in as root@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@lists.omniti.com
>
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
If the hardware is there will it be used? On Wed, Jan 11, 2017 at 11:33 AM Nahum Shalman wrote: > On Wed, Jan 11, 2017 at 11:01 AM, Mini Trader > wrote: > > With respect to virtualization, should one be turning on any hardware > specific feature for the VM to properly use LX or it doesn't matter? > > > LX doesn't require hardware virtualization support. LX zones are like > other zones except that they use an emulated Linux system call table > instead of a native illumos system call table. > No actual Linux kernel is used so there's no need for the hardware > shenanigans (and their associated performance costs) to trick Linux into > thinking it's on hardware. > > -Nahum > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
With respect to virtualization, should one be turning on any hardware specific feature for the VM to properly use LX or it doesn't matter? On Wed, Jan 11, 2017 at 9:35 AM Nahum Shalman wrote: > At this phase I would honestly recommend attempting to reproduce LX issues > on the latest SmartOS and reporting them to Joyent. > Anything that manifests on OmniOS but not SmartOS would be an indication > that there's something we could pull over from SmartOS to fix on OmniOS. > > Chrome and Chromium I'm confident are still broken on SmartOS too. I think > it uses namespace and/or cgroup functionality for sandboxing that have not > been implemented in LX yet. > > I seem to recall Firefox mostly working the last time I tried, for > whatever that's worth. > > -Nahum > > On Wed, Jan 11, 2017 at 5:08 AM, Tobias Oetiker wrote: > > On 11 Jan, 2017, at 00:03, Dan McDonald dan...@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@lists.omniti.com > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > ___ > > OmniOS-discuss mailing list > > OmniOS-discuss@lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts
Any examples on what needs to be done to make this work with LOFS? On Tue, Jan 10, 2017 at 7:19 PM Dan McDonald wrote: > > > > On Jan 10, 2017, at 6:49 PM, Mini Trader > wrote: > > > > > > Currently the UID Mapping between the host (OmniOS) and my zone (Linux) > is based purely on UID. Obviously the UID's on my Linux zone are going to > be very different from my OmniOS setup. > > > > > > Is there any NFS4 IDMAPD concept available here? e.g. nobody/nogroup > for unrecognized users and groups or mapping from a numerical id to user? > > > > http://illumos.org/man/1m/idmap > > > > Dan > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX zones: configurations
No Python 3.x ? On Tue, Jan 10, 2017 at 6:04 PM, Dale Ghent wrote: > > > On Jan 10, 2017, at 5:04 PM, Dominik Hassler wrote: > > > > @Dan: LX zones are considered BETA in r20 and r22 seems to be "late", is > there a chance to get LX bleeding edge in r20 w/o the risk of breaking > something else? > > Zones in 020 is still largely in sync with the LX code currently in bloody > (021). Since zones (beta) was released with 020, we’ve been primarily > focussed on other items required for 022, the most laborious of which is > the Python 2.6 -> 2.7 upgrade. This is needed for a number of reasons. > First, the benefits of getting off of 2.6 and on to 2.7 is > self-explanatory, but 2.7 is also needed for being able to stay in sync > with the pkg code, as well as the next big project for 022 - a > loader-enabled installer (text installer and kayak) to replace the current > one. > > In the mean-time, we’re always looking for ideas (and even contributions!) > from the community on how best to handle the management and administrivia > involved with LX zones. For now, we’d like this to stay within the realm of > zoneadm/zonecfg and family. > > /dale > > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] LX Zones and UID Mapping on LOFS Mounts
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? ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
zones sharenfs offdefault main/zones checksum on default main/zones compression lz4inherited from main main/zones atime offlocal main/zones devices on default main/zones exec on default main/zones setuidon default main/zones readonly offdefault main/zones zoned offdefault main/zones snapdir hidden local main/zones aclmode passthroughlocal main/zones aclinheritpassthroughlocal main/zones canmount on default main/zones xattr on default main/zones copies1 default main/zones version 5 - main/zones utf8only on - main/zones normalization formD - main/zones casesensitivity insensitive- main/zones vscan offdefault main/zones nbmandon local main/zones sharesmb offlocal main/zones refquota none default main/zones refreservationnone default main/zones primarycache alldefault main/zones secondarycachealldefault main/zones usedbysnapshots 0 - main/zones usedbydataset 226M - main/zones usedbychildren0 - main/zones usedbyrefreservation 0 - main/zones logbias latencydefault main/zones dedup offdefault 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_limitnone default main/zones filesystem_count none default main/zones snapshot_countnone default main/zones redundant_metadataalldefault root@storage1:/main# /usr/bin/ls -lV ./zones/ total 1 drwxrwxrwx+ 2 root root 3 Jan 10 13:57 images user:root:rwxpdDaARWcCos:fdI:allow everyone@:rwxpdDaARWc--s:fdI:allow owner@:rwxp-DaARWcCos:---:allow group@:r-x---a-R-c--s:---:allow everyone@:r-x---a-R-c--s:---:allow On Tue, Jan 10, 2017 at 5:40 AM, Илья Кулагин wrote: > Hi all. > > 1st, it seems to me that it is necessary for all lx-users to > find/share/explain some common steps to debug software misbehaviour in lx > zone. Because for my (very small, of course) practice, linux software often > is based on strange assumptions and even 'dirty hacks'. > Maybe with dtrace, like it was done for 'unimplemented syscalls' in > SmartOS wiki https://wiki.smartos.org/display/DOC/LX+Branded+Zones# > LXBrandedZones-huntingforunsupportedsyscalls > Maybe whatelse... > > So i have reproducible steps and also solve my problem. > > If I create my dataset via napp-it. It seems like it applies special > permissions. LX will complain that other and group should not have write > permissions on the zone directory. So I remove these via chmod o-w and > chmod g-w. > > > I think that in this case it will be useful that you compare full zfs > properties list (`zfs get all ` for zone root) and full acls (`/usr/bin/ls > -lV ` -- of course, issued from host with zone running to display actual > permissions while FS is mounted) for both zones - working and crashing ones. > > > At this point I can create the zone and in doing so I can reproduce the > error. If I create the data set with your standard zfs create tank/zones > the permissions are fine by default and the bug is not reproducible. > > So somehow somewhere whatever is happening underneath the hood is > sensitive to these permissions on the second write in this program. > > Strange indeed. > > On Mon, Jan 9, 2017 at 10:03 PM, Dan McDonald wrote: > >> >> > On Jan 9, 2017, at 10:01 PM, Mini Trader >> wrote: >> > >> > Just to reiterate on a fresh install of 20 I got no error. Different &
Re: [OmniOS-discuss] LX Program Issue
So i have reproducible steps and also solve my problem. If I create my dataset via napp-it. It seems like it applies special permissions. LX will complain that other and group should not have write permissions on the zone directory. So I remove these via chmod o-w and chmod g-w. At this point I can create the zone and in doing so I can reproduce the error. If I create the data set with your standard zfs create tank/zones the permissions are fine by default and the bug is not reproducible. So somehow somewhere whatever is happening underneath the hood is sensitive to these permissions on the second write in this program. Strange indeed. On Mon, Jan 9, 2017 at 10:03 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 10:01 PM, Mini Trader > wrote: > > > > Just to reiterate on a fresh install of 20 I got no error. Different > hardware too. > > WEIRD. (Sorry I didn't catch that earlier. Juggling other balls > concurrently!) > > Okay, thanks for the update. Not sure if there's anything I can do in the > immediate term, but thanks for keeping me informed (and giving me the full > zonecfg). > > Thanks! > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
# zonecfg -z lx0 create set zonepath=/main/zones/lx0 set brand=lx set autoboot=false set ip-type=exclusive add net set physical=vmxnet3s2 add property (name=gateway,value="10.255.0.1") add property (name=ips,value="10.255.0.16/24") add property (name=primary,value="true") end add attr set name=dns-domain set type=string set value=mydomain.systems end add attr set name=resolvers set type=string set value=10.255.0.1 end add attr set name=kernel-version set type=string set value=3.16.0 end exit Image was from here: https://images.joyent.com/images/9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1/file Just to reiterate on a fresh install of 20 I got no error. Different hardware too. On Mon, Jan 9, 2017 at 9:52 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 9:51 PM, Mini Trader > wrote: > > > > 2. Setup the LX System The same way I tested before. > > > > I want that setup! I want: > > - zonecfg input (modulo IP addresses) > > - image you used > > I can test it on 020 and bloody, to see if it's a problem fixed post-020. > > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
So I tried the following. 1. Update my system from LTS to stable. 2. Setup the LX System The same way I tested before. 3. Download the program again It failed. Basically I have a successful run off of a fresh install and a failed run off of a non fresh install. Will try a fresh install of LTS, and an update up to 20 to see if that makes a difference. Weird. On Mon, Jan 9, 2017 at 8:09 PM, Mini Trader wrote: > I can't reproduce this evening :) I started with a fresh install off the > CD instead of upgrading from LTS. Will continue and get back to you. > > On Mon, Jan 9, 2017 at 3:24 PM, Dan McDonald wrote: > >> >> > On Jan 9, 2017, at 3:22 PM, Mini Trader >> wrote: >> > >> > I also used Debian 8.6 and when I did a backup. The first one worked >> but a second call to same directory with no changes did not. >> >> Still bloody, the Ubuntu 16 zone, and it works with multiple followups: >> >> root@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@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@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@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@ubuntu-14-04-b:~# >> >> >> Dan >> >> > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
One thing that is weird. I am seeing that after installing the zone. I get the following error when shutting down or rebooting. Often followed by a kernel panic. showmount: hostname: RPC: Program Not registered On Mon, Jan 9, 2017 at 8:11 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 8:09 PM, Mini Trader > wrote: > > > > I can't reproduce this evening :) I started with a fresh install off > the CD instead of upgrading from LTS. Will continue and get back to you. > > That should be a NOP, you'll land on the same r151020 bits. > > Share your "zonecfg -z lx-zone export" and what image you used so I can > see if it's an 020-specific bug or not. > > Thanks, > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
I can't reproduce this evening :) I started with a fresh install off the CD instead of upgrading from LTS. Will continue and get back to you. On Mon, Jan 9, 2017 at 3:24 PM, Dan McDonald wrote: > > > On Jan 9, 2017, at 3:22 PM, Mini Trader > wrote: > > > > I also used Debian 8.6 and when I did a backup. The first one worked but > a second call to same directory with no changes did not. > > Still bloody, the Ubuntu 16 zone, and it works with multiple followups: > > root@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@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@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@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@ubuntu-14-04-b:~# > > > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
I tested on 1520. I also used Debian 8.6 and when I did a backup. The first one worked but a second call to same directory with no changes did not. On Mon, Jan 9, 2017 at 3:08 PM Dan McDonald wrote: > > > > On Jan 9, 2017, at 2:58 PM, Mini Trader > wrote: > > > > > > It's a single binary. That can be downloaded. > > > > > > > Oh that's not so bad. > > > > You saw my other note. > > > > What I neglected to mention, however, is that my tests were on OmniOS > bloody, which has more fixes from Joyent than r151020 does. > > > > Dan > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
It's a single binary. That can be downloaded. I don't think the author is available to generate the test case. My question was as an end user how can we determine why the software is not working on LX. On Mon, Jan 9, 2017 at 2:34 PM Dan McDonald wrote: > On Jan 9, 2017, at 2:31 PM, Mini Trader wrote: > > The test case was in my previous post. Does this require a whole wad of installation? I was hoping you (or the hashbackup folks) would be able to produce a smaller, easy-to-compile, test case of some sort. They told you what they thought the problem was, they should be able to extract the bit of failing code and shrink it to a test case. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
The test case was in my previous post. On Mon, Jan 9, 2017 at 1:53 PM Jerry Jelinek wrote: > A simple test case would be great, or at least we'll need details on what > you are running and how to reproduce the problem. You could also check the > known bug list at https://smartos.org/bugview/index.html, although > searching there is not very good. All open lx bugs are listed there under > OS-. > > Thanks, > Jerry > > > On Mon, Jan 9, 2017 at 9:58 AM, Dan McDonald wrote: > > > > > > On Jan 9, 2017, at 11:25 AM, Mini Trader > wrote: > > > > > > > > I have a program that is behaving differently in an LX environment. > Specifically something about permission issues. I've corresponded with the > author and they believe the issue could take place if the system was > falsely reporting the status of a file e.g. file open instead of closed. > > > > > > > > Regardless issue does not happen if running Debian on VMware. > > > > > > > > What would be the appropriate route to go to report this bug? > > > > > > Good question. > > > > > > The primary maintainers of LX are all at Joyent. Yet now LX has spread > beyond just SmartOS/illumos-joyent. > > > > > > First off: Can you reduce your program (mis)behavior to a simple test > case? If so, that'll be easier regardless of where you report it. > > > > > > I'm Bcc:ing some SmartOS people, who can either jump in here or tell me & > you privately what they think the best course of action is. > > > > > > Thanks, > > > Dan > > > > > > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
The above was tested with Debian 8.6 SmartOS image. On Mon, Jan 9, 2017 at 12:35 PM Mini Trader wrote: > The program is from hashbackup.com it's a backup utility that allows you > to backup to backblaze > > To reproduce create a directory with some files. And instruct the program > to backup the directory > > hb init -c hb # init backup to directory hb > hb backup -c hb ./data # backup directory data > hb backup -c hb ./data # Program crashes only on LX > > > > On Mon, Jan 9, 2017 at 12:13 PM Dale Ghent wrote: > > > > Can you talk more about the program you're having issues with, how you're > using it and how this problem is manifesting itself? > > > > /dale > > > > > On Jan 9, 2017, at 11:25 AM, Mini Trader > wrote: > > > > > > I have a program that is behaving differently in an LX environment. > Specifically something about permission issues. I've corresponded with the > author and they believe the issue could take place if the system was > falsely reporting the status of a file e.g. file open instead of closed. > > > > > > Regardless issue does not happen if running Debian on VMware. > > > > > > What would be the appropriate route to go to report this bug? > > > ___ > > > OmniOS-discuss mailing list > > > OmniOS-discuss@lists.omniti.com > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Program Issue
The program is from hashbackup.com it's a backup utility that allows you to backup to backblaze To reproduce create a directory with some files. And instruct the program to backup the directory hb init -c hb # init backup to directory hb hb backup -c hb ./data # backup directory data hb backup -c hb ./data # Program crashes only on LX On Mon, Jan 9, 2017 at 12:13 PM Dale Ghent wrote: > > > Can you talk more about the program you're having issues with, how you're > using it and how this problem is manifesting itself? > > > > /dale > > > > > On Jan 9, 2017, at 11:25 AM, Mini Trader > wrote: > > > > > > I have a program that is behaving differently in an LX environment. > Specifically something about permission issues. I've corresponded with the > author and they believe the issue could take place if the system was > falsely reporting the status of a file e.g. file open instead of closed. > > > > > > Regardless issue does not happen if running Debian on VMware. > > > > > > What would be the appropriate route to go to report this bug? > > > ___ > > > OmniOS-discuss mailing list > > > OmniOS-discuss@lists.omniti.com > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] LX Program Issue
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@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
Only added the vnic because I saw it in some other install manual. Obviously not needed - thank you for pointing that out! I added a third NIC on the same network and wham I am up and running :) Thank you for the help. Is there any documentation on what I need to do to make my datasets visible? On Thu, Jan 5, 2017 at 1:48 PM, Dan McDonald wrote: > > > On Jan 5, 2017, at 1:44 PM, Michael Rasmussen wrote: > > > > Does it not require promiscuous mode to be able to create a nic alias? > > I do not think this is supported with default settings in VmWare. > > I don't know my VMware-fu very well, but this sounds like what I was > talking about. > > Thanks! > Dan > > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
root@storage1:/root# dladm show-link LINKCLASS MTUSTATEBRIDGE OVER vmxnet3s0 phys 1500 up -- -- vmxnet3s1 phys 9000 up -- -- lx0 vnic 1500 up -- vmxnet3s0 root@storage1:/root# root@storage1:/root# dladm show-vnic LINK OVER SPEED MACADDRESSMACADDRTYPE VID lx0 vmxnet3s01 2:8:20:75:44:a6 random 0 root@storage1:/root# root@storage1:/root# dladm show-ether LINKPTYPESTATEAUTO SPEED-DUPLEX PAUSE vmxnet3s0 current up no10G-f none vmxnet3s1 current up no10G-f none Will be hard to get a physical NIC on the machine. On Thu, Jan 5, 2017 at 1:34 PM, Dan McDonald wrote: > Hmmm. > > So now we do have to go back to the global zone... but not what you showed > me. > > Please show: > > dladm show-link > > dladm show-vnic > > dladm show-ether > > I notice you're running on vmxnet... I wonder if your host is preventing > you from creating vNICs through some sort of address filtering? > > One thing to try is to pass a native NIC to the LX zone (instead of an lx0 > vnic) to see if that works. > > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
The only machine I can ping is the host. Nothing else. root@debian-8:~# ifconfig -a loLink 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@debian-8:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default 10.255.0.1 0.0.0.0 UG0 00 * 10.255.0.0 * 255.255.255.0 U 0 00 lx0 root@debian-8:~# cat /etc/network/interfaces # AUTOMATIC ZONE CONFIG iface lo inet manual iface lx0 inet manual root@debian-8:~# cat /etc/resolv.conf # AUTOMATIC ZONE CONFIG nameserver 10.255.0.1 search mydomain.com root@debian-8:~# ip route show default via 10.255.0.1 proto static 10.255.0.0/24 dev lx0 proto kernel scope link src 10.255.0.16 On Thu, Jan 5, 2017 at 1:11 PM, Dan McDonald wrote: > Why are you showing me global-zone things when the problem is in the LX > zone? > > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
Having trouble with networking. Any thoughts on this? ipadm show-addr ADDROBJ TYPE STATEADDR vmxnet3s0/v4 static ok 10.255.0.15/24 dladm show-vnic LINK OVER SPEED MACADDRESSMACADDRTYPE VID lx0 vmxnet3s01 2:8:20:94:5e:crandom 0 netstat -rn -finet Routing Table: IPv4 Destination Gateway Flags Ref Use Interface - - -- - default 10.255.0.1 UG2 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.1127.0.0.1UH2 60 lo0 Here is the config: create set zonepath=/main/zones/lx0 set brand=lx set autoboot=false set ip-type=exclusive add net set physical=lx0 add property (name=gateway,value="10.255.0.1") add property (name=ips,value="10.255.0.16/24") add property (name=primary,value="true") end add attr set name=dns-domain set type=string set value=mydomain.com end add attr set name=resolvers set type=string set value=10.255.0.1 end add attr set name=kernel-version set type=string set value=3.16.0 end exit On Thu, Jan 5, 2017 at 11:35 AM, Dan McDonald wrote: > https://omnios.omniti.com/wiki.php/LXZones > > See the zonecfg example where you add properties to the "net" instance. > For now, this is the only way to support network configurations on LX > Zones. We plan to have /native/sbin/ipadm working before r151022 ships. > > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
I deleted and re-created. And it seems to be fine now. Odd. My ifconfig settings keep getting overwritten. Is there something special that needs to be done to have these settings maintained? Looking for a simple DHCP or Static IP config. On Thu, Jan 5, 2017 at 11:19 AM, Rafael Pardinas wrote: > It may be useful to take a look at your config file then. > > On Thu, 5 Jan 2017 at 15:51 Mini Trader wrote: > >> Yes. Doesn't seem to make a difference. >> >> On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas >> wrote: >> >> Have you tried rebooting the LX zone? Sometimes they don't load correctly >> the first time. >> >> On Thu, 5 Jan 2017 at 15:45 Mini Trader wrote: >> >> root@storage1:/main/zones# zlogin -e ! lx0 >> [Connected to zone 'lx0' pts/2] >> Last login: Thu Jan 5 15:43:39 UTC 2017 on console >> Linux debian-8 3.16.0 BrandZ virtual linux x86_64 >>__. . >> _| |_ | .-. . . .-. :--. |- >> |__| ;| || |(.-' | | | >> |__| `--' `-' `;-| `-' ' ' `-' >>/ ; Instance (Debian 8.6 (jessie) 20161213) >>`-' https://docs.joyent.com/ >> images/container-native-linux >> >> >> Login timed out after 60 seconds. >> >> [Connection to zone 'lx0' pts/2 closed] >> >> >> On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader >> wrote: >> >> My system is acting funny. >> >> If I login via zlogin nameofzone >> >> I don't get dumped into the command prompt right away. I was able to >> change the password via zlogin nameofzone passwd >> >> If I login via zlogin -C nameofzone >> >> Everything seems normal. It's like the shell is not properly feeding >> back if using zlogin without the -C option. >> >> On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas >> wrote: >> >> From your host you should be able to do: >> >> ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian >> machine. >> >> From there you can assign passwords. By default there isn't one assigned >> to the root user as far as I know. >> >> -Rafa >> >> On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: >> >> Hello all, >> >> I am trying to use a Debian LX Image based on the instructions from: >> >> https://omnios.omniti.com/wiki.php/LXZones >> >> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >> >> I've been able to get my zone to start up no problems. But I cannot >> login. >> >> Is there a default password for these images? >> >> Thanks! >> >> >> ___ >> OmniOS-discuss mailing list >> OmniOS-discuss@lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> >> >> ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
root@storage1:/main/zones# zlogin -e ! lx0 [Connected to zone 'lx0' pts/2] Last login: Thu Jan 5 15:43:39 UTC 2017 on console Linux debian-8 3.16.0 BrandZ virtual linux x86_64 __. . _| |_ | .-. . . .-. :--. |- |__| ;| || |(.-' | | | |__| `--' `-' `;-| `-' ' ' `-' / ; Instance (Debian 8.6 (jessie) 20161213) `-' https://docs.joyent.com/images/container-native-linux Login timed out after 60 seconds. [Connection to zone 'lx0' pts/2 closed] On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader wrote: > My system is acting funny. > > If I login via zlogin nameofzone > > I don't get dumped into the command prompt right away. I was able to > change the password via zlogin nameofzone passwd > > If I login via zlogin -C nameofzone > > Everything seems normal. It's like the shell is not properly feeding back > if using zlogin without the -C option. > > On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas wrote: > >> From your host you should be able to do: >> >> ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian >> machine. >> >> From there you can assign passwords. By default there isn't one assigned >> to the root user as far as I know. >> >> -Rafa >> >> On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: >> >>> Hello all, >>> >>> I am trying to use a Debian LX Image based on the instructions from: >>> >>> https://omnios.omniti.com/wiki.php/LXZones >>> >>> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >>> >>> I've been able to get my zone to start up no problems. But I cannot >>> login. >>> >>> Is there a default password for these images? >>> >>> Thanks! >>> >>> >>> ___ >>> OmniOS-discuss mailing list >>> OmniOS-discuss@lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> >> > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
Yes. Doesn't seem to make a difference. On Thu, Jan 5, 2017 at 10:47 AM, Rafael Pardinas wrote: > Have you tried rebooting the LX zone? Sometimes they don't load correctly > the first time. > > On Thu, 5 Jan 2017 at 15:45 Mini Trader wrote: > >> root@storage1:/main/zones# zlogin -e ! lx0 >> [Connected to zone 'lx0' pts/2] >> Last login: Thu Jan 5 15:43:39 UTC 2017 on console >> Linux debian-8 3.16.0 BrandZ virtual linux x86_64 >>__. . >> _| |_ | .-. . . .-. :--. |- >> |__| ;| || |(.-' | | | >> |__| `--' `-' `;-| `-' ' ' `-' >>/ ; Instance (Debian 8.6 (jessie) 20161213) >>`-' https://docs.joyent.com/ >> images/container-native-linux >> >> >> Login timed out after 60 seconds. >> >> [Connection to zone 'lx0' pts/2 closed] >> >> >> On Thu, Jan 5, 2017 at 10:44 AM, Mini Trader >> wrote: >> >> My system is acting funny. >> >> If I login via zlogin nameofzone >> >> I don't get dumped into the command prompt right away. I was able to >> change the password via zlogin nameofzone passwd >> >> If I login via zlogin -C nameofzone >> >> Everything seems normal. It's like the shell is not properly feeding >> back if using zlogin without the -C option. >> >> On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas >> wrote: >> >> From your host you should be able to do: >> >> ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian >> machine. >> >> From there you can assign passwords. By default there isn't one assigned >> to the root user as far as I know. >> >> -Rafa >> >> On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: >> >> Hello all, >> >> I am trying to use a Debian LX Image based on the instructions from: >> >> https://omnios.omniti.com/wiki.php/LXZones >> >> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >> >> I've been able to get my zone to start up no problems. But I cannot >> login. >> >> Is there a default password for these images? >> >> Thanks! >> >> >> ___ >> OmniOS-discuss mailing list >> OmniOS-discuss@lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> >> ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
My system is acting funny. If I login via zlogin nameofzone I don't get dumped into the command prompt right away. I was able to change the password via zlogin nameofzone passwd If I login via zlogin -C nameofzone Everything seems normal. It's like the shell is not properly feeding back if using zlogin without the -C option. On Thu, Jan 5, 2017 at 10:23 AM, Rafael Pardinas wrote: > From your host you should be able to do: > > ~ $ zlogin -e ! lxbox <-- lxbox is the name you've given to your Debian > machine. > > From there you can assign passwords. By default there isn't one assigned > to the root user as far as I know. > > -Rafa > > On Thu, 5 Jan 2017 at 15:14 Mini Trader wrote: > >> Hello all, >> >> I am trying to use a Debian LX Image based on the instructions from: >> >> https://omnios.omniti.com/wiki.php/LXZones >> >> The UUID I am using is: 9a8d53c0-c15b-11e6-9c4f-3bcedc82f8e1 >> >> I've been able to get my zone to start up no problems. But I cannot >> login. >> >> Is there a default password for these images? >> >> Thanks! >> >> >> ___ >> OmniOS-discuss mailing list >> OmniOS-discuss@lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFS 4.2 Support - Sparse Files
I have not used the tool but it doesn't seem to offer the same intelligence you would get with something like BORG or hashbackup. I did not know about the LX feature so that seems like it can help significantly - trying to get it going but currently unable to login to the zones system! On Thu, Jan 5, 2017 at 9:56 AM Olaf Marzocchi wrote: > Their Linux tool is working with Backblaze B2, but it's a python tool, not > a native closed source application. They do not offer the normal backup > agent for anything but Win/Mac. > > > > > > At that point it may be possible to run the pytjon tool directly on OmniOS? > > > > > > I thought about it but never went on with the testing. > > > If you try please report any success. I'm using right now Crashplan under > OmniOS but it's been already declared as discontinued and I may need an > alternative sometimes in the future, even if it still works fine. > > > > > > > Olaf > > > > > > > > > Il 5 gennaio 2017 14:19:33 CET, Mini Trader ha > scritto: > > > > This could work :) Thank you. > > On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott wrote: > > You can create an LX zone with the latest stable Omni release, share the > dataset(s) with the zone and run the backup agent in there. That's what I'm > using for a bunch of things such as Veeam, BeeGFS, and Plex. Works like a > charm as long as you don't need extended attribute support. > > > > > > Michael > > > Sent from my iPhone > > > > > > > On Jan 4, 2017, at 4:15 PM, Michael Rasmussen wrote: > > > > > > > > On Wed, 04 Jan 2017 23:59:15 + > > > > Mini Trader wrote: > > > > > > > >> > > > >> If anyone has any recommendations for an incremental cloud storage > solution > > > >> that is compatible with OmniOS it would be greatly appreciated. I > realize > > > >> that ZFS send works quite well but haven't found an off site provider > who I > > > >> consider to be cost effective. > > > >> > > > > Would it be possible to use rsync with backblaze? > > > > rsync handles sparse files equally well using option --sparse > > > > > > > > -- > > > > Hilsen/Regards > > > > Michael Rasmussen > > > > > > > > Get my public GnuPG keys: > > > > michael rasmussen cc > > > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > > > > mir datanom net > > > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > > > > mir miras org > > > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > > > > -- > > > > /usr/games/fortune -es says: > > > > "Whoever undertakes to set himself up as a judge of Truth and Knowledge > > > > is shipwrecked by the laughter of the gods." > > > >-- Albert Einstein > > > > ___ > > > > OmniOS-discuss mailing list > > > > OmniOS-discuss@lists.omniti.com > > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > ___ > > > OmniOS-discuss mailing list > > > OmniOS-discuss@lists.omniti.com > > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] LX Zones - Password for Canned SmartOS Images
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@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFS 4.2 Support - Sparse Files
This could work :) Thank you. On Wed, Jan 4, 2017 at 7:27 PM, Michael Talbott wrote: > You can create an LX zone with the latest stable Omni release, share the > dataset(s) with the zone and run the backup agent in there. That's what I'm > using for a bunch of things such as Veeam, BeeGFS, and Plex. Works like a > charm as long as you don't need extended attribute support. > > Michael > Sent from my iPhone > > > On Jan 4, 2017, at 4:15 PM, Michael Rasmussen wrote: > > > > On Wed, 04 Jan 2017 23:59:15 + > > Mini Trader wrote: > > > >> > >> If anyone has any recommendations for an incremental cloud storage > solution > >> that is compatible with OmniOS it would be greatly appreciated. I > realize > >> that ZFS send works quite well but haven't found an off site provider > who I > >> consider to be cost effective. > >> > > Would it be possible to use rsync with backblaze? > > rsync handles sparse files equally well using option --sparse > > > > -- > > Hilsen/Regards > > Michael Rasmussen > > > > Get my public GnuPG keys: > > michael rasmussen cc > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > > mir datanom net > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > > mir miras org > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > > -- > > /usr/games/fortune -es says: > > "Whoever undertakes to set himself up as a judge of Truth and Knowledge > > is shipwrecked by the laughter of the gods." > >-- Albert Einstein > > ___ > > OmniOS-discuss mailing list > > OmniOS-discuss@lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFS 4.2 Support - Sparse Files
They are .10 per GB. Backblaze is 0.005 per GB. About $2400/yr vs $120/yr. On Wed, Jan 4, 2017 at 7:25 PM, Michael Rasmussen wrote: > On Thu, 5 Jan 2017 01:15:18 +0100 > Michael Rasmussen wrote: > > > Would it be possible to use rsync with backblaze? > > rsync handles sparse files equally well using option --sparse > > > A quick google: > http://www.rsync.net/resources/howto/unix.html > https://www.elastichosts.com/blog/cloud-storage-backup-using-rsync/ > > NB: I dont know the companies nor their solutions but it looks very > Unix like;-) > > -- > Hilsen/Regards > Michael Rasmussen > > Get my public GnuPG keys: > michael rasmussen cc > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > mir datanom net > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > mir miras org > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > -- > /usr/games/fortune -es says: > From concentrate. > > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFS 4.2 Support - Sparse Files
Not really. There is one tool called rclone. But it will do a full upload on any changed file so does not help. There are some FUSE file systems but I don't believe these will work with Illumos either. I'd really like to avoid moving my pool if I don't have to. OmniOS has been great. On Wed, Jan 4, 2017 at 7:17 PM Michael Rasmussen wrote: > On Wed, 04 Jan 2017 23:59:15 +0000 > > Mini Trader wrote: > > > > > > > > If anyone has any recommendations for an incremental cloud storage > solution > > > that is compatible with OmniOS it would be greatly appreciated. I realize > > > that ZFS send works quite well but haven't found an off site provider > who I > > > consider to be cost effective. > > > > > Would it be possible to use rsync with backblaze? > > rsync handles sparse files equally well using option --sparse > > > > -- > > Hilsen/Regards > > Michael Rasmussen > > > > Get my public GnuPG keys: > > michael rasmussen cc > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E > > mir datanom net > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C > > mir miras org > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 > > -- > > /usr/games/fortune -es says: > > "Whoever undertakes to set himself up as a judge of Truth and Knowledge > > is shipwrecked by the laughter of the gods." > > -- Albert Einstein > > ___ > > OmniOS-discuss mailing list > > OmniOS-discuss@lists.omniti.com > > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] NFS 4.2 Support - Sparse Files
That is unfortunate. The requirement stems from the need to perform an incremental backup to cloud storage (backblaze). Many of my files are large and sparse (VMs). Unfortunately the only software that I have found to perform the backups runs on BSD or Linux hence the use for NFS. Running the utility over NFS without sparse support is not ideal. If anyone has any recommendations for an incremental cloud storage solution that is compatible with OmniOS it would be greatly appreciated. I realize that ZFS send works quite well but haven't found an off site provider who I consider to be cost effective. On Wed, Jan 4, 2017 at 2:01 PM Dan McDonald wrote: > > > > On Jan 4, 2017, at 1:19 PM, Mini Trader > wrote: > > > > > > Hello all, > > > > > > Is there any support for NFS 4.2 in Illumos? I am interested in the > Sparse File functionality that has been introduced. > > > > There is not, currently. > > > > There have been some stop/starts on this, but at the end of the day, at > least one illumos shop's customers basically didn't care enough to make it > a priority for that shop. The other illumos shops either have similar > customer viewpoints, don't care about NFS at all, or don't have the > resources to devote to such a nontrivial project. > > > > I'm sorry I don't have a better answer for you at the moment. > > > > Dan > > > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] NFS 4.2 Support - Sparse Files
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! ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] CIFS ignores TCP Buffer Settings
| 11
128 | 0
unacked(bytes) 10.250.0.2
2049
value - Distribution - count
-1 | 0
0 |@@@ 23
1 | 0
2 | 0
4 | 0
8 | 0
16 | 0
32 | 0
64 |@4
128 |@84
256 | 12
512 |@4
1024 |@@ 6
2048 | 0
unacked(bytes) 10.255.0.55
445
value - Distribution - count
-1 | 0
0 | 9
1 | 0
2 | 0
4 | 0
8 | 0
16 | 0
32 | 10
64 | 50
128 | 9
256 | 0
512 | 0
1024 | 1
2048 | 0
4096 | 0
8192 | 0
16384 | 0
32768 | 1
65536 | 2
131072 | 260
262144 | 27135
524288 | 0
SWND(bytes) 10.255.0.55
22
value - Distribution - count
16384 | 0
32768 | 1
65536 | 0
SWND(bytes) 10.250.0.3
2049
value - Distribution - count
32768 | 0
65536 | 17
131072 | 0
SWND(bytes) 10.250.0.2
2049
value - Distribution - count
131072 | 0
262144 | 155
524288 | 0
SWND(bytes) 10.255.0.55
445
value - Distribution - count
16384 | 0
32768 | 54
65536 | 63
131072 | 306
262144 | 330
524288 |@@@ 210636
1048576 |@28037
2097152 | 0
On Tue, Mar 8, 2016 at 8:20 PM, Mini Trader
wrote:
> Running the following dtrace.
>
> #!/usr/sbin/dtrace -s
>
> #pragma D option quiet
>
> tcp:::send
> / (args[4]->tcp_flags & (TH_SYN|TH_RST|TH_FIN)) == 0 /
> {
> @unacked["unacked(bytes)", args[2]->ip_daddr, args[4]->tcp_sport] =
> quantize(args[3]->tcps_snxt - args[3]->tcps_suna);
> }
>
> tcp:::receive
> / (args[4]->tcp_flags & (TH_SYN|TH_RST|TH_FIN)) == 0 /
> {
> @swnd["SWND(bytes)", args[2]->ip_saddr, args[4]->tcp_dport] =
> quantize
Re: [OmniOS-discuss] CIFS ignores TCP Buffer Settings
Running the following dtrace.
#!/usr/sbin/dtrace -s
#pragma D option quiet
tcp:::send
/ (args[4]->tcp_flags & (TH_SYN|TH_RST|TH_FIN)) == 0 /
{
@unacked["unacked(bytes)", args[2]->ip_daddr, args[4]->tcp_sport] =
quantize(args[3]->tcps_snxt - args[3]->tcps_suna);
}
tcp:::receive
/ (args[4]->tcp_flags & (TH_SYN|TH_RST|TH_FIN)) == 0 /
{
@swnd["SWND(bytes)", args[2]->ip_saddr, args[4]->tcp_dport] =
quantize((args[4]->tcp_window)*(1 << args[3]->tcps_snd_ws));
}
Is showing that the windows sizes are not going above 64k when things are
not working properly.
On Tue, Mar 8, 2016 at 7:56 PM, Mini Trader
wrote:
> If it helps. This doesn't happen on NFS from the exact same client. How
> do I file a bug?
>
> On Tue, Mar 8, 2016 at 1:51 PM, Mini Trader
> wrote:
>
>> Simple example.
>>
>> 1 Server 1 client.
>>
>> Restart service everything is fast. A few hours later from same client
>> (nothing happening concurrently) speed is slow. Restart service again,
>> speed is fast.
>>
>> Its like CIFS starts off fast than somehow for whatever reason if it is
>> not used, the connection for my CIFS drives to the server becomes slow.
>> Also this only happens when the client is downloading. Not when uploading
>> to the server that is always fast.
>>
>> On Tue, Mar 8, 2016 at 1:42 AM, Jim Klimov wrote:
>>
>>> 8 марта 2016 г. 6:42:13 CET, Mini Trader
>>> пишет:
>>> >Is it possible that CIFS will ignore TCP buffer settings after a while?
>>> >
>>> >I've confirmed my systems max transfer rate using iperf and have tuned
>>> >my
>>> >buffers accordingly. For whatever reason CIFS seems to forget these
>>> >settings after a while as speed drops significantly. Issuing a restart
>>> >of
>>> >the service immediately appears to restore the setting as transfer
>>> >speed
>>> >becomes normal again.
>>> >
>>> >Any ideas why this would happen?
>>> >
>>> >
>>> >
>>> >
>>> >___
>>> >OmniOS-discuss mailing list
>>> >OmniOS-discuss@lists.omniti.com
>>> >http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>>
>>> As a random guess from experience with other network stuff - does the
>>> speed-drop happen on a running connection or new ones too? Do you have
>>> concurrent transfers at this time?
>>>
>>> Some other subsystems (no idea if this one too) use best speeds for new
>>> or recently awakened dormant connections, so short-lived bursts are fast -
>>> at expence of long-running active bulk transfers (deemed to be bulk because
>>> they run for a long time).
>>>
>>> HTH, Jim
>>> --
>>> Typos courtesy of K-9 Mail on my Samsung Android
>>>
>>
>>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] CIFS ignores TCP Buffer Settings
If it helps. This doesn't happen on NFS from the exact same client. How do I file a bug? On Tue, Mar 8, 2016 at 1:51 PM, Mini Trader wrote: > Simple example. > > 1 Server 1 client. > > Restart service everything is fast. A few hours later from same client > (nothing happening concurrently) speed is slow. Restart service again, > speed is fast. > > Its like CIFS starts off fast than somehow for whatever reason if it is > not used, the connection for my CIFS drives to the server becomes slow. > Also this only happens when the client is downloading. Not when uploading > to the server that is always fast. > > On Tue, Mar 8, 2016 at 1:42 AM, Jim Klimov wrote: > >> 8 марта 2016 г. 6:42:13 CET, Mini Trader >> пишет: >> >Is it possible that CIFS will ignore TCP buffer settings after a while? >> > >> >I've confirmed my systems max transfer rate using iperf and have tuned >> >my >> >buffers accordingly. For whatever reason CIFS seems to forget these >> >settings after a while as speed drops significantly. Issuing a restart >> >of >> >the service immediately appears to restore the setting as transfer >> >speed >> >becomes normal again. >> > >> >Any ideas why this would happen? >> > >> > >> > >> > >> >___ >> >OmniOS-discuss mailing list >> >OmniOS-discuss@lists.omniti.com >> >http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> As a random guess from experience with other network stuff - does the >> speed-drop happen on a running connection or new ones too? Do you have >> concurrent transfers at this time? >> >> Some other subsystems (no idea if this one too) use best speeds for new >> or recently awakened dormant connections, so short-lived bursts are fast - >> at expence of long-running active bulk transfers (deemed to be bulk because >> they run for a long time). >> >> HTH, Jim >> -- >> Typos courtesy of K-9 Mail on my Samsung Android >> > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] CIFS ignores TCP Buffer Settings
Simple example. 1 Server 1 client. Restart service everything is fast. A few hours later from same client (nothing happening concurrently) speed is slow. Restart service again, speed is fast. Its like CIFS starts off fast than somehow for whatever reason if it is not used, the connection for my CIFS drives to the server becomes slow. Also this only happens when the client is downloading. Not when uploading to the server that is always fast. On Tue, Mar 8, 2016 at 1:42 AM, Jim Klimov wrote: > 8 марта 2016 г. 6:42:13 CET, Mini Trader пишет: > >Is it possible that CIFS will ignore TCP buffer settings after a while? > > > >I've confirmed my systems max transfer rate using iperf and have tuned > >my > >buffers accordingly. For whatever reason CIFS seems to forget these > >settings after a while as speed drops significantly. Issuing a restart > >of > >the service immediately appears to restore the setting as transfer > >speed > >becomes normal again. > > > >Any ideas why this would happen? > > > > > > > > > >___ > >OmniOS-discuss mailing list > >OmniOS-discuss@lists.omniti.com > >http://lists.omniti.com/mailman/listinfo/omnios-discuss > > As a random guess from experience with other network stuff - does the > speed-drop happen on a running connection or new ones too? Do you have > concurrent transfers at this time? > > Some other subsystems (no idea if this one too) use best speeds for new or > recently awakened dormant connections, so short-lived bursts are fast - at > expence of long-running active bulk transfers (deemed to be bulk because > they run for a long time). > > HTH, Jim > -- > Typos courtesy of K-9 Mail on my Samsung Android > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] CIFS ignores TCP Buffer Settings
Is it possible that CIFS will ignore TCP buffer settings after a while? I've confirmed my systems max transfer rate using iperf and have tuned my buffers accordingly. For whatever reason CIFS seems to forget these settings after a while as speed drops significantly. Issuing a restart of the service immediately appears to restore the setting as transfer speed becomes normal again. Any ideas why this would happen? ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
Perhaps it was too good to be true. It seems that one of the parameters is being disregarded for CIFS shares. 1. When the system first starts and I download from my CIFS share, the transfer rates are good, around 95mb/sec. 2. If I restart CIFS the rates are good. 3. If I wait sometime after the restart or the system has been connected for a few hours and I attempt to download the rates are bad, around 20mb/sec! 4. If I run iperf when CIFS rates are bad, my speed is good, over 900megabit. What is going on with CIFS that is causing the client to have slow download speeds? It's like CIFS is forgetting the buffer values because whenever I restart it I am back to good downloads on my client for a brief period. I appreciate any suggestions. On Fri, Jan 29, 2016 at 3:09 PM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Fri, 29 Jan 2016, Guenther Alka wrote: > > With the default mtu 1500 you can max out 1G networks but on 10G you are >> limited to about 300-400 MB/s. >> With mtu 9000 that is supported on all of my switches and computers the >> SMB2 limit is near the limit of 10G >> > > Since this topic started about Moca 2.0, its worth mentioning that this > consumer-grade networking technology might not adequately support large > MTUs. A particular Moca 2.0 device might support large MTUs, but this is > likely atypical. > > Hardware that I am working with does support a somewhat elevated MTU (e.g. > 2k) with Moca 2.0 but that is because we wrote code to support it and > tested it between two units of our hardware. With limited interoperability > testing, we have not encountered other Moca 2.0 hardware which supports MTU > over 1500 bytes. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > ___ > OmniOS-discuss mailing list > OmniOS-discuss@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
You are right about this. Client connecting to storage1.midway, TCP port 5001 TCP window size: 977 KByte [ 4] local 10.255.0.141 port 14766 connected with 10.255.0.15 port 5001 [ 5] local 10.255.0.141 port 5001 connected with 10.255.0.15 port 55052 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 87.2 MBytes 732 Mbits/sec [ 5] 0.0- 1.0 sec 17.6 MBytes 147 Mbits/sec [ 4] 1.0- 2.0 sec 78.4 MBytes 657 Mbits/sec [ 5] 1.0- 2.0 sec 33.4 MBytes 280 Mbits/sec [ 4] 2.0- 3.0 sec 69.5 MBytes 583 Mbits/sec [ 5] 2.0- 3.0 sec 34.7 MBytes 291 Mbits/sec [ 5] 3.0- 4.0 sec 31.8 MBytes 267 Mbits/sec [ 4] 3.0- 4.0 sec 68.1 MBytes 571 Mbits/sec [ 4] 4.0- 5.0 sec 71.9 MBytes 603 Mbits/sec [ 5] 4.0- 5.0 sec 31.9 MBytes 267 Mbits/sec [ 4] 5.0- 6.0 sec 72.1 MBytes 605 Mbits/sec [ 5] 5.0- 6.0 sec 30.5 MBytes 256 Mbits/sec [ 4] 6.0- 7.0 sec 74.0 MBytes 621 Mbits/sec [ 5] 6.0- 7.0 sec 30.3 MBytes 254 Mbits/sec [ 5] 7.0- 8.0 sec 31.0 MBytes 260 Mbits/sec [ 4] 7.0- 8.0 sec 77.8 MBytes 652 Mbits/sec [ 4] 8.0- 9.0 sec 74.9 MBytes 628 Mbits/sec [ 5] 8.0- 9.0 sec 33.5 MBytes 281 Mbits/sec [ 4] 9.0-10.0 sec 57.1 MBytes 479 Mbits/sec [ 4] 0.0-10.0 sec 731 MBytes 613 Mbits/sec [ 5] 9.0-10.0 sec 41.5 MBytes 348 Mbits/sec [ 5] 0.0-10.0 sec 318 MBytes 266 Mbits/sec On Thu, Jan 28, 2016 at 4:58 PM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Thu, 28 Jan 2016, Mini Trader wrote: > > Turns out that running svcadm restart smb/server after tuning the send and >> receive buffers has fixed the problem. I can now >> transfer at nearly 1GBe both up and down! >> Problem has been resolved :) >> > > The next problem you may encounter is that MoCA is basically half-duplex > so performance will suffer with two-way traffic. MoCA is not at all like > Ethernet although it passes Ethernet frames. It "bundles" multiple frames > which happens to be going to the same place because it seems like it is > slow to turn the pipe around. > > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
I most definitely will. Any other tunables worth looking at or can most of these issues be fixed by send/receive buffer size? This was a nice crash course on how TCP Window sizes can affect your data throughput! On Thu, Jan 28, 2016 at 2:49 PM, Dan McDonald wrote: > > > On Jan 28, 2016, at 2:44 PM, Mini Trader > wrote: > > > > Problem has been resolved :) > > > > Makes sense. Those settings are only inherited by new TCP connections. > Sorry I missed a good chunk of this thread, but you pretty much figured it > all out. > > And you should check out this bloody cycle... SMB2 is on it, and it may > help you further. Or you can wait until r151018, but early testing is why > we have bloody. :) > > Dan > > ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
Is there a way to adjust the default Window Size for CIFS or NFS? On Thu, Jan 28, 2016 at 1:39 PM, Mini Trader wrote: > I also tried the following. Which seems to have improved iperf speeds. > But I am still getting the same CIFS speeds. > > root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p > recv_buf=1048576 tcp > root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p > send_buf=1048576 tcp > root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p > max_buf=4194304 tcp > > > > Server listening on TCP port 5001 > TCP window size: 977 KByte > > > Client connecting to storage1.midway, TCP port 5001 > TCP window size: 977 KByte > > [ 4] local 10.255.0.141 port 33452 connected with 10.255.0.15 port 5001 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0- 1.0 sec 106 MBytes 892 Mbits/sec > [ 4] 1.0- 2.0 sec 111 MBytes 928 Mbits/sec > [ 4] 2.0- 3.0 sec 108 MBytes 904 Mbits/sec > [ 4] 3.0- 4.0 sec 109 MBytes 916 Mbits/sec > [ 4] 4.0- 5.0 sec 110 MBytes 923 Mbits/sec > [ 4] 5.0- 6.0 sec 110 MBytes 919 Mbits/sec > [ 4] 6.0- 7.0 sec 110 MBytes 919 Mbits/sec > [ 4] 7.0- 8.0 sec 105 MBytes 884 Mbits/sec > [ 4] 8.0- 9.0 sec 109 MBytes 915 Mbits/sec > [ 4] 9.0-10.0 sec 111 MBytes 928 Mbits/sec > [ 4] 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec > [ 4] local 10.255.0.141 port 5001 connected with 10.255.0.15 port 50899 > [ 4] 0.0- 1.0 sec 97.5 MBytes 818 Mbits/sec > [ 4] 1.0- 2.0 sec 110 MBytes 923 Mbits/sec > [ 4] 2.0- 3.0 sec 49.3 MBytes 414 Mbits/sec > [ 4] 3.0- 4.0 sec 98.0 MBytes 822 Mbits/sec > [ 4] 4.0- 5.0 sec 96.7 MBytes 811 Mbits/sec > [ 4] 5.0- 6.0 sec 99.7 MBytes 836 Mbits/sec > [ 4] 6.0- 7.0 sec 103 MBytes 861 Mbits/sec > [ 4] 7.0- 8.0 sec 101 MBytes 851 Mbits/sec > [ 4] 8.0- 9.0 sec 104 MBytes 876 Mbits/sec > [ 4] 9.0-10.0 sec 104 MBytes 876 Mbits/sec > [ 4] 0.0-10.0 sec 966 MBytes 808 Mbits/sec > > root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p recv_buf > tcp > root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p send_buf > tcp > root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p max_buf > tcp > > > Server listening on TCP port 5001 > TCP window size: 977 KByte > > > Client connecting to storage1.midway, TCP port 5001 > TCP window size: 977 KByte > > [ 4] local 10.255.0.141 port 33512 connected with 10.255.0.15 port 5001 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0- 1.0 sec 35.2 MBytes 296 Mbits/sec > [ 4] 1.0- 2.0 sec 35.0 MBytes 294 Mbits/sec > [ 4] 2.0- 3.0 sec 34.2 MBytes 287 Mbits/sec > [ 4] 3.0- 4.0 sec 33.4 MBytes 280 Mbits/sec > [ 4] 4.0- 5.0 sec 34.1 MBytes 286 Mbits/sec > [ 4] 5.0- 6.0 sec 35.2 MBytes 296 Mbits/sec > [ 4] 6.0- 7.0 sec 35.4 MBytes 297 Mbits/sec > [ 4] 7.0- 8.0 sec 34.4 MBytes 288 Mbits/sec > [ 4] 8.0- 9.0 sec 35.0 MBytes 294 Mbits/sec > [ 4] 9.0-10.0 sec 33.4 MBytes 280 Mbits/sec > [ 4] 0.0-10.0 sec 346 MBytes 289 Mbits/sec > [ 4] local 10.255.0.141 port 5001 connected with 10.255.0.15 port 41435 > [ 4] 0.0- 1.0 sec 57.6 MBytes 483 Mbits/sec > [ 4] 1.0- 2.0 sec 87.2 MBytes 732 Mbits/sec > [ 4] 2.0- 3.0 sec 99.3 MBytes 833 Mbits/sec > [ 4] 3.0- 4.0 sec 99.5 MBytes 835 Mbits/sec > [ 4] 4.0- 5.0 sec 100 MBytes 842 Mbits/sec > [ 4] 5.0- 6.0 sec 103 MBytes 866 Mbits/sec > [ 4] 6.0- 7.0 sec 100 MBytes 840 Mbits/sec > [ 4] 7.0- 8.0 sec 98.7 MBytes 828 Mbits/sec > [ 4] 8.0- 9.0 sec 101 MBytes 847 Mbits/sec > [ 4] 9.0-10.0 sec 105 MBytes 882 Mbits/sec > [ 4] 0.0-10.0 sec 954 MBytes 799 Mbits/sec > > > On Thu, Jan 28, 2016 at 11:34 AM, Mini Trader > wrote: > >> Thank you for all the responses! Ive run some more detailed tests using >> iperf 2. The results that I see are inline with the transfer rates so they >> describe the behavior that I am seeing. >> >> Note I used a laptop on same connection as desktop. So that there would >> be a basis to compare it to the Desktop. >> >> For some reason the laptop has a limit of around 500-600 mbit/sec for its >> dow
Re: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
Turns out that running svcadm restart smb/server after tuning the send and receive buffers has fixed the problem. I can now transfer at nearly 1GBe both up and down! Problem has been resolved :) On Thu, Jan 28, 2016 at 2:30 PM, Mini Trader wrote: > Is there a way to adjust the default Window Size for CIFS or NFS? > > On Thu, Jan 28, 2016 at 1:39 PM, Mini Trader > wrote: > >> I also tried the following. Which seems to have improved iperf speeds. >> But I am still getting the same CIFS speeds. >> >> root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p >> recv_buf=1048576 tcp >> root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p >> send_buf=1048576 tcp >> root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p >> max_buf=4194304 tcp >> >> >> >> Server listening on TCP port 5001 >> TCP window size: 977 KByte >> >> >> Client connecting to storage1.midway, TCP port 5001 >> TCP window size: 977 KByte >> >> [ 4] local 10.255.0.141 port 33452 connected with 10.255.0.15 port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 4] 0.0- 1.0 sec 106 MBytes 892 Mbits/sec >> [ 4] 1.0- 2.0 sec 111 MBytes 928 Mbits/sec >> [ 4] 2.0- 3.0 sec 108 MBytes 904 Mbits/sec >> [ 4] 3.0- 4.0 sec 109 MBytes 916 Mbits/sec >> [ 4] 4.0- 5.0 sec 110 MBytes 923 Mbits/sec >> [ 4] 5.0- 6.0 sec 110 MBytes 919 Mbits/sec >> [ 4] 6.0- 7.0 sec 110 MBytes 919 Mbits/sec >> [ 4] 7.0- 8.0 sec 105 MBytes 884 Mbits/sec >> [ 4] 8.0- 9.0 sec 109 MBytes 915 Mbits/sec >> [ 4] 9.0-10.0 sec 111 MBytes 928 Mbits/sec >> [ 4] 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec >> [ 4] local 10.255.0.141 port 5001 connected with 10.255.0.15 port 50899 >> [ 4] 0.0- 1.0 sec 97.5 MBytes 818 Mbits/sec >> [ 4] 1.0- 2.0 sec 110 MBytes 923 Mbits/sec >> [ 4] 2.0- 3.0 sec 49.3 MBytes 414 Mbits/sec >> [ 4] 3.0- 4.0 sec 98.0 MBytes 822 Mbits/sec >> [ 4] 4.0- 5.0 sec 96.7 MBytes 811 Mbits/sec >> [ 4] 5.0- 6.0 sec 99.7 MBytes 836 Mbits/sec >> [ 4] 6.0- 7.0 sec 103 MBytes 861 Mbits/sec >> [ 4] 7.0- 8.0 sec 101 MBytes 851 Mbits/sec >> [ 4] 8.0- 9.0 sec 104 MBytes 876 Mbits/sec >> [ 4] 9.0-10.0 sec 104 MBytes 876 Mbits/sec >> [ 4] 0.0-10.0 sec 966 MBytes 808 Mbits/sec >> >> root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p >> recv_buf tcp >> root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p >> send_buf tcp >> root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p max_buf >> tcp >> >> >> Server listening on TCP port 5001 >> TCP window size: 977 KByte >> >> >> Client connecting to storage1.midway, TCP port 5001 >> TCP window size: 977 KByte >> >> [ 4] local 10.255.0.141 port 33512 connected with 10.255.0.15 port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 4] 0.0- 1.0 sec 35.2 MBytes 296 Mbits/sec >> [ 4] 1.0- 2.0 sec 35.0 MBytes 294 Mbits/sec >> [ 4] 2.0- 3.0 sec 34.2 MBytes 287 Mbits/sec >> [ 4] 3.0- 4.0 sec 33.4 MBytes 280 Mbits/sec >> [ 4] 4.0- 5.0 sec 34.1 MBytes 286 Mbits/sec >> [ 4] 5.0- 6.0 sec 35.2 MBytes 296 Mbits/sec >> [ 4] 6.0- 7.0 sec 35.4 MBytes 297 Mbits/sec >> [ 4] 7.0- 8.0 sec 34.4 MBytes 288 Mbits/sec >> [ 4] 8.0- 9.0 sec 35.0 MBytes 294 Mbits/sec >> [ 4] 9.0-10.0 sec 33.4 MBytes 280 Mbits/sec >> [ 4] 0.0-10.0 sec 346 MBytes 289 Mbits/sec >> [ 4] local 10.255.0.141 port 5001 connected with 10.255.0.15 port 41435 >> [ 4] 0.0- 1.0 sec 57.6 MBytes 483 Mbits/sec >> [ 4] 1.0- 2.0 sec 87.2 MBytes 732 Mbits/sec >> [ 4] 2.0- 3.0 sec 99.3 MBytes 833 Mbits/sec >> [ 4] 3.0- 4.0 sec 99.5 MBytes 835 Mbits/sec >> [ 4] 4.0- 5.0 sec 100 MBytes 842 Mbits/sec >> [ 4] 5.0- 6.0 sec 103 MBytes 866 Mbits/sec >> [ 4] 6.0- 7.0 sec 100 MBytes 840 Mbits/sec >> [ 4] 7.0- 8.0 sec 98.7 MBytes 828 Mbits/sec >> [ 4] 8.0- 9.0 sec 101 MBytes 847 Mbits/sec >> [ 4] 9.0-10.0 sec 105 MBytes
Re: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
I also tried the following. Which seems to have improved iperf speeds. But I am still getting the same CIFS speeds. root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p recv_buf=1048576 tcp root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p send_buf=1048576 tcp root@storage1:/var/web-gui/data/tools/iperf# ipadm set-prop -p max_buf=4194304 tcp Server listening on TCP port 5001 TCP window size: 977 KByte Client connecting to storage1.midway, TCP port 5001 TCP window size: 977 KByte [ 4] local 10.255.0.141 port 33452 connected with 10.255.0.15 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 106 MBytes 892 Mbits/sec [ 4] 1.0- 2.0 sec 111 MBytes 928 Mbits/sec [ 4] 2.0- 3.0 sec 108 MBytes 904 Mbits/sec [ 4] 3.0- 4.0 sec 109 MBytes 916 Mbits/sec [ 4] 4.0- 5.0 sec 110 MBytes 923 Mbits/sec [ 4] 5.0- 6.0 sec 110 MBytes 919 Mbits/sec [ 4] 6.0- 7.0 sec 110 MBytes 919 Mbits/sec [ 4] 7.0- 8.0 sec 105 MBytes 884 Mbits/sec [ 4] 8.0- 9.0 sec 109 MBytes 915 Mbits/sec [ 4] 9.0-10.0 sec 111 MBytes 928 Mbits/sec [ 4] 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec [ 4] local 10.255.0.141 port 5001 connected with 10.255.0.15 port 50899 [ 4] 0.0- 1.0 sec 97.5 MBytes 818 Mbits/sec [ 4] 1.0- 2.0 sec 110 MBytes 923 Mbits/sec [ 4] 2.0- 3.0 sec 49.3 MBytes 414 Mbits/sec [ 4] 3.0- 4.0 sec 98.0 MBytes 822 Mbits/sec [ 4] 4.0- 5.0 sec 96.7 MBytes 811 Mbits/sec [ 4] 5.0- 6.0 sec 99.7 MBytes 836 Mbits/sec [ 4] 6.0- 7.0 sec 103 MBytes 861 Mbits/sec [ 4] 7.0- 8.0 sec 101 MBytes 851 Mbits/sec [ 4] 8.0- 9.0 sec 104 MBytes 876 Mbits/sec [ 4] 9.0-10.0 sec 104 MBytes 876 Mbits/sec [ 4] 0.0-10.0 sec 966 MBytes 808 Mbits/sec root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p recv_buf tcp root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p send_buf tcp root@storage1:/var/web-gui/data/tools/iperf# ipadm reset-prop -p max_buf tcp Server listening on TCP port 5001 TCP window size: 977 KByte Client connecting to storage1.midway, TCP port 5001 TCP window size: 977 KByte [ 4] local 10.255.0.141 port 33512 connected with 10.255.0.15 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 35.2 MBytes 296 Mbits/sec [ 4] 1.0- 2.0 sec 35.0 MBytes 294 Mbits/sec [ 4] 2.0- 3.0 sec 34.2 MBytes 287 Mbits/sec [ 4] 3.0- 4.0 sec 33.4 MBytes 280 Mbits/sec [ 4] 4.0- 5.0 sec 34.1 MBytes 286 Mbits/sec [ 4] 5.0- 6.0 sec 35.2 MBytes 296 Mbits/sec [ 4] 6.0- 7.0 sec 35.4 MBytes 297 Mbits/sec [ 4] 7.0- 8.0 sec 34.4 MBytes 288 Mbits/sec [ 4] 8.0- 9.0 sec 35.0 MBytes 294 Mbits/sec [ 4] 9.0-10.0 sec 33.4 MBytes 280 Mbits/sec [ 4] 0.0-10.0 sec 346 MBytes 289 Mbits/sec [ 4] local 10.255.0.141 port 5001 connected with 10.255.0.15 port 41435 [ 4] 0.0- 1.0 sec 57.6 MBytes 483 Mbits/sec [ 4] 1.0- 2.0 sec 87.2 MBytes 732 Mbits/sec [ 4] 2.0- 3.0 sec 99.3 MBytes 833 Mbits/sec [ 4] 3.0- 4.0 sec 99.5 MBytes 835 Mbits/sec [ 4] 4.0- 5.0 sec 100 MBytes 842 Mbits/sec [ 4] 5.0- 6.0 sec 103 MBytes 866 Mbits/sec [ 4] 6.0- 7.0 sec 100 MBytes 840 Mbits/sec [ 4] 7.0- 8.0 sec 98.7 MBytes 828 Mbits/sec [ 4] 8.0- 9.0 sec 101 MBytes 847 Mbits/sec [ 4] 9.0-10.0 sec 105 MBytes 882 Mbits/sec [ 4] 0.0-10.0 sec 954 MBytes 799 Mbits/sec On Thu, Jan 28, 2016 at 11:34 AM, Mini Trader wrote: > Thank you for all the responses! Ive run some more detailed tests using > iperf 2. The results that I see are inline with the transfer rates so they > describe the behavior that I am seeing. > > Note I used a laptop on same connection as desktop. So that there would > be a basis to compare it to the Desktop. > > For some reason the laptop has a limit of around 500-600 mbit/sec for its > downloads, regardless the test still seem to show the behavior > that I am seeing. Note that Linux does not seem to have the same issues > where OmniOS does. Additionally OmniOS does not have the issue > when using a direct ethernet connection. One thing I can say about Linux > is that its downloads on the adapters are less than its uploads which > is the complete opposite as OmniOS. This Linux behavior is not seen when > using ethernet. > > Both Linux and OmniOS are running on ESXi 6U1. OmniOS is using the vmxnet > driver. > > The adapters being used are Ad
Re: [OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
window size: 977 KByte [ 4] local 10.255.0.54 port 57387 connected with 10.255.0.73 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 110 MBytes 919 Mbits/sec [ 4] 1.0- 2.0 sec 110 MBytes 920 Mbits/sec [ 4] 2.0- 3.0 sec 110 MBytes 921 Mbits/sec [ 4] 3.0- 4.0 sec 110 MBytes 923 Mbits/sec [ 4] 4.0- 5.0 sec 110 MBytes 919 Mbits/sec [ 4] 0.0- 5.0 sec 548 MBytes 919 Mbits/sec [ 4] local 10.255.0.54 port 5001 connected with 10.255.0.73 port 52723 [ 4] 0.0- 1.0 sec 49.8 MBytes 418 Mbits/sec [ 4] 1.0- 2.0 sec 55.1 MBytes 462 Mbits/sec [ 4] 2.0- 3.0 sec 55.1 MBytes 462 Mbits/sec [ 4] 3.0- 4.0 sec 53.6 MBytes 449 Mbits/sec [ 4] 4.0- 5.0 sec 56.9 MBytes 477 Mbits/sec [ 4] 0.0- 5.0 sec 271 MBytes 454 Mbits/sec Machine: Laptop Connection: Ethernet Windows <-> OmniOS (No issues on upload) Server listening on TCP port 5001 TCP window size: 977 KByte Client connecting to storage1.midway, TCP port 5001 TCP window size: 977 KByte [ 4] local 10.255.0.54 port 57858 connected with 10.255.0.15 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 113 MBytes 950 Mbits/sec [ 4] 1.0- 2.0 sec 111 MBytes 928 Mbits/sec [ 4] 2.0- 3.0 sec 109 MBytes 912 Mbits/sec [ 4] 3.0- 4.0 sec 111 MBytes 931 Mbits/sec [ 4] 4.0- 5.0 sec 106 MBytes 889 Mbits/sec [ 4] 0.0- 5.0 sec 550 MBytes 921 Mbits/sec [ 4] local 10.255.0.54 port 5001 connected with 10.255.0.15 port 42565 [ 4] 0.0- 1.0 sec 38.4 MBytes 322 Mbits/sec [ 4] 1.0- 2.0 sec 68.9 MBytes 578 Mbits/sec [ 4] 2.0- 3.0 sec 67.7 MBytes 568 Mbits/sec [ 4] 3.0- 4.0 sec 66.7 MBytes 559 Mbits/sec [ 4] 4.0- 5.0 sec 63.2 MBytes 530 Mbits/sec [ 4] 0.0- 5.0 sec 306 MBytes 513 Mbits/sec Machine: Laptop Connection: Ethernet Windows <-> Linux (Exact same speeds this time as OmnioOS) Server listening on TCP port 5001 TCP window size: 977 KByte Client connecting to media.midway, TCP port 5001 TCP window size: 977 KByte [ 4] local 10.255.0.54 port 57966 connected with 10.255.0.73 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 110 MBytes 920 Mbits/sec [ 4] 1.0- 2.0 sec 111 MBytes 932 Mbits/sec [ 4] 2.0- 3.0 sec 111 MBytes 931 Mbits/sec [ 4] 3.0- 4.0 sec 108 MBytes 902 Mbits/sec [ 4] 4.0- 5.0 sec 106 MBytes 887 Mbits/sec [ 4] 0.0- 5.0 sec 545 MBytes 913 Mbits/sec [ 4] local 10.255.0.54 port 5001 connected with 10.255.0.73 port 52726 [ 4] 0.0- 1.0 sec 63.4 MBytes 532 Mbits/sec [ 4] 1.0- 2.0 sec 62.9 MBytes 528 Mbits/sec [ 4] 2.0- 3.0 sec 66.7 MBytes 560 Mbits/sec [ 4] 3.0- 4.0 sec 65.3 MBytes 548 Mbits/sec [ 4] 4.0- 5.0 sec 66.8 MBytes 560 Mbits/sec [ 4] 0.0- 5.0 sec 326 MBytes 545 Mbits/sec On Wed, Jan 27, 2016 at 10:35 PM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Wed, 27 Jan 2016, Mini Trader wrote: > > Slow CIFS Writes when using Moca 2.0 Adapter. >> >> I am experiencing this only under OmniOS. I do not see this in Windows >> or Linux. >> >> I have a ZFS CIFS share setup which can easily do writes that would >> saturate a 1GBe connection. >> >> My problem appears to be related somehow to the interaction between >> OmniOS and ECB6200 Moca 2.0 adapters. >> >> 1. If I write to my OmniOS CIFS share using ethernet my speeds up/down >> are around 110 mb/sec - good >> >> 2. If I write to my share using the same source but over the adapter my >> speeds are around 35mb/sec - problem >> > > MoCA has a 3.0+ millisecond latency (I typically see 3.5ms when using > ping). This latency is fairly large compared with typical hard drive > latencies and vastly higher than Ethernet. There is nothing which can be > done about this latency. > > Unbonded MoCA 2.0 throughput for streaming data is typically > 500Mbit/second, and bonded (two channels) MoCA 2.0 doubles that (the > claimed specs are of course higher than this and higher speeds can be > measured under ideal conditions). This means that typical MoCA 2.0 (not > bonded) achieves a bit less than half of what gigabit Ethernet achieves > when streaming data over TCP. > > 3. If I read from the share using the same device over the adapter my >> speeds are around 110mb/sec - good >> > > Reading is normally m
[OmniOS-discuss] Slow CIFS Writes when using Moca 2.0 Adapter
Slow CIFS Writes when using Moca 2.0 Adapter. I am experiencing this only under OmniOS. I do not see this in Windows or Linux. I have a ZFS CIFS share setup which can easily do writes that would saturate a 1GBe connection. My problem appears to be related somehow to the interaction between OmniOS and ECB6200 Moca 2.0 adapters. 1. If I write to my OmniOS CIFS share using ethernet my speeds up/down are around 110 mb/sec - good 2. If I write to my share using the same source but over the adapter my speeds are around 35mb/sec - problem 3. If I read from the share using the same device over the adapter my speeds are around 110mb/sec - good 4. If I setup a share on a Windows machine and write to it from the same source using the adapter the speeds are around 110mb/sec. The Windows machine is actually a VM whos disks are backed by a ZFS NFS share on the same machine So basically the issue only takes place when writing to the OmniOS CIFS share using the adapter, if the adapter is not used than the write speed is perfect. Any ideas why/how a Moca 2.0 adapter which is just designed to convert an ethernet signal to a coax and back to ethernet would cause issues with writes on OmniOS when the exact same share has no issues when using an actual ethernet connection? More importantly, why is this happening with OmniOS CIFS and not anything else? I appreciate any help. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
