[OmniOS-discuss] Intel RAID Controller RS3UC080
Hafiz Rafiyev
rafibeyli at gmail.com
Sat Nov 7 18:42:52 UTC 2015
Hello,
Anyone has tested Intel RS3UC080 SAS3 HBA 12Gb card with OmniOS?
Basically it uses LSI3008 controller,planning to use with all SSD pool.
Thanks,
Hafiz
----- Orijinal Mesaj -----
Kimden: omnios-discuss-request at lists.omniti.com
Kime: "omnios-discuss" <omnios-discuss at lists.omniti.com>
Gönderilenler: 7 Kasım Cumartesi 2015 1:59:32
Konu: OmniOS-discuss Digest, Vol 44, Issue 13
Send OmniOS-discuss mailing list submissions to
omnios-discuss at lists.omniti.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.omniti.com/mailman/listinfo/omnios-discuss
or, via email, send a message with subject or body 'help' to
omnios-discuss-request at lists.omniti.com
You can reach the person managing the list at
omnios-discuss-owner at lists.omniti.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OmniOS-discuss digest..."
Today's Topics:
1. Re: ILB memory leak? (Dan McDonald)
2. Re: ILB memory leak? (Al Slater)
3. Re: ILB memory leak? (Dan McDonald)
4. Re: ILB memory leak? (Dan McDonald)
5. Re: ILB memory leak? (Bob Friesenhahn)
6. SMB 2.1 any many other improvements (Guenther Alka)
7. Re: Bloody // mailwrapper & mta mediator (Paul B. Henson)
----------------------------------------------------------------------
Message: 1
Date: Fri, 6 Nov 2015 10:43:35 -0500
From: Dan McDonald <danmcd at omniti.com>
To: Al Slater <al.slater at scluk.com>
Cc: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <0C222003-AF3C-4BAB-A5ED-2748083B8F4B at omniti.com>
Content-Type: text/plain; charset=windows-1252
> On Nov 6, 2015, at 10:38 AM, Al Slater <al.slater at scluk.com> wrote:
>
> 3D600000 1048576 1048576 1048576 - rwx-- [ anon ]
> 7D800000 1048576 1048576 1048576 - rwx-- [ anon ]
Hmmm.
I wonder if those are pre-allocated by libumem? They're HUGE (1G) and more around them are smaller
Do you think you could run pmap on a production box (it's just an observation tool) where libumem isn't activated?
Thanks,
Dan
------------------------------
Message: 2
Date: Fri, 6 Nov 2015 15:57:08 +0000
From: Al Slater <al.slater at scluk.com>
To: Dan McDonald <danmcd at omniti.com>
Cc: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <563CCDD4.7040903 at scluk.com>
Content-Type: text/plain; charset=windows-1252
On 06/11/15 15:43, Dan McDonald wrote:
>
>> On Nov 6, 2015, at 10:38 AM, Al Slater <al.slater at scluk.com> wrote:
>>
>> 3D600000 1048576 1048576 1048576 - rwx-- [ anon ]
>> 7D800000 1048576 1048576 1048576 - rwx-- [ anon ]
>
> Hmmm.
>
> I wonder if those are pre-allocated by libumem? They're HUGE (1G) and more around them are smaller
>
> Do you think you could run pmap on a production box (it's just an observation tool) where libumem isn't activated?
No problem Dan, this is from a production ilbd that was restarted at
07:00 GMT
14585: /usr/lib/inet/ilbd
Address Kbytes RSS Anon Locked Mode Mapped File
0802D000 108 108 108 - rw--- [ stack ]
08050000 76 76 - - r-x-- ilbd
08073000 4 4 4 - rw--- ilbd
08074000 96 - - - rw--- ilbd
0808C000 252 248 244 - rw--- [ heap ]
7D800000 1048576 1048576 1048576 - rwx-- [ anon ]
BDA00000 524288 524288 524288 - rwx-- [ anon ]
DDC00000 262144 262144 262144 - rwx-- [ anon ]
EDE00000 131072 131072 131072 - rwx-- [ anon ]
F6000000 65536 65536 65536 - rwx-- [ anon ]
FA200000 32768 32768 32768 - rwx-- [ anon ]
FC400000 16384 16384 16384 - rwx-- [ anon ]
FD600000 8192 8192 8192 - rwx-- [ anon ]
FE000000 4096 4096 4096 - rwx-- [ anon ]
FE600000 2048 2048 2048 - rwx-- [ anon ]
FE9A0000 1024 1024 1024 - rwx-- [ anon ]
FEAB0000 512 512 512 - rwx-- [ anon ]
FEB40000 256 256 256 - rwx-- [ anon ]
FEB90000 128 128 128 - rwx-- [ anon ]
FEBC0000 64 64 64 - rwx-- [ anon ]
FEBE0000 64 16 16 - rwx-- [ anon ]
FEC00000 4 4 4 - rwx-- [ anon ]
FEC10000 20 20 - - r-x-- libilb.so.1
FEC25000 4 4 4 - rw--- libilb.so.1
FEC30000 32 32 - - r-x-- libuutil.so.1
FEC48000 4 4 4 - rw--- libuutil.so.1
FEC50000 4 4 4 - rwx-- [ anon ]
FEC60000 172 172 - - r-x-- libscf.so.1
FEC9B000 4 4 4 - rw--- libscf.so.1
FECA0000 20 20 - - r-x-- libinetutil.so.1
FECB5000 4 4 4 - rw--- libinetutil.so.1
FECC0000 4 4 4 - rwx-- [ anon ]
FECD0000 20 20 - - r-x-- libcmdutils.so.1
FECE5000 4 4 4 - rw--- libcmdutils.so.1
FECF0000 4 4 - - r--s- dev:528,9 ino:1532084444
FED00000 64 64 4 - rwx-- [ anon ]
FED20000 64 64 4 - rwx-- [ anon ]
FED40000 416 388 - - r-x-- libnsl.so.1
FEDB8000 8 8 8 - rw--- libnsl.so.1
FEDBA000 20 12 - - rw--- libnsl.so.1
FEDC0000 4 4 4 - rwx-- [ anon ]
FEDD0000 52 52 - - r-x-- libsocket.so.1
FEDED000 4 4 4 - rw--- libsocket.so.1
FEDF0000 24 12 12 - rwx-- [ anon ]
FEE00000 4 4 4 - rwx-- [ anon ]
FEE10000 1252 888 - - r-x-- libc_hwcap1.so.1
FEF59000 36 36 32 - rwx-- libc_hwcap1.so.1
FEF62000 8 8 8 - rwx-- libc_hwcap1.so.1
FEF70000 4 4 - - r--s- ld.config
FEF80000 4 4 4 - rwx-- [ anon ]
FEF90000 4 4 4 - rw--- [ anon ]
FEFA0000 4 4 4 - rw--- [ anon ]
FEFB0000 4 4 4 - rwx-- [ anon ]
FEFB5000 216 216 - - r-x-- ld.so.1
FEFFB000 8 8 8 - rwx-- ld.so.1
FEFFD000 4 4 4 - rwx-- ld.so.1
-------- ------- ------- ------- -------
total Kb 2100192 2099632 2097600 -
Definitely no libumem:
root at thor:/export/home/BRIGHTON/aslate# pldd 14585
14585: /usr/lib/inet/ilbd
/zones/roots/l1-lb1/root/usr/lib/libc/libc_hwcap1.so.1
/zones/roots/l1-lb1/root/lib/libsocket.so.1
/zones/roots/l1-lb1/root/lib/libnsl.so.1
/zones/roots/l1-lb1/root/lib/libcmdutils.so.1
/zones/roots/l1-lb1/root/lib/libinetutil.so.1
/zones/roots/l1-lb1/root/lib/libscf.so.1
/zones/roots/l1-lb1/root/lib/libuutil.so.1
/zones/roots/l1-lb1/root/usr/lib/libilb.so.1
--
Al Slater
------------------------------
Message: 3
Date: Fri, 6 Nov 2015 11:25:09 -0500
From: Dan McDonald <danmcd at omniti.com>
To: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <C84216BB-B2BD-4BFB-9477-E70D056F4D5E at omniti.com>
Content-Type: text/plain; charset=windows-1252
> On Nov 6, 2015, at 10:57 AM, Al Slater <al.slater at scluk.com> wrote:
>
>
> 7D800000 1048576 1048576 1048576 - rwx-- [ anon ]
> BDA00000 524288 524288 524288 - rwx-- [ anon ]
> DDC00000 262144 262144 262144 - rwx-- [ anon ]
> EDE00000 131072 131072 131072 - rwx-- [ anon ]
More huge anonymous mappings (1G, 512MB, 256MB, 128MB).
I don't know pmap as well as I should. I don't see anything in the man page to give me further insight into why these chunks of memory are being eaten.
Dan
------------------------------
Message: 4
Date: Fri, 6 Nov 2015 13:31:19 -0500
From: Dan McDonald <danmcd at omniti.com>
To: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID: <964395C2-376C-48A1-BFE8-A655EB667992 at omniti.com>
Content-Type: text/plain; charset=windows-1252
> On Nov 6, 2015, at 11:25 AM, Dan McDonald <danmcd at omniti.com> wrote:
>
>> On Nov 6, 2015, at 10:57 AM, Al Slater <al.slater at scluk.com> wrote:
>>
>>
>> 7D800000 1048576 1048576 1048576 - rwx-- [ anon ]
>> BDA00000 524288 524288 524288 - rwx-- [ anon ]
>> DDC00000 262144 262144 262144 - rwx-- [ anon ]
>> EDE00000 131072 131072 131072 - rwx-- [ anon ]
>
> More huge anonymous mappings (1G, 512MB, 256MB, 128MB).
>
You said you had a test box, right?
Can you:
- Disable UMEM_DEBUG
- RESTART the service.
- IMMEDIATELY after restart do pmap, and do pmap once per (sec, 10 sec, something) to see how it grows?
After that, maybe we can dtrace and see what's going on.
Dan
------------------------------
Message: 5
Date: Fri, 6 Nov 2015 12:33:47 -0600 (CST)
From: Bob Friesenhahn <bfriesen at simple.dallas.tx.us>
To: Dan McDonald <danmcd at omniti.com>
Cc: OmniOS-discuss <omnios-discuss at lists.omniti.com>
Subject: Re: [OmniOS-discuss] ILB memory leak?
Message-ID:
<alpine.GSO.2.01.1511061227120.20442 at freddy.simplesystems.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Fri, 6 Nov 2015, Dan McDonald wrote:
>
> More huge anonymous mappings (1G, 512MB, 256MB, 128MB).
>
> I don't know pmap as well as I should. I don't see anything in the
> man page to give me further insight into why these chunks of memory
> are being eaten.
It is pretty common for memory allocators to use anonymous mappings
for large memory allocations. This allows releasing memory back to
the system.
Some applications use algorithms where they double the memory size
request from the previous request when a little more memory is
required in order to lessen the hit from many realloc() calls. This
might explain the power-of two sizes. If this is being done, the
smaller power of two allocations may be a bug.
Tracing mmap() calls on the program while is is running might reveal
something.
Bob
--
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
------------------------------
Message: 6
Date: Fri, 6 Nov 2015 22:11:42 +0100
From: Guenther Alka <alka at hfg-gmuend.de>
To: omnios-discuss at lists.omniti.com
Subject: [OmniOS-discuss] SMB 2.1 any many other improvements
Message-ID: <563D178E.8090401 at hfg-gmuend.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Just saw the notice at Illumos IRC
Long awaited (Gordon Ross from Nexenta, gratulation, among others)
SMB 2.1 is there - my Mac users will be happy
https://www.illumos.org/issues/6399
https://www.illumos.org/issues/6398
https://www.illumos.org/issues/6352
https://www.illumos.org/issues/6400
https://www.illumos.org/issues/1087
soon
https://www.illumos.org/issues/3525
Pretty good news for OmniOS
Two question
- When - will SMB 2.1 be included - to LTS or 151016??
- Can 6352 support Primary and a Secondary AD Server as a failover - and how
Gea
------------------------------
Message: 7
Date: Fri, 06 Nov 2015 14:59:29 -0800
From: "Paul B. Henson" <henson at acm.org>
To: "'Dale Ghent'" <daleg at omniti.com>, "'Lauri Tirkkonen'"
<lotheac at iki.fi>
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] Bloody // mailwrapper & mta mediator
Message-ID: <005401d118e6$cb7a9c50$626fd4f0$@acm.org>
Content-Type: text/plain; charset=us-ascii
> Dale Ghent
> Sent: Thursday, November 05, 2015 10:56 PM
>
> Well "do nothing" has been the apparent course of action for almost 6
years
> now. But that's speaking in general illumos-gate terms. As far as OmniOS
> goes, we can completely ignore that part of the tree and install our own
thing
> in our own way... but I want to at least explore the options which have a
> bearing on illumos-gate (ie; the greater illumos community) first.
>From a design perspective, I think the best option would be to rip sendmail
out of illumos-gate and replace it with something that just did simple local
mail delivery so the components of illumos-gate that require mail aren't
broken. Then distributions could add their own MTA of choice and/or allow
end-users to install other ones.
------------------------------
Subject: Digest Footer
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss at lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
------------------------------
End of OmniOS-discuss Digest, Vol 44, Issue 13
**********************************************
More information about the OmniOS-discuss
mailing list