From henson at acm.org  Sun Feb  2 01:46:07 2014
From: henson at acm.org (Paul B. Henson)
Date: Sat, 1 Feb 2014 17:46:07 -0800
Subject: [OmniOS-discuss] overriding serial port IRQ
Message-ID: <20140202014607.GS5681@bender.unx.csupomona.edu>

So I updated the BIOS on my storage box, which has a supermicro X9SRi-F,
from 2.0a to 3.0a, and my IPMI SOL console stopped working :(. After an
annoying investigation, I discovered that the new BIOS misconfigures
ttyc/COM3, the BIOS says it's using irq 4, when in actuality it's using
irq 10. Under linux, when I override the bios config and force the
driver to use irq 10, it works fine.

How do I get an illumos/omnios box to override the bios serial port
config and use an explicitly configured irq rather than the BIOS
provided one? It looks like I need to tweak something in
/kernel/drv/asy.conf, but I'm not really clear on exactly what.

Thanks for any pointers, and ay, supermicro, fix one thing and break
another <sigh>...


From henson at acm.org  Sun Feb  2 21:37:19 2014
From: henson at acm.org (Paul B. Henson)
Date: Sun, 2 Feb 2014 13:37:19 -0800
Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ
In-Reply-To: <CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
Message-ID: <20140202213719.GX5681@bender.unx.csupomona.edu>

On Sun, Feb 02, 2014 at 11:10:35AM -0500, Albert Lee wrote:

> To introduce this info to the devinfo tree, append to /kernel/drv/asy.conf:
> name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10;

Thanks for the tip. I updated my asy.conf, it looks like this now:

-----
interrupt-priorities=12;

# temporarily hardcode serial config due to broken BIOS
name="asy" parent="isa" reg=1,0x3f8,8 interrupts=4;
name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3;
name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10;
-----

I then did a 'bootadm update-archive' (under the assumption this config
needed to be pulled into it), and rebooted, but unfortunately, the
serial console is still misbehaving :(. I have verbose boot enabled, and
all I see is:

SunOS Release 5.11 Version omnios-6de5e81 64-bit
Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights
reserved.
[ network/ip-inter

and then it stops, like it did before I tweaked asy.conf. I don't see
any mention of serial, or asy, or tty/console in dmesg, is there any way
to confirm what irq the os is using to make sure it picked up the
hardcoded config? Hmm, looks like prtconf -v shows it:

            asy, instance #2
                System properties:
                    name='interrupts' type=int items=1
                        value=0000000a
                    name='reg' type=int items=3
                        value=00000001.000003e8.00000008
                    name='interrupt-priorities' type=int items=1
                        value=0000000c

Looks like it picked up irq 10 (0xa)? The other two ports say "not attached",
not sure why, maybe because nothing's using them:

            asy, instance #0 (driver not attached)

            asy, instance #1 (driver not attached)

Hmm, darn it. I tested it under linux while I was trying to figure out
what broke, linux barfed on the bad bios config too, but when I hardcoded
the irq to 10 linux worked fine on the SOL port, so I know it can work.

Any other thoughts? Or maybe I'm SOL on the SOL port pending a supermicro
bios update <sigh>.

Thanks much...


From trisk at nexenta.com  Sun Feb  2 16:10:35 2014
From: trisk at nexenta.com (Albert Lee)
Date: Sun, 2 Feb 2014 11:10:35 -0500
Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ
In-Reply-To: <20140202014607.GS5681@bender.unx.csupomona.edu>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
Message-ID: <CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>

On Sat, Feb 1, 2014 at 8:46 PM, Paul B. Henson <henson at acm.org> wrote:
> So I updated the BIOS on my storage box, which has a supermicro X9SRi-F,
> from 2.0a to 3.0a, and my IPMI SOL console stopped working :(. After an
> annoying investigation, I discovered that the new BIOS misconfigures
> ttyc/COM3, the BIOS says it's using irq 4, when in actuality it's using
> irq 10. Under linux, when I override the bios config and force the
> driver to use irq 10, it works fine.
>
> How do I get an illumos/omnios box to override the bios serial port
> config and use an explicitly configured irq rather than the BIOS
> provided one? It looks like I need to tweak something in
> /kernel/drv/asy.conf, but I'm not really clear on exactly what.
>
> Thanks for any pointers, and ay, supermicro, fix one thing and break
> another <sigh>...
>
>

To introduce this info to the devinfo tree, append to /kernel/drv/asy.conf:
name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10;

If the first two serial ports don't keep working, also prepend
name="asy" parent="isa" reg=1,0x3f8,8 interrupts=4;
name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3;

-Albert

>
> -------------------------------------------
> illumos-discuss
> Archives: https://www.listbox.com/member/archive/182180/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175801-8cd47afa
> Modify Your Subscription: https://www.listbox.com/member/?member_id=21175801&id_secret=21175801-f1323306
> Powered by Listbox: http://www.listbox.com



-- 
Albert Lee <trisk at nexenta.com>
Nexenta Systems, Inc.

From tobi at oetiker.ch  Mon Feb  3 10:51:59 2014
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Mon, 3 Feb 2014 11:51:59 +0100 (CET)
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <alpine.DEB.2.02.1401212356540.2519@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>
	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>
	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>
	<CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>
	<alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>
	<52DEF033.7010107@gmail.com> <52DEF1AB.9030305@gmail.com>
	<52DEF24B.7070806@gmail.com>
	<alpine.DEB.2.02.1401212356540.2519@froburg.oetiker.ch>
Message-ID: <alpine.DEB.2.02.1402031143370.13918@froburg.oetiker.ch>

a short update on the matter for anyone browsing the ML archives:

The affected system runs on an S2600CP motherboard with RMM4 remote
management.  RMM comes with the ability to use any of the existing
Ethernet ports on the MB for its communication needs ...  we have
configured it with a separate hw port, but it seems that this
ability the access the other ports can interfere with omnios
operation.

10 days ago, we have upgraded the bios to
version SE5C600.86B.02.01.0002.082220131453 08/22/2013

since then we have not seen any issues ...

I am not 100% sure that this is the solution to the problem, as we
only found the behaviour after several weeks of uptime ...  in any
event, for now things look good.

cheers
tobi



-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900

From skiselkov.ml at gmail.com  Mon Feb  3 11:48:09 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Mon, 03 Feb 2014 11:48:09 +0000
Subject: [OmniOS-discuss] iscsi timeouts
In-Reply-To: <alpine.DEB.2.02.1402031143370.13918@froburg.oetiker.ch>
References: <alpine.DEB.2.02.1401211001380.2519@froburg.oetiker.ch>	<CABweQmKLuZggZBpwxH=HR+Qbq+4-T7eKnJpydCwWFRVpZ732XQ@mail.gmail.com>	<AFC10231-28C8-46AB-A73D-37B8E410563E@omniti.com>	<CABweQm+_aeDiMk6aVJmuf9K9V52zeWmi=3s9GTvej72+w9ajOg@mail.gmail.com>	<alpine.DEB.2.02.1401212254290.2519@froburg.oetiker.ch>	<52DEF033.7010107@gmail.com>
	<52DEF1AB.9030305@gmail.com>	<52DEF24B.7070806@gmail.com>	<alpine.DEB.2.02.1401212356540.2519@froburg.oetiker.ch>
	<alpine.DEB.2.02.1402031143370.13918@froburg.oetiker.ch>
Message-ID: <52EF81F9.8010204@gmail.com>

On 2/3/14, 10:51 AM, Tobias Oetiker wrote:
> a short update on the matter for anyone browsing the ML archives:
> 
> The affected system runs on an S2600CP motherboard with RMM4 remote
> management.  RMM comes with the ability to use any of the existing
> Ethernet ports on the MB for its communication needs ...  we have
> configured it with a separate hw port, but it seems that this
> ability the access the other ports can interfere with omnios
> operation.
> 
> 10 days ago, we have upgraded the bios to
> version SE5C600.86B.02.01.0002.082220131453 08/22/2013
> 
> since then we have not seen any issues ...
> 
> I am not 100% sure that this is the solution to the problem, as we
> only found the behaviour after several weeks of uptime ...  in any
> event, for now things look good.

Interesting observation, thanks for keeping the list updated!

Best wishes,
-- 
Saso

From kai at meder.info  Mon Feb  3 12:19:33 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 13:19:33 +0100
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to satisfy
	constraints
Message-ID: <lco1gu$c1k$1@ger.gmane.org>

Hello,

running 'pkg update' I get the following result:

pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution to update to 
latest available versions.
This may indicate an overly constrained set of packages are installed.

latest incorporations:
 
pkg://omnios/consolidation/osnet/osnet-incorporation at 0.5.11,5.11-0.151008:20131204T022427Z
 
pkg://omnios/incorporation/jeos/omnios-userland at 11,5.11-0.151008:20131206T160517Z
   pkg://omnios/entire at 11,5.11-0.151008:20131205T195242Z
 
pkg://omnios/incorporation/jeos/illumos-gate at 11,5.11-0.151008:20131204T024149Z
Dependency analysis is unable to determine exact cause.
Try specifying expected results to obtain more detailed error messages.


Is this simply a matter of waiting until something in the repository is 
fixed or am I supposed to do anything?

Thanks a lot,
Kai


From esproul at omniti.com  Mon Feb  3 14:46:06 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 09:46:06 -0500
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <lco1gu$c1k$1@ger.gmane.org>
References: <lco1gu$c1k$1@ger.gmane.org>
Message-ID: <CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>

On Mon, Feb 3, 2014 at 7:19 AM, Kai Meder <kai at meder.info> wrote:
> Dependency analysis is unable to determine exact cause.
> Try specifying expected results to obtain more detailed error messages.
>
>
> Is this simply a matter of waiting until something in the repository is
> fixed or am I supposed to do anything?

What version of OmniOS are you currently on (see /etc/release)?  Are
you using packages from any publishers other than omnios?  Others that
have run into this were using packages from ms.omniti.com that require
r151006.  The errors from pkg(1) are, it's safe to say, less than
helpful here.

Eric

From trisk at nexenta.com  Sun Feb  2 22:26:36 2014
From: trisk at nexenta.com (Albert Lee)
Date: Sun, 2 Feb 2014 17:26:36 -0500
Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ
In-Reply-To: <20140202213719.GX5681@bender.unx.csupomona.edu>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
Message-ID: <CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>

On Sun, Feb 2, 2014 at 4:37 PM, Paul B. Henson <henson at acm.org> wrote:
> On Sun, Feb 02, 2014 at 11:10:35AM -0500, Albert Lee wrote:
>
>> To introduce this info to the devinfo tree, append to /kernel/drv/asy.conf:
>> name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10;
>
> Thanks for the tip. I updated my asy.conf, it looks like this now:
>
> -----
> interrupt-priorities=12;
>
> # temporarily hardcode serial config due to broken BIOS
> name="asy" parent="isa" reg=1,0x3f8,8 interrupts=4;
> name="asy" parent="isa" reg=1,0x2f8,8 interrupts=3;
> name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10;
> -----
>
> I then did a 'bootadm update-archive' (under the assumption this config
> needed to be pulled into it), and rebooted, but unfortunately, the
> serial console is still misbehaving :(. I have verbose boot enabled, and
> all I see is:
>
> SunOS Release 5.11 Version omnios-6de5e81 64-bit
> Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights
> reserved.
> [ network/ip-inter
>
> and then it stops, like it did before I tweaked asy.conf. I don't see
> any mention of serial, or asy, or tty/console in dmesg, is there any way
> to confirm what irq the os is using to make sure it picked up the
> hardcoded config? Hmm, looks like prtconf -v shows it:
>
>             asy, instance #2
>                 System properties:
>                     name='interrupts' type=int items=1
>                         value=0000000a
>                     name='reg' type=int items=3
>                         value=00000001.000003e8.00000008
>                     name='interrupt-priorities' type=int items=1
>                         value=0000000c
>
> Looks like it picked up irq 10 (0xa)? The other two ports say "not attached",
> not sure why, maybe because nothing's using them:
>
>             asy, instance #0 (driver not attached)
>
>             asy, instance #1 (driver not attached)
>
> Hmm, darn it. I tested it under linux while I was trying to figure out
> what broke, linux barfed on the bad bios config too, but when I hardcoded
> the irq to 10 linux worked fine on the SOL port, so I know it can work.
>
> Any other thoughts? Or maybe I'm SOL on the SOL port pending a supermicro
> bios update <sigh>.
>
> Thanks much...
>

Are you sure it's still ttyc/COM3? asy should pick up the device name
from the I/O address, which is why I used 0x3e8.
Also, echo ::interrupts | mdb -k should show the current assignments.

-Albert

From kai at meder.info  Mon Feb  3 15:05:55 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 16:05:55 +0100
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
Message-ID: <lcob8t$5pd$1@ger.gmane.org>

Eric Sproul schrieb:
> On Mon, Feb 3, 2014 at 7:19 AM, Kai Meder<kai at meder.info>  wrote:
>> Dependency analysis is unable to determine exact cause.
>> Try specifying expected results to obtain more detailed error messages.
>>
>>
>> Is this simply a matter of waiting until something in the repository is
>> fixed or am I supposed to do anything?
>
> What version of OmniOS are you currently on (see /etc/release)?  Are
> you using packages from any publishers other than omnios?  Others that
> have run into this were using packages from ms.omniti.com that require
> r151006.  The errors from pkg(1) are, it's safe to say, less than
> helpful here.
I am on OmniOS v11 r151006.

I am indeed using php and lighttpd from ms.omniti.com,
how would I resolve this error?

Thank you very much,
Kai


From mmabis at vmware.com  Mon Feb  3 15:06:59 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Mon, 3 Feb 2014 07:06:59 -0800 (PST)
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
Message-ID: <1834167362.2619679.1391440019290.JavaMail.root@vmware.com>


Hello,

I have a few questions about a project that i am trying to work on, needless to say i have 1 80GB SSD Drive that i can fit in this case, the rest of the drives are a RaidZ2 configuration and there cannot be anymore added Disks to this system period!

My goal is to make the SSD capable of making NFS run better (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere!  

My Questions are

1) Splitting the SSD into partitions and running is that bad i always heard it was my question is why?
2) Can Omni be run from say a 32GB USB3 key directly?
3) What options do i have here outside of adding a drive.

I have SATA Slots on the mobo just no place to add an additional drive!

From dswartz at druber.com  Mon Feb  3 15:12:20 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Mon, 3 Feb 2014 10:12:20 -0500
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
Message-ID: <fe8b9892409f2eb944972162bbc6815b.squirrel@webmail.druber.com>

>
> Hello,
>
> I have a few questions about a project that i am trying to work on,
> needless to say i have 1 80GB SSD Drive that i can fit in this case, the
> rest of the drives are a RaidZ2 configuration and there cannot be anymore
> added Disks to this system period!
>
> My goal is to make the SSD capable of making NFS run better
> (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere!
>
> My Questions are
>
> 1) Splitting the SSD into partitions and running is that bad i always
> heard it was my question is why?
> 2) Can Omni be run from say a 32GB USB3 key directly?
> 3) What options do i have here outside of adding a drive.
>
> I have SATA Slots on the mobo just no place to add an additional drive!

Given how small and flat ssd drives are, you can't tape one to the inside
of the case out of the way somewhere?


From fabio at fabiorabelo.wiki.br  Mon Feb  3 15:12:54 2014
From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=)
Date: Mon, 3 Feb 2014 13:12:54 -0200
Subject: [OmniOS-discuss] industrial usb flash
Message-ID: <CAEekY67wz2J-fSYSLjw5xHs2owPgZffbf7B0biXM2rnH7MwEQA@mail.gmail.com>

Hi to all

People are talking about "industrial grade"  usb flash storage to use
as boot device for Omni and napp-it .

Exactly witch brand build this kind of device ?

I just can not find anything like that on amazon ....


F?bio Rabelo

From skiselkov.ml at gmail.com  Mon Feb  3 15:23:05 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Mon, 03 Feb 2014 15:23:05 +0000
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>	<20140202213719.GX5681@bender.unx.csupomona.edu>	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
Message-ID: <52EFB459.9050504@gmail.com>

On 2/3/14, 3:06 PM, Matthew Mabis wrote:
> 
> Hello,
> 
> I have a few questions about a project that i am trying to work on, needless to say i have 1 80GB SSD Drive that i can fit in this case, the rest of the drives are a RaidZ2 configuration and there cannot be anymore added Disks to this system period!
> 
> My goal is to make the SSD capable of making NFS run better (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere!  
> 
> My Questions are
> 
> 1) Splitting the SSD into partitions and running is that bad i always heard it was my question is why?
> 2) Can Omni be run from say a 32GB USB3 key directly?
> 3) What options do i have here outside of adding a drive.
> 
> I have SATA Slots on the mobo just no place to add an additional drive!

Yes, you can partition the SSD and it works okay. For the OS, set aside
something like 10GB and turn on compression. Although the standard
installer doesn't let you set compression on the root pool before
starting installation, there's a trick to doing it. Before firing up the
installation, get a shell from the installer menu and run the following
commands:

# screen
# while ! zpool set compress=lz4 rpool; do sleep 1; done

(after this hit 'Ctrl-A' + 'D' and type 'exit' to return to the
installer menu and leave the loop running)

The loop will try to set compression on the newly created root pool as
soon as the installer creates it, so that the OS's data itself will be
installed compressed.

For slog (aka ZIL) you don't need much - usually around 1-2GB is more
than enough, since it only needs to hold the sync write data from the
last transaction (by default: the last 5 seconds).

Use the rest of the SSD for L2ARC. Depending on the SSD type you may
also want to keep around 10-20% of the SSD unallocated, so that the
garbage collector on the controller always has blocks available it can
pre-erase - this can boost long-term slog performance quite a bit. YMMV

Cheers,
-- 
Saso

From doug at will.to  Mon Feb  3 15:34:29 2014
From: doug at will.to (Doug Hughes)
Date: Mon, 03 Feb 2014 10:34:29 -0500
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <fe8b9892409f2eb944972162bbc6815b.squirrel@webmail.druber.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
	<fe8b9892409f2eb944972162bbc6815b.squirrel@webmail.druber.com>
Message-ID: <52EFB705.2030300@will.to>


On 2/3/2014 10:12 AM, Dan Swartzendruber wrote:
>>
>> Hello,
>>
>> I have a few questions about a project that i am trying to work on,
>> needless to say i have 1 80GB SSD Drive that i can fit in this case, the
>> rest of the drives are a RaidZ2 configuration and there cannot be anymore
>> added Disks to this system period!
>>
>> My goal is to make the SSD capable of making NFS run better
>> (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere!
>>
>> My Questions are
>>
>> 1) Splitting the SSD into partitions and running is that bad i always
>> heard it was my question is why?
>> 2) Can Omni be run from say a 32GB USB3 key directly?
>> 3) What options do i have here outside of adding a drive.
>>
>> I have SATA Slots on the mobo just no place to add an additional drive!
>

Yes, we do this all the time. The OS image doesn't take that much space. 
Just carve off 8GB partition on your SSD for the ZIL, and you are set. 
It vastly improves NFS synchronous operations such as deletes, metadata 
changes, and small file writes.

What kind of SSD is it? I wouldn't recommend on an X-25M because there's 
no cap to write it out on power failure, but the Intel-320 line is a 
very good choice in general.



From kai at meder.info  Mon Feb  3 15:45:32 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 16:45:32 +0100
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <lcob8t$5pd$1@ger.gmane.org>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org>
Message-ID: <lcodj5$1fe$1@ger.gmane.org>



Kai Meder schrieb:
> Eric Sproul schrieb:
>> On Mon, Feb 3, 2014 at 7:19 AM, Kai
>> Meder<kai at meder.info> wrote:
>>> Dependency analysis is unable to determine exact cause.
>>> Try specifying expected results to obtain more detailed error messages.
>>>
>>>
>>> Is this simply a matter of waiting until something in the repository is
>>> fixed or am I supposed to do anything?
>>
>> What version of OmniOS are you currently on (see /etc/release)? Are
>> you using packages from any publishers other than omnios? Others that
>> have run into this were using packages from ms.omniti.com that require
>> r151006. The errors from pkg(1) are, it's safe to say, less than
>> helpful here.
> I am on OmniOS v11 r151006.
>
> I am indeed using php and lighttpd from ms.omniti.com,
> how would I resolve this error?

I have installed those packages:

pkg list | grep ms.omniti.com
omniti/database/mysql-55 (ms.omniti.com)          5.5.31-0.151004 
      i--
omniti/database/mysql-55/library (ms.omniti.com)  5.5.31-0.151004 
      i--
omniti/editor/nano (ms.omniti.com)                2.2.6-0.151002 
      i--
omniti/library/freetype2 (ms.omniti.com)          2.4.10-0.151002 
      i--
omniti/library/gd (ms.omniti.com)                 2.0.35-0.151002 
      i--
omniti/library/libjpeg (ms.omniti.com)            8.4-0.151002 
      i--
omniti/library/libmcrypt (ms.omniti.com)          2.5.7-0.151002 
      i--
omniti/library/libpng (ms.omniti.com)             1.5.12-0.151002 
      i--
omniti/library/libpq5 (ms.omniti.com)             9.2.0-0.151002 
      i--
omniti/library/libssh2 (ms.omniti.com)            1.4.2-0.151002 
      i--
omniti/library/mhash (ms.omniti.com)              0.9.9.9-0.151002 
      i--
omniti/runtime/php-54 (ms.omniti.com)             5.4.19-0.151006 
      i--
omniti/server/lighttpd (ms.omniti.com)            1.4.32-0.151004 
      i--
omniti/system/storage/smartmontools (ms.omniti.com) 6.0-0.151004 
        i--

How do I find out which one breaks the update?

Thanks!


From mmabis at vmware.com  Mon Feb  3 15:52:37 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Mon, 3 Feb 2014 07:52:37 -0800 (PST)
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <52EFB705.2030300@will.to>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
	<fe8b9892409f2eb944972162bbc6815b.squirrel@webmail.druber.com>
	<52EFB705.2030300@will.to>
Message-ID: <413332433.2630440.1391442757714.JavaMail.root@vmware.com>

Its an Intel 320 80GB Drive  I ensured to buy SSDs for my lab that have the power Caps didnt want to make that mistake!


Matt

----- Original Message -----
From: "Doug Hughes" <doug at will.to>
To: omnios-discuss at lists.omniti.com
Sent: Monday, February 3, 2014 7:34:29 AM
Subject: Re: [OmniOS-discuss] Where to Run Omni


On 2/3/2014 10:12 AM, Dan Swartzendruber wrote:
>>
>> Hello,
>>
>> I have a few questions about a project that i am trying to work on,
>> needless to say i have 1 80GB SSD Drive that i can fit in this case, the
>> rest of the drives are a RaidZ2 configuration and there cannot be anymore
>> added Disks to this system period!
>>
>> My goal is to make the SSD capable of making NFS run better
>> (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere!
>>
>> My Questions are
>>
>> 1) Splitting the SSD into partitions and running is that bad i always
>> heard it was my question is why?
>> 2) Can Omni be run from say a 32GB USB3 key directly?
>> 3) What options do i have here outside of adding a drive.
>>
>> I have SATA Slots on the mobo just no place to add an additional drive!
>

Yes, we do this all the time. The OS image doesn't take that much space. 
Just carve off 8GB partition on your SSD for the ZIL, and you are set. 
It vastly improves NFS synchronous operations such as deletes, metadata 
changes, and small file writes.

What kind of SSD is it? I wouldn't recommend on an X-25M because there's 
no cap to write it out on power failure, but the Intel-320 line is a 
very good choice in general.


_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
https://urldefense.proofpoint.com/v1/url?u=http://lists.omniti.com/mailman/listinfo/omnios-discuss&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yqgQ6LhGnfWMd79QvLrmWsnr%2FlpWj5c0oy4MpT8%2Bgik%3D%0A&m=jbXB0E2AdHLBwrLyWlAxJtx7ZA5Rg7gTJaePeKew70Y%3D%0A&s=b5c7784a65fcfa3c44e8f9f89d910678eda6fe717feb159eba020e2d1bab7582

From mmabis at vmware.com  Mon Feb  3 15:53:57 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Mon, 3 Feb 2014 07:53:57 -0800 (PST)
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <52EFB459.9050504@gmail.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
	<52EFB459.9050504@gmail.com>
Message-ID: <1221717239.2630686.1391442837397.JavaMail.root@vmware.com>

This is perfect, I was reading on Hardforum from a user named GEA saying that its unsupported and not recommended about a year ago so i figured why not bring the question to the forum and get the answer to Why!

This information will get things rolling!  Thanks!

Matt Mabis 

----- Original Message -----
From: "Saso Kiselkov" <skiselkov.ml at gmail.com>
To: omnios-discuss at lists.omniti.com
Sent: Monday, February 3, 2014 7:23:05 AM
Subject: Re: [OmniOS-discuss] Where to Run Omni

On 2/3/14, 3:06 PM, Matthew Mabis wrote:
> 
> Hello,
> 
> I have a few questions about a project that i am trying to work on, needless to say i have 1 80GB SSD Drive that i can fit in this case, the rest of the drives are a RaidZ2 configuration and there cannot be anymore added Disks to this system period!
> 
> My goal is to make the SSD capable of making NFS run better (Slog/ZIL/L2ARC) whatever... but i need the OS to go somewhere!  
> 
> My Questions are
> 
> 1) Splitting the SSD into partitions and running is that bad i always heard it was my question is why?
> 2) Can Omni be run from say a 32GB USB3 key directly?
> 3) What options do i have here outside of adding a drive.
> 
> I have SATA Slots on the mobo just no place to add an additional drive!

Yes, you can partition the SSD and it works okay. For the OS, set aside
something like 10GB and turn on compression. Although the standard
installer doesn't let you set compression on the root pool before
starting installation, there's a trick to doing it. Before firing up the
installation, get a shell from the installer menu and run the following
commands:

# screen
# while ! zpool set compress=lz4 rpool; do sleep 1; done

(after this hit 'Ctrl-A' + 'D' and type 'exit' to return to the
installer menu and leave the loop running)

The loop will try to set compression on the newly created root pool as
soon as the installer creates it, so that the OS's data itself will be
installed compressed.

For slog (aka ZIL) you don't need much - usually around 1-2GB is more
than enough, since it only needs to hold the sync write data from the
last transaction (by default: the last 5 seconds).

Use the rest of the SSD for L2ARC. Depending on the SSD type you may
also want to keep around 10-20% of the SSD unallocated, so that the
garbage collector on the controller always has blocks available it can
pre-erase - this can boost long-term slog performance quite a bit. YMMV

Cheers,
-- 
Saso
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
https://urldefense.proofpoint.com/v1/url?u=http://lists.omniti.com/mailman/listinfo/omnios-discuss&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yqgQ6LhGnfWMd79QvLrmWsnr%2FlpWj5c0oy4MpT8%2Bgik%3D%0A&m=SIl8BuMbKpDSpCGhnR41LKGpg8kFruHNVH1eJ2FH%2BGE%3D%0A&s=c03620d2a0c94f3a2b271e1c23f59d4e9b986a1c1dadcc8744a1ca51a20fc7af

From dswartz at druber.com  Mon Feb  3 16:01:34 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Mon, 3 Feb 2014 11:01:34 -0500
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <1221717239.2630686.1391442837397.JavaMail.root@vmware.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
	<52EFB459.9050504@gmail.com>
	<1221717239.2630686.1391442837397.JavaMail.root@vmware.com>
Message-ID: <8dc163b35c20fb4496e0e226b7e6196b.squirrel@webmail.druber.com>

> This is perfect, I was reading on Hardforum from a user named GEA saying
> that its unsupported and not recommended about a year ago so i figured why
> not bring the question to the forum and get the answer to Why!

I seem to recall there being sound reasons not to share the same device
between SLOG and L2ARC (or anything else, for that matter...)


From esproul at omniti.com  Mon Feb  3 16:16:55 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 11:16:55 -0500
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <lcodj5$1fe$1@ger.gmane.org>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
Message-ID: <CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>

On Mon, Feb 3, 2014 at 10:45 AM, Kai Meder <kai at meder.info> wrote:
> I have installed those packages:
>
> pkg list | grep ms.omniti.com
> omniti/database/mysql-55 (ms.omniti.com)          5.5.31-0.151004      i--
> omniti/database/mysql-55/library (ms.omniti.com)  5.5.31-0.151004      i--
> omniti/editor/nano (ms.omniti.com)                2.2.6-0.151002      i--
> omniti/library/freetype2 (ms.omniti.com)          2.4.10-0.151002      i--
> omniti/library/gd (ms.omniti.com)                 2.0.35-0.151002      i--
> omniti/library/libjpeg (ms.omniti.com)            8.4-0.151002      i--
> omniti/library/libmcrypt (ms.omniti.com)          2.5.7-0.151002      i--
> omniti/library/libpng (ms.omniti.com)             1.5.12-0.151002      i--
> omniti/library/libpq5 (ms.omniti.com)             9.2.0-0.151002      i--
> omniti/library/libssh2 (ms.omniti.com)            1.4.2-0.151002      i--
> omniti/library/mhash (ms.omniti.com)              0.9.9.9-0.151002      i--
> omniti/runtime/php-54 (ms.omniti.com)             5.4.19-0.151006      i--
> omniti/server/lighttpd (ms.omniti.com)            1.4.32-0.151004      i--
> omniti/system/storage/smartmontools (ms.omniti.com) 6.0-0.151004        i--
>
> How do I find out which one breaks the update?

I'm going to surmise that it is php-54.  More recent builds in
ms.omniti.com began incorporating on the 'entire' package of the
version they were built on, because we could not know whether they
would work properly on future versions of the OS.

You can try this to confirm my suspicion: pkg search -H -l -o pkg.name
'depend:incorporate:entire'

That generates a list of pkg.name values (from pkg metadata) of
locally installed (-l) packages that have a dependency of type
incorporate on entire.  The -H eliminates the header line in output.

Eric

From doug at will.to  Mon Feb  3 16:26:56 2014
From: doug at will.to (Doug Hughes)
Date: Mon, 03 Feb 2014 11:26:56 -0500
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <1221717239.2630686.1391442837397.JavaMail.root@vmware.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
	<52EFB459.9050504@gmail.com>
	<1221717239.2630686.1391442837397.JavaMail.root@vmware.com>
Message-ID: <52EFC350.20306@will.to>

On 2/3/2014 10:53 AM, Matthew Mabis wrote:
> This is perfect, I was reading on Hardforum from a user named GEA saying that its unsupported and not recommended about a year ago so i figured why not bring the question to the forum and get the answer to Why!
>
> This information will get things rolling!  Thanks!
>
> Matt Mabis

On a normal spinning disk this has the potential to be questionable 
because the head has to seek to get to the zil, and then back again, 
especially if you have swap enabled and in use. The OS, though, really 
doesn't do much disk activity after being loaded (unless you have a lot 
of logging going on), and SSD has no seek penalty, per se.


From esproul at omniti.com  Mon Feb  3 16:28:50 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 11:28:50 -0500
Subject: [OmniOS-discuss] Fwd: omnios-b281e50: No solution was found to
 satisfy constraints
In-Reply-To: <CA+QY2RSKPKGcx5F7TUJZjhOjdNHUpc13hWa3nd_JwdYNH4O7gA@mail.gmail.com>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<1E670AA9-9943-49E1-B3E4-BE73596A6402@fluffy.co.uk>
	<CA+QY2RSKPKGcx5F7TUJZjhOjdNHUpc13hWa3nd_JwdYNH4O7gA@mail.gmail.com>
Message-ID: <CA+QY2RRns8f5iZ36RdvsBSibcNa2DNQj6dyAbVcMDQZBW8cY+w@mail.gmail.com>

Forgot to reply-all


---------- Forwarded message ----------
From: Eric Sproul <esproul at omniti.com>
Date: Mon, Feb 3, 2014 at 11:28 AM
Subject: Re: [OmniOS-discuss] omnios-b281e50: No solution was found to
satisfy constraints
To: Ben Summers <ben at fluffy.co.uk>


On Mon, Feb 3, 2014 at 11:20 AM, Ben Summers <ben at fluffy.co.uk> wrote:
>
> On 3 Feb 2014, at 16:16, Eric Sproul <esproul at omniti.com> wrote:
>
>> I'm going to surmise that it is php-54.  More recent builds in
>> ms.omniti.com began incorporating on the 'entire' package of the
>> version they were built on, because we could not know whether they
>> would work properly on future versions of the OS.
>
> The expectation of someone from the Solaris world is that if it works now, it'll work on any future version of the OS.
>
> Should OmniOS users expect this to be the case, or should we recompile for new versions of the OS?

That's only for libc ABI.  Those promises do not extend to userland
libraries, which is where we would most likely expect breakage for
high-level apps.

Eric

From kai at meder.info  Mon Feb  3 18:57:45 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 19:57:45 +0100
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
Message-ID: <52EFE6A9.8070203@meder.info>

Eric Sproul schrieb:
> On Mon, Feb 3, 2014 at 10:45 AM, Kai Meder<kai at meder.info>  wrote:
>> I have installed those packages:
>>
>> pkg list | grep ms.omniti.com
>> omniti/database/mysql-55 (ms.omniti.com)          5.5.31-0.151004      i--
>> omniti/database/mysql-55/library (ms.omniti.com)  5.5.31-0.151004      i--
>> omniti/editor/nano (ms.omniti.com)                2.2.6-0.151002      i--
>> omniti/library/freetype2 (ms.omniti.com)          2.4.10-0.151002      i--
>> omniti/library/gd (ms.omniti.com)                 2.0.35-0.151002      i--
>> omniti/library/libjpeg (ms.omniti.com)            8.4-0.151002      i--
>> omniti/library/libmcrypt (ms.omniti.com)          2.5.7-0.151002      i--
>> omniti/library/libpng (ms.omniti.com)             1.5.12-0.151002      i--
>> omniti/library/libpq5 (ms.omniti.com)             9.2.0-0.151002      i--
>> omniti/library/libssh2 (ms.omniti.com)            1.4.2-0.151002      i--
>> omniti/library/mhash (ms.omniti.com)              0.9.9.9-0.151002      i--
>> omniti/runtime/php-54 (ms.omniti.com)             5.4.19-0.151006      i--
>> omniti/server/lighttpd (ms.omniti.com)            1.4.32-0.151004      i--
>> omniti/system/storage/smartmontools (ms.omniti.com) 6.0-0.151004        i--
>>
>> How do I find out which one breaks the update?
>
> I'm going to surmise that it is php-54.  More recent builds in
> ms.omniti.com began incorporating on the 'entire' package of the
> version they were built on, because we could not know whether they
> would work properly on future versions of the OS.
>
> You can try this to confirm my suspicion: pkg search -H -l -o pkg.name
> 'depend:incorporate:entire'
>
> That generates a list of pkg.name values (from pkg metadata) of
> locally installed (-l) packages that have a dependency of type
> incorporate on entire.  The -H eliminates the header line in output.

pkg search -H -l -o pkg.name 'depend:incorporate:entire'
omniti/runtime/php-54

OK, you hit it. What am I supposed to do now?
I did not really understand the 'entire'-incorporation...

Thank you




From kai at meder.info  Mon Feb  3 19:00:32 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 20:00:32 +0100
Subject: [OmniOS-discuss] industrial usb flash
In-Reply-To: <CAEekY67wz2J-fSYSLjw5xHs2owPgZffbf7B0biXM2rnH7MwEQA@mail.gmail.com>
References: <CAEekY67wz2J-fSYSLjw5xHs2owPgZffbf7B0biXM2rnH7MwEQA@mail.gmail.com>
Message-ID: <52EFE750.5040307@meder.info>

The SanDisk Extreme USB3.0 32GB is said to be good.
http://www.sandisk.com/products/usb/drives/extreme/

But this is still far from "industrial grade" if you're talking about 
SLC heavy-write-endurance drives...

Would be interested too for my next Avoton/Rangeley build using OmniOS.
Anyone any advice?

F?bio Rabelo schrieb:
> Hi to all
>
> People are talking about "industrial grade"  usb flash storage to use
> as boot device for Omni and napp-it .
>
> Exactly witch brand build this kind of device ?
>
> I just can not find anything like that on amazon ....
>
>
> F?bio Rabelo
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


From esproul at omniti.com  Mon Feb  3 19:40:04 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 14:40:04 -0500
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <52EFE6A9.8070203@meder.info>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
Message-ID: <CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>

On Mon, Feb 3, 2014 at 1:57 PM, Kai Meder <kai at meder.info> wrote:
> pkg search -H -l -o pkg.name 'depend:incorporate:entire'
> omniti/runtime/php-54
>
> OK, you hit it. What am I supposed to do now?
> I did not really understand the 'entire'-incorporation...

The php-54 package declares that it requires entire at 11-0.151006 and
only that version.  'entire' is a package that controls (directly or
indirectly) the versions of all the packages available in the omnios
publisher, so php-54 uses that as a way to say "I will only run on
r151006".

You can remove that package and upgrade, or you can stay on r151006 if
you want to keep using the php-54 package.

Eric

From esproul at omniti.com  Mon Feb  3 20:29:06 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 15:29:06 -0500
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <52EFF9E0.5010209@meder.info>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
	<CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
	<52EFF9E0.5010209@meder.info>
Message-ID: <CA+QY2RS+Mu1NXW2EaqKhEMLZqBJ0+REz=yLMZ8wqQjTkjmbPfA@mail.gmail.com>

On Mon, Feb 3, 2014 at 3:19 PM, Kai Meder <kai at meder.info> wrote:
> Eric Sproul schrieb:
>> You can remove that package and upgrade, or you can stay on r151006 if
>> you want to keep using the php-54 package.
>
> OK, but since there is no php-55, I can't currently use PHP if I want to
> stay upgradeable, do I?
> My server-WebInterface is based on PHP5, so I need any PHP5-version...

There certainly is PHP 5.5 available as source. ;)

You cannot use the ms.omniti.com php-54 package on anything except
r151006.  You can always roll your own.

On the other hand, note that r151006 is a long-term support release
with security updates through 2016, so unless you have some
non-negotiable reason to go to r151008, perhaps you could stay on 006.

Eric

From esproul at omniti.com  Mon Feb  3 21:11:35 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 16:11:35 -0500
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <52EFFCF3.7070001@meder.info>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
	<CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
	<52EFF9E0.5010209@meder.info>
	<CA+QY2RS+Mu1NXW2EaqKhEMLZqBJ0+REz=yLMZ8wqQjTkjmbPfA@mail.gmail.com>
	<52EFFCF3.7070001@meder.info>
Message-ID: <CA+QY2RRC=dA2YJGwRmAOSPc6f53r-5H24yX+eJq4qjr_Lz-WKA@mail.gmail.com>

On Mon, Feb 3, 2014 at 3:32 PM, Kai Meder <kai at meder.info> wrote:
> Do you actually plan to change php-54's 'entire' incorporation?
> I am willing to stay on LTS for the time being but not for the next 3 years
> ;)
>
> Thank you very much for these explanations

The ms.omniti.com package set is what OmniTI uses internally for
hosting and other production purposes.  We prefer the stability of LTS
for that, so I can't say if/when there will be builds for r151008.  If
you really need both php 5.4 *and* always the latest-and-greatest OS
every 6 months, then you should invest in rolling your own packages,
as you have needs that aren't being met by the available community
packages.

Eric

From esproul at omniti.com  Mon Feb  3 21:16:16 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 16:16:16 -0500
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <52F0068A.9050404@meder.info>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
	<CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
	<52EFF9E0.5010209@meder.info>
	<CA+QY2RS+Mu1NXW2EaqKhEMLZqBJ0+REz=yLMZ8wqQjTkjmbPfA@mail.gmail.com>
	<52EFFCF3.7070001@meder.info>
	<CA+QY2RRC=dA2YJGwRmAOSPc6f53r-5H24yX+eJq4qjr_Lz-WKA@mail.gmail.com>
	<52F0068A.9050404@meder.info>
Message-ID: <CA+QY2RRfP7ZYZc=-0e4OyjhknEzPoiC0Fzbh-Jv1eB0yz49Xvw@mail.gmail.com>

On Mon, Feb 3, 2014 at 4:13 PM, Kai Meder <kai at meder.info> wrote:
> OK, this is perfectly acceptable.
> How do I tell my OmniOS to update anything possible but stop whining about
> php's and possible future 'entire'-dependencies?

You cannot do that.  A package (php-54) has declared that it must have
r151006.  The only way to upgrade would be to remove that package, and
accept that it will not be installable on the upgraded system.

From henson at acm.org  Mon Feb  3 21:30:03 2014
From: henson at acm.org (Paul B. Henson)
Date: Mon, 3 Feb 2014 13:30:03 -0800
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <52EFB459.9050504@gmail.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>	<20140202213719.GX5681@bender.unx.csupomona.edu>	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>
	<52EFB459.9050504@gmail.com>
Message-ID: <089c01cf2127$1b4e9650$51ebc2f0$@acm.org>

> From: Saso Kiselkov
> Sent: Monday, February 03, 2014 7:23 AM
> something like 10GB and turn on compression. Although the standard
> installer doesn't let you set compression on the root pool before
> starting installation, there's a trick to doing it. Before firing up the

With a little more effort:

http://omnios.omniti.com/wiki.php/ISOrpoolCustomize

You can configure the size of the rpool partition, provide arbitrary pool
creation options including compression, and also size swap/dump explicitly
rather than use the installer defaults.



From henson at acm.org  Mon Feb  3 21:40:44 2014
From: henson at acm.org (Paul B. Henson)
Date: Mon, 3 Feb 2014 13:40:44 -0800
Subject: [OmniOS-discuss] [discuss] overriding serial port IRQ
In-Reply-To: <CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>
	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>
	<20140202213719.GX5681@bender.unx.csupomona.edu>
	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>
Message-ID: <08a001cf2128$995d49f0$cc17ddd0$@acm.org>

> From: Albert Lee [mailto:trisk at nexenta.com]
> Sent: Sunday, February 02, 2014 2:27 PM
>
> Are you sure it's still ttyc/COM3? asy should pick up the device name
> from the I/O address, which is why I used 0x3e8.

Pretty sure. Linux works okay on ttyS2 (COM3) with the irq overridden to 10. I also see the first bit of booting under omnios with the console set to ttyc, and I also see "rebooting" on the serial console when I reboot. The behavior is very similar to a problem I had with openbsd and the SOL console when it was using the wrong irq, it would print out like 16 characters or so until the buffer was full and then hang waiting for an interrupt that never came.

> Also, echo ::interrupts | mdb -k should show the current assignments.

Arg, looks like it didn't get the override after all:

CPU/Vect  IRQ IPL Bus    Trg Type   Share APIC/INT# ISR
10/0x20   3   5   ISA    Edg Fixed  1     0x0/0x3   asyintr
11/0x20   4   5   ISA    Edg Fixed  2     0x0/0x4   asyintr
11/0x20   4   5   ISA    Edg Fixed  2     0x0/0x4   asyintr

I've seen some other examples for asy.conf that look more like:

name="asy" class="sysbus" interrupts=12,10 reg=0x3e8,0,0 ioaddr=0x3e8;

As opposed to the one I have now:

name="asy" parent="isa" reg=1,0x3e8,8 interrupts=10;

I'm not sure if that was for an older version of Solaris though?



From kai at meder.info  Mon Feb  3 20:19:44 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 21:19:44 +0100
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
 satisfy constraints
In-Reply-To: <CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
	<CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
Message-ID: <52EFF9E0.5010209@meder.info>

Eric Sproul schrieb:
> On Mon, Feb 3, 2014 at 1:57 PM, Kai Meder<kai at meder.info>  wrote:
>> pkg search -H -l -o pkg.name 'depend:incorporate:entire'
>> omniti/runtime/php-54
>>
>> OK, you hit it. What am I supposed to do now?
>> I did not really understand the 'entire'-incorporation...
>
> The php-54 package declares that it requires entire at 11-0.151006 and
> only that version.  'entire' is a package that controls (directly or
> indirectly) the versions of all the packages available in the omnios
> publisher, so php-54 uses that as a way to say "I will only run on
> r151006".
>
> You can remove that package and upgrade, or you can stay on r151006 if
> you want to keep using the php-54 package.
OK, but since there is no php-55, I can't currently use PHP if I want to 
stay upgradeable, do I?
My server-WebInterface is based on PHP5, so I need any PHP5-version...

Thanks,
Kai

From kai at meder.info  Mon Feb  3 20:32:51 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 21:32:51 +0100
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
 satisfy constraints
In-Reply-To: <CA+QY2RS+Mu1NXW2EaqKhEMLZqBJ0+REz=yLMZ8wqQjTkjmbPfA@mail.gmail.com>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
	<CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
	<52EFF9E0.5010209@meder.info>
	<CA+QY2RS+Mu1NXW2EaqKhEMLZqBJ0+REz=yLMZ8wqQjTkjmbPfA@mail.gmail.com>
Message-ID: <52EFFCF3.7070001@meder.info>

Eric Sproul schrieb:
> On Mon, Feb 3, 2014 at 3:19 PM, Kai Meder<kai at meder.info>  wrote:
>> Eric Sproul schrieb:
>>> You can remove that package and upgrade, or you can stay on r151006 if
>>> you want to keep using the php-54 package.
>> OK, but since there is no php-55, I can't currently use PHP if I want to
>> stay upgradeable, do I?
>> My server-WebInterface is based on PHP5, so I need any PHP5-version...
>
> There certainly is PHP 5.5 available as source. ;)
>
> You cannot use the ms.omniti.com php-54 package on anything except
> r151006.  You can always roll your own.
>
> On the other hand, note that r151006 is a long-term support release
> with security updates through 2016, so unless you have some
> non-negotiable reason to go to r151008, perhaps you could stay on 006.
Do you actually plan to change php-54's 'entire' incorporation?
I am willing to stay on LTS for the time being but not for the next 3 
years ;)

Thank you very much for these explanations

From kai at meder.info  Mon Feb  3 21:13:46 2014
From: kai at meder.info (Kai Meder)
Date: Mon, 03 Feb 2014 22:13:46 +0100
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
 satisfy constraints
In-Reply-To: <CA+QY2RRC=dA2YJGwRmAOSPc6f53r-5H24yX+eJq4qjr_Lz-WKA@mail.gmail.com>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
	<CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
	<52EFF9E0.5010209@meder.info>
	<CA+QY2RS+Mu1NXW2EaqKhEMLZqBJ0+REz=yLMZ8wqQjTkjmbPfA@mail.gmail.com>
	<52EFFCF3.7070001@meder.info>
	<CA+QY2RRC=dA2YJGwRmAOSPc6f53r-5H24yX+eJq4qjr_Lz-WKA@mail.gmail.com>
Message-ID: <52F0068A.9050404@meder.info>

Eric Sproul schrieb:
> On Mon, Feb 3, 2014 at 3:32 PM, Kai Meder<kai at meder.info>  wrote:
>> Do you actually plan to change php-54's 'entire' incorporation?
>> I am willing to stay on LTS for the time being but not for the next 3 years
>> ;)
>>
>> Thank you very much for these explanations
>
> The ms.omniti.com package set is what OmniTI uses internally for
> hosting and other production purposes.  We prefer the stability of LTS
> for that, so I can't say if/when there will be builds for r151008.  If
> you really need both php 5.4 *and* always the latest-and-greatest OS
> every 6 months, then you should invest in rolling your own packages,
> as you have needs that aren't being met by the available community
> packages.

OK, this is perfectly acceptable.
How do I tell my OmniOS to update anything possible but stop whining 
about php's and possible future 'entire'-dependencies?

Thanks,
Kai

From esproul at omniti.com  Mon Feb  3 21:49:15 2014
From: esproul at omniti.com (Eric Sproul)
Date: Mon, 3 Feb 2014 16:49:15 -0500
Subject: [OmniOS-discuss] omnios-b281e50: No solution was found to
	satisfy constraints
In-Reply-To: <542DB2F3-EAB2-40B3-9782-3C57BCF6355C@marzocchi.net>
References: <lco1gu$c1k$1@ger.gmane.org>
	<CA+QY2RREPJ1uKhPKrXEdX75AatDmJUYYsy166ifCgVLNAeOwHw@mail.gmail.com>
	<lcob8t$5pd$1@ger.gmane.org> <lcodj5$1fe$1@ger.gmane.org>
	<CA+QY2RRYjVfiMhgv4tbLr9QnjCMS8JwCO6AKhPmdU9knidtZew@mail.gmail.com>
	<52EFE6A9.8070203@meder.info>
	<CA+QY2RS+oGO3kv0bSj2fRYq=NU3ZQWxqCUqBc8_MfSBCnGLLoA@mail.gmail.com>
	<52EFF9E0.5010209@meder.info>
	<CA+QY2RS+Mu1NXW2EaqKhEMLZqBJ0+REz=yLMZ8wqQjTkjmbPfA@mail.gmail.com>
	<52EFFCF3.7070001@meder.info>
	<CA+QY2RRC=dA2YJGwRmAOSPc6f53r-5H24yX+eJq4qjr_Lz-WKA@mail.gmail.com>
	<52F0068A.9050404@meder.info>
	<CA+QY2RRfP7ZYZc=-0e4OyjhknEzPoiC0Fzbh-Jv1eB0yz49Xvw@mail.gmail.com>
	<542DB2F3-EAB2-40B3-9782-3C57BCF6355C@marzocchi.net>
Message-ID: <CA+QY2RQjoW30gz_e3B+kgP3OihmwY9L2_GA5GO6xcaYy6pGgZg@mail.gmail.com>

On Mon, Feb 3, 2014 at 4:24 PM, Olaf Marzocchi <lists at marzocchi.net> wrote:
>
> Il giorno 03/feb/2014, alle ore 22:16, Eric Sproul <esproul at omniti.com> ha scritto:
>
>> On Mon, Feb 3, 2014 at 4:13 PM, Kai Meder <kai at meder.info> wrote:
>>> OK, this is perfectly acceptable.
>>> How do I tell my OmniOS to update anything possible but stop whining about
>>> php's and possible future 'entire'-dependencies?
>>
>> You cannot do that.  A package (php-54) has declared that it must have
>> r151006.  The only way to upgrade would be to remove that package, and
>> accept that it will not be installable on the upgraded system.
>
> Kai, I had the same problem with perl provided by ms.omniti and the suggestion was to take it out and compile my own perl.
> It seemed a burden, it took only 10 minutes. Now I also enjoy some advantages I didn't think about.
> I think php is about as complex as perl :)

It's even easier because there's an existing build you can look at:
https://github.com/omniti-labs/omnios-build/tree/omniti-ms/build/php-54

There is a single patch to fix a zlib issue, but otherwise it "just works".

From skiselkov.ml at gmail.com  Mon Feb  3 22:26:15 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Mon, 03 Feb 2014 22:26:15 +0000
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <089c01cf2127$1b4e9650$51ebc2f0$@acm.org>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>	<20140202213719.GX5681@bender.unx.csupomona.edu>	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>	<52EFB459.9050504@gmail.com>
	<089c01cf2127$1b4e9650$51ebc2f0$@acm.org>
Message-ID: <52F01787.7050801@gmail.com>

On 2/3/14, 9:30 PM, Paul B. Henson wrote:
>> From: Saso Kiselkov
>> Sent: Monday, February 03, 2014 7:23 AM
>> something like 10GB and turn on compression. Although the standard
>> installer doesn't let you set compression on the root pool before
>> starting installation, there's a trick to doing it. Before firing up the
> 
> With a little more effort:
> 
> http://omnios.omniti.com/wiki.php/ISOrpoolCustomize
> 
> You can configure the size of the rpool partition, provide arbitrary pool
> creation options including compression, and also size swap/dump explicitly
> rather than use the installer defaults.

Oh wow, configure network, download script, make executable, execute,
bootstrap pre-install environment, edit perl script, then cross fingers
that it works as expected (be sure to read the log!). I mean I
understand that this is more flexible than just running stuff in a
screen, but if you were willing to go to such lengths to create this
script, what's the problem with fixing the installer to simply prompt
for some of these options in the first place? You know, things like
swap/dump size, fs options, etc - little things. Doesn't have to be a
full installer rewrite.

Cheers,
-- 
Saso

From henson at acm.org  Mon Feb  3 23:34:46 2014
From: henson at acm.org (Paul B. Henson)
Date: Mon, 3 Feb 2014 15:34:46 -0800
Subject: [OmniOS-discuss] Where to Run Omni
In-Reply-To: <52F01787.7050801@gmail.com>
References: <20140202014607.GS5681@bender.unx.csupomona.edu>	<CAN101Ljy+T_y3TW6qNJY_5L4m=8+4-_tpZD=5hphf=eJdHvZHg@mail.gmail.com>	<20140202213719.GX5681@bender.unx.csupomona.edu>	<CAN101LiZBxMxg0vc7QWsujWrGF_8edvggxF-OfKOGSFoMzkrjg@mail.gmail.com>	<1834167362.2619679.1391440019290.JavaMail.root@vmware.com>	<52EFB459.9050504@gmail.com>	<089c01cf2127$1b4e9650$51ebc2f0$@acm.org>
	<52F01787.7050801@gmail.com>
Message-ID: <08a601cf2138$87dc2330$97946990$@acm.org>

> From: Saso Kiselkov
> Sent: Monday, February 03, 2014 2:26 PM
>
> Oh wow, configure network, download script, make executable, execute,
> bootstrap pre-install environment, edit perl script, then cross fingers
> that it works as expected (be sure to read the log!).

The omnios installer itself has a log, do you cross your fingers when you
use it? I really don't think you can correlate "something creates a log you
can look at in case something goes wrong" with "something is likely to go
wrong". I haven't had any problems with it, but if somebody doesn't like how
it works out for them, they're more than welcome to a full refund ;).

> understand that this is more flexible than just running stuff in a
> screen, but if you were willing to go to such lengths to create this
> script, what's the problem with fixing the installer to simply prompt
> for some of these options in the first place?

I think you overestimate considerably how much time I put into whipping up
this little workaround. I can't imagine it took more than 30 minutes all
told. Good luck reengineering the text based installer in that timeframe
8-/.

Dunno, it scratched my itch, I know of at least a couple of other people it
worked out for, and if somebody gets a good chuckle out of making fun of it,
I suppose that's better than nothing.



From ask at apache.org  Mon Feb  3 23:43:30 2014
From: ask at apache.org (=?windows-1252?Q?Ask_Bj=F8rn_Hansen?=)
Date: Mon, 3 Feb 2014 15:43:30 -0800
Subject: [OmniOS-discuss] industrial usb flash
In-Reply-To: <CAEekY67wz2J-fSYSLjw5xHs2owPgZffbf7B0biXM2rnH7MwEQA@mail.gmail.com>
References: <CAEekY67wz2J-fSYSLjw5xHs2owPgZffbf7B0biXM2rnH7MwEQA@mail.gmail.com>
Message-ID: <91A14458-B2EF-42F1-9439-FB1E7A3741A3@apache.org>


On Feb 3, 2014, at 7:12 , F?bio Rabelo <fabio at fabiorabelo.wiki.br> wrote:

> People are talking about "industrial grade"  usb flash storage to use
> as boot device for Omni and napp-it .

I haven?t tried them but Transcend have various SLC flash form factors:

http://us.transcend-info.com/industry/products.asp?CatNo=2&LangNo=0&Func1No=1&Func2No=171

Including a USB connected drive:

http://us.transcend-info.com/industry/products.asp?CatNo=2&LangNo=0&Func1No=1&Func2No=171



Ask


From cks at cs.toronto.edu  Tue Feb  4 16:27:27 2014
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Tue, 04 Feb 2014 11:27:27 -0500
Subject: [OmniOS-discuss] Are reboots hanging on 'rebooting...' still of
	interest?
Message-ID: <20140204162727.BDA2C1A0A8D@apps0.cs.toronto.edu>

 Back in October there was a thread about OmniOS systems hanging on
reboot (starting at
http://lists.omniti.com/pipermail/omnios-discuss/2013-October/001494.html).
I now have a OmniOS r151008j install that does this reliably
on a SuperMicro X9SRH-7TF motherboard (and the workaround from
http://lists.omniti.com/pipermail/omnios-discuss/2013-October/001496.html
works for me to work around the issue).

 Is hardware information or other diagnostics from the machine still of
interest to either the list or to individual people? This machine is not
in production so I can easily do experiments on it for people, and I'm
happy to give configuration dumps or whatever you'd find handy.

	- cks

From mamruoc at gmail.com  Tue Feb  4 20:06:41 2014
From: mamruoc at gmail.com (Mam Ruoc)
Date: Tue, 4 Feb 2014 21:06:41 +0100
Subject: [OmniOS-discuss] Shutdown/reboot hangs
Message-ID: <F89F7AF0-9A37-4B53-B70F-35E150017B3B@gmail.com>

Hello,

I have recently moved from ZFSguru to OmniOS and love it. 

I do have a "problem" though:
When I reboot/shutdhown, the system seems to hang due to clients connected to samba and nfs shares.
Is it possible to terminate these connects, so the system can shutdown/reboot without me pulling the physical plug?

Brgds,
Mam

From mayuresh at kathe.in  Wed Feb  5 13:09:25 2014
From: mayuresh at kathe.in (Mayuresh Kathe)
Date: Wed, 05 Feb 2014 18:39:25 +0530
Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not happening!
Message-ID: <d6eb86300d8b1042edaabc0152dc4e93@kathe.in>

hi,

i have been trying to download the r151008 iso since afternoon.
fails after downloading around 120mb.

this has happened thrice.
and inspite of using 'wget -c' it fails to restart.

is there any problem with the omniti network connectivity?
have successfully downloaded crux linux after that.

best,

~mayuresh


From skiselkov.ml at gmail.com  Wed Feb  5 13:30:40 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Wed, 05 Feb 2014 13:30:40 +0000
Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not
	happening!
In-Reply-To: <d6eb86300d8b1042edaabc0152dc4e93@kathe.in>
References: <d6eb86300d8b1042edaabc0152dc4e93@kathe.in>
Message-ID: <52F23D00.1030500@gmail.com>

On 2/5/14, 1:09 PM, Mayuresh Kathe wrote:
> hi,
> 
> i have been trying to download the r151008 iso since afternoon.
> fails after downloading around 120mb.
> 
> this has happened thrice.
> and inspite of using 'wget -c' it fails to restart.
> 
> is there any problem with the omniti network connectivity?
> have successfully downloaded crux linux after that.

Works for me.

-- 
Saso


From mayuresh at kathe.in  Wed Feb  5 14:06:22 2014
From: mayuresh at kathe.in (Mayuresh Kathe)
Date: Wed, 5 Feb 2014 14:06:22 +0000
Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not
 happening!
In-Reply-To: <52F23D00.1030500@gmail.com>
References: <d6eb86300d8b1042edaabc0152dc4e93@kathe.in>
	<52F23D00.1030500@gmail.com>
Message-ID: <20140205140620.GA11447@SDF.ORG>

On Wed, Feb 05, 2014 at 01:30:40PM +0000, Saso Kiselkov wrote:
> On 2/5/14, 1:09 PM, Mayuresh Kathe wrote:
> > hi,
> > 
> > i have been trying to download the r151008 iso since afternoon.
> > fails after downloading around 120mb.
> > 
> > this has happened thrice.
> > and inspite of using 'wget -c' it fails to restart.
> > 
> > is there any problem with the omniti network connectivity?
> > have successfully downloaded crux linux after that.
> 
> Works for me.

yeah, worked at my end too, done in less than 40 minutes.
strange...

~mayuresh


From skiselkov.ml at gmail.com  Wed Feb  5 14:18:36 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Wed, 05 Feb 2014 14:18:36 +0000
Subject: [OmniOS-discuss] omnios : r151008 : iso : download : not
	happening!
In-Reply-To: <20140205140620.GA11447@SDF.ORG>
References: <d6eb86300d8b1042edaabc0152dc4e93@kathe.in>
	<52F23D00.1030500@gmail.com> <20140205140620.GA11447@SDF.ORG>
Message-ID: <52F2483C.9040408@gmail.com>

On 2/5/14, 2:06 PM, Mayuresh Kathe wrote:
> On Wed, Feb 05, 2014 at 01:30:40PM +0000, Saso Kiselkov wrote:
>> On 2/5/14, 1:09 PM, Mayuresh Kathe wrote:
>>> hi,
>>>
>>> i have been trying to download the r151008 iso since afternoon.
>>> fails after downloading around 120mb.
>>>
>>> this has happened thrice.
>>> and inspite of using 'wget -c' it fails to restart.
>>>
>>> is there any problem with the omniti network connectivity?
>>> have successfully downloaded crux linux after that.
>>
>> Works for me.
> 
> yeah, worked at my end too, done in less than 40 minutes.
> strange...

I guess it would be kind of nice if the OmniTI would publish torrents,
so that the community can help out with the traffic situation, or at
least have it work as a back up.

-- 
Saso


From moo at wuffers.net  Wed Feb  5 19:59:10 2014
From: moo at wuffers.net (wuffers)
Date: Wed, 5 Feb 2014 14:59:10 -0500
Subject: [OmniOS-discuss] Supermicro IPMI based BIOS update
In-Reply-To: <03f401cf0e75$faf5d0d0$f0e17270$@acm.org>
References: <094801cef550$b5cc58a0$216509e0$@acm.org>
	<CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>
	<03f401cf0e75$faf5d0d0$f0e17270$@acm.org>
Message-ID: <CA+tR_Kz92PRPgcuN2waxuGifNPD=sOXcy0ZLqihr2xtimyfzsw@mail.gmail.com>

On Fri, Jan 10, 2014 at 9:36 PM, Paul B. Henson <henson at acm.org> wrote:

> Did you ever get a response? So far I have still been unable to find a
> source for purchasing these "IPMI BIOS update" license keys...
>

Sorry, hadn't gotten a response and had to push my reseller again for some
updated information which I finally got, hence the late reply.

The part number you are looking for is "SFT-OOB-LIC", which seems to be
~$20 per node (or motherboard).

And yes, it's somehow tied to the serial number or BMC MAC of the server,
so you can't just buy one activation key and use it on multiple servers.
It's all part of their "value-add" Server Management Utilities (
http://www.supermicro.com/products/nfo/files/SSM/SSM_brochure.pdf).

I guess in the end, it's up to the vendor to determine what's "essential"
or not in their base offerings. I mean, HP charges for "remote graphical
access" on their Advanced iLO licenses..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140205/58dbd7a7/attachment.html>

From henson at acm.org  Wed Feb  5 20:23:34 2014
From: henson at acm.org (Paul B. Henson)
Date: Wed, 5 Feb 2014 12:23:34 -0800
Subject: [OmniOS-discuss] Supermicro IPMI based BIOS update
In-Reply-To: <CA+tR_Kz92PRPgcuN2waxuGifNPD=sOXcy0ZLqihr2xtimyfzsw@mail.gmail.com>
References: <094801cef550$b5cc58a0$216509e0$@acm.org>	<CA+tR_KyQD=6RYkgcChhixoMF36Oi7Uk9koaj4H-YHrsZ57igzQ@mail.gmail.com>	<03f401cf0e75$faf5d0d0$f0e17270$@acm.org>
	<CA+tR_Kz92PRPgcuN2waxuGifNPD=sOXcy0ZLqihr2xtimyfzsw@mail.gmail.com>
Message-ID: <0a3a01cf22b0$27f4d920$77de8b60$@acm.org>

> From: wuffers> Sent: Wednesday, February 05, 2014 11:59 AM
> To: Paul B. Henson
>
> Sorry, hadn't gotten a response and had to push my reseller again for some
> updated information which I finally got, hence the late reply.
> 
> The part number you are looking for is "SFT-OOB-LIC", which seems to be
> ~$20 per node (or motherboard).

Thanks; I had actually finally gotten the same information out of Supermicro
a couple of weeks ago. I tried ordering one of these from CDW, they let me
put it in the shopping cart and pay for it, but after two weeks I still
hadn't actually gotten an activation key. Multiple voicemail messages and
emails to the account representative listed on the invoice yielded nothing,
I finally ended up canceling the order after two weeks.

Maybe it's just not meant for low volume customers 8-/...



From geoffn at gnaa.net  Thu Feb  6 00:00:18 2014
From: geoffn at gnaa.net (Geoff Nordli)
Date: Wed, 05 Feb 2014 16:00:18 -0800
Subject: [OmniOS-discuss] java can't find libjli.so on OmniOS v11 r151008 --
	workaround
Message-ID: <52F2D092.5020403@gnaa.net>

I know very little about Java, so not sure exactly if there are more 
things that need to get done in order to fix it, but here is a workaround.

I installed the package:  pkg install java

pkg info java
         Name: runtime/java
        Summary: Open-source implementation of the seventh edition of 
the Java SE Platform
          State: Installed
      Publisher: omnios
        Version: 0.5.11 (jdk7u21-b30)
  Build Release: 5.11
         Branch: 0.151008
Packaging Date:  4 December, 2013 08:10:13 PM
           Size: 105.29 MB
           FMRI: 
pkg://omnios/runtime/java at 0.5.11,5.11-0.151008:20131204T201013Z

For whatever reason java couldn't find a library.

  /usr/bin/java -v
ld.so.1: java: fatal: libjli.so: open failed: No such file or directory
Killed

ldd /usr/bin/java
         libthread.so.1 =>        /lib/libthread.so.1
         libjli.so =>     (file not found)
         libdl.so.1 =>    /lib/libdl.so.1
         libc.so.1 =>     /lib/libc.so.1
         libm.so.2 =>     /lib/libm.so.2

So I ended up doing:

cd /usr/lib/

ln -s /usr/java/jre/lib/i386/jli/libjli.so


and we are good......

/usr/bin/java -version
openjdk version "1.7.0_21"
OpenJDK Runtime Environment (build 1.7.0_21-b30)
OpenJDK Server VM (build 24.60-b03, mixed mode)




Geoff


From mayuresh at kathe.in  Thu Feb  6 06:30:24 2014
From: mayuresh at kathe.in (Mayuresh Kathe)
Date: Thu, 6 Feb 2014 06:30:24 +0000
Subject: [OmniOS-discuss] java can't find libjli.so on OmniOS v11
 r151008 -- workaround
In-Reply-To: <52F2D092.5020403@gnaa.net>
References: <52F2D092.5020403@gnaa.net>
Message-ID: <20140206063022.GA22816@SDF.ORG>

hey, doesn't java come pre-installed with omnios-r151008j?
i just installed jdk and it didn't even touch java packages
for installation.

~mayuresh

On Wed, Feb 05, 2014 at 04:00:18PM -0800, Geoff Nordli wrote:
> I know very little about Java, so not sure exactly if there are more
> things that need to get done in order to fix it, but here is a
> workaround.
> 
> I installed the package:  pkg install java
> 
> pkg info java
>         Name: runtime/java
>        Summary: Open-source implementation of the seventh edition of
> the Java SE Platform
>          State: Installed
>      Publisher: omnios
>        Version: 0.5.11 (jdk7u21-b30)
>  Build Release: 5.11
>         Branch: 0.151008
> Packaging Date:  4 December, 2013 08:10:13 PM
>           Size: 105.29 MB
>           FMRI:
> pkg://omnios/runtime/java at 0.5.11,5.11-0.151008:20131204T201013Z
> 
> For whatever reason java couldn't find a library.
> 
>  /usr/bin/java -v
> ld.so.1: java: fatal: libjli.so: open failed: No such file or directory
> Killed
> 
> ldd /usr/bin/java
>         libthread.so.1 =>        /lib/libthread.so.1
>         libjli.so =>     (file not found)
>         libdl.so.1 =>    /lib/libdl.so.1
>         libc.so.1 =>     /lib/libc.so.1
>         libm.so.2 =>     /lib/libm.so.2
> 
> So I ended up doing:
> 
> cd /usr/lib/
> 
> ln -s /usr/java/jre/lib/i386/jli/libjli.so
> 
> 
> and we are good......
> 
> /usr/bin/java -version
> openjdk version "1.7.0_21"
> OpenJDK Runtime Environment (build 1.7.0_21-b30)
> OpenJDK Server VM (build 24.60-b03, mixed mode)
> 
> 
> 
> 
> Geoff
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From omniti at familyk.org  Fri Feb  7 17:14:07 2014
From: omniti at familyk.org (Willard Korfhage)
Date: Fri, 07 Feb 2014 11:14:07 -0600
Subject: [OmniOS-discuss] Warning that partition is too large when mirroring
 identical disks in root pool
Message-ID: <52F5145F.4060005@familyk.org>

I just installed OmniOS r151008j last night, and today I wanted to 
mirror rpool, but have a warning about the disk size. I have 2 Seagate 
1TB disks (model ST1000LM024HN), and my OmniOS install is on one of 
them. I told the install to use the whole disk. Some version of 
OpenIndiana was previously installed on the disk. The install went 
without any problem.

c2t0d0 is the disk with OmniOS
c2t1d0 is supposed to be its mirror

To do the mirroring, following the directions in the wiki, I did

root at s1:~# pfexec fdisk -B c2t1d0p0
root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s - 
/dev/rdsk/c2t1d0s2
fmthard: Partition 2 specifies the full disk and is not equal
full size of disk. The full disk capacity is 1953407610 sectors.
fmthard: Partition 2 specified as 1953471870 sectors starting at 0
  does not fit. The full disk contains 1953407610 sectors.
fmthard: New volume table of contents now in place.

At this point I stopped, and haven't done the mirror.

For the disk with the install, format reports

Current Disk = c2t0d0
<ATA-ST1000LM024HN-M-0001 cyl 60797 alt 2 hd 255 sec 126>
/pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0

and further information is

root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2
* /dev/rdsk/c2t0d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*     126 sectors/track
*     255 tracks/cylinder
*   32130 sectors/cylinder
*   60799 cylinders
*   60797 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector
*           0     32130     32129
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
        0      2    00      32130 1953375480 1953407609
        2      5    01          0 1953471870 1953471869
        8      1    01          0     32130     32129

Any idea what is going on?

I tried to format the disk without the install (c2t1d0), just to start 
with a completely fresh disk, but it doesn't work. This appears to be a 
long-standing (11-month old) Illumos bug 
(https://www.illumos.org/issues/3610)



From protonwrangler at gmail.com  Fri Feb  7 17:54:01 2014
From: protonwrangler at gmail.com (Warren Marts)
Date: Fri, 7 Feb 2014 10:54:01 -0700
Subject: [OmniOS-discuss] Warning that partition is too large when
 mirroring identical disks in root pool
In-Reply-To: <52F5145F.4060005@familyk.org>
References: <52F5145F.4060005@familyk.org>
Message-ID: <CAN8fiVu+HhU3o8sVsOSOyL09fxNn_ZKh5=zpbaP20i3XdCFUwg@mail.gmail.com>

This may be a genuine mismatch between the disks.

A few weeks ago I was trying to image between two apparently identical
Western Digital RE2 400GB drives. They were produced on the same day and
their serial numbers were only ~200 apart, but the disk utility reported
block counts that differed by about 20,000 (10 MB) and neither count
matched the one on the disk label.

I was surprised, to say the least.


On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage <omniti at familyk.org>wrote:

> I just installed OmniOS r151008j last night, and today I wanted to mirror
> rpool, but have a warning about the disk size. I have 2 Seagate 1TB disks
> (model ST1000LM024HN), and my OmniOS install is on one of them. I told the
> install to use the whole disk. Some version of OpenIndiana was previously
> installed on the disk. The install went without any problem.
>
> c2t0d0 is the disk with OmniOS
> c2t1d0 is supposed to be its mirror
>
> To do the mirroring, following the directions in the wiki, I did
>
> root at s1:~# pfexec fdisk -B c2t1d0p0
> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s -
> /dev/rdsk/c2t1d0s2
> fmthard: Partition 2 specifies the full disk and is not equal
> full size of disk. The full disk capacity is 1953407610 sectors.
> fmthard: Partition 2 specified as 1953471870 sectors starting at 0
>  does not fit. The full disk contains 1953407610 sectors.
> fmthard: New volume table of contents now in place.
>
> At this point I stopped, and haven't done the mirror.
>
> For the disk with the install, format reports
>
> Current Disk = c2t0d0
> <ATA-ST1000LM024HN-M-0001 cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0
>
> and further information is
>
> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2
> * /dev/rdsk/c2t0d0s2 partition map
> *
> * Dimensions:
> *     512 bytes/sector
> *     126 sectors/track
> *     255 tracks/cylinder
> *   32130 sectors/cylinder
> *   60799 cylinders
> *   60797 accessible cylinders
> *
> * Flags:
> *   1: unmountable
> *  10: read-only
> *
> * Unallocated space:
> *       First     Sector    Last
> *       Sector     Count    Sector
> *           0     32130     32129
> *
> *                          First     Sector    Last
> * Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
>        0      2    00      32130 1953375480 1953407609
>        2      5    01          0 1953471870 1953471869
>        8      1    01          0     32130     32129
>
> Any idea what is going on?
>
> I tried to format the disk without the install (c2t1d0), just to start
> with a completely fresh disk, but it doesn't work. This appears to be a
> long-standing (11-month old) Illumos bug (https://www.illumos.org/
> issues/3610)
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140207/84ef252f/attachment.html>

From bfriesen at simple.dallas.tx.us  Sat Feb  8 00:06:38 2014
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Fri, 7 Feb 2014 18:06:38 -0600 (CST)
Subject: [OmniOS-discuss] Warning that partition is too large when
 mirroring identical disks in root pool
In-Reply-To: <52F5145F.4060005@familyk.org>
References: <52F5145F.4060005@familyk.org>
Message-ID: <alpine.GSO.2.01.1402071803020.22695@freddy.simplesystems.org>

On Fri, 7 Feb 2014, Willard Korfhage wrote:
>
> At this point I stopped, and haven't done the mirror.

There is some possibility that the mirror will still work.  Due to 
problems like this, zfs leaves some spare unused space.  This might 
only apply to the case where zfs does the partitioning though (i.e. 
not for rpool).

You can try initating the mirror and see if there is a failure.  Zfs 
puts a marker toward the end of the partition so it will know if there 
is a problem.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

From omniti at familyk.org  Sat Feb  8 06:21:53 2014
From: omniti at familyk.org (Willard Korfhage)
Date: Sat, 08 Feb 2014 00:21:53 -0600
Subject: [OmniOS-discuss] Warning that partition is too large when
 mirroring identical disks in root pool
In-Reply-To: <CAN8fiVu+HhU3o8sVsOSOyL09fxNn_ZKh5=zpbaP20i3XdCFUwg@mail.gmail.com>
References: <52F5145F.4060005@familyk.org>
	<CAN8fiVu+HhU3o8sVsOSOyL09fxNn_ZKh5=zpbaP20i3XdCFUwg@mail.gmail.com>
Message-ID: <52F5CD01.9020500@familyk.org>

That could happen, depending on how many bad blocks the disk has, but in 
this case, the numbers it reports, the numbers it says are inconsistent, 
are from the original OmniOS install. I am surprised that the original 
install would generate an inconsistent partition arrangement.

Now if I could just figure out how to format the disk, I could try 
starting from scratch. Given the Illumos bug, I suppose I'll have to 
pull it and format it on another machine.

On 2/7/2014 11:54 AM, Warren Marts wrote:
> This may be a genuine mismatch between the disks.
>
> A few weeks ago I was trying to image between two apparently identical 
> Western Digital RE2 400GB drives. They were produced on the same day 
> and their serial numbers were only ~200 apart, but the disk utility 
> reported block counts that differed by about 20,000 (10 MB) and 
> neither count matched the one on the disk label.
>
> I was surprised, to say the least.
>
>
> On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage <omniti at familyk.org 
> <mailto:omniti at familyk.org>> wrote:
>
>     I just installed OmniOS r151008j last night, and today I wanted to
>     mirror rpool, but have a warning about the disk size. I have 2
>     Seagate 1TB disks (model ST1000LM024HN), and my OmniOS install is
>     on one of them. I told the install to use the whole disk. Some
>     version of OpenIndiana was previously installed on the disk. The
>     install went without any problem.
>
>     c2t0d0 is the disk with OmniOS
>     c2t1d0 is supposed to be its mirror
>
>     To do the mirroring, following the directions in the wiki, I did
>
>     root at s1:~# pfexec fdisk -B c2t1d0p0
>     root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s -
>     /dev/rdsk/c2t1d0s2
>     fmthard: Partition 2 specifies the full disk and is not equal
>     full size of disk. The full disk capacity is 1953407610 sectors.
>     fmthard: Partition 2 specified as 1953471870 sectors starting at 0
>      does not fit. The full disk contains 1953407610 sectors.
>     fmthard: New volume table of contents now in place.
>
>     At this point I stopped, and haven't done the mirror.
>
>     For the disk with the install, format reports
>
>     Current Disk = c2t0d0
>     <ATA-ST1000LM024HN-M-0001 cyl 60797 alt 2 hd 255 sec 126>
>     /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0
>
>     and further information is
>
>     root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2
>     * /dev/rdsk/c2t0d0s2 partition map
>     *
>     * Dimensions:
>     *     512 bytes/sector
>     *     126 sectors/track
>     *     255 tracks/cylinder
>     *   32130 sectors/cylinder
>     *   60799 cylinders
>     *   60797 accessible cylinders
>     *
>     * Flags:
>     *   1: unmountable
>     *  10: read-only
>     *
>     * Unallocated space:
>     *       First     Sector    Last
>     *       Sector     Count    Sector
>     *           0     32130     32129
>     *
>     *                          First     Sector    Last
>     * Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
>            0      2    00      32130 1953375480 1953407609
>            2      5    01          0 1953471870 1953471869
>            8      1    01          0     32130     32129
>
>     Any idea what is going on?
>
>     I tried to format the disk without the install (c2t1d0), just to
>     start with a completely fresh disk, but it doesn't work. This
>     appears to be a long-standing (11-month old) Illumos bug
>     (https://www.illumos.org/issues/3610)
>
>
>     _______________________________________________
>     OmniOS-discuss mailing list
>     OmniOS-discuss at lists.omniti.com
>     <mailto:OmniOS-discuss at lists.omniti.com>
>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140208/4c15a8a8/attachment.html>

From mayuresh at kathe.in  Sat Feb  8 11:18:30 2014
From: mayuresh at kathe.in (Mayuresh Kathe)
Date: Sat, 8 Feb 2014 16:48:30 +0530
Subject: [OmniOS-discuss] building our own packages : suggested prefix?
Message-ID: <20140208111830.GA7220@h61m>

hello, would anyone with custom software building for omnios
be able to suggest the usual value for "--prefix" variable
to "./configure"?
to test things out, i have installed everything within my
home directory, which has created a bunch of directories which
kind-a looks messy.  :)

i have been building and playing with lynx, mutt and ircii.

thanks,

~mayuresh


From ben at fluffy.co.uk  Sat Feb  8 16:00:21 2014
From: ben at fluffy.co.uk (Ben Summers)
Date: Sat, 8 Feb 2014 16:00:21 +0000
Subject: [OmniOS-discuss] publisher signature-policy=require-signatures for
	new zones
Message-ID: <3A7AF9D2-AB1E-492A-B18B-C36A86C91E3F@fluffy.co.uk>


Hello,

r151008 now includes signed packages, but the default signature-policy is verify, so it's still vulnerable to MITM if the attacker simply removes the signatures from the manifests.

I can run

   pkg set-publisher --set-property signature-policy=require-signatures omnios

immediately after install from the iso to make sure any updates in the global zone are properly checked.

However, when I install a zone, the zone's signature-policy is the default of verify. pkg downloads files from the IPS server, so anything in the zone's image is vulnerable.

Is it possible to specify signature-policy=require-signatures for new zones in the initial configuration?

Thanks,

Ben




From tim at multitalents.net  Sat Feb  8 19:10:52 2014
From: tim at multitalents.net (Tim Rice)
Date: Sat, 8 Feb 2014 11:10:52 -0800 (PST)
Subject: [OmniOS-discuss] building our own packages : suggested prefix?
In-Reply-To: <20140208111830.GA7220@h61m>
References: <20140208111830.GA7220@h61m>
Message-ID: <Pine.UW2.4.64.1402081047560.32@server01.int.multitalents.net>

Mayuresh,

On Sat, 8 Feb 2014, Mayuresh Kathe wrote:

> hello, would anyone with custom software building for omnios
> be able to suggest the usual value for "--prefix" variable
> to "./configure"?

That would depend on whether you intend to build installable packages or
are just doing the equivalent of "configure ; make ; make install".
If you are not packaging up the code and are just doing a "make install",
the convention is to use /usr/local as the prefix.

If you intend to build a package installable with
"pkg install some_package_name", there are more things to consider.
If you intend to publish them for others to use, you will probably want
to choose some new directory in /opt. Perhaps /opt/mk.
If they are only used for systems you control, you may want to consider
something like 

PACKAGE=lynx
	./configure \
	--prefix=/opt                           \
	--sysconfdir=/etc/opt/${PACKAGE}        \
	--localstatedir=/var/opt/${PACKAGE}     \
	--mandir=/opt/man                       \
	--docdir=/opt/share/doc/packages/${PACKAGE}     \
	--htmldir=/opt/share/doc/packages/${PACKAGE}/html       \


> to test things out, i have installed everything within my
> home directory, which has created a bunch of directories which
> kind-a looks messy.  :)
> 
> i have been building and playing with lynx, mutt and ircii.
> 
> thanks,
> 
> ~mayuresh

-- 
Tim Rice				Multitalents
tim at multitalents.net



From peter.tribble at gmail.com  Sat Feb  8 21:10:39 2014
From: peter.tribble at gmail.com (Peter Tribble)
Date: Sat, 8 Feb 2014 21:10:39 +0000
Subject: [OmniOS-discuss] Warning that partition is too large when
 mirroring identical disks in root pool
In-Reply-To: <52F5CD01.9020500@familyk.org>
References: <52F5145F.4060005@familyk.org>
	<CAN8fiVu+HhU3o8sVsOSOyL09fxNn_ZKh5=zpbaP20i3XdCFUwg@mail.gmail.com>
	<52F5CD01.9020500@familyk.org>
Message-ID: <CAEgYsbG4qpst02mXBo6a6M5C4YhKn1VA_ASpvsVwVn=CZjoy_A@mail.gmail.com>

On Sat, Feb 8, 2014 at 6:21 AM, Willard Korfhage <omniti at familyk.org> wrote:

>  That could happen, depending on how many bad blocks the disk has, but in
> this case, the numbers it reports, the numbers it says are inconsistent,
> are from the original OmniOS install. I am surprised that the original
> install would generate an inconsistent partition arrangement.
>

Why do you think that? What the error you've given is saying is that
the size of the Solaris partition on the new disk is smaller than the
size of the Solaris partition on the original disk. That's all.


> Now if I could just figure out how to format the disk, I could try
> starting from scratch. Given the Illumos bug, I suppose I'll have to pull
> it and format it on another machine.
>

I can't see where that bug comes into play. The need to do a low-level
format of a drive is extremely rare.

I see these discrepancies fairly frequently when fdisk gets out of whack.
Most commonly, because some drives have a diagnostic partition on them,
but sometimes because it can't decide whether to start at cylinder 0 or 1.
Or just because the drives were partitioned up on different OS versions.

Compare:

fdisk -W - /dev/rdsk/c2t0d0p0
fdisk -W - /dev/rdsk/c2t1d0p0

If the fdisk dimensions do actually match, then you could save
out the fdisk table off the first disk and load it onto the second,
something like:

fdisk -W /tmp/fmap /dev/rdsk/c2t0d0p0
fdisk -F /tmp/fmap /dev/rdsk/c2t1d0p0

and then do the ptrtvtoc|fmthard step.

If you look at the sizes reported, specifically:

*   32130 sectors/cylinder
*   60799 cylinders
*   60797 accessible cylinders

and

*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00      32130 1953375480 1953407609
       2      5    01          0 1953471870 1953471869
       8      1    01          0     32130     32129

then it's allocated slice 0 up to the end of the 60797 accessible
cylinders, but slice 2 (which refers to the whole disk) is 64260
sectors or 2 cylinders longer, filling out to the end of 60799.
The second disk you have is reporting a size of 1953407610
sectors, or 0-1953407609, or 32130*60797, so it's just picked
up the accessible cylinders. The disks appear to be the same
size, it's those 2 inaccessible cylinders that are confusing matters.

If the fdisk dimensions are different (the second disk only appears
to really be 60797 sectors) then it's still not a problem, as all you're
interested in is slice 0, which is the right size. Simplest way to do
that is to grep out the line in the prtvtoc output for partition 2, and
fmthard will fill it in automatically at whatever size it thinks is correct.


On 2/7/2014 11:54 AM, Warren Marts wrote:
>
> This may be a genuine mismatch between the disks.
>
>  A few weeks ago I was trying to image between two apparently identical
> Western Digital RE2 400GB drives. They were produced on the same day and
> their serial numbers were only ~200 apart, but the disk utility reported
> block counts that differed by about 20,000 (10 MB) and neither count
> matched the one on the disk label.
>
>  I was surprised, to say the least.
>
>
> On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage <omniti at familyk.org>wrote:
>
>> I just installed OmniOS r151008j last night, and today I wanted to mirror
>> rpool, but have a warning about the disk size. I have 2 Seagate 1TB disks
>> (model ST1000LM024HN), and my OmniOS install is on one of them. I told the
>> install to use the whole disk. Some version of OpenIndiana was previously
>> installed on the disk. The install went without any problem.
>>
>> c2t0d0 is the disk with OmniOS
>> c2t1d0 is supposed to be its mirror
>>
>> To do the mirroring, following the directions in the wiki, I did
>>
>> root at s1:~# pfexec fdisk -B c2t1d0p0
>> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard -s -
>> /dev/rdsk/c2t1d0s2
>> fmthard: Partition 2 specifies the full disk and is not equal
>> full size of disk. The full disk capacity is 1953407610 sectors.
>> fmthard: Partition 2 specified as 1953471870 sectors starting at 0
>>  does not fit. The full disk contains 1953407610 sectors.
>> fmthard: New volume table of contents now in place.
>>
>>
>> At this point I stopped, and haven't done the mirror.
>>
>> For the disk with the install, format reports
>>
>> Current Disk = c2t0d0
>> <ATA-ST1000LM024HN-M-0001 cyl 60797 alt 2 hd 255 sec 126>
>> /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0
>>
>> and further information is
>>
>> root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2
>> * /dev/rdsk/c2t0d0s2 partition map
>> *
>> * Dimensions:
>> *     512 bytes/sector
>> *     126 sectors/track
>> *     255 tracks/cylinder
>> *   32130 sectors/cylinder
>> *   60799 cylinders
>> *   60797 accessible cylinders
>> *
>> * Flags:
>> *   1: unmountable
>> *  10: read-only
>> *
>> * Unallocated space:
>> *       First     Sector    Last
>> *       Sector     Count    Sector
>> *           0     32130     32129
>> *
>> *                          First     Sector    Last
>> * Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
>>        0      2    00      32130 1953375480 1953407609
>>        2      5    01          0 1953471870 1953471869
>>        8      1    01          0     32130     32129
>>
>> Any idea what is going on?
>>
>> I tried to format the disk without the install (c2t1d0), just to start
>> with a completely fresh disk, but it doesn't work. This appears to be a
>> long-standing (11-month old) Illumos bug (
>> https://www.illumos.org/issues/3610)
>>
>>
>>
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>


-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140208/1f45dd7f/attachment.html>

From mayuresh at kathe.in  Sun Feb  9 02:47:45 2014
From: mayuresh at kathe.in (Mayuresh Kathe)
Date: Sun, 9 Feb 2014 08:17:45 +0530
Subject: [OmniOS-discuss] building our own packages : suggested prefix?
In-Reply-To: <Pine.UW2.4.64.1402081047560.32@server01.int.multitalents.net>
References: <20140208111830.GA7220@h61m>
	<Pine.UW2.4.64.1402081047560.32@server01.int.multitalents.net>
Message-ID: <20140209024744.GA9374@h61m>

On Sat, Feb 08, 2014 at 11:10:52AM -0800, Tim Rice wrote:
> Mayuresh,
> 
> On Sat, 8 Feb 2014, Mayuresh Kathe wrote:
> 
> > hello, would anyone with custom software building for omnios
> > be able to suggest the usual value for "--prefix" variable
> > to "./configure"?
> That would depend on whether you intend to build installable packages or
> are just doing the equivalent of "configure ; make ; make install".
> If you are not packaging up the code and are just doing a "make install",
> the convention is to use /usr/local as the prefix.

tim, thanks for that tip, stuff installed and works like a charm.
there's just one hitch though, how do i suggest to omnios to also
use /usr/local/man as a directory for man pages?

i did hunt for man.conf in /etc, found nothing.

> If you intend to build a package installable with
> "pkg install some_package_name", there are more things to consider.
> If you intend to publish them for others to use, you will probably want
> to choose some new directory in /opt. Perhaps /opt/mk.
> If they are only used for systems you control, you may want to consider
> something like 

i don't have the resources to put up my own repository.
is there a way i could work with someone having a repository to put up a
bunch of packages which might be useful for general work like mail, www,
irc, etc.
 
thanks,

~mayuresh


From tim at multitalents.net  Sun Feb  9 03:31:49 2014
From: tim at multitalents.net (Tim Rice)
Date: Sat, 8 Feb 2014 19:31:49 -0800 (PST)
Subject: [OmniOS-discuss] building our own packages : suggested prefix?
In-Reply-To: <20140209024744.GA9374@h61m>
References: <20140208111830.GA7220@h61m>
	<Pine.UW2.4.64.1402081047560.32@server01.int.multitalents.net>
	<20140209024744.GA9374@h61m>
Message-ID: <Pine.UW2.4.64.1402081928460.2262@server01.int.multitalents.net>

On Sun, 9 Feb 2014, Mayuresh Kathe wrote:

> tim, thanks for that tip, stuff installed and works like a charm.
> there's just one hitch though, how do i suggest to omnios to also
> use /usr/local/man as a directory for man pages?

Try
MANPATH=/usr/share/man:/usr/local/man ; export MANPATH


-- 
Tim Rice				Multitalents
tim at multitalents.net



From mayuresh at kathe.in  Sun Feb  9 03:48:17 2014
From: mayuresh at kathe.in (Mayuresh Kathe)
Date: Sun, 9 Feb 2014 09:18:17 +0530
Subject: [OmniOS-discuss] building our own packages : suggested prefix?
In-Reply-To: <Pine.UW2.4.64.1402081928460.2262@server01.int.multitalents.net>
References: <20140208111830.GA7220@h61m>
	<Pine.UW2.4.64.1402081047560.32@server01.int.multitalents.net>
	<20140209024744.GA9374@h61m>
	<Pine.UW2.4.64.1402081928460.2262@server01.int.multitalents.net>
Message-ID: <20140209034817.GA731@h61m>

On Sat, Feb 08, 2014 at 07:31:49PM -0800, Tim Rice wrote:
> On Sun, 9 Feb 2014, Mayuresh Kathe wrote:
> 
> > tim, thanks for that tip, stuff installed and works like a charm.
> > there's just one hitch though, how do i suggest to omnios to also
> > use /usr/local/man as a directory for man pages?
> 
> Try
> MANPATH=/usr/share/man:/usr/local/man ; export MANPATH

perfect. works like a charm. thanks a million.  :)

~mayuresh


From omniti at familyk.org  Sun Feb  9 05:07:33 2014
From: omniti at familyk.org (Willard Korfhage)
Date: Sat, 08 Feb 2014 23:07:33 -0600
Subject: [OmniOS-discuss] Warning that partition is too large when
 mirroring identical disks in root pool
In-Reply-To: <CAEgYsbG4qpst02mXBo6a6M5C4YhKn1VA_ASpvsVwVn=CZjoy_A@mail.gmail.com>
References: <52F5145F.4060005@familyk.org>	<CAN8fiVu+HhU3o8sVsOSOyL09fxNn_ZKh5=zpbaP20i3XdCFUwg@mail.gmail.com>	<52F5CD01.9020500@familyk.org>
	<CAEgYsbG4qpst02mXBo6a6M5C4YhKn1VA_ASpvsVwVn=CZjoy_A@mail.gmail.com>
Message-ID: <52F70D15.4010109@familyk.org>

Thanks for the explanation of the discrepancy.

The output of the fdisk -W commands is identical for both disks, as I 
would expect, and the vtoc is identical on both disks, too.

I think I misinterpreted the intent of the message from fmthard. I was 
concerned that it meant "the vtoc doesn't make sense, but I am copying 
it to the disk, anyway," leaving me with a disk in a bad state. Instead 
it appears to have been more of a "fixed that for you" message, and the 
disk is fine, with all the dimensions matching on both disks. I will 
continue with the mirroring.

On 2/8/2014 3:10 PM, Peter Tribble wrote:
> On Sat, Feb 8, 2014 at 6:21 AM, Willard Korfhage <omniti at familyk.org 
> <mailto:omniti at familyk.org>> wrote:
>
>     That could happen, depending on how many bad blocks the disk has,
>     but in this case, the numbers it reports, the numbers it says are
>     inconsistent, are from the original OmniOS install. I am surprised
>     that the original install would generate an inconsistent partition
>     arrangement.
>
>
> Why do you think that? What the error you've given is saying is that
> the size of the Solaris partition on the new disk is smaller than the
> size of the Solaris partition on the original disk. That's all.
>
>     Now if I could just figure out how to format the disk, I could try
>     starting from scratch. Given the Illumos bug, I suppose I'll have
>     to pull it and format it on another machine.
>
>
> I can't see where that bug comes into play. The need to do a low-level
> format of a drive is extremely rare.
>
> I see these discrepancies fairly frequently when fdisk gets out of whack.
> Most commonly, because some drives have a diagnostic partition on them,
> but sometimes because it can't decide whether to start at cylinder 0 or 1.
> Or just because the drives were partitioned up on different OS versions.
>
> Compare:
>
> fdisk -W - /dev/rdsk/c2t0d0p0
> fdisk -W - /dev/rdsk/c2t1d0p0
>
> If the fdisk dimensions do actually match, then you could save
> out the fdisk table off the first disk and load it onto the second,
> something like:
>
> fdisk -W /tmp/fmap /dev/rdsk/c2t0d0p0
> fdisk -F /tmp/fmap /dev/rdsk/c2t1d0p0
>
> and then do the ptrtvtoc|fmthard step.
>
> If you look at the sizes reported, specifically:
>
> *   32130 sectors/cylinder
> *   60799 cylinders
> *   60797 accessible cylinders
>
> and
>
> *                          First     Sector    Last
> * Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
>        0      2    00      32130 1953375480 1953407609
>        2      5    01          0 1953471870 1953471869
>        8      1    01          0     32130     32129
>
> then it's allocated slice 0 up to the end of the 60797 accessible
> cylinders, but slice 2 (which refers to the whole disk) is 64260
> sectors or 2 cylinders longer, filling out to the end of 60799.
> The second disk you have is reporting a size of 1953407610
> sectors, or 0-1953407609, or 32130*60797, so it's just picked
> up the accessible cylinders. The disks appear to be the same
> size, it's those 2 inaccessible cylinders that are confusing matters.
>
> If the fdisk dimensions are different (the second disk only appears
> to really be 60797 sectors) then it's still not a problem, as all you're
> interested in is slice 0, which is the right size. Simplest way to do
> that is to grep out the line in the prtvtoc output for partition 2, and
> fmthard will fill it in automatically at whatever size it thinks is 
> correct.
>
>
>     On 2/7/2014 11:54 AM, Warren Marts wrote:
>>     This may be a genuine mismatch between the disks.
>>
>>     A few weeks ago I was trying to image between two apparently
>>     identical Western Digital RE2 400GB drives. They were produced on
>>     the same day and their serial numbers were only ~200 apart, but
>>     the disk utility reported block counts that differed by about
>>     20,000 (10 MB) and neither count matched the one on the disk label.
>>
>>     I was surprised, to say the least.
>>
>>
>>     On Fri, Feb 7, 2014 at 10:14 AM, Willard Korfhage
>>     <omniti at familyk.org <mailto:omniti at familyk.org>> wrote:
>>
>>         I just installed OmniOS r151008j last night, and today I
>>         wanted to mirror rpool, but have a warning about the disk
>>         size. I have 2 Seagate 1TB disks (model ST1000LM024HN), and
>>         my OmniOS install is on one of them. I told the install to
>>         use the whole disk. Some version of OpenIndiana was
>>         previously installed on the disk. The install went without
>>         any problem.
>>
>>         c2t0d0 is the disk with OmniOS
>>         c2t1d0 is supposed to be its mirror
>>
>>         To do the mirroring, following the directions in the wiki, I did
>>
>>         root at s1:~# pfexec fdisk -B c2t1d0p0
>>         root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2 | pfexec fmthard
>>         -s - /dev/rdsk/c2t1d0s2
>>         fmthard: Partition 2 specifies the full disk and is not equal
>>         full size of disk. The full disk capacity is 1953407610 sectors.
>>         fmthard: Partition 2 specified as 1953471870 sectors starting
>>         at 0
>>          does not fit. The full disk contains 1953407610 sectors.
>>         fmthard: New volume table of contents now in place.
>>
>>
>>         At this point I stopped, and haven't done the mirror.
>>
>>         For the disk with the install, format reports
>>
>>         Current Disk = c2t0d0
>>         <ATA-ST1000LM024HN-M-0001 cyl 60797 alt 2 hd 255 sec 126>
>>         /pci at 0,0/pci8086,1c02 at 1f,2/disk at 0,0
>>
>>         and further information is
>>
>>         root at s1:~# pfexec prtvtoc /dev/rdsk/c2t0d0s2
>>         * /dev/rdsk/c2t0d0s2 partition map
>>         *
>>         * Dimensions:
>>         *     512 bytes/sector
>>         *     126 sectors/track
>>         *     255 tracks/cylinder
>>         *   32130 sectors/cylinder
>>         *   60799 cylinders
>>         *   60797 accessible cylinders
>>         *
>>         * Flags:
>>         *   1: unmountable
>>         *  10: read-only
>>         *
>>         * Unallocated space:
>>         *       First     Sector    Last
>>         *       Sector     Count    Sector
>>         *           0     32130     32129
>>         *
>>         *                          First     Sector  Last
>>         * Partition  Tag  Flags    Sector     Count  Sector  Mount
>>         Directory
>>                0      2    00      32130 1953375480 1953407609
>>                2      5    01          0 1953471870 1953471869
>>                8      1    01          0     32130 32129
>>
>>         Any idea what is going on?
>>
>>         I tried to format the disk without the install (c2t1d0), just
>>         to start with a completely fresh disk, but it doesn't work.
>>         This appears to be a long-standing (11-month old) Illumos bug
>>         (https://www.illumos.org/issues/3610)
>>
>>
>>
>>         _______________________________________________
>>         OmniOS-discuss mailing list
>>         OmniOS-discuss at lists.omniti.com
>>         <mailto:OmniOS-discuss at lists.omniti.com>
>>         http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>
>
>     _______________________________________________
>     OmniOS-discuss mailing list
>     OmniOS-discuss at lists.omniti.com
>     <mailto:OmniOS-discuss at lists.omniti.com>
>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
>
> -- 
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140208/6d297368/attachment.html>

From omniti at familyk.org  Sun Feb  9 05:23:03 2014
From: omniti at familyk.org (Willard Korfhage)
Date: Sat, 08 Feb 2014 23:23:03 -0600
Subject: [OmniOS-discuss] An error on the VirtualMachinesKVM wiki page
Message-ID: <52F710B7.7010606@familyk.org>

On http://omnios.omniti.com/wiki.php/VirtualMachinesKVM, the start 
virtual machine script has an error in it.  The 5th line from the bottom is

public_nic=$(dladm show-vnic|grep vnic1|awk '{print $2}')

but that "vnic1" in the middle should really be ${VNIC}

Also, that "prepare a volume for the VM" section on the page, which 
currently contains only "TBD" can be as simple as a single command, such as

zfs create -p -V 10G tank/myvm/disk0

That worked for me, but I expect there are other ways of preparing the 
disk, too.

From franz.schober at firmos.at  Mon Feb 10 11:42:08 2014
From: franz.schober at firmos.at (Franz Schober)
Date: Mon, 10 Feb 2014 12:42:08 +0100
Subject: [OmniOS-discuss] Kernel panic on using iSCSI target on same host,
 differences between OmniOS r151006 and r151008 ?
Message-ID: <52F8BB10.3090207@firmos.at>

Hi,

when using a device provided by iSCSI COMSTAR target on the same host 
for a zpool, the system (OmniOS r151008j) raised a kernel panic
after a timeout of the COMSTAR device at the first try, on the second 
attempt it just did not work.

On OmniOS r151006y the same worked without any problems.

Are there any possible known changes on COMSTAR and ZFS regarding
this problem in between the two stable OmniOS versions ?

Details, why to do that anyway :-) and a crash dump are available at 
https://www.illumos.org/issues/4589

Thx a lot,
Franz

-- 

---------------------------------------------------------------------
Dipl.-Ing. Franz Schober
franz.schober at firmos.at
FirmOS Business Solutions Gmbh
Obstweg 4
A-8073 Graz-Neupirka
Tel +43 316 242322-10
Fax +43 316 242322-99
http://www.firmos.at
FN 278321x, Lg f?r ZRS Graz UID-Nr: ATU62657119

Dieses eMail ist vertraulich und nur f?r die genannten Empf?nger bestimmt. Sollten Sie nicht der gew?nschte Adressat sein, bitten wir Sie, uns umgehend zu informieren sowie vorliegende Nachricht zu l?schen ohne vorher einen Ausdruck oder eine Kopie anzufertigen.

This message and any attached files are confidential and intended solely for the adressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee(s) is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission.


From franz.schober at firmos.at  Mon Feb 10 15:41:25 2014
From: franz.schober at firmos.at (Franz Schober)
Date: Mon, 10 Feb 2014 16:41:25 +0100
Subject: [OmniOS-discuss] Kernel panic on using iSCSI target on same
 host, differences between OmniOS r151006 and r151008 ?
In-Reply-To: <52F8BB10.3090207@firmos.at>
References: <52F8BB10.3090207@firmos.at>
Message-ID: <52F8F325.1070405@firmos.at>

Although the creation of the zpool worked on OmniOS r151006y, the zfs 
send I wanted to test on the pool failed with a kernel panic on r151006y 
also.

zfs create test/testds
dd if=/dev/zero of=/test/testds/file1 bs=1M count=50
dd if=/dev/zero of=/test/testds/file2 bs=1M count=50

zfs snapshot test/testds at test
zfs send -R test/testds at test | pv > /dev/null
> Hi,
>
> when using a device provided by iSCSI COMSTAR target on the same host 
> for a zpool, the system (OmniOS r151008j) raised a kernel panic
> after a timeout of the COMSTAR device at the first try, on the second 
> attempt it just did not work.
>
> On OmniOS r151006y the same worked without any problems.
>
> Are there any possible known changes on COMSTAR and ZFS regarding
> this problem in between the two stable OmniOS versions ?
>
> Details, why to do that anyway :-) and a crash dump are available at 
> https://www.illumos.org/issues/4589
>
> Thx a lot,
> Franz
>


From thierry.bingen at haulogy.net  Mon Feb 10 18:59:42 2014
From: thierry.bingen at haulogy.net (Thierry Bingen)
Date: Mon, 10 Feb 2014 19:59:42 +0100
Subject: [OmniOS-discuss] A publisher for certutil ?
In-Reply-To: <mailman.1122.1377540896.5504.omnios-discuss@lists.omniti.com>
References: <mailman.1122.1377540896.5504.omnios-discuss@lists.omniti.com>
Message-ID: <262ABC7D-A1DC-4A8B-ABD3-6DB6989BE9C0@homeshore.be>

Does anyone publish a package containing NSS certutil ?

Thanks, 

Thierry

From cj.keist at colostate.edu  Mon Feb 10 22:55:13 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Mon, 10 Feb 2014 15:55:13 -0700
Subject: [OmniOS-discuss] LFS Support for Samba
Message-ID: <52F958D1.5060001@colostate.edu>

Hello,
    Trying to compile Samba 4.1.4 on OminOS 151.08j-r1.  running 
configure I get the following:

Checking getconf LFS_CFLAGS                : -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64
Checking getconf large file support flags work : not found
Checking for large file support without additional flags : not found
Checking for -D_FILE_OFFSET_BITS=64                      : not found
Checking for -D_LARGE_FILES                              : not found
Samba requires large file support support, but not available on this 
platform: sizeof(off_t) < 8

I have not been able to find anything searching the net on this issue. 
Any ideas?

I have gcc 4.8.1 installed.


-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

From jimklimov at cos.ru  Mon Feb 10 23:01:23 2014
From: jimklimov at cos.ru (Jim Klimov)
Date: Tue, 11 Feb 2014 00:01:23 +0100
Subject: [OmniOS-discuss] Shutdown/reboot hangs
In-Reply-To: <F89F7AF0-9A37-4B53-B70F-35E150017B3B@gmail.com>
References: <F89F7AF0-9A37-4B53-B70F-35E150017B3B@gmail.com>
Message-ID: <52F95A43.1070002@cos.ru>

On 2014-02-04 21:06, Mam Ruoc wrote:
> Hello,
>
> I have recently moved from ZFSguru to OmniOS and love it.
>
> I do have a "problem" though:
> When I reboot/shutdhown, the system seems to hang due to clients connected to samba and nfs shares.
> Is it possible to terminate these connects, so the system can shutdown/reboot without me pulling the physical plug?

Just to clarify: does this also hang on shutdown requests indeed,
or only on reboots? There is this feature called fastboot, which
essentially allows a running kernel to execute another kernel and
pass control to it, giving the effect of an OS restart without
the BIOS POST tests. However, on some hardware this procedure fails
and a full reboot is required (configurable via SMF, or done from
command line as "reboot -p").

Does this help? ;)
//Jim Klimov

From cj.keist at colostate.edu  Mon Feb 10 23:09:24 2014
From: cj.keist at colostate.edu (CJ Keist)
Date: Mon, 10 Feb 2014 16:09:24 -0700
Subject: [OmniOS-discuss] LFS Support for Samba
Message-ID: <52F95C24.2060602@colostate.edu>

Never mind,
    I was missing some developer packages: so along with gcc48 I 
installed the following. Not sure which package fixed the issue though.


pkg install pkg:/developer/versioning/git
pkg install pkg:/developer/build/gnu-make
pkg install pkg:/system/header

-------------------------------------

Hello,
    Trying to compile Samba 4.1.4 on OminOS 151.08j-r1.  running 
configure I get the following:

Checking getconf LFS_CFLAGS                : -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64
Checking getconf large file support flags work : not found
Checking for large file support without additional flags : not found
Checking for -D_FILE_OFFSET_BITS=64                      : not found
Checking for -D_LARGE_FILES                              : not found
Samba requires large file support support, but not available on this 
platform: sizeof(off_t) < 8

I have not been able to find anything searching the net on this issue. 
Any ideas?

I have gcc 4.8.1 installed.


-- 
C. J. Keist                     Email: cj.keist at colostate.edu
Systems Group Manager           Solaris 10 OS (SAI)
Engineering Network Services    Phone: 970-491-0630
College of Engineering, CSU     Fax:   970-491-5569
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

From danmcd at omniti.com  Mon Feb 10 23:19:15 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Mon, 10 Feb 2014 18:19:15 -0500
Subject: [OmniOS-discuss] LFS Support for Samba
In-Reply-To: <52F95C24.2060602@colostate.edu>
References: <52F95C24.2060602@colostate.edu>
Message-ID: <F893B585-7A4E-4DF1-80E1-99E1E6263CD5@omniti.com>


On Feb 10, 2014, at 6:09 PM, CJ Keist <cj.keist at colostate.edu> wrote:

> Never mind,
>   I was missing some developer packages: so along with gcc48 I installed the following. Not sure which package fixed the issue though.

<SNIP!>

> pkg install pkg:/system/header

Likely that one.

Dan



From ben at fluffy.co.uk  Tue Feb 11 16:22:38 2014
From: ben at fluffy.co.uk (Ben Summers)
Date: Tue, 11 Feb 2014 16:22:38 +0000
Subject: [OmniOS-discuss] publisher signature-policy=require-signatures
	for new zones
In-Reply-To: <3A7AF9D2-AB1E-492A-B18B-C36A86C91E3F@fluffy.co.uk>
References: <3A7AF9D2-AB1E-492A-B18B-C36A86C91E3F@fluffy.co.uk>
Message-ID: <3E9ABD4B-9752-4BD4-8AE8-BCEFCA4143BD@fluffy.co.uk>


Replying to my own email for the archives...

It appears you can't do this. pkg is hard coded to use "verify" as the signature-policy.

The workaround is to install the zone and before booting,

  pfexec pkg -R /path/to/zone/root set-publisher --set-property signature-policy=require-signatures omnios

to set the property, then

  pfexec pkg -R /path/to/zone/root fix

to check all the signatures and correct any errors.

Ben





On 8 Feb 2014, at 16:00, Ben Summers <ben at fluffy.co.uk> wrote:

> 
> Hello,
> 
> r151008 now includes signed packages, but the default signature-policy is verify, so it's still vulnerable to MITM if the attacker simply removes the signatures from the manifests.
> 
> I can run
> 
>   pkg set-publisher --set-property signature-policy=require-signatures omnios
> 
> immediately after install from the iso to make sure any updates in the global zone are properly checked.
> 
> However, when I install a zone, the zone's signature-policy is the default of verify. pkg downloads files from the IPS server, so anything in the zone's image is vulnerable.
> 
> Is it possible to specify signature-policy=require-signatures for new zones in the initial configuration?
> 
> Thanks,
> 
> Ben
> 
> 
> 


From ben.summers at oneis.co.uk  Tue Feb 11 16:25:19 2014
From: ben.summers at oneis.co.uk (Ben Summers)
Date: Tue, 11 Feb 2014 16:25:19 +0000
Subject: [OmniOS-discuss] Packages without signatures in r151008j
Message-ID: <C0E263C7-D9DE-4407-B29E-E439697379F7@oneis.co.uk>


Installing r151008j and running pkg verify with signature-policy=require-signatures shows the updated packages aren't signed:

Verifying: pkg://omnios/library/security/openssl                ERROR          
		The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/library/security/openssl at 1.0.1.6,5.11-0.151008:20140110T173804Z.
Verifying: pkg://omnios/package/pkg                             ERROR          
		The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/package/pkg at 0.5.11,5.11-0.151008:20131230T201906Z.
Verifying: pkg://omnios/system/zones/brand/ipkg                 ERROR          
		The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/system/zones/brand/ipkg at 0.5.11,5.11-0.151008:20131230T201908Z.


Is running with signature-policy=require-signatures a realistic option?

Thanks,

Ben




From ben at fluffy.co.uk  Tue Feb 11 16:30:47 2014
From: ben at fluffy.co.uk (Ben Summers)
Date: Tue, 11 Feb 2014 16:30:47 +0000
Subject: [OmniOS-discuss] Packages without signatures in r151008j
Message-ID: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>


Installing r151008j and running pkg verify with signature-policy=require-signatures shows the updated packages aren't signed:

Verifying: pkg://omnios/library/security/openssl                ERROR          
		The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/library/security/openssl at 1.0.1.6,5.11-0.151008:20140110T173804Z.
Verifying: pkg://omnios/package/pkg                             ERROR          
		The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/package/pkg at 0.5.11,5.11-0.151008:20131230T201906Z.
Verifying: pkg://omnios/system/zones/brand/ipkg                 ERROR          
		The policy for omnios requires signatures to be present but no signature was found in pkg://omnios/system/zones/brand/ipkg at 0.5.11,5.11-0.151008:20131230T201908Z.


Is running with signature-policy=require-signatures a realistic option?

Thanks,

Ben



--
http://bens.me.uk


From mmabis at vmware.com  Tue Feb 11 17:19:09 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Tue, 11 Feb 2014 09:19:09 -0800 (PST)
Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e
In-Reply-To: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>
References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>
Message-ID: <1443312846.4351885.1392139149497.JavaMail.root@vmware.com>

Hey all,

I just checked in with my system remotely and found that it had panic'ed for some reason i have left it in this state just in case i need to get more information... Has this been seen before?  using Build OmniOS-6de5e81 64bit on a C2740D4I by ASRock with 2x8GB ECC Memory Modules.

Attaching picture

Thanks

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-02-11 at 9.13.51 AM.png
Type: image/png
Size: 180891 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140211/18c26752/attachment-0001.png>

From danmcd at omniti.com  Tue Feb 11 19:10:49 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 11 Feb 2014 14:10:49 -0500
Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e
In-Reply-To: <1443312846.4351885.1392139149497.JavaMail.root@vmware.com>
References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>
	<1443312846.4351885.1392139149497.JavaMail.root@vmware.com>
Message-ID: <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com>


On Feb 11, 2014, at 12:19 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> Hey all,
> 
> I just checked in with my system remotely and found that it had panic'ed for some reason i have left it in this state just in case i need to get more information... Has this been seen before?  using Build OmniOS-6de5e81 64bit on a C2740D4I by ASRock with 2x8GB ECC Memory Modules.

Does this constantly happen?  Or just this once?  Seeing *where* in "unix" it crashed, complete with a stack trace, would be a good first step.  Providing a system dump would be better (see dumpadm(1M)).

Dan


From mmabis at vmware.com  Tue Feb 11 19:37:33 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Tue, 11 Feb 2014 11:37:33 -0800 (PST)
Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e
In-Reply-To: <679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com>
References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>
	<1443312846.4351885.1392139149497.JavaMail.root@vmware.com>
	<679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com>
Message-ID: <631092638.4391426.1392147453266.JavaMail.root@vmware.com>

First time crash, system was up for ~48 hours and it crashed like this... 

Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... 

Any way i can get to the dump files now? 


Matt


----- Original Message -----
From: "Dan McDonald" <danmcd at omniti.com>
To: "Matthew Mabis" <mmabis at vmware.com>
Cc: "Ben Summers" <ben at fluffy.co.uk>, "omnios-discuss" <omnios-discuss at lists.omniti.com>
Sent: Tuesday, February 11, 2014 11:10:49 AM
Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e


On Feb 11, 2014, at 12:19 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> Hey all,
> 
> I just checked in with my system remotely and found that it had panic'ed for some reason i have left it in this state just in case i need to get more information... Has this been seen before?  using Build OmniOS-6de5e81 64bit on a C2740D4I by ASRock with 2x8GB ECC Memory Modules.

Does this constantly happen?  Or just this once?  Seeing *where* in "unix" it crashed, complete with a stack trace, would be a good first step.  Providing a system dump would be better (see dumpadm(1M)).

Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-02-11 at 11.34.08 AM.png
Type: image/png
Size: 86926 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140211/f2c56928/attachment-0001.png>

From danmcd at omniti.com  Tue Feb 11 19:38:52 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 11 Feb 2014 14:38:52 -0500
Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e
In-Reply-To: <631092638.4391426.1392147453266.JavaMail.root@vmware.com>
References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>
	<1443312846.4351885.1392139149497.JavaMail.root@vmware.com>
	<679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com>
	<631092638.4391426.1392147453266.JavaMail.root@vmware.com>
Message-ID: <F8BF5E22-F04E-47D8-9FB6-8C934F41123A@omniti.com>


On Feb 11, 2014, at 2:37 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> First time crash, system was up for ~48 hours and it crashed like this... 
> 
> Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... 
> 
> Any way i can get to the dump files now? 

If it's in a crash-on-boot cycle, likely not.

Have you tried booting an install CD or USB stick?  If it ALSO crashes, it's highly likely a HW problem, like you mention.

Dan


From mmabis at vmware.com  Tue Feb 11 19:46:01 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Tue, 11 Feb 2014 11:46:01 -0800 (PST)
Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e
In-Reply-To: <F8BF5E22-F04E-47D8-9FB6-8C934F41123A@omniti.com>
References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>
	<1443312846.4351885.1392139149497.JavaMail.root@vmware.com>
	<679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com>
	<631092638.4391426.1392147453266.JavaMail.root@vmware.com>
	<F8BF5E22-F04E-47D8-9FB6-8C934F41123A@omniti.com>
Message-ID: <434682277.4398481.1392147961082.JavaMail.root@vmware.com>

Running Mem-Test on it now to check if its memory issue

I will update with results when i have them.. 

Matt

----- Original Message -----
From: "Dan McDonald" <danmcd at omniti.com>
To: "Matthew Mabis" <mmabis at vmware.com>
Cc: "Ben Summers" <ben at fluffy.co.uk>, "omnios-discuss" <omnios-discuss at lists.omniti.com>
Sent: Tuesday, February 11, 2014 11:38:52 AM
Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e


On Feb 11, 2014, at 2:37 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> First time crash, system was up for ~48 hours and it crashed like this... 
> 
> Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... 
> 
> Any way i can get to the dump files now? 

If it's in a crash-on-boot cycle, likely not.

Have you tried booting an install CD or USB stick?  If it ALSO crashes, it's highly likely a HW problem, like you mention.

Dan

From mmabis at vmware.com  Tue Feb 11 22:54:29 2014
From: mmabis at vmware.com (Matthew Mabis)
Date: Tue, 11 Feb 2014 14:54:29 -0800 (PST)
Subject: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e
In-Reply-To: <434682277.4398481.1392147961082.JavaMail.root@vmware.com>
References: <4EA5FE54-C063-4368-9A07-36B1BE09E9EC@fluffy.co.uk>
	<1443312846.4351885.1392139149497.JavaMail.root@vmware.com>
	<679EAA8D-5B8E-48D7-A67E-6C3F17AA4EF9@omniti.com>
	<631092638.4391426.1392147453266.JavaMail.root@vmware.com>
	<F8BF5E22-F04E-47D8-9FB6-8C934F41123A@omniti.com>
	<434682277.4398481.1392147961082.JavaMail.root@vmware.com>
Message-ID: <390608997.4478107.1392159269331.JavaMail.root@vmware.com>

Did a full Pass via memory no issues, now the system is booting.... 

I have captured the fmdump info and currently am extracting the dump file.. 

here is the fmdump info, if you want me to send you the dump file please let me know where.. 

Matt 


----- Original Message -----
From: "Matthew Mabis" <mmabis at vmware.com>
To: "Dan McDonald" <danmcd at omniti.com>
Cc: "omnios-discuss" <omnios-discuss at lists.omniti.com>
Sent: Tuesday, February 11, 2014 11:46:01 AM
Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e

Running Mem-Test on it now to check if its memory issue

I will update with results when i have them.. 

Matt

----- Original Message -----
From: "Dan McDonald" <danmcd at omniti.com>
To: "Matthew Mabis" <mmabis at vmware.com>
Cc: "Ben Summers" <ben at fluffy.co.uk>, "omnios-discuss" <omnios-discuss at lists.omniti.com>
Sent: Tuesday, February 11, 2014 11:38:52 AM
Subject: Re: [OmniOS-discuss] C2750D4I and CPU Panic Bad Trap: Type=e


On Feb 11, 2014, at 2:37 PM, Matthew Mabis <mmabis at vmware.com> wrote:

> First time crash, system was up for ~48 hours and it crashed like this... 
> 
> Now i cannot reboot it at all, she will panic on loading of the OS and reboot, i am attaching a new picture... i will be running hardware diags too just to be sure... 
> 
> Any way i can get to the dump files now? 

If it's in a crash-on-boot cycle, likely not.

Have you tried booting an install CD or USB stick?  If it ALSO crashes, it's highly likely a HW problem, like you mention.

Dan
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
https://urldefense.proofpoint.com/v1/url?u=http://lists.omniti.com/mailman/listinfo/omnios-discuss&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yqgQ6LhGnfWMd79QvLrmWsnr%2FlpWj5c0oy4MpT8%2Bgik%3D%0A&m=qPhUb5pnPZEs8lTPOtg9k3Tm3gT3xSdxwof9nozrO2Q%3D%0A&s=504976f584b541bb03faffff433091182ddbdfa2d92d3a0e5f013debb9d8682e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-02-11 at 2.52.38 PM.png
Type: image/png
Size: 80336 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140211/40ecb5b7/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-02-11 at 2.52.32 PM.png
Type: image/png
Size: 74760 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140211/40ecb5b7/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-02-11 at 2.52.27 PM.png
Type: image/png
Size: 71730 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140211/40ecb5b7/attachment-0005.png>

From moo at wuffers.net  Wed Feb 12 15:31:17 2014
From: moo at wuffers.net (wuffers)
Date: Wed, 12 Feb 2014 10:31:17 -0500
Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output
	discrepancy?
Message-ID: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>

So I only upgraded to r151008 recently, and was wondering whether the new
L2ARC compression was working. After getting an updated arcstat script
which added the l2asize option (which returned a 0), and a few rounds in
IRC which lead me to the correct kstat (zfs:0:arcstats:l2_asize), and an
even more updated arcstat to fix the 0 result..

Now both kstat and arcstat are outputting the same info:
zfs:0:arcstats:l2_asize 864682956800
zfs:0:arcstats:l2_size  1374605708288

arcstat:
read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz  l2size
l2asize
2.7K  2.6K    53    98      53      44       9      83   229G    1.3T
806G
5.1K  4.8K   282    94     282      17     265       6   229G    1.3T
806G
7.3K  7.3K    10    99      10       4       6      40   229G    1.3T
806G
...

But.. why is zpool iostat -v showing me my cache devices using up ~1.25T
(314Gx4), which is close to the 1.3T l2size?

                              capacity     operations    bandwidth
pool                       alloc   free   read  write   read  write
-------------------------  -----  -----  -----  -----  -----  -----
[snip]

cache                          -      -      -      -      -      -
  c2t500117310015D579d0     313G  59.4G     19     15   711K   833K
  c2t50011731001631FDd0     314G  58.1G     18     15   712K   836K
  c12t500117310015D59Ed0    314G  58.8G     19     15   710K   835K
  c12t500117310015D54Ed0    313G  59.7G     18     15   709K   832K
-------------------------  -----  -----  -----  -----  -----  -----

What's with the discrepancy? Is zpool iostat calculating the free capacity
incorrectly now (my cache drives are 400GB)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140212/72742471/attachment.html>

From skiselkov.ml at gmail.com  Wed Feb 12 15:44:22 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Wed, 12 Feb 2014 15:44:22 +0000
Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output
 discrepancy?
In-Reply-To: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>
References: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>
Message-ID: <52FB96D6.3000206@gmail.com>

On 2/12/14, 3:31 PM, wuffers wrote:
> So I only upgraded to r151008 recently, and was wondering whether the
> new L2ARC compression was working. After getting an updated arcstat
> script which added the l2asize option (which returned a 0), and a few
> rounds in IRC which lead me to the correct kstat
> (zfs:0:arcstats:l2_asize), and an even more updated arcstat to fix the 0
> result..
> 
> Now both kstat and arcstat are outputting the same info:
> zfs:0:arcstats:l2_asize 864682956800
> zfs:0:arcstats:l2_size  1374605708288
> 
> arcstat:
> read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz  l2size 
> l2asize
> 2.7K  2.6K    53    98      53      44       9      83   229G   
> 1.3T     806G
> 5.1K  4.8K   282    94     282      17     265       6   229G   
> 1.3T     806G
> 7.3K  7.3K    10    99      10       4       6      40   229G   
> 1.3T     806G
> ...
> 
> But.. why is zpool iostat -v showing me my cache devices using up ~1.25T
> (314Gx4), which is close to the 1.3T l2size?
> 
>                               capacity     operations    bandwidth
> pool                       alloc   free   read  write   read  write
> -------------------------  -----  -----  -----  -----  -----  -----
> [snip]
> 
> cache                          -      -      -      -      -      -
>   c2t500117310015D579d0     313G  59.4G     19     15   711K   833K
>   c2t50011731001631FDd0     314G  58.1G     18     15   712K   836K
>   c12t500117310015D59Ed0    314G  58.8G     19     15   710K   835K
>   c12t500117310015D54Ed0    313G  59.7G     18     15   709K   832K
> -------------------------  -----  -----  -----  -----  -----  -----
> 
> What's with the discrepancy? Is zpool iostat calculating the free
> capacity incorrectly now (my cache drives are 400GB)?

What's the block size of your SSDs and the average recordsize of the
data on them?

-- 
Saso

From skiselkov.ml at gmail.com  Wed Feb 12 15:55:53 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Wed, 12 Feb 2014 15:55:53 +0000
Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output
 discrepancy?
In-Reply-To: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>
References: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>
Message-ID: <52FB9989.3090600@gmail.com>

On 2/12/14, 3:31 PM, wuffers wrote:
> So I only upgraded to r151008 recently, and was wondering whether the
> new L2ARC compression was working. After getting an updated arcstat
> script which added the l2asize option (which returned a 0), and a few
> rounds in IRC which lead me to the correct kstat
> (zfs:0:arcstats:l2_asize), and an even more updated arcstat to fix the 0
> result..
> 
> Now both kstat and arcstat are outputting the same info:
> zfs:0:arcstats:l2_asize 864682956800
> zfs:0:arcstats:l2_size  1374605708288
> 
> arcstat:
> read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz  l2size 
> l2asize
> 2.7K  2.6K    53    98      53      44       9      83   229G   
> 1.3T     806G
> 5.1K  4.8K   282    94     282      17     265       6   229G   
> 1.3T     806G
> 7.3K  7.3K    10    99      10       4       6      40   229G   
> 1.3T     806G
> ...
> 
> But.. why is zpool iostat -v showing me my cache devices using up ~1.25T
> (314Gx4), which is close to the 1.3T l2size?
> 
>                               capacity     operations    bandwidth
> pool                       alloc   free   read  write   read  write
> -------------------------  -----  -----  -----  -----  -----  -----
> [snip]
> 
> cache                          -      -      -      -      -      -
>   c2t500117310015D579d0     313G  59.4G     19     15   711K   833K
>   c2t50011731001631FDd0     314G  58.1G     18     15   712K   836K
>   c12t500117310015D59Ed0    314G  58.8G     19     15   710K   835K
>   c12t500117310015D54Ed0    313G  59.7G     18     15   709K   832K
> -------------------------  -----  -----  -----  -----  -----  -----
> 
> What's with the discrepancy? Is zpool iostat calculating the free
> capacity incorrectly now (my cache drives are 400GB)?

Can you also try running this piece of dtrace on the machine? I have a
hypothesis that I'd like to test:

dtrace -n 'fbt::l2arc_evict:entry{printf("dev=%p; l2ad_first=%d",
args[0], args[0]->l2ad_first)}'

(let it run for about 5-10s and post the output)

-- 
Saso

From moo at wuffers.net  Wed Feb 12 18:11:21 2014
From: moo at wuffers.net (wuffers)
Date: Wed, 12 Feb 2014 13:11:21 -0500
Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output
	discrepancy?
In-Reply-To: <52FB9989.3090600@gmail.com>
References: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>
	<52FB9989.3090600@gmail.com>
Message-ID: <CA+tR_KxR5B=98W-jD9=vb-3py_c9Y-t=9q4OmYxnQRs3Q5XcjQ@mail.gmail.com>

On Wed, Feb 12, 2014 at 10:55 AM, Saso Kiselkov <skiselkov.ml at gmail.com>wrote:

Can you also try running this piece of dtrace on the machine? I have a
> hypothesis that I'd like to test:
>
> dtrace -n 'fbt::l2arc_evict:entry{printf("dev=%p; l2ad_first=%d",
> args[0], args[0]->l2ad_first)}'
>
> (let it run for about 5-10s and post the output)
>


Output from the above dtrace:

dtrace: description 'fbt::l2arc_evict:entry' matched 1 probe
CPU     ID                    FUNCTION:NAME
 12  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
 12  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
 12  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
 14  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
  0  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  5  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
  5  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  1  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
 19  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
 21  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
 23  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  0  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
 11  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
 13  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
 14  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
 15  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
 19  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  1  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
  3  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  3  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
  3  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  3  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
 16  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  3  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
 13  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  3  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
  0  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
 21  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
  2  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
 18  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
  1  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  1  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
  1  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  2  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
  2  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  2  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
 20  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  0  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
  0  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  0  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
  1  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  2  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
  0  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
  8  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
  1  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1
  4  40955                l2arc_evict:entry dev=ffffff4377e25058;
l2ad_first=1
 14  40955                l2arc_evict:entry dev=ffffff4377e25148;
l2ad_first=1
 12  40955                l2arc_evict:entry dev=ffffff432153be68;
l2ad_first=1
 21  40955                l2arc_evict:entry dev=ffffff43782a8240;
l2ad_first=1

And on your other question:

> What's the block size of your SSDs and the average recordsize of the
> data on them?

I'm actually not sure what you're asking about.. the recordsize on the pool
itself? It's 128K. I have different volblocksize on various volumes. Or
information about the SSD itself?

* /dev/rdsk/c2t500117310015D579d0 partition map
*
* Dimensions:
*     512 bytes/sector
* 781422768 sectors
* 781422701 accessible sectors
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector
*          34       222       255
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      4    00        256 781406095 781406350
       8     11    00  781406351     16384 781422734
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140212/510cf551/attachment-0001.html>

From skiselkov.ml at gmail.com  Wed Feb 12 18:33:07 2014
From: skiselkov.ml at gmail.com (Saso Kiselkov)
Date: Wed, 12 Feb 2014 18:33:07 +0000
Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output
 discrepancy?
In-Reply-To: <CA+tR_KxR5B=98W-jD9=vb-3py_c9Y-t=9q4OmYxnQRs3Q5XcjQ@mail.gmail.com>
References: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>	<52FB9989.3090600@gmail.com>
	<CA+tR_KxR5B=98W-jD9=vb-3py_c9Y-t=9q4OmYxnQRs3Q5XcjQ@mail.gmail.com>
Message-ID: <52FBBE63.4090405@gmail.com>

Okay, I think I have a convincing analysis for this:

TL;DR Sadly, the zpool vdev space stats are less than useless for L2ARC
here and they're confusing you.

L2ARC devices are rotors, so they start writing at low offsets and
progress higher until they wrap around. What your vdev space stats
(zpool iostat -v) show is really the difference between the maximum and
the minimum buffer offsets. It doesn't actually say how much of the
space in between is occupied by usable buffers.  l2asize, however, does.

The reason why I asked for the l2ad_first measurement is because I
wanted to understand why your space usage was showing ~59GB of free
space on each device - it's because your L2ARC devices have not yet even
completed a single run through the rotor. If it had completed the first,
it would have indicated a serious flaw in the wrap-around logic. So this
is currently the situation:

                             write hand--------,
 L2ARC device                                   \
+------------------------------------------------V---------------------+
|  |lowest|  ...... buffers & gaps ..... |highest|  (nothing here yet) |
+----------------------------------------------------------------------+

   |                "allocated"                  |      "free"        |
   |<----------------- 313G -------------------->|<------ 59G ------->|

The gaps in between the "lowest" and "highest" L2ARC buffers get created
when the buffers previously written there are evicted from L2ARC for
whatever reason (e.g. the filesystem holding them is destroyed, or they
are written to in ARC, invalidating the contents cached in L2ARC).
Unfortunately, the "allocated" vdev space stat is not altered when this
happens, so your L2ARC could really just hold two buffers and still
appear as full in the vdev stats.

The reason why l2asize is different is because it *does* take eviction
into account. So as the vdev space allocated metric was growing due to
the write hand moving to the right, the actual amount of data stored in
the L2ARC didn't grow nearly as quickly since buffers that had
previously been written had to be evicted.

As for why the (uncompressed) l2size is roughly equal to vdev space
allocated, I'd say it's due to a rounding error in the reporting tools
and some luck. The numbers don't actually even add up to the same result:

l2size: 1374605708288 bytes / 2^30 = 1280 GB
vdev space: 313 + 314 + 314 + 313 = 1254 GB

As for general ZFS design, I think we should either fix the vdev space
stats on L2ARC devices so that they precisely correspond to l2asize, or
get rid of them altogether. Right now, the discrepancy there just
confuses people.

Hope this helps.

Cheers,
-- 
Saso


From moo at wuffers.net  Wed Feb 12 19:19:23 2014
From: moo at wuffers.net (wuffers)
Date: Wed, 12 Feb 2014 14:19:23 -0500
Subject: [OmniOS-discuss] L2ARC actual size and zpool iostat -v output
	discrepancy?
In-Reply-To: <52FBBE63.4090405@gmail.com>
References: <CA+tR_KwX1GKMU7Q9uaTCsh=aJHbZJs08c4O9zetgGZBeUJXu8A@mail.gmail.com>
	<52FB9989.3090600@gmail.com>
	<CA+tR_KxR5B=98W-jD9=vb-3py_c9Y-t=9q4OmYxnQRs3Q5XcjQ@mail.gmail.com>
	<52FBBE63.4090405@gmail.com>
Message-ID: <CA+tR_KxzQpmis5WvrzPuihSGJBVv9rpWy9L2xa0r9rMtKScrCQ@mail.gmail.com>

Wow, thanks for the insightful explanation (and brilliant ASCII diagram).

You're right in that my L2ARC hasn't had time to fill up yet, as my system
uptime is creeping up to 5 days since the upgrade. Will be nice when the
persistent L2ARC feature finally makes it in so that it doesn't take that
long to rebuild.

As for general ZFS design, I think we should either fix the vdev space
> stats on L2ARC devices so that they precisely correspond to l2asize, or
> get rid of them altogether. Right now, the discrepancy there just
> confuses people.
>

Consider my curiosity sated (and confusion resolved), but I was glad I was
able to help raise this point. I'll just ignore the, as you call them,
"vdev space stats" for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140212/1d55b65a/attachment.html>

From thibault.vincent at smartjog.com  Thu Feb 13 10:18:58 2014
From: thibault.vincent at smartjog.com (Thibault VINCENT)
Date: Thu, 13 Feb 2014 11:18:58 +0100
Subject: [OmniOS-discuss] Overheating faults with ST4000NM0023
In-Reply-To: <6B4199959CFA4E1CB067BBF9270654CB@486dx4>
References: <6B4199959CFA4E1CB067BBF9270654CB@486dx4>
Message-ID: <52FC9C12.9090900@smartjog.com>

On 02/12/2014 09:59 PM, Steamer wrote:
> Did you ever find a solution to the overheating faults with the
> ST4000NM0023?
>  
> I'm currently having the exact same issue with ST1000NM0023 drives,
> seems like seagate has the user temp probe set at 40'C. The manual
> states that the temperature settings are programmable via smart, but I
> haven't found a way to do that.

Hello Emile,

I've found a workaround but the definitive fix should be handled by
Illumos I guess. There is no open ticket, first I was waiting for
something to happen with #4051 before going back to using that distro
and kernel.

Here's the story:
The SCSI specification defines two registers to store the temperature
thresholds in SMART data. One contains the recommended maximum operation
temperature for best MTBF, and the other register is for the absolute
maximum rating. Usually the industry has always put the same value in
both, and that is the absolute maximum. That's why we always see
something like 60/65?C from SMART. But recently Seagate has changed that
because it was asked by a large OS company to comply with the
specification for better hardware monitoring integration. The change did
not only occur in newer products but in a firmware update for existing
disks and that was applied to the production line which explains some
disks mays or may not expose this problem although they are the same
model. Our disks are of the Megalodon serie and all share the same
firmware basecode.

So any Seagate disk will now trigger faults in FMA if they have a
firmware with the newer policy. Also I think other brands will follow
the same path.

Like other members suggested in that thread, maybe nothing should change
in FMA but let's face it, you can't maintain a temperature steadily
under 40?C in a JBOD of hundreds of busy disks. Especially in
eco-friendly datacenters. IMHO we should not trigger a fault on the
lower threshold, and certainly not a drive retirement. It breaks storage
servers on reboot or before a pool import, also spare disks could
disappear with the retirement triggered.

The workaround is to downgrade firmware to the last version before the
change, and to reset the register with an SCSI command. It is not
possible to set the register to a user specified value like the
documentation suggests, they confirmed it.

I'm sending a working firmware to you in a private mail. I'm not aware
of any issue working with that older version and hopefully it should
upload to 1TB drives as well.
I'm applying it like this but from Linux not OmniOS:
# ./dl_sea_fw-0.2.3_32 -f Megalodon_StdOEM_SAS_0002+C84C.lod -m ST4000NM0023
# ./dl_sea_fw-0.2.3_32 -i

Then you should reset the drives so they reload the firmware.
Here's our example for 4TB drives:
-------------
for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do
  sg_reset -d $i
done
-------------

And reset the register that contains value from the previous firmware.
It doesn't work well so we've got this script to run a few times until
all disks got it. Again it matches 4TB Megalodon.
-------------
for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do
  echo -n "$i "
  if sg_logs $i --page=0x0d | grep 'Reference temperature = 68 C'
>/dev/null ; then
    echo 'ok'
  else
    sg_logs $i --page=0x0d --reset
    echo 'reset'
  fi
done
-------------


Cheers

-- 
Thibault VINCENT - Lead System Engineer, Infrastructure -
Arkena | Phone: +33 1 58 68 62 38 | Mobile: +33 6 78 97 01 08
27 Blvd Hippolyte Marqu?s, 94200 Ivry-sur-Seine, France | www.arkena.com
Arkena - Ready to Play

From dswartz at druber.com  Fri Feb 14 16:29:43 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Fri, 14 Feb 2014 11:29:43 -0500
Subject: [OmniOS-discuss] Disappearing drives?
Message-ID: <d59adc2cacdcc467e372cf0c5c3b57e0.squirrel@webmail.druber.com>


I've been running an install on r151008.  rpool mirrored on two WD black
160GB sata drives.  8 SAS nearline drives in a raid10.  Two samsung 840PRO
128GB drives as l2arc.  The sas and l2arc drives are on an LSI HBA, and
the rpool on motherboard sata ports.  Twice now, I've had drives disappear
- the first time was one of the rpool drives, and yesterday one of the
l2arc drives.  The symptom is that zpool status shows thousands of
read/write errors and the drive is offlined.  If I run the format command,
it shows that drive as 'unknown drive type'.  I apologize for not getting
more specific data - the first time, I wrote off as an anomaly, but
yesterday I really should have cut&pasted anything relevant.  Anyway, I'm
puzzled that there seems no common hardware or driver factor.  The rpool
drives are sata, and are using the sata-phy driver (I think that's what I
dug out of prtconf -v), whereas, although the l2arc drives are sata, since
they are on the lsi hba, they are using the sas-mpt driver.  I wasn't that
concerned about yesterday's incident, since l2arc drives could both die
suddenly and not take things down, but having rpool go bye-bye is not good
- this is why I was paranoid and mirrored it.  Any ideas?  If this happens
again, what should I look for?


From natxo.asenjo at gmail.com  Sat Feb 15 09:09:53 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sat, 15 Feb 2014 10:09:53 +0100
Subject: [OmniOS-discuss] apache22 from ms.omniti.com
Message-ID: <CAHBEJzXrEFD7_snpynGLOCzS=hqy69TygHYM-NZNywX9ovE4bA@mail.gmail.com>

hi,

maybe handy for anyone trying to get this package operational.

Obviosly, you need to add the publisher ms.omniti.com first.

Then add the packge. After which, import the xml service schema in
/opt/apache22/conf/:

svccfg import /opt/apache22/conf/http-apache.xml

After wich, you can enable/disable the service.

Configure /opt/apache22/conf/httpd.conf to your needs.

If after editing httpd.conf and verifying its syntax with
/opt/apache22/bin/httpd -t the syntax is ok and apache2 does not start with
the unhelpful error

 Feb 14 21:46:21 Executing start method ("/opt/apache22/bin/httpd -f
/opt/apache22/conf/httpd.conf -k start"). ]
[ Feb 14 21:46:21 Method "start" exited with status 1. ]

adding the hostnanme to the hosts file fixed it for me

--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140215/ef2af466/attachment.html>

From natxo.asenjo at gmail.com  Sat Feb 15 18:54:15 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sat, 15 Feb 2014 19:54:15 +0100
Subject: [OmniOS-discuss] software compilation errors
Message-ID: <CAHBEJzU-ZNs=XrgA1vT_Y2S01x0-twTV+rkpACsXhBusVFqNgg@mail.gmail.com>

hi,

When trying to compile some Perl modules using cpanm I get errors. My
google fu is not being helpful, maybe you could point me in the right
direction.

This is the compiler I have in a zone:

root at zone2:~# pkg list | grep gcc
developer/gcc48
4.8.1-0.151008             i--
developer/gcc48/libgmp-gcc48
5.0.5-0.151008             i--
developer/gcc48/libmpc-gcc48
1.0.1-0.151008             i--
developer/gcc48/libmpfr-gcc48
3.1.1-0.151008             i--
system/library/gcc-4-runtime

When trying to install Text::Markdown::Discount I get this error:

cpanm (App::cpanminus) 1.7001 on perl 5.016001 built for
i86pc-solaris-thread-multi-64int
Work directory is /root/.cpanm/work/1392489889.18009
You have make /usr/bin/make
You have /usr/bin/wget
You have /usr/bin/tar, /usr/bin/gzip and /usr/bin/bzip2
You have /usr/bin/unzip
Searching Text::Markdown::Discount on cpanmetadb ...
--> Working on Text::Markdown::Discount
Fetching
http://www.cpan.org/authors/id/S/SE/SEKIMURA/Text-Markdown-Discount-0.11.tar.gz
-> OK
Unpacking Text-Markdown-Discount-0.11.tar.gz
Entering Text-Markdown-Discount-0.11
Checking configure dependencies from META.yml
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.63_02)
Configuring Text-Markdown-Discount-0.11
Running Makefile.PL
Checking if your kit is complete...
Looks good
Warning: -Ldiscount changed to
-L/root/.cpanm/work/1392489889.18009/Text-Markdown-Discount-0.11/discount
Writing Makefile for Text::Markdown::Discount
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.63_02)
Building and testing Text-Markdown-Discount-0.11
cp lib/Text/Markdown/Discount.pm blib/lib/Text/Markdown/Discount.pm
( cd discount; CC='cc -fPIC' sh configure.sh; make )
Configuring for [markdown]
Looking for cpp (/opt/gcc-4.8.1/bin/cpp) ok
looking for install (/usr/gnu/bin/install)
checking the C compiler (cc -fPIC) does not compile code properly
*** Error code 1
make: Fatal error: Command failed for target `discount/libmarkdown.a'

--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140215/20bac031/attachment-0001.html>

From tim at multitalents.net  Sat Feb 15 19:55:09 2014
From: tim at multitalents.net (Tim Rice)
Date: Sat, 15 Feb 2014 11:55:09 -0800 (PST)
Subject: [OmniOS-discuss] software compilation errors
In-Reply-To: <CAHBEJzU-ZNs=XrgA1vT_Y2S01x0-twTV+rkpACsXhBusVFqNgg@mail.gmail.com>
References: <CAHBEJzU-ZNs=XrgA1vT_Y2S01x0-twTV+rkpACsXhBusVFqNgg@mail.gmail.com>
Message-ID: <Pine.UW2.4.64.1402151151300.22689@server01.int.multitalents.net>

On Sat, 15 Feb 2014, Natxo Asenjo wrote:

> checking the C compiler (cc -fPIC) does not compile code properly
> *** Error code 1
> make: Fatal error: Command failed for target `discount/libmarkdown.a'

Can you compile anything on that system?

Is pkg://omnios/system/header installed?


-- 
Tim Rice				Multitalents
tim at multitalents.net



From natxo.asenjo at gmail.com  Sat Feb 15 21:32:53 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sat, 15 Feb 2014 22:32:53 +0100
Subject: [OmniOS-discuss] software compilation errors
In-Reply-To: <Pine.UW2.4.64.1402151151300.22689@server01.int.multitalents.net>
References: <CAHBEJzU-ZNs=XrgA1vT_Y2S01x0-twTV+rkpACsXhBusVFqNgg@mail.gmail.com>
	<Pine.UW2.4.64.1402151151300.22689@server01.int.multitalents.net>
Message-ID: <CAHBEJzXKPdDaWxb=X1=41ERoJEWcvKwJE=L15FsRZYjR+QGgSQ@mail.gmail.com>

--
Groeten,
natxo


On Sat, Feb 15, 2014 at 8:55 PM, Tim Rice <tim at multitalents.net> wrote:

> On Sat, 15 Feb 2014, Natxo Asenjo wrote:
>
> > checking the C compiler (cc -fPIC) does not compile code properly
> > *** Error code 1
> > make: Fatal error: Command failed for target `discount/libmarkdown.a'
>
> Can you compile anything on that system?
>
> Is pkg://omnios/system/header installed?
>
> yes:

# pkg info system/header
          Name: system/header
       Summary: SunOS Header Files
   Description: SunOS C/C++ header files for general development of software
      Category: System/Core
         State: Installed
     Publisher: omnios
       Version: 0.5.11
 Build Release: 5.11
        Branch: 0.151008
Packaging Date: Wed Dec  4 02:47:08 2013
          Size: 12.19 MB
          FMRI: pkg://omnios/system/header at 0.5.11
,5.11-0.151008:20131204T024708Z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140215/301fce7d/attachment.html>

From tim at multitalents.net  Sat Feb 15 22:51:48 2014
From: tim at multitalents.net (Tim Rice)
Date: Sat, 15 Feb 2014 14:51:48 -0800 (PST)
Subject: [OmniOS-discuss] software compilation errors
In-Reply-To: <CAHBEJzXKPdDaWxb=X1=41ERoJEWcvKwJE=L15FsRZYjR+QGgSQ@mail.gmail.com>
References: <CAHBEJzU-ZNs=XrgA1vT_Y2S01x0-twTV+rkpACsXhBusVFqNgg@mail.gmail.com>
	<Pine.UW2.4.64.1402151151300.22689@server01.int.multitalents.net>
	<CAHBEJzXKPdDaWxb=X1=41ERoJEWcvKwJE=L15FsRZYjR+QGgSQ@mail.gmail.com>
Message-ID: <Pine.UW2.4.64.1402151441140.22689@server01.int.multitalents.net>

On Sat, 15 Feb 2014, Natxo Asenjo wrote:

| --
| Groeten,
| natxo
| 
| 
| On Sat, Feb 15, 2014 at 8:55 PM, Tim Rice <tim at multitalents.net> wrote:
| 
| > On Sat, 15 Feb 2014, Natxo Asenjo wrote:
| >
| > > checking the C compiler (cc -fPIC) does not compile code properly
                               ^^^^^^^^
I should have caught this last time. The OmniOS gcc packages do not
provide a cc only gcc. Unless you have the sun compilers installed,
there is no cc. Even if they were installed, "cc -fPIC" is not valid
for sun compilers.  It would need to be "cc -Kpic".
You'll need to patch the perl module and build manually.

A possible workaround would be to (cd /opt/gcc/bin ; ln -s gcc cc)

| > > *** Error code 1
| > > make: Fatal error: Command failed for target `discount/libmarkdown.a'
| >
| > Can you compile anything on that system?
| >
| > Is pkg://omnios/system/header installed?
| >
| > yes:
| 
| # pkg info system/header
|           Name: system/header
[snip]

-- 
Tim Rice				Multitalents
tim at multitalents.net



From rmarc at copacetic.net  Sun Feb 16 03:57:06 2014
From: rmarc at copacetic.net (Marc Phillips)
Date: Sat, 15 Feb 2014 21:57:06 -0600
Subject: [OmniOS-discuss] New to OmniOS (hopefully easy question)
Message-ID: <20140216035706.GA30682@copacetic.net>


I'm trying to get going use OmniOS but can't seem to get paste a basic hurdle.

I installed LTS (I've not tried stable), I then used pkg to install developer/gcc48 (I also tried gcc47)
My goal is to compile and create packages for the services I require.

The first item I'm trying to compile is x11vnc.  When I do a ./configure I get:

checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

I'm sure I'm glossing over something simple, but I'm at an impass.
Guidance would be appreciated.

R. Marc

From ben at fluffy.co.uk  Sun Feb 16 07:26:39 2014
From: ben at fluffy.co.uk (Ben Summers)
Date: Sun, 16 Feb 2014 07:26:39 +0000
Subject: [OmniOS-discuss] New to OmniOS (hopefully easy question)
In-Reply-To: <20140216035706.GA30682@copacetic.net>
References: <20140216035706.GA30682@copacetic.net>
Message-ID: <491902031.113312.1392535602487@08350ac283874659a4c1a48e1ff998c5.nuevasync.com>

Have you installed the system/headers package?

What does config.log say?

Ben


> On 16 Feb 2014, at 03:59, "Marc Phillips" <rmarc at copacetic.net> wrote:
> 
> 
> I'm trying to get going use OmniOS but can't seem to get paste a basic hurdle.
> 
> I installed LTS (I've not tried stable), I then used pkg to install developer/gcc48 (I also tried gcc47)
> My goal is to compile and create packages for the services I require.
> 
> The first item I'm trying to compile is x11vnc.  When I do a ./configure I get:
> 
> checking how to run the C preprocessor... /lib/cpp
> configure: error: C preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.
> 
> I'm sure I'm glossing over something simple, but I'm at an impass.
> Guidance would be appreciated.
> 
> R. Marc
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From natxo.asenjo at gmail.com  Sun Feb 16 07:56:09 2014
From: natxo.asenjo at gmail.com (Natxo Asenjo)
Date: Sun, 16 Feb 2014 08:56:09 +0100
Subject: [OmniOS-discuss] software compilation errors
In-Reply-To: <Pine.UW2.4.64.1402151441140.22689@server01.int.multitalents.net>
References: <CAHBEJzU-ZNs=XrgA1vT_Y2S01x0-twTV+rkpACsXhBusVFqNgg@mail.gmail.com>
	<Pine.UW2.4.64.1402151151300.22689@server01.int.multitalents.net>
	<CAHBEJzXKPdDaWxb=X1=41ERoJEWcvKwJE=L15FsRZYjR+QGgSQ@mail.gmail.com>
	<Pine.UW2.4.64.1402151441140.22689@server01.int.multitalents.net>
Message-ID: <CAHBEJzWmrMFTPB9mQTW8i8y5XePMcvS72b3T+WPnuOQzoukQYw@mail.gmail.com>

On Sat, Feb 15, 2014 at 11:51 PM, Tim Rice <tim at multitalents.net> wrote:

> | > On Sat, 15 Feb 2014, Natxo Asenjo wrote:
> | >
> | > > checking the C compiler (cc -fPIC) does not compile code properly
>                                ^^^^^^^^
> I should have caught this last time. The OmniOS gcc packages do not
> provide a cc only gcc. Unless you have the sun compilers installed,
> there is no cc. Even if they were installed, "cc -fPIC" is not valid
> for sun compilers.  It would need to be "cc -Kpic".
> You'll need to patch the perl module and build manually.
>

Yes! I installed  developer/sunstudio12.1, modified Makefile.PL with your
suggestion, installed pkg:/developer/object-file (needed for ar), used
gmake instead of make and finally got it to work.

Thanks so much for your tip!

-- 
groet,
Natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140216/786b0f1d/attachment.html>

From mariusz.stanczak at gmail.com  Sun Feb 16 10:35:58 2014
From: mariusz.stanczak at gmail.com (Mariusz Stanczak)
Date: Sun, 16 Feb 2014 02:35:58 -0800
Subject: [OmniOS-discuss] SUNW* libraries
Message-ID: <20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com>

Hello All,

I'm trying to install Nvidia drivers, and I found instructions [https://community.oracle.com/thread/2487788] for creating a boot environment, but when trying to add the driver package I get the following errors:

----
root at Omni:~/NVIDIA-Solaris-x86-334.16# pkgadd -R /mnt -d . NVDAgraphics NVDAgraphicsr

Processing package instance <NVDAgraphics> from </root/NVIDIA-Solaris-x86-334.16>

NVIDIA Graphics System Software(i386) 334.16,REV=2014.02.04.15.20
Copyright 2005-2009 by NVIDIA Corporation.  All rights reserved.
Use is subject to license terms.

This appears to be an attempt to install the same architecture and
version of a package which is already installed.  This installation
will attempt to overwrite this package.

Using </mnt/usr> as the package base directory.
## Processing package information.
## Processing system information.
   189 package pathnames are already properly installed.
## Verifying package dependencies.
WARNING:
    The <SUNWlibmsr> package "Math & Microtasking Libraries
    (Root)" is a prerequisite package and should be
    installed.
WARNING:
    The <SUNWxwrtl> package "X Window System & Graphics
    Runtime Library Links in /usr/lib" is a prerequisite
    package and should be installed.
WARNING:
    The <SUNWxwplt> package "X Window System platform
    software" is a prerequisite package and should be
    installed.
WARNING:
    The <SUNWgnome-base-libs> package "GNOME base GUI
    libraries" is a prerequisite package and should be
    installed.
WARNING:
    The <SUNWgccruntime> package "GCC Runtime libraries" is
    a prerequisite package and should be installed.
WARNING:
    The <SUNWxorg-clientlibs> package "X.Org Foundation X
    Client Libraries" is a prerequisite package and should
    be installed.

Do you want to continue with the installation of <NVDAgraphics> [y,n,?] n
----
Here the force (Google ;) has failed me, except for clues that things may not be what they seem to.  So, what's the story with those libs.

Thank you,
/Mariusz

From jdg117 at elvis.arl.psu.edu  Sun Feb 16 17:33:03 2014
From: jdg117 at elvis.arl.psu.edu (John D Groenveld)
Date: Sun, 16 Feb 2014 12:33:03 -0500
Subject: [OmniOS-discuss] SUNW* libraries
In-Reply-To: Your message of "Sun, 16 Feb 2014 02:35:58 PST."
	<20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com> 
References: <20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com> 
Message-ID: <201402161733.s1GHX35H011496@elvis.arl.psu.edu>

In message <20140216023558.b34940c1f29e5a71f49d4cdd at gmail.com>, Mariusz Stancza
k writes:
>be what they seem to.  So, what's the story with those libs.

The libraries are not supported by OmniTI.

However, /kernel/drv/amd64/nvidia from NVDAgraphicsr package is not
dependent on them.

John
groenveld at acm.org

From derek at umiacs.umd.edu  Mon Feb 17 22:48:58 2014
From: derek at umiacs.umd.edu (Derek Yarnell)
Date: Mon, 17 Feb 2014 17:48:58 -0500
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
Message-ID: <530291DA.6050009@umiacs.umd.edu>

Hi,

So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped
as a Pliant-LB206S-D323-186.31GB via format.  The bulk of the storage is
just a 6+2 RaidZ2 with 3TB disks.  When doing a simple untar (40MB/2000
files) over NFS (synchronous IO) having the mirrored slog of Pliant SSDs
seems to offer horrendous performance.  On the order of 18-20 OPs per
second (via zpool iostat -v 1).  We have a number of other ZFS builds
with ZeusRAM slogs and they work very well and while the Pliant may not
be as good a choice it shouldn't be as bad as this.

# zfs get sync,dedup,logbias,compression,checksum zpool0
NAME    PROPERTY     VALUE          SOURCE
zpool0  sync         standard       default
zpool0  dedup        off            default
zpool0  logbias      latency        default
zpool0  compression  off            default
zpool0  checksum     on             default

Adding a ramdisk slog device makes everything perform as expected.
Setting sync=disabled of course makes things all better.

# zpool status zpool0
  pool: zpool0
 state: ONLINE
  scan: none requested
config:

        NAME                       STATE     READ WRITE CKSUM
        zpool0                     ONLINE       0     0     0
          raidz2-0                 ONLINE       0     0     0
            c1t5000C50057EC4B73d0  ONLINE       0     0     0
            c1t5000C50057EC6EABd0  ONLINE       0     0     0
            c1t5000C50057EC7CB7d0  ONLINE       0     0     0
            c1t5000C50057EC8F23d0  ONLINE       0     0     0
            c1t5000C50057EC998Bd0  ONLINE       0     0     0
            c1t5000C50057ECB1BBd0  ONLINE       0     0     0
            c1t5000C50057ECFEE7d0  ONLINE       0     0     0
            c1t5000C50057ED03F7d0  ONLINE       0     0     0
        logs
          mirror-1                 ONLINE       0     0     0
            c3t5001E820026DA2CAd0  ONLINE       0     0     0
            c3t5001E820026DA45Ad0  ONLINE       0     0     0

errors: No known data errors


-- 
Derek T. Yarnell
University of Maryland
Institute for Advanced Computer Studies

From mir at miras.org  Mon Feb 17 23:06:57 2014
From: mir at miras.org (Michael Rasmussen)
Date: Tue, 18 Feb 2014 00:06:57 +0100
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <530291DA.6050009@umiacs.umd.edu>
References: <530291DA.6050009@umiacs.umd.edu>
Message-ID: <20140218000657.020f86f3@sleipner.datanom.net>

On Mon, 17 Feb 2014 17:48:58 -0500
Derek Yarnell <derek at umiacs.umd.edu> wrote:

> Adding a ramdisk slog device makes everything perform as expected.
> Setting sync=disabled of course makes things all better.
> 
To the best of my knowledge using sync=disabled means no data hitting
your log. sync=standard means respect request for synchronous writes
while sync=always means make all write synchronous. Only synchronous
writes will ever hit the log.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
/usr/games/fortune -es says:
Q:	What's the difference between Bell Labs and the Boy Scouts of
America? A:	The Boy Scouts have adult supervision.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140218/92812095/attachment.bin>

From richard.elling at richardelling.com  Tue Feb 18 00:31:42 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Mon, 17 Feb 2014 16:31:42 -0800
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <530291DA.6050009@umiacs.umd.edu>
References: <530291DA.6050009@umiacs.umd.edu>
Message-ID: <C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>

On Feb 17, 2014, at 2:48 PM, Derek Yarnell <derek at umiacs.umd.edu> wrote:

> Hi,
> 
> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped
> as a Pliant-LB206S-D323-186.31GB via format.

Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for
lots of concurrent I/O operations. This is not the kind of workload generated by
the ZIL, which is more contiguous, single thread-like.

>  The bulk of the storage is
> just a 6+2 RaidZ2 with 3TB disks.  When doing a simple untar (40MB/2000
> files) over NFS (synchronous IO) having the mirrored slog of Pliant SSDs
> seems to offer horrendous performance.  On the order of 18-20 OPs per
> second (via zpool iostat -v 1).

Never ever use zpool iostat to measure application performance. zpool iostat
measures workload to the vdevs, showing back-end operations to disk. As such
there is no correlation to client-side operations of any sort, especially writes and
metadata updates. You'll need to go up the stack and see what it is doing. For NFS
I highly recommend nfssvrtop. To see the response time of the Pliant, use "iostat -x"
or, as I prefer, "iostat -zxCn"

Note: response time (measured by iostat -x as a variant of "svc_t") is the critical 
measurement for NFS workloads. Bandwidth is almost meaningless in analyzing
NFS.

>  We have a number of other ZFS builds
> with ZeusRAM slogs and they work very well and while the Pliant may not
> be as good a choice it shouldn't be as bad as this.

It can be as bad as that.

> # zfs get sync,dedup,logbias,compression,checksum zpool0
> NAME    PROPERTY     VALUE          SOURCE
> zpool0  sync         standard       default
> zpool0  dedup        off            default
> zpool0  logbias      latency        default
> zpool0  compression  off            default
> zpool0  checksum     on             default
> 
> Adding a ramdisk slog device makes everything perform as expected.

yep.  A ZeusRAM will also help.
 -- richard

> Setting sync=disabled of course makes things all better.
> 
> # zpool status zpool0
>  pool: zpool0
> state: ONLINE
>  scan: none requested
> config:
> 
>        NAME                       STATE     READ WRITE CKSUM
>        zpool0                     ONLINE       0     0     0
>          raidz2-0                 ONLINE       0     0     0
>            c1t5000C50057EC4B73d0  ONLINE       0     0     0
>            c1t5000C50057EC6EABd0  ONLINE       0     0     0
>            c1t5000C50057EC7CB7d0  ONLINE       0     0     0
>            c1t5000C50057EC8F23d0  ONLINE       0     0     0
>            c1t5000C50057EC998Bd0  ONLINE       0     0     0
>            c1t5000C50057ECB1BBd0  ONLINE       0     0     0
>            c1t5000C50057ECFEE7d0  ONLINE       0     0     0
>            c1t5000C50057ED03F7d0  ONLINE       0     0     0
>        logs
>          mirror-1                 ONLINE       0     0     0
>            c3t5001E820026DA2CAd0  ONLINE       0     0     0
>            c3t5001E820026DA45Ad0  ONLINE       0     0     0
> 
> errors: No known data errors
> 
> 
> -- 
> Derek T. Yarnell
> University of Maryland
> Institute for Advanced Computer Studies
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

--

Richard.Elling at RichardElling.com
+1-760-896-4422



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140217/04688ba6/attachment.html>

From derek at umiacs.umd.edu  Tue Feb 18 01:48:55 2014
From: derek at umiacs.umd.edu (Derek Yarnell)
Date: Mon, 17 Feb 2014 20:48:55 -0500
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
Message-ID: <5302BC07.9070304@umiacs.umd.edu>

On 2/17/14, 7:31 PM, Richard Elling wrote:
> On Feb 17, 2014, at 2:48 PM, Derek Yarnell <derek at umiacs.umd.edu> wrote:
> 
>> Hi,
>>
>> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped
>> as a Pliant-LB206S-D323-186.31GB via format.
> 
> Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for
> lots of concurrent I/O operations. This is not the kind of workload generated by
> the ZIL, which is more contiguous, single thread-like.

I realize that they may not be as good as Stec/HGST ZeusRAM drives for
the slog.  I still can't wrap my head around that it is as bad as having
no discrete slog.

> 
> Never ever use zpool iostat to measure application performance. zpool iostat
> measures workload to the vdevs, showing back-end operations to disk. As such
> there is no correlation to client-side operations of any sort, especially writes and
> metadata updates. You'll need to go up the stack and see what it is doing. For NFS
> I highly recommend nfssvrtop. To see the response time of the Pliant, use "iostat -x"
> or, as I prefer, "iostat -zxCn"

Yes I realize that iostat will show me this information and the svc_t
for the Pliant ssd(s) is anywhere from 2-7ms.  But zpool iostat will
show you your ZIL writes accurately no?  I realize that it will then
coalesce these into its transactions and write it out at the 5sec interval.

> 
> Note: response time (measured by iostat -x as a variant of "svc_t") is the critical 
> measurement for NFS workloads. Bandwidth is almost meaningless in analyzing
> NFS.

Yes and I have done this too.  The average RTT on untaring is 43.000 ms.
 I guess we will just be getting another set of ZeusRAM drives.

Thanks,
derek

-- 
Derek T. Yarnell
University of Maryland
Institute for Advanced Computer Studies

From richard.elling at richardelling.com  Tue Feb 18 07:05:23 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Mon, 17 Feb 2014 23:05:23 -0800
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <5302BC07.9070304@umiacs.umd.edu>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
Message-ID: <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>


On Feb 17, 2014, at 5:48 PM, Derek Yarnell <derek at umiacs.umd.edu> wrote:

> On 2/17/14, 7:31 PM, Richard Elling wrote:
>> On Feb 17, 2014, at 2:48 PM, Derek Yarnell <derek at umiacs.umd.edu> wrote:
>> 
>>> Hi,
>>> 
>>> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped
>>> as a Pliant-LB206S-D323-186.31GB via format.
>> 
>> Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized for
>> lots of concurrent I/O operations. This is not the kind of workload generated by
>> the ZIL, which is more contiguous, single thread-like.
> 
> I realize that they may not be as good as Stec/HGST ZeusRAM drives for
> the slog.  

They are not. By your measurements, the ZeusRAM is 2 orders of magnitude faster.

> I still can't wrap my head around that it is as bad as having
> no discrete slog.
> 
>> 
>> Never ever use zpool iostat to measure application performance. zpool iostat
>> measures workload to the vdevs, showing back-end operations to disk. As such
>> there is no correlation to client-side operations of any sort, especially writes and
>> metadata updates. You'll need to go up the stack and see what it is doing. For NFS
>> I highly recommend nfssvrtop. To see the response time of the Pliant, use "iostat -x"
>> or, as I prefer, "iostat -zxCn"
> 
> Yes I realize that iostat will show me this information and the svc_t
> for the Pliant ssd(s) is anywhere from 2-7ms.  But zpool iostat will
> show you your ZIL writes accurately no?

zpool iostat does not show latency (svc_t) except for a very limited few, distros.
For NFS, latency matters.

>  I realize that it will then
> coalesce these into its transactions and write it out at the 5sec interval.
> 
>> 
>> Note: response time (measured by iostat -x as a variant of "svc_t") is the critical 
>> measurement for NFS workloads. Bandwidth is almost meaningless in analyzing
>> NFS.
> 
> Yes and I have done this too.  The average RTT on untaring is 43.000 ms.
> I guess we will just be getting another set of ZeusRAM drives.

Be careful with these measurements. Untar is the pathological worst case workload
for NFS because of sync-on-close for clients. This workload is the poster child for Amdahl?s
Law. Also, the bulk of the latency could in fact be due to transfer from the client to the server
waiting to occur. In other words, the client can significantly impact these measurements. 
From a server?s perspective, nfssvrtop is the only tool I?m aware of that measures NFS 
operation latency from IP down to disk and back (the reason I wrote it :-). Of course, dtrace 
allows you to measure almost everything in the system, so you can add more measurements.

Fortunately, most real workloads are not tar -x.
 ? richard

> 
> Thanks,
> derek
> 
> -- 
> Derek T. Yarnell
> University of Maryland
> Institute for Advanced Computer Studies
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-- 

ZFS storage and performance consulting at http://www.RichardElling.com







From richard.elling at richardelling.com  Tue Feb 18 07:16:16 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Mon, 17 Feb 2014 23:16:16 -0800
Subject: [OmniOS-discuss] Disappearing drives?
In-Reply-To: <d59adc2cacdcc467e372cf0c5c3b57e0.squirrel@webmail.druber.com>
References: <d59adc2cacdcc467e372cf0c5c3b57e0.squirrel@webmail.druber.com>
Message-ID: <BFCE3818-A91A-4223-AF8D-4D7C7D9EED68@RichardElling.com>


On Feb 14, 2014, at 8:29 AM, Dan Swartzendruber <dswartz at druber.com> wrote:

> 
> I've been running an install on r151008.  rpool mirrored on two WD black
> 160GB sata drives.  8 SAS nearline drives in a raid10.  Two samsung 840PRO
> 128GB drives as l2arc.  The sas and l2arc drives are on an LSI HBA, and
> the rpool on motherboard sata ports.  Twice now, I've had drives disappear
> - the first time was one of the rpool drives, and yesterday one of the
> l2arc drives.  The symptom is that zpool status shows thousands of
> read/write errors and the drive is offlined.  If I run the format command,
> it shows that drive as 'unknown drive type'.  I apologize for not getting
> more specific data - the first time, I wrote off as an anomaly, but
> yesterday I really should have cut&pasted anything relevant.  Anyway, I'm
> puzzled that there seems no common hardware or driver factor.  The rpool
> drives are sata, and are using the sata-phy driver (I think that's what I
> dug out of prtconf -v), whereas, although the l2arc drives are sata, since
> they are on the lsi hba, they are using the sas-mpt driver.  I wasn't that
> concerned about yesterday's incident, since l2arc drives could both die
> suddenly and not take things down, but having rpool go bye-bye is not good
> - this is why I was paranoid and mirrored it.  Any ideas?  If this happens
> again, what should I look for?

?fmadm faulty? and "fmdump -eV? sheds a lot of light on these sorts of problems.
 ? richard

-- 

ZFS storage and performance consulting at http://www.RichardElling.com







From dswartz at druber.com  Tue Feb 18 14:15:49 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Tue, 18 Feb 2014 09:15:49 -0500
Subject: [OmniOS-discuss] Disappearing drives?
In-Reply-To: <BFCE3818-A91A-4223-AF8D-4D7C7D9EED68@RichardElling.com>
References: <d59adc2cacdcc467e372cf0c5c3b57e0.squirrel@webmail.druber.com>
	<BFCE3818-A91A-4223-AF8D-4D7C7D9EED68@RichardElling.com>
Message-ID: <0a6f4c57871ffbfbd813161d96532c72.squirrel@webmail.druber.com>


Thanks, Richard.  I will make a note of this...


From jimklimov at cos.ru  Tue Feb 18 18:40:37 2014
From: jimklimov at cos.ru (Jim Klimov)
Date: Tue, 18 Feb 2014 19:40:37 +0100
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
Message-ID: <5303A925.6060209@cos.ru>

On 2014-02-18 08:05, Richard Elling wrote:
> Fortunately, most real workloads are not tar -x.

Oh, alas, on build farms they are. And the hordes of files produced
as a result of "make" are not far behind. Oh, well, often they are
behind - and subsequent accesses fail for a few seconds, just until
something syncs down the pipe and back to the client. So the typical
mantra is "gmake -j -k all; gmake all" for producing as many objects
as we can first, and then cleaning up the mess sequentially :)

//Jim


From anhquach at me.com  Wed Feb 19 00:17:18 2014
From: anhquach at me.com (Anh Quach)
Date: Tue, 18 Feb 2014 16:17:18 -0800
Subject: [OmniOS-discuss] Granular control of fma modules
Message-ID: <etPan.5303f80e.79e2a9e3.4ee@abp.local>

Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks??

I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates.?

Thanks in advance!

--?
Anh Quach
Sent with Airmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140218/2ead818b/attachment.html>

From hakansom at ohsu.edu  Wed Feb 19 02:41:13 2014
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Tue, 18 Feb 2014 18:41:13 -0800
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: Message from Derek Yarnell <derek@umiacs.umd.edu>
	of "Mon, 17 Feb 2014 20:48:55 EST." <5302BC07.9070304@umiacs.umd.edu>
Message-ID: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu>

Derek Yarnell wrote:
>>> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped
>>> as a Pliant-LB206S-D323-186.31GB via format.

Richard Elling wrote:
>> Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized 
for
>> lots of concurrent I/O operations. This is not the kind of workload 
generated
>> by the ZIL, which is more contiguous, single thread-like.

Derek Yarnell wrote:
> I realize that they may not be as good as Stec/HGST ZeusRAM drives for
> the slog.  I still can't wrap my head around that it is as bad as having
> no discrete slog.

Hi Derek,

No better than with the ZIL running on the pool's HDD's?  Really?

Out of curiosity, what HBA is being used for these drives (and slog)
in this R720xd, H710 or H310?  Something else?

I'm also looking at the R720xd here, though I was thinking of using the
Intel DC S3700 SSD for a log device (in one of the internal flex-bay's),
with the pool drives being of the 2.5" form-factor.

Regards,

Marion



From danmcd at omniti.com  Wed Feb 19 02:51:18 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Tue, 18 Feb 2014 21:51:18 -0500
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu>
References: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu>
Message-ID: <BA478EDB-0E47-4C08-BD47-AFA9C041A864@omniti.com>


On Feb 18, 2014, at 9:41 PM, Marion Hakanson <hakansom at ohsu.edu> wrote:

> Derek Yarnell wrote:
>>>> So we bought a new Dell R720xd with 2 Dell SLC SSDs which were shipped
>>>> as a Pliant-LB206S-D323-186.31GB via format.
> 
> Richard Elling wrote:
>>> Pliant SSDs (note: Pliant was purchased by Sandisk in 2011) are optimized 
> for
>>> lots of concurrent I/O operations. This is not the kind of workload 
> generated
>>> by the ZIL, which is more contiguous, single thread-like.
> 
> Derek Yarnell wrote:
>> I realize that they may not be as good as Stec/HGST ZeusRAM drives for
>> the slog.  I still can't wrap my head around that it is as bad as having
>> no discrete slog.
> 
> Hi Derek,
> 
> No better than with the ZIL running on the pool's HDD's?  Really?
> 
> Out of curiosity, what HBA is being used for these drives (and slog)
> in this R720xd, H710 or H310?  Something else?
> 
> I'm also looking at the R720xd here, though I was thinking of using the
> Intel DC S3700 SSD for a log device (in one of the internal flex-bay's),
> with the pool drives being of the 2.5" form-factor.

The H710 sticks you with HW-RAID.  Ick.

The H310 allows you to use raw SAS disks, BUT I've encountered problems with BIOS failing INT13 reads on H310 raw disks, which makes booting difficult.  (Also some Dell-issued disks require power entries in /kernel/drv/sd.conf.)

Just be cautious when using the Dell HBAs.

Dan


From derek at umiacs.umd.edu  Wed Feb 19 03:09:51 2014
From: derek at umiacs.umd.edu (Derek Yarnell)
Date: Tue, 18 Feb 2014 22:09:51 -0500
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu>
References: <201402190241.s1J2fDEn004342@kyklops.ohsu.edu>
Message-ID: <5304207F.9010406@umiacs.umd.edu>

On 2/18/14, 9:41 PM, Marion Hakanson wrote:
> No better than with the ZIL running on the pool's HDD's?  Really?

Yes it would seem I was getting just as bad svc_t from these Pliant SSDs
then from the pools spinners.

> Out of curiosity, what HBA is being used for these drives (and slog)
> in this R720xd, H710 or H310?  Something else?

This is a R720xd shipped with a pristine LSI card (mine even came with
IT firmware).  You will need to talk to your rep but they can do it.  My
hope here was to get a fully supported OmniOS box from Dell which the
biggest problem was before making me take a H710/H800 card.  While we
have been successful running ZFS with a R510 w/ H700s drives all in R0
and setting zfs_nocacheflush it just isn't right.  We have also never
gone more than 9 data drives with the R0 configuration (also this has
been mostly on Nexenta not Omni).

> 
> I'm also looking at the R720xd here, though I was thinking of using the
> Intel DC S3700 SSD for a log device (in one of the internal flex-bay's),
> with the pool drives being of the 2.5" form-factor.

The R720xd flex bays are no longer internal but in the back of the
machine[1].  I actually will test some spare DC S3700 drives as the slog
devices that we have for a Ceph cluster in this in the next few days and
will report back on this thread.

One also thing to note is that Dell "Enterprise" drives have this
problem of not spinning up[2] which made for a very fun to get
installed.  I had to install on a non-dell disk that was equal or
smaller than my OS disks then modify the /kernel/drv/sd.conf file, then
mirror the rpool reboot and then detach the non-dell drive and add the
other drive back to the mirror.

[1] - http://www.anchor.com.au/blog/2012/10/shiny-new-hardware-dell-r720xd/
[2] - https://www.illumos.org/issues/2091

Thanks,
derek

-- 
Derek T. Yarnell
University of Maryland
Institute for Advanced Computer Studies

From hakansom at ohsu.edu  Wed Feb 19 03:54:05 2014
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Tue, 18 Feb 2014 19:54:05 -0800
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: Message from Derek Yarnell <derek@umiacs.umd.edu>
	of "Tue, 18 Feb 2014 22:09:51 EST." <5304207F.9010406@umiacs.umd.edu>
Message-ID: <201402190354.s1J3s59O004444@kyklops.ohsu.edu>

Thanks for everybody's comments.  More data from folks doing similar stuff
is always welcome.


Marion Hakanson wrote:
>> Out of curiosity, what HBA is being used for these drives (and slog)
>> in this R720xd, H710 or H310?  Something else?
> 
Derek Yarnell wrote:
> This is a R720xd shipped with a pristine LSI card (mine even came with
> IT firmware).  You will need to talk to your rep but they can do it.  My
> hope here was to get a fully supported OmniOS box from Dell which the
> biggest problem was before making me take a H710/H800 card.  While we
> have been successful running ZFS with a R510 w/ H700s drives all in R0
> and setting zfs_nocacheflush it just isn't right.  We have also never
> gone more than 9 data drives with the R0 configuration (also this has
> been mostly on Nexenta not Omni).

We have quite a few R710's with the PERC/6i internally, but for those used
as ZFS file servers, the PERC's only apply to the two boot drives, where
the "R0" approach is relatively painless.  BTW, with these RAID HBA's that
have non-volatile caches, you shouldn't need "zfs_nocacheflush" -- the OS
recognizes when a cache is NV, and won't send a flush.  That's been my
experience since late 2008, anyway.

We've had mixed results when asking Dell to send us LSI-branded HBA's.
Sometimes they'll do it, sometimes not.  Lately, we've gotten them to
sell us Dell branded SAS 6gbps HBA's for use with external MD1200's,
and those seem to be working just like LSI 9200-8e's & 9207-8e's.

Anyway, thanks for the suggestion, I'll see what our rep can do for the
internal HBA.  That would be much nicer than having to deal with possible
H310 glitches.


> The R720xd flex bays are no longer internal but in the back of the
> machine[1].

Well, that's close enough to "internal" for my purposes (:-).  We have
an Oracle X4270-M2 configured like that, now 3+ years old.  Very nice
layout, it's a pity they stopped selling them to mere mortals.


> I actually will test some spare DC S3700 drives as the slog
> devices that we have for a Ceph cluster in this in the next few days and
> will report back on this thread.

Cool, I look forward to seeing what you find out.

Thanks and regards,

Marion



From doug at will.to  Wed Feb 19 04:11:30 2014
From: doug at will.to (Doug Hughes)
Date: Tue, 18 Feb 2014 23:11:30 -0500
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <201402190354.s1J3s59O004444@kyklops.ohsu.edu>
References: <201402190354.s1J3s59O004444@kyklops.ohsu.edu>
Message-ID: <53042EF2.6020703@will.to>

On 2/18/2014 10:54 PM, Marion Hakanson wrote:
> Thanks for everybody's comments.  More data from folks doing similar stuff
> is always welcome.
>
>
> Marion Hakanson wrote:
>>> Out of curiosity, what HBA is being used for these drives (and slog)
>>> in this R720xd, H710 or H310?  Something else?
>>
> Derek Yarnell wrote:
>> This is a R720xd shipped with a pristine LSI card (mine even came with
>> IT firmware).  You will need to talk to your rep but they can do it.  My
>> hope here was to get a fully supported OmniOS box from Dell which the
>> biggest problem was before making me take a H710/H800 card.  While we
>> have been successful running ZFS with a R510 w/ H700s drives all in R0
>> and setting zfs_nocacheflush it just isn't right.  We have also never
>> gone more than 9 data drives with the R0 configuration (also this has
>> been mostly on Nexenta not Omni).
>
> We have quite a few R710's with the PERC/6i internally, but for those used
> as ZFS file servers, the PERC's only apply to the two boot drives, where
> the "R0" approach is relatively painless.  BTW, with these RAID HBA's that
> have non-volatile caches, you shouldn't need "zfs_nocacheflush" -- the OS
> recognizes when a cache is NV, and won't send a flush.  That's been my
> experience since late 2008, anyway.
>
> We've had mixed results when asking Dell to send us LSI-branded HBA's.
> Sometimes they'll do it, sometimes not.  Lately, we've gotten them to
> sell us Dell branded SAS 6gbps HBA's for use with external MD1200's,
> and those seem to be working just like LSI 9200-8e's & 9207-8e's.
>
> Anyway, thanks for the suggestion, I'll see what our rep can do for the
> internal HBA.  That would be much nicer than having to deal with possible
> H310 glitches.
>
>
>> The R720xd flex bays are no longer internal but in the back of the
>> machine[1].
>
> Well, that's close enough to "internal" for my purposes (:-).  We have
> an Oracle X4270-M2 configured like that, now 3+ years old.  Very nice
> layout, it's a pity they stopped selling them to mere mortals.
>
>
>> I actually will test some spare DC S3700 drives as the slog
>> devices that we have for a Ceph cluster in this in the next few days and
>> will report back on this thread.
>
> Cool, I look forward to seeing what you find out.
>
> Thanks and regards,
>

We've used S3700 as SLOG. it's a fine device for that. I find the 
current price point for the Intel 320 series to be hard to beat though. 
It's just over $1/GB. It also seems to perform better than the DCS3700 
on the tests that I've run that seem to be reasonable predictors, up to 
20%.

The worst case for NFS performance tends to be lots of synchronous 
metadata operations, so I have a test that creates 100 0 byte files in 
each of 100 directories. And then an rm -rf on the lot. The rm 
difference is insignificant.

I didn't compare exactly the same physical hardware (machine or data 
disks) though, so in the end the performance difference may not be that 
significant.

From derek at umiacs.umd.edu  Wed Feb 19 19:59:27 2014
From: derek at umiacs.umd.edu (Derek Yarnell)
Date: Wed, 19 Feb 2014 14:59:27 -0500
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <201402190354.s1J3s59O004444@kyklops.ohsu.edu>
References: <201402190354.s1J3s59O004444@kyklops.ohsu.edu>
Message-ID: <53050D1F.2070505@umiacs.umd.edu>

On 2/18/14, 10:54 PM, Marion Hakanson wrote:
>> I actually will test some spare DC S3700 drives as the slog
>> devices that we have for a Ceph cluster in this in the next few days and
>> will report back on this thread.
> 
> Cool, I look forward to seeing what you find out.

For a 44MB/1981 file tar file.

With DC S3700 drive in slog (ATA-INTEL SSDSC2BA10-0265-93.16GB)

# time tar -xf littletarfile.tar

real	0m8.337s
user	0m0.056s
sys	0m0.659s

With Pliant LB206S drive in slog (Pliant-LB206S-D323-186.31GB)

# time tar -xf littletarfile.tar

real	8m43.268s
user	0m0.109s
sys	0m1.493s

With no slog

# time tar -xf littletarfile.tar

real	9m17.243s
user	0m0.127s
sys	0m1.409s


-- 
Derek T. Yarnell
University of Maryland
Institute for Advanced Computer Studies

From hakansom at ohsu.edu  Wed Feb 19 21:14:58 2014
From: hakansom at ohsu.edu (Marion Hakanson)
Date: Wed, 19 Feb 2014 13:14:58 -0800
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: Message from Derek Yarnell <derek@umiacs.umd.edu>
	of "Wed, 19 Feb 2014 14:59:27 EST." <53050D1F.2070505@umiacs.umd.edu>
Message-ID: <201402192114.s1JLEwQ2005540@kyklops.ohsu.edu>

derek at umiacs.umd.edu said:
> For a 44MB/1981 file tar file.
> 
> With DC S3700 drive in slog (ATA-INTEL SSDSC2BA10-0265-93.16GB)
> # time tar -xf littletarfile.tar
> real	0m8.337s
> user	0m0.056s
> sys	0m0.659s
> 
> With Pliant LB206S drive in slog (Pliant-LB206S-D323-186.31GB)
> # time tar -xf littletarfile.tar
> real	8m43.268s
> user	0m0.109s
> sys	0m1.493s
> 
> With no slog
> # time tar -xf littletarfile.tar
> real	9m17.243s
> user	0m0.127s
> sys	0m1.409s

Wow.  One review I read says the LB206S has no DRAM cache, thus it's not
prone to power-fail data loss.  The DC S3700 does have such a cache, but
with capacitor protection.  Good latency for small ops, eh?

Thanks and regards,

Marion



From alex at cooperi.net  Thu Feb 20 03:58:06 2014
From: alex at cooperi.net (Alex Wilson)
Date: Thu, 20 Feb 2014 13:58:06 +1000
Subject: [OmniOS-discuss] Granular control of fma modules
In-Reply-To: <etPan.5303f80e.79e2a9e3.4ee@abp.local>
References: <etPan.5303f80e.79e2a9e3.4ee@abp.local>
Message-ID: <94925D68-A787-4BF4-9A26-AD9CF80D7268@cooperi.net>

I?ve been recently trying to find a way to get disk-transport to ignore certain SMART values when deciding if a disk is going to fail ? in particular, the Seek Error figures, which Seagate drives tend to make out to be a lot more significant than they really are, using a different scale to everyone else. I had a look through the code for disk-transport though and it doesn?t seem like it can do very much to help: the module itself is pretty dumb and just passes on errors from deeper down in the libraries it uses (where there is also no means of filtering out events).

The closest you can get is to use ?fmadm acquit?, but it doesn?t seem to work for me ? it clears out the fault that?s there for the moment, but doesn?t block it from coming back again, even though the man page suggests that it should. I guess this is because of disk-transport generating new UUIDs for each individual event rather than on the type of event? It?s a bit annoying.

I?d really like a disk-transport.conf var to say ?ignore this particular type of SMART data? or ?ignore it for these disks?. Maybe I should sit down and try to write some code for it...



On 19 Feb 2014, at 10:17 am, Anh Quach <anhquach at me.com> wrote:

> Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks? 
> 
> I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates. 
> 
> Thanks in advance!
> 
> -- 
> Anh Quach
> Sent with Airmail
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

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

From mariusz.stanczak at gmail.com  Thu Feb 20 12:36:32 2014
From: mariusz.stanczak at gmail.com (M.S.)
Date: Thu, 20 Feb 2014 04:36:32 -0800
Subject: [OmniOS-discuss] SUNW* libraries
In-Reply-To: <201402161733.s1GHX35H011496@elvis.arl.psu.edu>
References: <20140216023558.b34940c1f29e5a71f49d4cdd@gmail.com>
	<201402161733.s1GHX35H011496@elvis.arl.psu.edu>
Message-ID: <20140220043632.d66a9c6a7ac34b0b68385cf0@gmail.com>

On Sun, 16 Feb 2014 12:33:03 -0500 John D Groenveld <jdg117 at elvis.arl.psu.edu> wrote:
> In message <20140216023558.b34940c1f29e5a71f49d4cdd at gmail.com>, Mariusz Stancza
> k writes:
> >be what they seem to.  So, what's the story with those libs.
> 
> The libraries are not supported by OmniTI.
> 
> However, /kernel/drv/amd64/nvidia from NVDAgraphicsr package is not
> dependent on them.

Works well enough.

Thanks,
/Mariusz

> 
> John
> groenveld at acm.org
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss


--- 
M.S. <Mariusz.Stanczak at gmail.com>

From mweiss at cimlbr.com  Thu Feb 20 17:06:40 2014
From: mweiss at cimlbr.com (Matt Weiss)
Date: Thu, 20 Feb 2014 11:06:40 -0600
Subject: [OmniOS-discuss] Performance Issues
In-Reply-To: <348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
References: <530291DA.6050009@umiacs.umd.edu>	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
Message-ID: <53063620.3020404@cimlbr.com>

I am having some major performance issues and cannot figure out why.

All-in-one box sharing storage with NFS
 From Veaam (another vm on same box) I am getting 55 MB/s backup 
speeds.  Everything has vmware tools 5.5 installed and shows up as a 10 
Gbit adapter.
Veeam says my bottleneck is source (which would be the omnios vm)

I have a 2nd box setup with freenas on a smaller supermicro with similar 
specs but with an expander backplane and WD Red drives.
I can write to that at 156 MB/s

In general, the system just seems way slower than it should be, not just 
from veeam.  iostats on the zpool don't seem to be really hitting things 
all that hard.

What can I do to narrow this down?


SPECS and info:

Supermicro SC846A-R900B (Direct Attach, 6 SFF 8087)
Supermicro X9DR7-LN4F-JBOD
14x  Seagate 4TB Constellation ES.3 3.5" 7200RPM SAS ST4000NM0023
2x   Intel Xeon E5-2620V2 2.1GHZ 15MB DDR3 Up to 1866MHZ 6C
256 GB ram 16 Axiom Memory Solutions 16GB DDR3-1600 ECC Rdimm-
1 STEC Zues RAM 6 GB SAS 8 GB
2 x LSI 9207-8I plus onboard motherboard lsi
10 Gbit ethernet via Intel TX540

All 6 SFF connections from the 2308 lsi's are hooked up to the 6 
connections on the backplane of the supermicro case.

Here is my zpool info:

zpool status tank
   pool: tank
  state: ONLINE
   scan: scrub repaired 0 in 16h54m with 0 errors on Tue Feb  4 11:54:24 
2014
config:

         NAME                       STATE     READ WRITE CKSUM
         tank                       ONLINE       0     0     0
           mirror-1                 ONLINE       0     0     0
             c4t5000C5005702158Fd0  ONLINE       0     0     0
             c4t5000C500570880CBd0  ONLINE       0     0     0
           mirror-2                 ONLINE       0     0     0
             c4t5000C500572792B3d0  ONLINE       0     0     0
             c4t5000C5005731D42Bd0  ONLINE       0     0     0
           mirror-3                 ONLINE       0     0     0
             c4t5000C5005731DA97d0  ONLINE       0     0     0
             c4t5000C5005731DBD3d0  ONLINE       0     0     0
           mirror-4                 ONLINE       0     0     0
             c4t5000C5005731DEFBd0  ONLINE       0     0     0
             c4t5000C5005731DF4Fd0  ONLINE       0     0     0
           mirror-5                 ONLINE       0     0     0
             c4t5000C5005731F03Fd0  ONLINE       0     0     0
             c4t5000C500573209EBd0  ONLINE       0     0     0
           mirror-6                 ONLINE       0     0     0
             c4t5000C50057320E5Bd0  ONLINE       0     0     0
             c4t5000C50057321177d0  ONLINE       0     0     0
           mirror-7                 ONLINE       0     0     0
             c4t5000C5005732F953d0  ONLINE       0     0     0
             c4t5000C50057330B27d0  ONLINE       0     0     0
         logs
           c6t5000A72A3008DF19d0    ONLINE       0     0     0
         cache
           c4t50025388A01D572Cd0    ONLINE       0     0     0
         spares
           c4t5000C500570212AFd0    AVAIL

errors: No known data errors

logs: zuesram
cache: samsung 840 evo (just added yesterday)


uname -a
SunOS omnios.kcgo.com 5.11 omnios-b281e50 i86pc i386 i86pc



This is currently a napp-it all in one box.

Vmware 5.1 sharing a OmniOS vmbox with
8 cpu
64 GB ram All reserved






From tim at multitalents.net  Thu Feb 20 17:32:24 2014
From: tim at multitalents.net (Tim Rice)
Date: Thu, 20 Feb 2014 09:32:24 -0800 (PST)
Subject: [OmniOS-discuss] Performance Issues
In-Reply-To: <53063620.3020404@cimlbr.com>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
	<53063620.3020404@cimlbr.com>
Message-ID: <Pine.UW2.4.64.1402200930060.28579@server01.int.multitalents.net>

On Thu, 20 Feb 2014, Matt Weiss wrote:

> I am having some major performance issues and cannot figure out why.
[snip]
> 
> This is currently a napp-it all in one box.
> 
> Vmware 5.1 sharing a OmniOS vmbox with
> 8 cpu
> 64 GB ram All reserved

What happens if you drop the OmniOS VM down to 2 CPU?

-- 
Tim Rice				Multitalents
tim at multitalents.net



From dswartz at druber.com  Thu Feb 20 17:41:23 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 20 Feb 2014 12:41:23 -0500
Subject: [OmniOS-discuss] Performance Issues
In-Reply-To: <Pine.UW2.4.64.1402200930060.28579@server01.int.multitalents.net>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
	<53063620.3020404@cimlbr.com>
	<Pine.UW2.4.64.1402200930060.28579@server01.int.multitalents.net>
Message-ID: <68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com>

> On Thu, 20 Feb 2014, Matt Weiss wrote:
>
>> I am having some major performance issues and cannot figure out why.
> [snip]
>>
>> This is currently a napp-it all in one box.
>>
>> Vmware 5.1 sharing a OmniOS vmbox with
>> 8 cpu
>> 64 GB ram All reserved
>
> What happens if you drop the OmniOS VM down to 2 CPU?

Yeah, I am wondering that too.  I am very skeptical you would ever need
more than 2 threads to service a network link that size.  Too many cores
for a VM can actually hurt performance.


From anhquach at me.com  Thu Feb 20 19:03:38 2014
From: anhquach at me.com (Anh Quach)
Date: Thu, 20 Feb 2014 11:03:38 -0800
Subject: [OmniOS-discuss] Granular control of fma modules
In-Reply-To: <94925D68-A787-4BF4-9A26-AD9CF80D7268@cooperi.net>
References: <etPan.5303f80e.79e2a9e3.4ee@abp.local>
	<94925D68-A787-4BF4-9A26-AD9CF80D7268@cooperi.net>
Message-ID: <etPan.5306518a.507ed7ab.12a0@abp.local>

Thanks for the reply, Alex.?

Yeah, to my knowledge fmadm acquit seems to just clear the one unique event. From a ?for your own good? standpoint, it makes sense that one probably shouldn?t be disabling this kind of stuff, but I?m surprised the .conf has no way of filtering by SMART data. Looks like you can set these properties:?

setprop temp-multiple ? ??
setprop selftest-multiple?
setprop smart-multiple

but no granular control for specific devices.?

--?
Anh Quach
Sent with Airmail

On February 19, 2014 at 8:04:20 PM, Alex Wilson (alex at cooperi.net) wrote:

I?ve been recently trying to find a way to get disk-transport to ignore certain SMART values when deciding if a disk is going to fail ? in particular, the Seek Error figures, which Seagate drives tend to make out to be a lot more significant than they really are, using a different scale to everyone else. I had a look through the code for disk-transport though and it doesn?t seem like it can do very much to help: the module itself is pretty dumb and just passes on errors from deeper down in the libraries it uses (where there is also no means of filtering out events).

The closest you can get is to use ?fmadm acquit?, but it doesn?t seem to work for me ? it clears out the fault that?s there for the moment, but doesn?t block it from coming back again, even though the man page suggests that it should. I guess this is because of disk-transport generating new UUIDs for each individual event rather than on the type of event? It?s a bit annoying.

I?d really like a disk-transport.conf var to say ?ignore this particular type of SMART data? or ?ignore it for these disks?. Maybe I should sit down and try to write some code for it...



On 19 Feb 2014, at 10:17 am, Anh Quach <anhquach at me.com> wrote:

Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks??

I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates.?

Thanks in advance!

--?
Anh Quach
Sent with Airmail
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

_______________________________________________  
OmniOS-discuss mailing list  
OmniOS-discuss at lists.omniti.com  
http://lists.omniti.com/mailman/listinfo/omnios-discuss  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140220/d4750be5/attachment.html>

From mweiss at cimlbr.com  Thu Feb 20 19:16:33 2014
From: mweiss at cimlbr.com (Matt Weiss)
Date: Thu, 20 Feb 2014 13:16:33 -0600
Subject: [OmniOS-discuss] Performance Issues
In-Reply-To: <68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com>
References: <530291DA.6050009@umiacs.umd.edu>	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>	<5302BC07.9070304@umiacs.umd.edu>	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>	<53063620.3020404@cimlbr.com>	<Pine.UW2.4.64.1402200930060.28579@server01.int.multitalents.net>
	<68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com>
Message-ID: <53065491.8000306@cimlbr.com>

I will try that as soon as I can take down the array.  10 Gbit on one 
array shouldn't need more than 2 new CPU cores eh?

On 2/20/2014 11:41 AM, Dan Swartzendruber wrote:
>> On Thu, 20 Feb 2014, Matt Weiss wrote:
>>
>>> I am having some major performance issues and cannot figure out why.
>> [snip]
>>> This is currently a napp-it all in one box.
>>>
>>> Vmware 5.1 sharing a OmniOS vmbox with
>>> 8 cpu
>>> 64 GB ram All reserved
>> What happens if you drop the OmniOS VM down to 2 CPU?
> Yeah, I am wondering that too.  I am very skeptical you would ever need
> more than 2 threads to service a network link that size.  Too many cores
> for a VM can actually hurt performance.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss



From dswartz at druber.com  Thu Feb 20 19:24:50 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 20 Feb 2014 14:24:50 -0500
Subject: [OmniOS-discuss] Performance Issues
In-Reply-To: <53065491.8000306@cimlbr.com>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
	<53063620.3020404@cimlbr.com>
	<Pine.UW2.4.64.1402200930060.28579@server01.int.multitalents.net>
	<68d7af76a5122fe39d8108143d962f83.squirrel@webmail.druber.com>
	<53065491.8000306@cimlbr.com>
Message-ID: <f7de9bcc32b2d6a37a354b0acef17aae.squirrel@webmail.druber.com>

> I will try that as soon as I can take down the array.  10 Gbit on one
> array shouldn't need more than 2 new CPU cores eh?

Well, it might or it might not.  You'd have to know for sure that even if
it does, the guest is multi-threaded enough to take advantage of them. 
Note that if you give too many cores to a guest, vsphere can have problems
scheduling the guest, so latency and performance in general might suck. 
If you run with two cores and performance is not good enough, look at how
much CPU is being used...


From paladinemishakal at gmail.com  Fri Feb 21 15:05:02 2014
From: paladinemishakal at gmail.com (Lawrence Giam)
Date: Fri, 21 Feb 2014 23:05:02 +0800
Subject: [OmniOS-discuss] SolarFlare 10GB network card
Message-ID: <CAGueQCfnGrbvxvgvmw_ynwj-AzJ+5Ua+RFjFT1PZu2ScE=2DTg@mail.gmail.com>

Hi All,

I have a Solarflare SFN5122F Dual-Port 10GbE SFP+ Onload Server Adapter
which I would like to use with OmniOS and I am currently using r150008j.

>From this post on the OmniOS-discuss,
http://lists.omniti.com/pipermail/omnios-discuss/2013-August/001254.html ,
someone mentioned the sfxge driver is being integrate into the illumos tree.

Is this release to the stable release? Where can I find information on how
to install the drivers?

Thanks & Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140221/866cf92b/attachment.html>

From danmcd at omniti.com  Fri Feb 21 15:14:17 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Fri, 21 Feb 2014 10:14:17 -0500
Subject: [OmniOS-discuss] SolarFlare 10GB network card
In-Reply-To: <CAGueQCfnGrbvxvgvmw_ynwj-AzJ+5Ua+RFjFT1PZu2ScE=2DTg@mail.gmail.com>
References: <CAGueQCfnGrbvxvgvmw_ynwj-AzJ+5Ua+RFjFT1PZu2ScE=2DTg@mail.gmail.com>
Message-ID: <AF7B5229-9CB0-4494-A425-35025CC0BB0B@omniti.com>


On Feb 21, 2014, at 10:05 AM, Lawrence Giam <paladinemishakal at gmail.com> wrote:

> Hi All,
> 
> I have a Solarflare SFN5122F Dual-Port 10GbE SFP+ Onload Server Adapter which I would like to use with OmniOS and I am currently using r150008j.
> 
> From this post on the OmniOS-discuss, http://lists.omniti.com/pipermail/omnios-discuss/2013-August/001254.html , someone mentioned the sfxge driver is being integrate into the illumos tree.
> 
> Is this release to the stable release? Where can I find information on how to install the drivers?

It was put up for review on the Illumos list in August, but nobody reviewed it.  It's not in any illumos-gate or child (incl. illumos-omnios) yet.

You could compile it from source.  Heck, *I* could compile it from source if you're feeling brave and want to do some testing.  Reviewing a driver like this takes time, and properly testing it 10x as much time.  I'm not sure if the original poster on the Illumos list is here as well, but if he is, perhaps he can speak to how ready-or-not the code is.

Sorry I can't be of more immediate assistance,
Dan


From esproul at omniti.com  Fri Feb 21 15:24:16 2014
From: esproul at omniti.com (Eric Sproul)
Date: Fri, 21 Feb 2014 10:24:16 -0500
Subject: [OmniOS-discuss] SolarFlare 10GB network card
In-Reply-To: <AF7B5229-9CB0-4494-A425-35025CC0BB0B@omniti.com>
References: <CAGueQCfnGrbvxvgvmw_ynwj-AzJ+5Ua+RFjFT1PZu2ScE=2DTg@mail.gmail.com>
	<AF7B5229-9CB0-4494-A425-35025CC0BB0B@omniti.com>
Message-ID: <CA+QY2RQZk2Ebyq9F10TFu6JNztm3bSdJqrZKx_NCAm0VXdoO-g@mail.gmail.com>

On Fri, Feb 21, 2014 at 10:14 AM, Dan McDonald <danmcd at omniti.com> wrote:
> It was put up for review on the Illumos list in August, but nobody reviewed it.  It's not in any illumos-gate or child (incl. illumos-omnios) yet.

For the record, the issue report is https://www.illumos.org/issues/4057

From richard.elling at richardelling.com  Sun Feb 23 05:14:46 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Sat, 22 Feb 2014 21:14:46 -0800
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <5303A925.6060209@cos.ru>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
	<5303A925.6060209@cos.ru>
Message-ID: <6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com>

On Feb 18, 2014, at 10:40 AM, Jim Klimov <jimklimov at cos.ru> wrote:

> On 2014-02-18 08:05, Richard Elling wrote:
>> Fortunately, most real workloads are not tar -x.
> 
> Oh, alas, on build farms they are. And the hordes of files produced
> as a result of "make" are not far behind. Oh, well, often they are
> behind - and subsequent accesses fail for a few seconds, just until
> something syncs down the pipe and back to the client. So the typical
> mantra is "gmake -j -k all; gmake all" for producing as many objects
> as we can first, and then cleaning up the mess sequentially :)

For build farms, why do you care about NFS sync writes? This is the
canonical case for sync=disabled, because there is no unique data.
 ? richard

-- 

ZFS storage and performance consulting at http://www.RichardElling.com







From richard.elling at richardelling.com  Sun Feb 23 05:50:25 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Sat, 22 Feb 2014 21:50:25 -0800
Subject: [OmniOS-discuss] Granular control of fma modules
In-Reply-To: <etPan.5303f80e.79e2a9e3.4ee@abp.local>
References: <etPan.5303f80e.79e2a9e3.4ee@abp.local>
Message-ID: <989404F2-E09D-4681-9CD4-9614CD795518@RichardElling.com>

On Feb 18, 2014, at 4:17 PM, Anh Quach <anhquach at me.com> wrote:

> Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks? 

In Solaris 11, yes this is possible. However, the open source community has not implemented it
yet, AFAIK.

> 
> I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates. 

You can unload disk-transport altogether as a workaround. The root cause is a bug in
the Seagate firmware introduced in version 3 of their firmware. A fix is in the works 
for version 4, available RSN.
 ? richard

-- 

ZFS storage and performance consulting at http://www.RichardElling.com







From anhquach at me.com  Sun Feb 23 20:09:51 2014
From: anhquach at me.com (Anh Quach)
Date: Sun, 23 Feb 2014 12:09:51 -0800
Subject: [OmniOS-discuss] Granular control of fma modules
In-Reply-To: <989404F2-E09D-4681-9CD4-9614CD795518@RichardElling.com>
References: <etPan.5303f80e.79e2a9e3.4ee@abp.local>
	<989404F2-E09D-4681-9CD4-9614CD795518@RichardElling.com>
Message-ID: <etPan.530a558f.6b8b4567.423f@abp.local>

Thanks, Richard.?

Yeah, it seems in Solaris 11.1, you can disable over-temp in the disk-transport module in /usr/lib/fm/fmd/plugins/disk-transport.conf by:?

setprop temp-multiple 0

but it applies to all disks as far as I know. I haven?t found a way to only specify certain disks to be omitted. Anyway, is this parameter not implemented in OminOS then? I?ve got the module unloaded for now, as you suggested.?

Not a huge deal as we won?t be going with these Seagates in production, but a minor annoyance during testing. :)


--?
Anh Quach
Sent with Airmail

On February 22, 2014 at 9:49:59 PM, Richard Elling (richard.elling at richardelling.com) wrote:

On Feb 18, 2014, at 4:17 PM, Anh Quach <anhquach at me.com> wrote:  

> Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks?  

In Solaris 11, yes this is possible. However, the open source community has not implemented it  
yet, AFAIK.  

>  
> I?m doing testing with some Seagate Constellation.3?s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don?t want to disable it for all disks, just these new Seagates.  

You can unload disk-transport altogether as a workaround. The root cause is a bug in  
the Seagate firmware introduced in version 3 of their firmware. A fix is in the works  
for version 4, available RSN.  
? richard  

--  

ZFS storage and performance consulting at http://www.RichardElling.com  






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140223/745969e5/attachment.html>

From richard.elling at richardelling.com  Mon Feb 24 02:42:47 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Sun, 23 Feb 2014 18:42:47 -0800
Subject: [OmniOS-discuss] Overheating faults with ST4000NM0023
In-Reply-To: <52FC9C12.9090900@smartjog.com>
References: <6B4199959CFA4E1CB067BBF9270654CB@486dx4>
	<52FC9C12.9090900@smartjog.com>
Message-ID: <9970E697-9693-4405-A85C-9369DDD3048D@RichardElling.com>

Clarification below...

On Feb 13, 2014, at 2:18 AM, Thibault VINCENT <thibault.vincent at smartjog.com> wrote:

> On 02/12/2014 09:59 PM, Steamer wrote:
>> Did you ever find a solution to the overheating faults with the
>> ST4000NM0023?
>> 
>> I'm currently having the exact same issue with ST1000NM0023 drives,
>> seems like seagate has the user temp probe set at 40'C. The manual
>> states that the temperature settings are programmable via smart, but I
>> haven't found a way to do that.
> 
> Hello Emile,
> 
> I've found a workaround but the definitive fix should be handled by
> Illumos I guess. There is no open ticket, first I was waiting for
> something to happen with #4051 before going back to using that distro
> and kernel.
> 
> Here's the story:
> The SCSI specification defines two registers to store the temperature
> thresholds in SMART data. One contains the recommended maximum operation
> temperature for best MTBF, and the other register is for the absolute
> maximum rating. Usually the industry has always put the same value in
> both, and that is the absolute maximum.

Yes, because the SPC-4 (section 7.3.21.3) standard is very precise in its defined use. 
Seagate made a mistake and didn't follow the spec. AIUI, this is being corrected in firmware 
0004, available RSN.
 -- richard

> That's why we always see
> something like 60/65?C from SMART. But recently Seagate has changed that
> because it was asked by a large OS company to comply with the
> specification for better hardware monitoring integration. The change did
> not only occur in newer products but in a firmware update for existing
> disks and that was applied to the production line which explains some
> disks mays or may not expose this problem although they are the same
> model. Our disks are of the Megalodon serie and all share the same
> firmware basecode.
> 
> So any Seagate disk will now trigger faults in FMA if they have a
> firmware with the newer policy. Also I think other brands will follow
> the same path.
> 
> Like other members suggested in that thread, maybe nothing should change
> in FMA but let's face it, you can't maintain a temperature steadily
> under 40?C in a JBOD of hundreds of busy disks. Especially in
> eco-friendly datacenters. IMHO we should not trigger a fault on the
> lower threshold, and certainly not a drive retirement. It breaks storage
> servers on reboot or before a pool import, also spare disks could
> disappear with the retirement triggered.
> 
> The workaround is to downgrade firmware to the last version before the
> change, and to reset the register with an SCSI command. It is not
> possible to set the register to a user specified value like the
> documentation suggests, they confirmed it.
> 
> I'm sending a working firmware to you in a private mail. I'm not aware
> of any issue working with that older version and hopefully it should
> upload to 1TB drives as well.
> I'm applying it like this but from Linux not OmniOS:
> # ./dl_sea_fw-0.2.3_32 -f Megalodon_StdOEM_SAS_0002+C84C.lod -m ST4000NM0023
> # ./dl_sea_fw-0.2.3_32 -i
> 
> Then you should reset the drives so they reload the firmware.
> Here's our example for 4TB drives:
> -------------
> for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do
>  sg_reset -d $i
> done
> -------------
> 
> And reset the register that contains value from the previous firmware.
> It doesn't work well so we've got this script to run a few times until
> all disks got it. Again it matches 4TB Megalodon.
> -------------
> for i in $(lsscsi | grep 'ST4000NM0023' | awk '{print $6}') ; do
>  echo -n "$i "
>  if sg_logs $i --page=0x0d | grep 'Reference temperature = 68 C'
>> /dev/null ; then
>    echo 'ok'
>  else
>    sg_logs $i --page=0x0d --reset
>    echo 'reset'
>  fi
> done
> -------------
> 
> 
> Cheers
> 
> -- 
> Thibault VINCENT - Lead System Engineer, Infrastructure -
> Arkena | Phone: +33 1 58 68 62 38 | Mobile: +33 6 78 97 01 08
> 27 Blvd Hippolyte Marqu?s, 94200 Ivry-sur-Seine, France | www.arkena.com
> Arkena - Ready to Play
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

--

Richard.Elling at RichardElling.com
+1-760-896-4422



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

From groups at tierarzt-mueller.de  Mon Feb 24 20:23:46 2014
From: groups at tierarzt-mueller.de (Alexander Lesle)
Date: Mon, 24 Feb 2014 21:23:46 +0100
Subject: [OmniOS-discuss] unknown kernel-crash
Message-ID: <1596969154.20140224212346@tierarzt-mueller.de>

Hello All,

I have here a new server and the kernel crashes and I cant find why.
Now I hope I get some help and a solution here.

Supermicro X10SLH-F, XEON E3-1230, 32GB ECC RAM, 2 x SSD Samsung 840,
LSI 9211-8i
On the first SSD ESXi5.5 and on the second SSD Omnios r151008f and
napp-it appliance as VM (1 socket, 2 cores, 16GB RAM reserved)
The rpool is customize with Paul Hensons script - I have changed:
,-----[  ]-----
| # uncomment to set size of s0 on install disk (in format syntax)
| #$rpool_size = '30gb';
| 
| # uncomment to add additional options for zpool create
| $rpool_opts = '-O compression=lz4 -O copies=2 -O checksum=sha256
| -O atime=off';
`-------------------
My data pool is a 3-way-mirror. One extra fs for other VMs.
This crash I reported here I do an new VM installation. Before crash
the CPU push up to 100%, Omnios getting very slow and the VM install
too.
Thats not the only one crash but this crash I am sitting in front of
the screen.

Panic was at Feb 23 17:30:37
See attachments please.
In putty.log the output from:
root at aio:~# fmadm faulty
root at aio:~# fmdump -Vp -u c040c25b-b481-ea5c-a1a6-a7cb74097521
root at aio:~# fmstat
root at aio:~# fmdump -e
root at aio:~# fmdump -eV
root at aio:~# fmdump -I

This messages confused me too:
genunix: [ID 723599 kern.warning] WARNING: Driver alias "pciex8086,1526" conflicts with an existing driver name or alias.
genunix: [ID 127566 kern.info] device pciclass,030000 at f(display#0) keeps up device sd at 0,0(sd#1), but the former is not power managed
smbd[556]: [ID 413393 daemon.error] dyndns: failed to get domainname

Thanks in advance.

-- 
Best Regards
Alexander
Februar, 24 2014

Attachments / Dateianlagen:
----------------------------
[1] putty.log
[2] messages.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: putty.log
Type: application/octet-stream
Size: 43415 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140224/434eb496/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: messages.0
Type: application/octet-stream
Size: 144528 bytes
Desc: not available
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140224/434eb496/attachment-0003.obj>

From paladinemishakal at gmail.com  Tue Feb 25 13:42:03 2014
From: paladinemishakal at gmail.com (Lawrence Giam)
Date: Tue, 25 Feb 2014 21:42:03 +0800
Subject: [OmniOS-discuss] fmd core dump in r150008j
Message-ID: <CAGueQCduf3Quv9dXOQmQjRjf-4qu+R52DgyGDgF=cPne6KfxfA@mail.gmail.com>

Hi All,

I have a new server and today I got an alert that diskspace was almost
fully used up. Checking on the system, I found that under /var/fm/fmd,
there is a core dump file. I checked /var/adm/messages and fmdump, cannot
find anything suspicious.

I am running OmniOS r150008j.

This is an analysis of the core dump.

root at sgbk02:/tankD01/backups/sgsan1n1/fmd# mdb core.fmd.559
Loading modules: [ fmd libumem.so.1 libc.so.1 libnvpair.so.1 libtopo.so.1
libuutil.so.1 libavl.so.1 libsysevent.so.1 eft.so ld.so.1 ]
> $c
libc.so.1`_lwp_kill+0x15(4, 6, 6786, fef56000, fef56000, 95)
libc.so.1`raise+0x2b(6, 0, fda5ea00, feed5a09, 0, 0)
libc.so.1`abort+0x10e(3a646d66, 4f424120, 203a5452, 75736e69, 63696666,
746e6569)
fmd_panic(80835e0, fda5ee84, 1, 0)
fmd_panic+0x12(80835e0, 50, 3e8, feb0e8e4)
fmd_alloc+0x81(50, 1, 80, e3b74613, 1, 3b9aca00)
fmd_event_create+0x18(1, 88fe3252, 11f57f, 0, fbd3ab30, 896ab30)
fmd_module_timeout+0x20(fbd3ab30, c4, 88fe3252, 11f57f, 8393e08)
fmd_timerq_exec+0x127(8393e00, 0, fed922a0, fef56000)
fmd_thread_start+0x5b(819e6d0, 0, 0, 0)
libc.so.1`_thrp_setup+0x88(fed92240)
libc.so.1`_lwp_start(fed92240, 0, 0, 0, 0, 0)

> ::showrev
Hostname: sgsan1n1
Release: 5.11
Kernel architecture: i86pc
Application architecture: i386
Kernel version: SunOS 5.11 i86pc omnios-6de5e81
Platform: i86pc

> ::status
debugging core file of fmd (32-bit) from sgsan1n1
file: /usr/lib/fm/fmd/fmd
initial argv: /usr/lib/fm/fmd/fmd
threading model: native threads
status: process terminated by SIGABRT (Abort), pid=559 uid=0 code=-1

> $r
%cs = 0x0043            %eax = 0x00000000
%ds = 0x004b            %ebx = 0xfef56000
%ss = 0x004b            %ecx = 0xfda5e9ac
%es = 0x004b            %edx = 0x00000000
%fs = 0x0000            %esi = 0x00000095
%gs = 0x01c3            %edi = 0x080835e0

 %eip = 0xfeee78b5 libc.so.1`_lwp_kill+0x15
 %ebp = 0xfda5e9c8
%kesp = 0x00000000

%eflags = 0x00000282
  id=0 vip=0 vif=0 ac=0 vm=0 rf=0 nt=0 iopl=0x0
  status=<of,df,IF,tf,SF,zf,af,pf,cf>

   %esp = 0xfda5e9ac
%trapno = 0xe
   %err = 0x6

> 0xfeee78b5::dis
libc.so.1`_lwp_kill:            call   +0x0     <libc.so.1`_lwp_kill+5>
libc.so.1`_lwp_kill+5:          popl   %edx
libc.so.1`_lwp_kill+6:          movl   $0xa3,%eax
libc.so.1`_lwp_kill+0xb:        movl   %esp,%ecx
libc.so.1`_lwp_kill+0xd:        addl   $0x10,%edx
libc.so.1`_lwp_kill+0x13:       sysenter
libc.so.1`_lwp_kill+0x15:       jae    +0xc     <libc.so.1`_lwp_kill+0x23>
libc.so.1`_lwp_kill+0x17:       cmpl   $0x5b,%eax
libc.so.1`_lwp_kill+0x1a:       jne    +0x9     <libc.so.1`_lwp_kill+0x25>
libc.so.1`_lwp_kill+0x1c:       movl   $0x4,%eax
libc.so.1`_lwp_kill+0x21:       jmp    +0x2     <libc.so.1`_lwp_kill+0x25>
libc.so.1`_lwp_kill+0x23:       xorl   %eax,%eax
libc.so.1`_lwp_kill+0x25:       ret
0xfeee78c6:                     leal   0x0(%esi),%esi
0xfeee78c9:                     leal   0x0(%edi),%edi
libc.so.1`_lwp_self:            call   +0x0     <libc.so.1`_lwp_self+5>
libc.so.1`_lwp_self+5:          popl   %edx

Looks like fmd crashed. Can anyone help me confirm that I am right?

Thanks & Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140225/54efcfc3/attachment.html>

From svavar at januar.is  Thu Feb 27 09:54:58 2014
From: svavar at januar.is (=?ISO-8859-1?Q?Svavar_=D6rn_Eysteinsson?=)
Date: Thu, 27 Feb 2014 09:54:58 +0000
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
Message-ID: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>

Hello List.

I'm experimenting with ZFS on a iSCSI target.
Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI
target
located out on the public internet from my hosting provider.

As for now the iSCSI target is about 300GB which I have managed to connect
and created a ZFS pool on the target.

Now for the questions, what would the scenario be if I asked my provider
to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see
the new size ? Do I need any to scrub the pool, or how to I grow my pool
to the new size provided by my hosting provider ?

As before, now I have a 300GB ZFS pool on the iSCSI target.
Which I have mounted and everything seems to work fine.

Later the iSCSI target will be grown to 500GB. Are there anything
special work that needs to be done regarding growing the ZFS datapool from
300GB to 500GB.
(those extra 200GB) ?


Thanks in advance people.

Best regards,

Svavar O - Reykjavik - Iceland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140227/715d442c/attachment.html>

From jimklimov at cos.ru  Thu Feb 27 14:25:15 2014
From: jimklimov at cos.ru (Jim Klimov)
Date: Thu, 27 Feb 2014 15:25:15 +0100
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
	<5303A925.6060209@cos.ru>
	<6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com>
Message-ID: <530F4ACB.40607@cos.ru>

On 2014-02-23 06:14, Richard Elling wrote:
> On Feb 18, 2014, at 10:40 AM, Jim Klimov <jimklimov at cos.ru> wrote:
>
>> On 2014-02-18 08:05, Richard Elling wrote:
>>> Fortunately, most real workloads are not tar -x.
>>
>> Oh, alas, on build farms they are. And the hordes of files produced
>> as a result of "make" are not far behind. Oh, well, often they are
>> behind - and subsequent accesses fail for a few seconds, just until
>> something syncs down the pipe and back to the client. So the typical
>> mantra is "gmake -j -k all; gmake all" for producing as many objects
>> as we can first, and then cleaning up the mess sequentially :)
>
> For build farms, why do you care about NFS sync writes? This is the
> canonical case for sync=disabled, because there is no unique data.
>   ? richard

Interesting suggestion :)

In one example I have, the builds from several nodes are done in
subdirectories of a user's home directory, as well as edition of
some files (sources, recipes/makefiles) in the process. And being
a home, it is sync'ed per defaults.

But I might investigate if dedicating a sub-dataset without sync
would help and won't cause races (i.e. edit a file on one host,
initiate a build quickly on another, and compile the obsolete
version which was cached by NFS client), so thanks :)

I hope, NFS cached-data syncs and locks, and ZFS write-syncs are
not very related in this case (i.e. zfs sync=disabled does not
influence co-ordination of NFS data between hosts), right?

Thanks,
//Jim



From mark at omniti.com  Thu Feb 27 15:49:52 2014
From: mark at omniti.com (Mark Harrison)
Date: Thu, 27 Feb 2014 10:49:52 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
References: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
Message-ID: <CABC3qWc=akV5E_EprxDqPGAH-yUQG-SjYsLbR0Xce9AuUPzLJw@mail.gmail.com>

If you have the pool on the raw device (i.e. you haven't created any
slices/partitions and instructed zfs to use the whole 'disk'), and the
device suddenly appears to the OS with a larger size, then ZFS will
use all the space available. This also applies to physical drives,
where if you replace all the mirrored drives in a pool or top level
vdev with larger drives, the pool will suddenly be larger.

On Thu, Feb 27, 2014 at 4:54 AM, Svavar ?rn Eysteinsson
<svavar at januar.is> wrote:
> Hello List.
>
> I'm experimenting with ZFS on a iSCSI target.
> Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI
> target
> located out on the public internet from my hosting provider.
>
> As for now the iSCSI target is about 300GB which I have managed to connect
> and created a ZFS pool on the target.
>
> Now for the questions, what would the scenario be if I asked my provider
> to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see
> the new size ? Do I need any to scrub the pool, or how to I grow my pool
> to the new size provided by my hosting provider ?
>
> As before, now I have a 300GB ZFS pool on the iSCSI target.
> Which I have mounted and everything seems to work fine.
>
> Later the iSCSI target will be grown to 500GB. Are there anything
> special work that needs to be done regarding growing the ZFS datapool from
> 300GB to 500GB.
> (those extra 200GB) ?
>
>
> Thanks in advance people.
>
> Best regards,
>
> Svavar O - Reykjavik - Iceland
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>

From dswartz at druber.com  Thu Feb 27 15:54:33 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 27 Feb 2014 10:54:33 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
References: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
Message-ID: <b417343aa9926ac5ba8ddc9a6443a484.squirrel@webmail.druber.com>

> Hello List.
>
> I'm experimenting with ZFS on a iSCSI target.
> Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI
> target
> located out on the public internet from my hosting provider.
>
> As for now the iSCSI target is about 300GB which I have managed to connect
> and created a ZFS pool on the target.
>
> Now for the questions, what would the scenario be if I asked my provider
> to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see
> the new size ? Do I need any to scrub the pool, or how to I grow my pool
> to the new size provided by my hosting provider ?
>
> As before, now I have a 300GB ZFS pool on the iSCSI target.
> Which I have mounted and everything seems to work fine.
>
> Later the iSCSI target will be grown to 500GB. Are there anything
> special work that needs to be done regarding growing the ZFS datapool from
> 300GB to 500GB.

I can't see this working at all.  Even if the iscsi initiator presents the
new bigger size, the pool/vdevs/etc have all been created using a specific
'disk' size.  Rather than grow the target, can they carve off more space
and present you a 2nd LUN?  You could then add that as a 2nd vdev to the
pool...


From dswartz at druber.com  Thu Feb 27 15:56:34 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 27 Feb 2014 10:56:34 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
Message-ID: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>

> If you have the pool on the raw device (i.e. you haven't created any
slices/partitions and instructed zfs to use the whole 'disk'), and the
device suddenly appears to the OS with a larger size, then ZFS will use
all the space available. This also applies to physical drives, where if
you replace all the mirrored drives in a pool or top level vdev with
larger drives, the pool will suddenly be larger.

Mark, you are talking about a scenario where a pool has redundancy.  You
replace a disk with a larger one and it resilvers, using the new size.  He
has (it seems) a single drive in that vdev.  By definition, you can't
replace it without losing all the data, no?





From dswartz at druber.com  Thu Feb 27 16:00:39 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 27 Feb 2014 11:00:39 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
Message-ID: <10674b0becfb9605662aec47b8a5861e.squirrel@webmail.druber.com>


Re-reading Mark's reply, I'm not so sure about my answer.  I want to take
a look at this...


From mark at omniti.com  Thu Feb 27 16:04:20 2014
From: mark at omniti.com (Mark Harrison)
Date: Thu, 27 Feb 2014 11:04:20 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
Message-ID: <CABC3qWfiqdKuHZFg0E_B3bvZ4d6sCP=cxT_hztdz4wmf89zJtg@mail.gmail.com>

Good point. I probably should have added the disclaimer that I haven't
tested this with iscsi devices directly, and was working on the
assumption that the device would suddenly show as a larger device with
all data intact.

If that's not possible, then one possible may of making this work
would be requesting a second device of the larger size, adding it to
the pool as a mirror, waiting for the resilver to finish, and then
removing the smaller device.

On Thu, Feb 27, 2014 at 10:56 AM, Dan Swartzendruber <dswartz at druber.com> wrote:
>> If you have the pool on the raw device (i.e. you haven't created any
> slices/partitions and instructed zfs to use the whole 'disk'), and the
> device suddenly appears to the OS with a larger size, then ZFS will use
> all the space available. This also applies to physical drives, where if
> you replace all the mirrored drives in a pool or top level vdev with
> larger drives, the pool will suddenly be larger.
>
> Mark, you are talking about a scenario where a pool has redundancy.  You
> replace a disk with a larger one and it resilvers, using the new size.  He
> has (it seems) a single drive in that vdev.  By definition, you can't
> replace it without losing all the data, no?
>
>
>
>



-- 
Mark Harrison
Lead Site Reliability Engineer
OmniTI

From dswartz at druber.com  Thu Feb 27 16:15:11 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 27 Feb 2014 11:15:11 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <CABC3qWfiqdKuHZFg0E_B3bvZ4d6sCP=cxT_hztdz4wmf89zJtg@mail.gmail.com>
References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
	<CABC3qWfiqdKuHZFg0E_B3bvZ4d6sCP=cxT_hztdz4wmf89zJtg@mail.gmail.com>
Message-ID: <df97d5926a22ef3dca026b4b94c6a894.squirrel@webmail.druber.com>


I can't actually swear that a dynamically grown LUN wouldn't work, it just
seems unlikely, but who knows?  I agree the simplest thing is to have them
give him another bigger lun, mirror them, detach the first, then make sure
the new one gets grown...


From danmcd at omniti.com  Thu Feb 27 16:20:42 2014
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 27 Feb 2014 11:20:42 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <df97d5926a22ef3dca026b4b94c6a894.squirrel@webmail.druber.com>
References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
	<CABC3qWfiqdKuHZFg0E_B3bvZ4d6sCP=cxT_hztdz4wmf89zJtg@mail.gmail.com>
	<df97d5926a22ef3dca026b4b94c6a894.squirrel@webmail.druber.com>
Message-ID: <69FB85D9-ED75-494B-BC8D-900D6D11E56A@omniti.com>


On Feb 27, 2014, at 11:15 AM, Dan Swartzendruber <dswartz at druber.com> wrote:

> 
> I can't actually swear that a dynamically grown LUN wouldn't work, it just
> seems unlikely, but who knows?  I agree the simplest thing is to have them
> give him another bigger lun, mirror them, detach the first, then make sure
> the new one gets grown...

MAKE SURE that the "autoexpand" property of the pool is enabled:

	zpool get autoexpand <poolname>

And set it to "on" if need be.

Dan


From esproul at omniti.com  Thu Feb 27 16:20:51 2014
From: esproul at omniti.com (Eric Sproul)
Date: Thu, 27 Feb 2014 11:20:51 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <df97d5926a22ef3dca026b4b94c6a894.squirrel@webmail.druber.com>
References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
	<CABC3qWfiqdKuHZFg0E_B3bvZ4d6sCP=cxT_hztdz4wmf89zJtg@mail.gmail.com>
	<df97d5926a22ef3dca026b4b94c6a894.squirrel@webmail.druber.com>
Message-ID: <CA+QY2RQsbpYrKUJNW4d+KqJX-Bz89S6+ribLbZBmAtD90ccEvw@mail.gmail.com>

See the autoexpand property in zpool(1M).  It defaults to off, but if
you turn it on, growing a LUN should result in growing the pool size.

On Thu, Feb 27, 2014 at 11:15 AM, Dan Swartzendruber <dswartz at druber.com> wrote:
>
> I can't actually swear that a dynamically grown LUN wouldn't work, it just
> seems unlikely, but who knows?  I agree the simplest thing is to have them
> give him another bigger lun, mirror them, detach the first, then make sure
> the new one gets grown...
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From doug at will.to  Thu Feb 27 16:25:20 2014
From: doug at will.to (Doug Hughes)
Date: Thu, 27 Feb 2014 11:25:20 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
Message-ID: <530F66F0.1080304@will.to>

On 2/27/2014 10:56 AM, Dan Swartzendruber wrote:
>> If you have the pool on the raw device (i.e. you haven't created any
> slices/partitions and instructed zfs to use the whole 'disk'), and the
> device suddenly appears to the OS with a larger size, then ZFS will use
> all the space available. This also applies to physical drives, where if
> you replace all the mirrored drives in a pool or top level vdev with
> larger drives, the pool will suddenly be larger.
>
> Mark, you are talking about a scenario where a pool has redundancy.  You
> replace a disk with a larger one and it resilvers, using the new size.  He
> has (it seems) a single drive in that vdev.  By definition, you can't
> replace it without losing all the data, no?

Are you taking into account this option from the zpool?
zpool1  autoexpand     off                  default


if you set autoexpand = on, you will see the behavior that replacing all 
of the disks will autoexpand the pool. This can be unfortunate if the 
disk model has been slightly tweaked (happened to us) for the same exact 
disk and shows to the OS as slightly fewer blocks. It won't resilver. I 
usually only set autoexpand = on if I explicitly want to grow the size 
of the pool, and then turn it back off again right away.


From dswartz at druber.com  Thu Feb 27 17:03:02 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 27 Feb 2014 12:03:02 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <530F66F0.1080304@will.to>
References: <4e0dfcedbb601387fa2e280a6e2f32ee.squirrel@webmail.druber.com>
	<530F66F0.1080304@will.to>
Message-ID: <363c0af8fa88505206bc0201e7c4b9c2.squirrel@webmail.druber.com>


Yes, that's the property I was thinking of.  I don't have an easy way to
confirm/disprove that an iSCSI lun being resized will work for the OP - I
am dubious, since the auto-partition code creates (AFAIR) a full-sized EFI
partition.  OmniOS would have to resize it and do who knows what juju. 
Scary, I think...


From richard.elling at richardelling.com  Thu Feb 27 19:39:05 2014
From: richard.elling at richardelling.com (Richard Elling)
Date: Thu, 27 Feb 2014 11:39:05 -0800
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <530F4ACB.40607@cos.ru>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
	<5303A925.6060209@cos.ru>
	<6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com>
	<530F4ACB.40607@cos.ru>
Message-ID: <17E70147-79EB-471C-A9F4-496F8C99BF77@richardelling.com>


On Feb 27, 2014, at 6:25 AM, Jim Klimov <jimklimov at cos.ru> wrote:

> On 2014-02-23 06:14, Richard Elling wrote:
>> On Feb 18, 2014, at 10:40 AM, Jim Klimov <jimklimov at cos.ru> wrote:
>> 
>>> On 2014-02-18 08:05, Richard Elling wrote:
>>>> Fortunately, most real workloads are not tar -x.
>>> 
>>> Oh, alas, on build farms they are. And the hordes of files produced
>>> as a result of "make" are not far behind. Oh, well, often they are
>>> behind - and subsequent accesses fail for a few seconds, just until
>>> something syncs down the pipe and back to the client. So the typical
>>> mantra is "gmake -j -k all; gmake all" for producing as many objects
>>> as we can first, and then cleaning up the mess sequentially :)
>> 
>> For build farms, why do you care about NFS sync writes? This is the
>> canonical case for sync=disabled, because there is no unique data.
>>  ? richard
> 
> Interesting suggestion :)
> 
> In one example I have, the builds from several nodes are done in
> subdirectories of a user's home directory, as well as edition of
> some files (sources, recipes/makefiles) in the process. And being
> a home, it is sync'ed per defaults.
> 
> But I might investigate if dedicating a sub-dataset without sync
> would help and won't cause races (i.e. edit a file on one host,
> initiate a build quickly on another, and compile the obsolete
> version which was cached by NFS client), so thanks :)
> 
> I hope, NFS cached-data syncs and locks, and ZFS write-syncs are
> not very related in this case (i.e. zfs sync=disabled does not
> influence co-ordination of NFS data between hosts), right?

Right. The file system is consistent. The NFS sync is for the case when
the server reboots. As long as your server isn't rebooting, everything
should be consistent (assuming the clients are configured appropriately)
 -- richard


From slefevre at indy.rr.com  Thu Feb 27 21:10:33 2014
From: slefevre at indy.rr.com (Scott LeFevre)
Date: Thu, 27 Feb 2014 16:10:33 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
References: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
Message-ID: <1393535433.707.6.camel@exilis.si-consulting.us>

As others have pointed out, setting autoexpand=on on the pool is the key
to making use of any new space allocated to your drive.

As a test, I created a 30GB drive and created a new pool.  I then
expanded that drive to 50GB.  The size of the pool didn't change until I
turned on autoexpand on the pool.  This was done in a VM and not with a
iscsi target lun but the principle should apply the same.


root at omnios1:~# zpool create tank0 /dev/rdsk/c1t2d0
root at omnios1:~# zpool list 
NAME    SIZE  ALLOC   FREE  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT
rpool  15.9G  2.51G  13.4G         -    15%  1.00x  ONLINE  -
tank0  29.8G   156K  29.7G         -     0%  1.00x  ONLINE  -
root at omnios1:~# zpool get autoexpand tank0
NAME   PROPERTY    VALUE   SOURCE
tank0  autoexpand  off     default

root at omnios1:~# prtvtoc /dev/rdsk/c1t2d0s0
* /dev/rdsk/c1t2d0s0 partition map
*
* Dimensions:
*     512 bytes/sector
* 62914560 sectors
* 62914493 accessible sectors
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector 
*          34       222       255
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      4    00        256  62897887  62898142
       8     11    00   62898143     16384  62914526


---
Expanded /dev/rdsk/c1t2d0 to 50GB

---

root at omnios1:~# zpool list 
NAME    SIZE  ALLOC   FREE  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT
rpool  15.9G  2.51G  13.4G         -    15%  1.00x  ONLINE  -
tank0  29.8G   130K  29.7G       20G     0%  1.00x  ONLINE  -
root at omnios1:~# zpool get autoexpand tank0
NAME   PROPERTY    VALUE   SOURCE
tank0  autoexpand  off     default

root at omnios1:~# zpool set autoexpand=on tank0
root at omnios1:~# zpool list 
NAME    SIZE  ALLOC   FREE  EXPANDSZ    CAP  DEDUP  HEALTH  ALTROOT
rpool  15.9G  2.51G  13.4G         -    15%  1.00x  ONLINE  -
tank0  49.8G   200K  49.7G         -     0%  1.00x  ONLINE  -

root at omnios1:~# prtvtoc /dev/rdsk/c1t2d0
* /dev/rdsk/c1t2d0 partition map
*
* Dimensions:
*     512 bytes/sector
* 104857600 sectors
* 104857533 accessible sectors
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector 
*          34       222       255
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      4    00        256 104840927 104841182
       8     11    00  104841183     16384 104857566


-- 
Scott LeFevre


On Thu, 2014-02-27 at 09:54 +0000, Svavar ?rn Eysteinsson wrote:
> Hello List.
> 
> 
> 
> I'm experimenting with ZFS on a iSCSI target.
> Currently I have a OmniOS server which is a iSCSI initiator to a iSCSI
> target
> located out on the public internet from my hosting provider.
> 
> 
> As for now the iSCSI target is about 300GB which I have managed to
> connect
> and created a ZFS pool on the target.
> 
> 
> Now for the questions, what would the scenario be if I asked my
> provider
> to extend (grow) the iSCSI target, and how will my ZFS OmniOS box see
> the new size ? Do I need any to scrub the pool, or how to I grow my
> pool
> to the new size provided by my hosting provider ?
> 
> 
> As before, now I have a 300GB ZFS pool on the iSCSI target.
> Which I have mounted and everything seems to work fine.
> 
> 
> Later the iSCSI target will be grown to 500GB. Are there anything
> special work that needs to be done regarding growing the ZFS datapool
> from 300GB to 500GB.
> (those extra 200GB) ?
> 
> 
> 
> 
> Thanks in advance people.
> 
> 
> Best regards,
> 
> 
> Svavar O - Reykjavik - Iceland
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140227/0a901960/attachment-0001.html>

From dswartz at druber.com  Thu Feb 27 21:15:48 2014
From: dswartz at druber.com (Dan Swartzendruber)
Date: Thu, 27 Feb 2014 16:15:48 -0500
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <1393535433.707.6.camel@exilis.si-consulting.us>
References: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
	<1393535433.707.6.camel@exilis.si-consulting.us>
Message-ID: <180ce8932be1f5de67374c83b067bf88.squirrel@webmail.druber.com>


Fascinating.  Thanks for the experiment!


From jimklimov at cos.ru  Thu Feb 27 22:01:01 2014
From: jimklimov at cos.ru (Jim Klimov)
Date: Thu, 27 Feb 2014 23:01:01 +0100
Subject: [OmniOS-discuss] Pliant/Sandisk SSD ZIL
In-Reply-To: <17E70147-79EB-471C-A9F4-496F8C99BF77@richardelling.com>
References: <530291DA.6050009@umiacs.umd.edu>
	<C7FCD61D-B246-4D2F-9712-90DF031D3E43@RichardElling.com>
	<5302BC07.9070304@umiacs.umd.edu>
	<348BDDFA-3B48-422E-A166-8427417EF432@RichardElling.com>
	<5303A925.6060209@cos.ru>
	<6D195400-4AA6-47B4-A7D6-1CF77D92A119@RichardElling.com>
	<530F4ACB.40607@cos.ru>
	<17E70147-79EB-471C-A9F4-496F8C99BF77@richardelling.com>
Message-ID: <530FB59D.3000703@cos.ru>

On 2014-02-27 20:39, Richard Elling wrote:
>> I hope, NFS cached-data syncs and locks, and ZFS write-syncs are
>> not very related in this case (i.e. zfs sync=disabled does not
>> influence co-ordination of NFS data between hosts), right?
>
> Right. The file system is consistent. The NFS sync is for the case when
> the server reboots. As long as your server isn't rebooting, everything
> should be consistent (assuming the clients are configured appropriately)

And "appropriately" is just how much different from "default"?
I.e. if I set sharenfs on the server dataset, and walk in with
autofs + nfs/client from the build host, with no special configs
other than those in solaris 10 or OpenIndiana, is that appropriate?
Or should some specific stuff be configured on clients and servers?

Thanks!
//Jim


From johan.kragsterman at capvert.se  Fri Feb 28 07:13:44 2014
From: johan.kragsterman at capvert.se (Johan Kragsterman)
Date: Fri, 28 Feb 2014 08:13:44 +0100
Subject: [OmniOS-discuss] illumos power management...again...
Message-ID: <OF2E1EA8BF.107A851D-ONC1257C8D.002607E8-C1257C8D.0027B5B6@inse.com>

Hi!

I remember a discussion on this theme last year. I've been reading up on that, but that didn't answer my questions.

I'm in the process of building a new main home server, and I would of coarse like it to be energy efficient. I don't use much space normally, so my daily working environment doesn't need much space, which means I can use all SSD's for that. 

Though I would like a backup/nfs environment, with more space on spinning disks, and I got two different scenarious to choose from here:

One is building a separate machine for backup/nfs, and only start it when it needs to be started( with wake on LAN).

The other is to have the spinning disks in my main home server, and use illumos power management to take care of powering down the disks when they are not in use.
This would of coarse be the easiest way, if the power management system is efficient enough.

I don't know if the system can/do power down the disks if the nfs server is active and the shares are mounted? (I don't have any problems with latencies/delays here, since it isn't in regular use)

If so, good!
If not, I could umount the shares and turn off the nfs server, and export the pool, if that would help spinning down disks...

Someone got any insight and/or suggestions here...?



Best regards from/Med v?nliga h?lsningar fr?n

Johan Kragsterman

Capvert


From svavar at januar.is  Fri Feb 28 09:21:37 2014
From: svavar at januar.is (=?ISO-8859-1?Q?Svavar_=D6rn_Eysteinsson?=)
Date: Fri, 28 Feb 2014 09:21:37 +0000
Subject: [OmniOS-discuss] ZFS on iSCSI Target. OmniOS as Initiator
In-Reply-To: <180ce8932be1f5de67374c83b067bf88.squirrel@webmail.druber.com>
References: <CAEc-0iWuU5+O1B+E5yo+APFHK1WMX5iBYws9smiut23bb4Q2pA@mail.gmail.com>
	<1393535433.707.6.camel@exilis.si-consulting.us>
	<180ce8932be1f5de67374c83b067bf88.squirrel@webmail.druber.com>
Message-ID: <CAEc-0iXYmizffNDg0v9SNFTaDuyzE00dQ8EJs2Do_DzaZDNR1Q@mail.gmail.com>

Thank you all for the help, and the tech talk about this scenario.

I have configured the autoexpand to ON on the pool. I will also ask my
provider to grow the LUN
and test it before using it. Will post information soon.

Thanks again.

Best regards,

Svavar O






*SVAVAR ?RN EYSTEINSSON*Kerfisstj?ri
Gsm / mobile +354 862 1624
S?mi / tel +354 531 0101


*Jan?ar marka?sh?s*www.januar.is / Facebook<http://facebook.com/viderumjanuar>



On 27 February 2014 21:15, Dan Swartzendruber <dswartz at druber.com> wrote:

>
> Fascinating.  Thanks for the experiment!
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140228/31ef9737/attachment.html>

From jimklimov at cos.ru  Fri Feb 28 09:36:47 2014
From: jimklimov at cos.ru (jimklimov at cos.ru)
Date: Fri, 28 Feb 2014 10:36:47 +0100
Subject: [OmniOS-discuss] illumos power management...again...
Message-ID: <072n48b3g5t0ujaah6lbh4ks.1393580207933@email.android.com>

When i asked about this a few years back, when Sun was high in the sky and OpenSolaris roamed the web, the answer was that the one thing that might keep disks from spinning down is outstanding i/o's, which may include scrubs, slocate/mlocate uodatedb runs, zds-autosnap, and in case of homedirs - stuff like firefox caches and DE working files. Otherwise, disks can spin down even with a pool imported and mounted (possibly, some data would even be read off the cache and won't require spinups).

I am not sure how valid this remains today, but seems worth a try.


Typos courtesy of my Samsung Mobile

-------- ???????? ????????? --------
??: Johan Kragsterman <johan.kragsterman at capvert.se> 
????: 2014.02.28  8:13  (GMT+01:00) 
????: omnios-discuss <omnios-discuss at lists.omniti.com> 
????: [OmniOS-discuss] illumos power management...again... 
 
Hi!

I remember a discussion on this theme last year. I've been reading up on that, but that didn't answer my questions.

I'm in the process of building a new main home server, and I would of coarse like it to be energy efficient. I don't use much space normally, so my daily working environment doesn't need much space, which means I can use all SSD's for that. 

Though I would like a backup/nfs environment, with more space on spinning disks, and I got two different scenarious to choose from here:

One is building a separate machine for backup/nfs, and only start it when it needs to be started( with wake on LAN).

The other is to have the spinning disks in my main home server, and use illumos power management to take care of powering down the disks when they are not in use.
This would of coarse be the easiest way, if the power management system is efficient enough.

I don't know if the system can/do power down the disks if the nfs server is active and the shares are mounted? (I don't have any problems with latencies/delays here, since it isn't in regular use)

If so, good!
If not, I could umount the shares and turn off the nfs server, and export the pool, if that would help spinning down disks...

Someone got any insight and/or suggestions here...?



Best regards from/Med v?nliga h?lsningar fr?n

Johan Kragsterman

Capvert

_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140228/8565c3c6/attachment.html>

From lists at marzocchi.net  Fri Feb 28 11:14:28 2014
From: lists at marzocchi.net (Olaf Marzocchi)
Date: Fri, 28 Feb 2014 12:14:28 +0100
Subject: [OmniOS-discuss] illumos power management...again...
In-Reply-To: <072n48b3g5t0ujaah6lbh4ks.1393580207933@email.android.com>
References: <072n48b3g5t0ujaah6lbh4ks.1393580207933@email.android.com>
Message-ID: <C49520AC-8D5A-492A-BDDF-20F6E7961BF6@marzocchi.net>

I remember connecting two USB disks and they never spun down, even after exporting the pool. The light was briefly blinking anyway.
Am I going to try soon the same using eSATA... But the same external case and bridge chipset.

Olaf



Inviato da iPhone

> Il giorno 28/feb/2014, alle ore 10:36, "jimklimov at cos.ru" <jimklimov at cos.ru> ha scritto:
> 
> When i asked about this a few years back, when Sun was high in the sky and OpenSolaris roamed the web, the answer was that the one thing that might keep disks from spinning down is outstanding i/o's, which may include scrubs, slocate/mlocate uodatedb runs, zds-autosnap, and in case of homedirs - stuff like firefox caches and DE working files. Otherwise, disks can spin down even with a pool imported and mounted (possibly, some data would even be read off the cache and won't require spinups).
> 
> I am not sure how valid this remains today, but seems worth a try.
> 
> 
> Typos courtesy of my Samsung Mobile
> 
> 
> -------- ???????? ????????? --------
> ??: Johan Kragsterman <johan.kragsterman at capvert.se> 
> ????: 2014.02.28 8:13 (GMT+01:00) 
> ????: omnios-discuss <omnios-discuss at lists.omniti.com> 
> ????: [OmniOS-discuss] illumos power management...again... 
> 
> 
> Hi!
> 
> I remember a discussion on this theme last year. I've been reading up on that, but that didn't answer my questions.
> 
> I'm in the process of building a new main home server, and I would of coarse like it to be energy efficient. I don't use much space normally, so my daily working environment doesn't need much space, which means I can use all SSD's for that. 
> 
> Though I would like a backup/nfs environment, with more space on spinning disks, and I got two different scenarious to choose from here:
> 
> One is building a separate machine for backup/nfs, and only start it when it needs to be started( with wake on LAN).
> 
> The other is to have the spinning disks in my main home server, and use illumos power management to take care of powering down the disks when they are not in use.
> This would of coarse be the easiest way, if the power management system is efficient enough.
> 
> I don't know if the system can/do power down the disks if the nfs server is active and the shares are mounted? (I don't have any problems with latencies/delays here, since it isn't in regular use)
> 
> If so, good!
> If not, I could umount the shares and turn off the nfs server, and export the pool, if that would help spinning down disks...
> 
> Someone got any insight and/or suggestions here...?
> 
> 
> 
> Best regards from/Med v?nliga h?lsningar fr?n
> 
> Johan Kragsterman
> 
> Capvert
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

From cks at cs.toronto.edu  Fri Feb 28 18:16:45 2014
From: cks at cs.toronto.edu (Chris Siebenmann)
Date: Fri, 28 Feb 2014 13:16:45 -0500
Subject: [OmniOS-discuss] How do you configure serial ports on OmniOS?
Message-ID: <20140228181645.624801A0BBB@apps0.cs.toronto.edu>

 This question makes me feel silly but I'm lost in a confusing maze of
documentation for sacadm, pmadm, and so on and I can't find anything
with web searches. What I would like to do is configure what I believe is
/dev/term/c ('ttyS3' in Linux) to run a getty or the OmniOS/Illumos/etc
equivalent at 115200 baud.

 Relatedly, I'd also like to change the getty-equivalent that 'pmadm -l'
at least theoretically says is talking to /dev/term/a from 9600 baud to
115200 baud. How to do this is also, well, not obvious to me.

(Please note that I do not want to make this the serial console, a
procedure for which there seems to be plenty of documentation. I just
want to be able to log in over that serial port, or it and /dev/term/a.)

 Thanks in advance.

	- cks

From lotheac at iki.fi  Fri Feb 28 18:28:16 2014
From: lotheac at iki.fi (Lauri Tirkkonen)
Date: Fri, 28 Feb 2014 20:28:16 +0200
Subject: [OmniOS-discuss] How do you configure serial ports on OmniOS?
In-Reply-To: <20140228181645.624801A0BBB@apps0.cs.toronto.edu>
References: <20140228181645.624801A0BBB@apps0.cs.toronto.edu>
Message-ID: <20140228182816.GC28245@gutsman.lotheac.fi>

On Fri, Feb 28 2014 13:16:45 -0500, Chris Siebenmann wrote:
>  This question makes me feel silly but I'm lost in a confusing maze of
> documentation for sacadm, pmadm, and so on and I can't find anything
> with web searches. What I would like to do is configure what I believe is
> /dev/term/c ('ttyS3' in Linux) to run a getty or the OmniOS/Illumos/etc
> equivalent at 115200 baud.

I found this pretty useful:
http://iws.cs.uni-magdeburg.de/~elkner/keyboard/serialconsole.txt

> (Please note that I do not want to make this the serial console, a
> procedure for which there seems to be plenty of documentation. I just
> want to be able to log in over that serial port, or it and /dev/term/a.)

Right, so skip setting console stuff; sttydefs and a console-login
service instance should do it I believe.

-- 
Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet

