date:20170104

On Thu, 5 Jan 2017 01:15:18 +0100
Michael Rasmussen  wrote:

> Would it be possible to use rsync with backblaze?
> rsync handles sparse files equally well using option --sparse
> 
A quick google: 
http://www.rsync.net/resources/howto/unix.html
https://www.elastichosts.com/blog/cloud-storage-backup-using-rsync/

NB: I dont know the companies nor their solutions but it looks very
Unix like;-)

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
From concentrate.


pgp5MgiTpevij.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] NFS 4.2 Support - Sparse Files

On Wed, 04 Jan 2017 23:59:15 +
Mini Trader  wrote:

> 
> If anyone has any recommendations for an incremental cloud storage solution
> that is compatible with OmniOS it would be greatly appreciated. I realize
> that ZFS send works quite well but haven't found an off site provider who I
> consider to be cost effective.
> 
Would it be possible to use rsync with backblaze?
rsync handles sparse files equally well using option --sparse

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
"Whoever undertakes to set himself up as a judge of Truth and Knowledge
is shipwrecked by the laughter of the gods."
-- Albert Einstein


pgpfVG05yyCx4.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] NFS 4.2 Support - Sparse Files

2017-01-04 Thread Mini Trader

That is unfortunate.

The requirement stems from the need to perform an incremental backup to
cloud storage  (backblaze).

Many of my files are large and sparse (VMs). Unfortunately the only
software that I have found to perform the backups runs on BSD or Linux
hence the use for NFS.

Running the utility over NFS without sparse support is not ideal.

If anyone has any recommendations for an incremental cloud storage solution
that is compatible with OmniOS it would be greatly appreciated. I realize
that ZFS send works quite well but haven't found an off site provider who I
consider to be cost effective.

On Wed, Jan 4, 2017 at 2:01 PM Dan McDonald  wrote:

>
>
> > On Jan 4, 2017, at 1:19 PM, Mini Trader 
> wrote:
>
> >
>
> > Hello all,
>
> >
>
> > Is there any support for NFS 4.2 in Illumos?  I am interested in the
> Sparse File functionality that has been introduced.
>
>
>
> There is not, currently.
>
>
>
> There have been some stop/starts on this, but at the end of the day, at
> least one illumos shop's customers basically didn't care enough to make it
> a priority for that shop.  The other illumos shops either have similar
> customer viewpoints, don't care about NFS at all, or don't have the
> resources to devote to such a nontrivial project.
>
>
>
> I'm sorry I don't have a better answer for you at the moment.
>
>
>
> Dan
>
>
>
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ms.omniti.com down?

2017-01-04 Thread Dale Ghent


> On Jan 4, 2017, at 4:57 PM, Michael Rasmussen  wrote:
> 
> Hi all,
> 
> pkg search diskinfo
> pkg: Some repositories failed to respond appropriately:
> ms.omniti.com:
> http protocol error: code: 503 reason: Service Unavailable
> URL: 
> 'http://pkg.omniti.com/omniti-ms/ms.omniti.com/search/1/False_2_None_None_%3A%3A%3Adiskinfo'

We’ve corrected this.

/dale


signature.asc
Description: Message signed with OpenPGP
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] device probe related command timeouts

So odd thing about this server….there is NO “/dev/rdsk/c14t0d0s0” anywhere. 

I wonder what that’s all about




On 1/4/17, 3:17 PM, "John Barfield"  wrote:

You’re awesome! Its hanging on “open /dev/rdsk/c14t0d0s0”

Looking at that disk now. 

On 1/4/17, 3:15 PM, "Joshua M. Clulow"  wrote:

On 4 January 2017 at 13:09, John Barfield  
wrote:
> It actually finally completed. Doing it again with the proper PID as 
suggested provides the following:
> root@PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k
>> 0t19448::pid2proc | ::walk thread | ::findstack -v
> stack pointer for thread ff249059: ff010a286750
> [ ff010a286750 _resume_from_idle+0xf4() ]
>   ff010a286780 swtch+0x141()
>   ff010a2867c0 sema_p+0x1c7(ff26e094b600)
>   ff010a286800 biowait+0xa4(ff26e094b540)
>   ff010a2868d0 scsi_uscsi_handle_cmd+0x127(c10d40, 1, 
ff24907f3da8, f7b159b0, 0, ff27c23171e8)
>   ff010a286960 sd_ssc_send+0x136(ff24227d4e00, 
ff010a286970, 8000, 1, 0)
>   ff010a286a30 
sd_send_scsi_TEST_UNIT_READY+0x121(ff24227d4e00, 1)
>   ff010a286b40 sd_get_media_info_com+0xaf(c10d40, 
ff010a286b50, ff010a286b54, ff010a286b58, 0)
>   ff010a286ba0 sd_get_media_info+0x41(c10d40, 8047330, 15)
>   ff010a286c80 sdioctl+0xc57(c10d40, 42a, 8047330, 15, 
ff24930f7580, ff010a286e68)
>   ff010a286cc0 cdev_ioctl+0x39(c10d40, 42a, 8047330, 15, 
ff24930f7580, ff010a286e68)
>   ff010a286d10 spec_ioctl+0x60(ff2492b62d80, 42a, 8047330, 
15, ff24930f7580, ff010a286e68, 0)
>   ff010a286da0 fop_ioctl+0x55(ff2492b62d80, 42a, 8047330, 
15, ff24930f7580, ff010a286e68, 0)
>   ff010a286ec0 ioctl+0x9b(3, 42a, 8047330)
>   ff010a286f10 _sys_sysenter_post_swapgs+0x149()

OK, it seems that we're hanging while sending a TEST UNIT READY to
some device.  It's probably easiest to just use truss(1), here; e.g.:

truss -t "open,ioctl" -f diskinfo

Once it starts hanging, you should be able to see which open(2) and
ioctl(2) calls happened just before the hang.


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org




___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] ms.omniti.com down?

Hi all,

pkg search diskinfo
pkg: Some repositories failed to respond appropriately:
ms.omniti.com:
http protocol error: code: 503 reason: Service Unavailable
URL: 
'http://pkg.omniti.com/omniti-ms/ms.omniti.com/search/1/False_2_None_None_%3A%3A%3Adiskinfo'


-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
Chicago law prohibits eating in a place that is on fire.


pgpzGrnhXep88.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New SAN deployment HBA recommendations

2017-01-04 Thread Nathan Huff

Just as a data point we have a couple hosts running the LSI 9300-8e HBA to
JBODs on 151014 with no issues so far.


I was specifically wondering what is supported in the latest OmniOS
> release, but I suppose youre suggesting that I could backport an illumos
> driver from the latest build into ominos?
>
> OmniOS is the distro I use for SAN deployments. I use SmartOS for
> hypervisors.
>
>
> On 1/4/17, 2:18 PM, "Dan McDonald"  wrote:
>
>
> > On Jan 4, 2017, at 3:02 PM, John Barfield 
> wrote:
> >
> > Greetings,
> >
> > I?m designing a new ZFS SAN and I?m wondering if anyone knows the
> latest greatest supported HBA that I should use for external JBOD?s.
> >
> > We have tons of SAN?s in production using LSI HBAs today but I?m
> wondering if there is anything new out there that I?m missing or not aware
> of yet.
>
> Are you using LSI 9300 series (driven by the 3008 chipset) yet?
> That's the latest from the world of LSI.  Those are fairly recent (last 3-4
> years), and many still use the 2008 chipset or 2208 chipset.
>
> There are parts currently just-in-SmartOS that may be getting
> upstreamed soon as well.
>
> You may be better off asking this question on the illumos developers'
> list, to see what the latest/greatest in supported HBA HW is.
>
> Dan
>
>
-- 
Nathan Huff
System Administrator
Academic Health Center Information Systems
University of Minnesota
612-626-9136
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] upgrading from 151014

2017-01-04 Thread Dale Ghent


> On Jan 4, 2017, at 4:21 PM, Michael Rasmussen  wrote:
> 
> On Wed, 4 Jan 2017 15:56:17 -0500
> Dan McDonald  wrote:
> 
>> 
>> (Note the get-rid-of-SunSSH before actually upgrading part.)
>> 
> I guess this will be a prerequisite doing 151014 -> 151022 anyway?

Yes. Even if you’re on 014, there’s no reason not to migrate to OpenSSH right 
away. The packages are available on 014.

/dale


signature.asc
Description: Message signed with OpenPGP
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] unsubcribe

2017-01-04 Thread Mathias Döhle





smime.p7s
Description: S/MIME Cryptographic Signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] device probe related command timeouts

For the record…here is the complete command output after it finally completed:

root@PRD-GIP-cpls-san1:/export/home/jbarfield# truss -t "open,ioctl" -f diskinfo
19752:  open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
19752:  open("/lib/libdladm.so.1", O_RDONLY)= 3
19752:  open("/usr/lib/libdiskmgt.so.1", O_RDONLY)  = 3
19752:  open("/lib/libnvpair.so.1", O_RDONLY)   = 3
19752:  open("/usr/lib/fm/libtopo.so.1", O_RDONLY)  = 3
19752:  open("/lib/libc.so.1", O_RDONLY)= 3
19752:  open("/lib/libumem.so.1", O_RDONLY) = 3
19752:  open("/lib/libcurses.so.1", O_RDONLY)   = 3
19752:  open("/lib/libnsl.so.1", O_RDONLY)  = 3
19752:  open("/usr/lib/libxml2.so.2", O_RDONLY) = 3
19752:  open("/lib/libpthread.so.1", O_RDONLY)  = 3
19752:  open("/usr/lib/libz.so", O_RDONLY)  = 3
19752:  open("/usr/lib/liblzma.so.5", O_RDONLY) = 3
19752:  open("/lib/libm.so.2", O_RDONLY)= 3
19752:  open("/lib/libsocket.so.1", O_RDONLY)   = 3
19752:  open("/lib/libmd.so.1", O_RDONLY)   = 3
19752:  ioctl(1, TCGETA, 0x08047C2E)= 0
TYPEDISKVID  PID  SIZE  RMV SSD
19752:  open("/lib/libdevinfo.so.1", O_RDONLY)  = 3
19752:  open("/etc/dev/.devlink_db", O_RDONLY)  = 3
19752:  open("/devices/pseudo/devinfo@0:devinfo", O_RDONLY) = 4
19752:  ioctl(4, DINFOIDENT, 0x)= 57311
19752:  ioctl(4, 0x10DF00, 0x0804730C)  = 515519
19752:  ioctl(4, DINFOUSRLD, 0x080B1000)= 516096
19752:  open("/dev/openprom", O_RDONLY) = 4
19752:  open("/lib/libdevid.so.1", O_RDONLY)= 5
19752:  open("/devices/pseudo/devinfo@0:devinfo", O_RDONLY) = 5
19752:  ioctl(5, DINFOIDENT, 0x)= 57311
19752:  ioctl(5, 0xDF0F, 0x0804730C)= 515519
19752:  ioctl(5, DINFOUSRLD, 0x080B1000)= 516096
19752:  open("/devices/pseudo/devinfo@0:devinfo", O_RDONLY) = 5
19752:  ioctl(5, DINFOIDENT, 0x)= 57311
19752:  ioctl(5, 0x10DF00, 0x0804730C)  = 515519
19752:  ioctl(5, DINFOUSRLD, 0x080B1000)= 516096
19752:  open("/lib/libsysevent.so.1", O_RDONLY) = 3
19752:  open("/etc/mnttab", O_RDONLY)   = 3
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  ioctl(3, MNTIOC_GETEXTMNTENT, 0x08046DC4)   = 0
19752:  open("/var/run/sysevent_channels/syseventd_channel/24", O_RDWR|O_CREAT, 
0600) = 3
19752/1:ioctl(4, I_CANPUT, 0x)  Err#89 ENOSYS
19752/1:open("/var/run/sysevent_channels/syseventd_channel/reg_door", 
O_RDONLY) = 3
19752/1:open("/var/run/sysevent_channels/syseventd_channel/reg_door", 
O_RDONLY) = 3
19752/1:open("/var/run/sysevent_channels/syseventd_channel/reg_door", 
O_RDONLY) = 3
19752/1:open("/dev/rdsk/c14t0d0s0", O_RDONLY|O_NDELAY)  = 3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x08047340)   Err#5 EIO
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x08047340)   Err#5 EIO
19752/1:open("/dev/rdsk/c18t5000C50041439FE7d0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x080477F0)   = 0
19752/1:open("/dev/rdsk/c18t5000C500565DDAFBd0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x080477F0)   = 0
19752/1:open("/dev/rdsk/c18t5000C5004143DC0Fd0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x080477F0)   = 0
19752/1:open("/dev/rdsk/c18t5000C5004164150Fd0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x080477F0)   = 0
19752/1:open("/dev/rdsk/c18t5000C500414406BFd0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x080477F0)   = 0
19752/1:open("/dev/rdsk/c18t5000C5005646520Bd0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x080477F0)   = 0
19752/1:open("/dev/rdsk/c18t5000C50041450EEBd0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:ioctl(3, DKIOCGMEDIAINFO, 0x080477F0)   = 0
19752/1:open("/dev/rdsk/c18t5000C500565B32ABd0s0", O_RDONLY|O_NDELAY) = 
3
19752/1:

Re: [OmniOS-discuss] upgrading from 151014

On Wed, 4 Jan 2017 15:56:17 -0500
Dan McDonald  wrote:

> 
> (Note the get-rid-of-SunSSH before actually upgrading part.)
> 
I guess this will be a prerequisite doing 151014 -> 151022 anyway?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
When women kiss it always reminds one of prize fighters shaking hands.
-- H. L. Mencken, "Sententiae"


pgpKR7TVzUpoN.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] device probe related command timeouts

You’re awesome! Its hanging on “open /dev/rdsk/c14t0d0s0”

Looking at that disk now. 

On 1/4/17, 3:15 PM, "Joshua M. Clulow"  wrote:

On 4 January 2017 at 13:09, John Barfield  wrote:
> It actually finally completed. Doing it again with the proper PID as 
suggested provides the following:
> root@PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k
>> 0t19448::pid2proc | ::walk thread | ::findstack -v
> stack pointer for thread ff249059: ff010a286750
> [ ff010a286750 _resume_from_idle+0xf4() ]
>   ff010a286780 swtch+0x141()
>   ff010a2867c0 sema_p+0x1c7(ff26e094b600)
>   ff010a286800 biowait+0xa4(ff26e094b540)
>   ff010a2868d0 scsi_uscsi_handle_cmd+0x127(c10d40, 1, 
ff24907f3da8, f7b159b0, 0, ff27c23171e8)
>   ff010a286960 sd_ssc_send+0x136(ff24227d4e00, ff010a286970, 
8000, 1, 0)
>   ff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ff24227d4e00, 1)
>   ff010a286b40 sd_get_media_info_com+0xaf(c10d40, 
ff010a286b50, ff010a286b54, ff010a286b58, 0)
>   ff010a286ba0 sd_get_media_info+0x41(c10d40, 8047330, 15)
>   ff010a286c80 sdioctl+0xc57(c10d40, 42a, 8047330, 15, 
ff24930f7580, ff010a286e68)
>   ff010a286cc0 cdev_ioctl+0x39(c10d40, 42a, 8047330, 15, 
ff24930f7580, ff010a286e68)
>   ff010a286d10 spec_ioctl+0x60(ff2492b62d80, 42a, 8047330, 
15, ff24930f7580, ff010a286e68, 0)
>   ff010a286da0 fop_ioctl+0x55(ff2492b62d80, 42a, 8047330, 15, 
ff24930f7580, ff010a286e68, 0)
>   ff010a286ec0 ioctl+0x9b(3, 42a, 8047330)
>   ff010a286f10 _sys_sysenter_post_swapgs+0x149()

OK, it seems that we're hanging while sending a TEST UNIT READY to
some device.  It's probably easiest to just use truss(1), here; e.g.:

truss -t "open,ioctl" -f diskinfo

Once it starts hanging, you should be able to see which open(2) and
ioctl(2) calls happened just before the hang.


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] device probe related command timeouts

2017-01-04 Thread Joshua M. Clulow

On 4 January 2017 at 13:09, John Barfield  wrote:
> It actually finally completed. Doing it again with the proper PID as 
> suggested provides the following:
> root@PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k
>> 0t19448::pid2proc | ::walk thread | ::findstack -v
> stack pointer for thread ff249059: ff010a286750
> [ ff010a286750 _resume_from_idle+0xf4() ]
>   ff010a286780 swtch+0x141()
>   ff010a2867c0 sema_p+0x1c7(ff26e094b600)
>   ff010a286800 biowait+0xa4(ff26e094b540)
>   ff010a2868d0 scsi_uscsi_handle_cmd+0x127(c10d40, 1, 
> ff24907f3da8, f7b159b0, 0, ff27c23171e8)
>   ff010a286960 sd_ssc_send+0x136(ff24227d4e00, ff010a286970, 
> 8000, 1, 0)
>   ff010a286a30 sd_send_scsi_TEST_UNIT_READY+0x121(ff24227d4e00, 1)
>   ff010a286b40 sd_get_media_info_com+0xaf(c10d40, ff010a286b50, 
> ff010a286b54, ff010a286b58, 0)
>   ff010a286ba0 sd_get_media_info+0x41(c10d40, 8047330, 15)
>   ff010a286c80 sdioctl+0xc57(c10d40, 42a, 8047330, 15, 
> ff24930f7580, ff010a286e68)
>   ff010a286cc0 cdev_ioctl+0x39(c10d40, 42a, 8047330, 15, 
> ff24930f7580, ff010a286e68)
>   ff010a286d10 spec_ioctl+0x60(ff2492b62d80, 42a, 8047330, 15, 
> ff24930f7580, ff010a286e68, 0)
>   ff010a286da0 fop_ioctl+0x55(ff2492b62d80, 42a, 8047330, 15, 
> ff24930f7580, ff010a286e68, 0)
>   ff010a286ec0 ioctl+0x9b(3, 42a, 8047330)
>   ff010a286f10 _sys_sysenter_post_swapgs+0x149()

OK, it seems that we're hanging while sending a TEST UNIT READY to
some device.  It's probably easiest to just use truss(1), here; e.g.:

truss -t "open,ioctl" -f diskinfo

Once it starts hanging, you should be able to see which open(2) and
ioctl(2) calls happened just before the hang.


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them

2017-01-04 Thread Richard Elling

one more thing…

> On Jan 4, 2017, at 10:29 AM, Richard Elling 
>  wrote:
> 
>> 
>> On Jan 4, 2017, at 10:04 AM, Chris Siebenmann  wrote:
>> 
>> We recently had a server reboot due to the ZFS vdev_deadman/spa_deadman
>> timeout timer activating and panicing the system. If you haven't heard
>> of this timer before, that's not surprising; triggering it requires an
>> IO to a vdev to take more than 1000 seconds (by default; it's controlled
>> by the value of zfs_deadman_synctime_ms, in spa_misc.c).
>> 
>> Before this happened, I would not have expected that our OmniOS system
>> allowed an IO to run that long before timing it out and returning an
>> error to ZFS. Clearly I'm wrong, which means that I'd like to understand
>> what disk IO timeouts OmniOS has and where (or if) we can control them
>> so that really long IOs get turned into forced errors well before 16
>> minutes go by. Unfortunately our disk topology is a bit complicated;
>> we have scsi_vhci multipathing on top of iSCSI disks.
> 
> Do not assume the timeout reflects properly operating software or firmware.
> The original impetus for the deadman was to allow debugging of the underlying
> stack. Prior to adding the deadman, the I/O could be stuck forever.
> 
>> 
>> In some Internet searching I've found sd_io_time (60 seconds by
>> default) and the default SD retry count of 5 (I think, it may be
>> 3), which can be adjusted on a per-disk-type basis through the
>> retries-timeout parameter (per the sd manpage). Searching the kernel
>> code suggests that there are some hard-coded timeouts in the 30 to 90
>> second range, which also doesn't seem excessive.
> 
> For sd-level, most commands follow the sd_io_time and retries. scsi_vhci adds
> significant complexity above sd and below zfs.
> — richard
> 
>> 
>> (I have a crash dump from this panic, so I can in theory use mdb
>> to look through it to see just what level an IO appears stuck at
>> if I know what to look for and how.)
>> 
>> Based on 'fmdump -eV' output, it looks like our server was
>> retrying IO repeatedly.
>> 
>> Does anyone know what I should be looking at to find and adjust
>> timeouts, retry counts, and so on? Is there any documentation that
>> I'm overlooking?

I find the "zio_state" mdb macro helpful in these cases. It shows all of the 
I/Os in the zio pipeline
and the timeout values relative to the deadman.
 — richard

>> 
>> Thanks in advance.
>> 
>>  - cks
>> PS: some links I've dug up in searches:
>>   
>> http://everycity.co.uk/alasdair/2011/05/adjusting-drive-timeouts-with-mdb-on-solaris-or-openindiana/
>>   https://smartos.org/bugview/OS-2415
>>   https://www.illumos.org/issues/1553
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] device probe related command timeouts

2017-01-04 Thread Joshua M. Clulow

On 4 January 2017 at 12:57, John Barfield  wrote:
> root@PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 18919
> 18919:  sudo diskinfo
>  fee8e665 pollsys  (8047b50, 2, 0, 0)
>  fee264af pselect  (6, 8089c30, 8089c50, fef06320, 0, 0) + 1bf
>  fee267b8 select   (6, 8089c30, 8089c50, 0, 0, 0) + 8e
>  08055f64 sudo_execute (807c960, 8047ce8, 41e, c0) + 4ba
>  080606f8 run_command (807c960, 807c9c0, 8047d88, 805dff9) + 4c
>  0805e03f main (8047d7c, fef076a8, 8047db4, 8054cc3, 2, 8047dc0) + 681
>  08054cc3 _start   (2, 8047e7c, 8047e81, 0, 8047e8a, 8047e95) + 83

I think you've grabbed the "sudo" process, rather than the child
"diskinfo" process.  If you use "ptree" on the pid first, you'll be
able to see the full tree of processes.


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] device probe related command timeouts

Hi Joshua, 

As requested:

root@PRD-GIP-cpls-san1:/export/home/jbarfield# pstack 18919
18919:  sudo diskinfo
 fee8e665 pollsys  (8047b50, 2, 0, 0)
 fee264af pselect  (6, 8089c30, 8089c50, fef06320, 0, 0) + 1bf
 fee267b8 select   (6, 8089c30, 8089c50, 0, 0, 0) + 8e
 08055f64 sudo_execute (807c960, 8047ce8, 41e, c0) + 4ba
 080606f8 run_command (807c960, 807c9c0, 8047d88, 805dff9) + 4c
 0805e03f main (8047d7c, fef076a8, 8047db4, 8054cc3, 2, 8047dc0) + 681
 08054cc3 _start   (2, 8047e7c, 8047e81, 0, 8047e8a, 8047e95) + 83
root@PRD-GIP-cpls-san1:/export/home/jbarfield# mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp 
scsi_vhci zfs sata sd ip hook neti sockfs arp usba uhci stmf stmf_sbd md lofs 
mpt_sas random idm ipc nfs ptm crypto cpc kvm ufs logindmux nsmb smbsrv ]
> 0t18919::pid2proc | ::ps -f
SPID   PPID   PGIDSIDUID  FLAGS ADDR NAME
R  18919  18022  18919  18022  0 0x5a016000 ff24c389d000 sudo diskinfo
> 0t18919::pid2proc | ::walk thread | ::findstack -v
stack pointer for thread ff24c5bf4500: ff010a032c50
[ ff010a032c50 _resume_from_idle+0xf4() ]
  ff010a032c80 swtch+0x141()
  ff010a032d10 cv_wait_sig_swap_core+0x1b9(ff26a30f47fa,
  ff26a30f47c0, 0)
  ff010a032d30 cv_wait_sig_swap+0x17(ff26a30f47fa, ff26a30f47c0)
  ff010a032d60 cv_timedwait_sig_hrtime+0x35(ff26a30f47fa,
  ff26a30f47c0, )
  ff010a032e20 poll_common+0x554(8047b50, 2, 0, 0)
  ff010a032ec0 pollsys+0xe7(8047b50, 2, 0, 0)
  ff010a032f10 _sys_sysenter_post_swapgs+0x149()
>
 

On 1/4/17, 2:52 PM, "Joshua M. Clulow"  wrote:

On 4 January 2017 at 12:29, John Barfield  wrote:
> I’ve got a SAN that seems to be timing out on any hardware probing 
commands such as “format” or “diskinfo” although prtconf seems to work.
>
> Does anyone happen to have a dtrace one liner or maybe kstat command I 
can run to see why/what they’re hanging on?

I would start by running "pstack" with the pid of one of the stuck
processes.  That will give you the part of the user program which is
stuck.  Then, I would get the in-kernel state of the stuck threads;
e.g., looking at my bash process:

asgard # echo $$
45435
asgard # ps -fp 45435
 UID   PID  PPID   CSTIME TTY TIME CMD
root 45435 45433   0 20:47:17 pts/3   0:00 -bash

asgard # mdb -k
Loading modules: [ unix genunix specfs ... ]
> 0t45435::pid2proc | ::ps -f
SPID   PPID   PGIDSIDUID  FLAGS ADDR NAME
R  45435  45433  45435  45435  0 0x4a014000 ff1b14d33048 -bash
> 0t45435::pid2proc | ::walk thread | ::findstack -v
stack pointer for thread ff03f776c080: ff0011b57c10
[ ff0011b57c10 _resume_from_idle+0x112() ]
  ff0011b57c40 swtch+0x141()
  ff0011b57cd0 cv_wait_sig_swap_core+0x1b9(ff1b14d33108, ...)
  ff0011b57cf0 cv_wait_sig_swap+0x17(ff1b14d33108, ...)
  ff0011b57da0 waitid+0x315(7, 0, ff0011b57e30, f)
  ff0011b57eb0 waitsys32+0x36(7, 0, 8047750, f)
  ff0011b57f10 sys_syscall32+0x123()


That might tell us where in the storage subsystem you're getting stuck.


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] upgrading from 151014

Start with 014, get rid of SunSSH, and you should be able to Just Upgrade:

https://omnios.omniti.com/wiki.php/Upgrade_to_r151020

(Note the get-rid-of-SunSSH before actually upgrading part.)

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] device probe related command timeouts

2017-01-04 Thread Joshua M. Clulow

On 4 January 2017 at 12:29, John Barfield  wrote:
> I’ve got a SAN that seems to be timing out on any hardware probing commands 
> such as “format” or “diskinfo” although prtconf seems to work.
>
> Does anyone happen to have a dtrace one liner or maybe kstat command I can 
> run to see why/what they’re hanging on?

I would start by running "pstack" with the pid of one of the stuck
processes.  That will give you the part of the user program which is
stuck.  Then, I would get the in-kernel state of the stuck threads;
e.g., looking at my bash process:

asgard # echo $$
45435
asgard # ps -fp 45435
 UID   PID  PPID   CSTIME TTY TIME CMD
root 45435 45433   0 20:47:17 pts/3   0:00 -bash

asgard # mdb -k
Loading modules: [ unix genunix specfs ... ]
> 0t45435::pid2proc | ::ps -f
SPID   PPID   PGIDSIDUID  FLAGS ADDR NAME
R  45435  45433  45435  45435  0 0x4a014000 ff1b14d33048 -bash
> 0t45435::pid2proc | ::walk thread | ::findstack -v
stack pointer for thread ff03f776c080: ff0011b57c10
[ ff0011b57c10 _resume_from_idle+0x112() ]
  ff0011b57c40 swtch+0x141()
  ff0011b57cd0 cv_wait_sig_swap_core+0x1b9(ff1b14d33108, ...)
  ff0011b57cf0 cv_wait_sig_swap+0x17(ff1b14d33108, ...)
  ff0011b57da0 waitid+0x315(7, 0, ff0011b57e30, f)
  ff0011b57eb0 waitsys32+0x36(7, 0, 8047750, f)
  ff0011b57f10 sys_syscall32+0x123()


That might tell us where in the storage subsystem you're getting stuck.


Cheers.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] upgrading from 151014

2017-01-04 Thread Richard Jahnel

I'm trying to update some omnios machines I use a fibre targets from 101514 to 
current one step at a time.

In step one just trying to get to 16 I've already gotten stuck. Any ideas on 
how to get the upgrade to proceed?

# cat /etc/release
  OmniOS v11 r151014
  Copyright 2015 OmniTI Computer Consulting, Inc. All rights reserved.
  Use is subject to license terms.
# pkg update
Creating Plan (Running solver): -
pkg update: No solution was found to satisfy constraints
Plan Creation: Package solver has not found a solution to update to latest 
available versions.
This may indicate an overly constrained set of packages are installed.

latest incorporations:

  pkg://omnios/entire@11,5.11-0.151016:20151202T161203Z
  pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151016:20151102T185724Z
  
pkg://omnios/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.151016:20160603T025742Z
  
pkg://omnios/incorporation/jeos/omnios-userland@11,5.11-0.151016:20160315T193155Z

The following indicates why the system cannot update to the latest version:

  No suitable version of required package 
pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151016:20151102T185724Z 
found:
Reject:  
pkg://omnios/incorporation/jeos/illumos-gate@11,5.11-0.151016:20151102T185724Z
Reason:  A version for 'incorporate' dependency on 
pkg:/system/data/zoneinfo@2015.7,5.11-0.151016 cannot be found
  No suitable version of required package 
pkg://omnios/network/openssh-server@7.1.1,5.11-0.151016:20151102T190719Z found:
Reject:  
pkg://omnios/network/openssh-server@7.1.1,5.11-0.151016:20151102T190719Z
Reason:  Package contains 'exclude' dependency pkg:/service/network/ssh on 
installed package


and much much more along the above lines.

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New SAN deployment HBA recommendations

> On Jan 4, 2017, at 3:35 PM, John Barfield  wrote:
> 
> Are you suggesting that I buy a 9300 series or simply stating that we can 
> move to that series soon in the future?

Buy a 9300 now.  It's been working for ALL of our supported releases (i.e. 014 
and later).

> I am looking to start purchasing and building immediately. What is the 
> release timeline for 151022?

022 is being pushed out to Summer due to major upstream changes in illumos 
(watch this list for a user-visible design-decision I need to make, e.g.).

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New SAN deployment HBA recommendations

We will definitely use the latest omnios after everything is ordered.

Are you suggesting that I buy a 9300 series or simply stating that we can move 
to that series soon in the future?

I am looking to start purchasing and building immediately. What is the release 
timeline for 151022?

On 1/4/17, 2:31 PM, "Dan McDonald"  wrote:

> On Jan 4, 2017, at 3:21 PM, John Barfield  
wrote:
> 
> I was specifically wondering what is supported in the latest OmniOS 
release, but I suppose youre suggesting that I could backport an illumos driver 
from the latest build into ominos? 
> 
> OmniOS is the distro I use for SAN deployments. I use SmartOS for 
hypervisors. 

Ahh, okay.

Everything HBA-wise in illumos-gate is already in OmniOS r151020.

I was projecting forward for you, in case you were gauging future HW 
purchases (and the upcoming OmniOS r151022, which is ALSO our next LTS).

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New SAN deployment HBA recommendations

> On Jan 4, 2017, at 3:21 PM, John Barfield  wrote:
> 
> I was specifically wondering what is supported in the latest OmniOS release, 
> but I suppose youre suggesting that I could backport an illumos driver from 
> the latest build into ominos? 
> 
> OmniOS is the distro I use for SAN deployments. I use SmartOS for 
> hypervisors. 

Ahh, okay.

Everything HBA-wise in illumos-gate is already in OmniOS r151020.

I was projecting forward for you, in case you were gauging future HW purchases 
(and the upcoming OmniOS r151022, which is ALSO our next LTS).

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] device probe related command timeouts

Greetings again,

I’ve got a SAN that seems to be timing out on any hardware probing commands 
such as “format” or “diskinfo” although prtconf seems to work.

Fmadm faulty shows a bad fan in the MD1200 JBOD that is connected and that is 
all.

I’m trying to nail down the root but I’m hitting a brick wall. Prstat, iostat 
all seem to be showing normal activity on all of the disks.

Does anyone happen to have a dtrace one liner or maybe kstat command I can run 
to see why/what they’re hanging on?

We’ve been experiencing some intermittent storage related freezes on the system 
(ESXi hosts) and I can’t seem to get very to close to the source…wondering if 
this is related.

Have a great day!

John Barfield
M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfi...@bissinc.com

[cid:image001.png@01D26696.FD87AAE0]
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com or 
supp...@bissinc.com


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New SAN deployment HBA recommendations

I was specifically wondering what is supported in the latest OmniOS release, 
but I suppose youre suggesting that I could backport an illumos driver from the 
latest build into ominos? 

OmniOS is the distro I use for SAN deployments. I use SmartOS for hypervisors. 

On 1/4/17, 2:18 PM, "Dan McDonald"  wrote:

> On Jan 4, 2017, at 3:02 PM, John Barfield  
wrote:
> 
> Greetings, 
>  
> I’m designing a new ZFS SAN and I’m wondering if anyone knows the latest 
greatest supported HBA that I should use for external JBOD’s.
>  
> We have tons of SAN’s in production using LSI HBAs today but I’m 
wondering if there is anything new out there that I’m missing or not aware of 
yet.

Are you using LSI 9300 series (driven by the 3008 chipset) yet?  That's the 
latest from the world of LSI.  Those are fairly recent (last 3-4 years), and 
many still use the 2008 chipset or 2208 chipset.

There are parts currently just-in-SmartOS that may be getting upstreamed 
soon as well.

You may be better off asking this question on the illumos developers' list, 
to see what the latest/greatest in supported HBA HW is.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] New SAN deployment HBA recommendations

> On Jan 4, 2017, at 3:02 PM, John Barfield  wrote:
> 
> Greetings, 
>  
> I’m designing a new ZFS SAN and I’m wondering if anyone knows the latest 
> greatest supported HBA that I should use for external JBOD’s.
>  
> We have tons of SAN’s in production using LSI HBAs today but I’m wondering if 
> there is anything new out there that I’m missing or not aware of yet.

Are you using LSI 9300 series (driven by the 3008 chipset) yet?  That's the 
latest from the world of LSI.  Those are fairly recent (last 3-4 years), and 
many still use the 2008 chipset or 2208 chipset.

There are parts currently just-in-SmartOS that may be getting upstreamed soon 
as well.

You may be better off asking this question on the illumos developers' list, to 
see what the latest/greatest in supported HBA HW is.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] New SAN deployment HBA recommendations

Greetings,

I’m designing a new ZFS SAN and I’m wondering if anyone knows the latest 
greatest supported HBA that I should use for external JBOD’s.

We have tons of SAN’s in production using LSI HBAs today but I’m wondering if 
there is anything new out there that I’m missing or not aware of yet.

Thanks for any recommendations.


John Barfield
M: +1 (214) 425-0783  O: +1 (214) 506-8354
john.barfi...@bissinc.com

[cid:image001.png@01D26693.1E73B1D0]
4925 Greenville Ave, Ste 900
Dallas, TX 75206

For Support Requests:
http://support.bissinc.com or 
supp...@bissinc.com

k
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them

2017-01-04 Thread Richard Elling


> On Jan 4, 2017, at 10:04 AM, Chris Siebenmann  wrote:
> 
> We recently had a server reboot due to the ZFS vdev_deadman/spa_deadman
> timeout timer activating and panicing the system. If you haven't heard
> of this timer before, that's not surprising; triggering it requires an
> IO to a vdev to take more than 1000 seconds (by default; it's controlled
> by the value of zfs_deadman_synctime_ms, in spa_misc.c).
> 
> Before this happened, I would not have expected that our OmniOS system
> allowed an IO to run that long before timing it out and returning an
> error to ZFS. Clearly I'm wrong, which means that I'd like to understand
> what disk IO timeouts OmniOS has and where (or if) we can control them
> so that really long IOs get turned into forced errors well before 16
> minutes go by. Unfortunately our disk topology is a bit complicated;
> we have scsi_vhci multipathing on top of iSCSI disks.

Do not assume the timeout reflects properly operating software or firmware.
The original impetus for the deadman was to allow debugging of the underlying
stack. Prior to adding the deadman, the I/O could be stuck forever.

> 
> In some Internet searching I've found sd_io_time (60 seconds by
> default) and the default SD retry count of 5 (I think, it may be
> 3), which can be adjusted on a per-disk-type basis through the
> retries-timeout parameter (per the sd manpage). Searching the kernel
> code suggests that there are some hard-coded timeouts in the 30 to 90
> second range, which also doesn't seem excessive.

For sd-level, most commands follow the sd_io_time and retries. scsi_vhci adds
significant complexity above sd and below zfs.
 — richard

> 
> (I have a crash dump from this panic, so I can in theory use mdb
> to look through it to see just what level an IO appears stuck at
> if I know what to look for and how.)
> 
> Based on 'fmdump -eV' output, it looks like our server was
> retrying IO repeatedly.
> 
> Does anyone know what I should be looking at to find and adjust
> timeouts, retry counts, and so on? Is there any documentation that
> I'm overlooking?
> 
> Thanks in advance.
> 
>   - cks
> PS: some links I've dug up in searches:
>
> http://everycity.co.uk/alasdair/2011/05/adjusting-drive-timeouts-with-mdb-on-solaris-or-openindiana/
>https://smartos.org/bugview/OS-2415
>https://www.illumos.org/issues/1553
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] NFS 4.2 Support - Sparse Files

2017-01-04 Thread Mini Trader

Hello all,

Is there any support for NFS 4.2 in Illumos?  I am interested in the Sparse
File functionality that has been introduced.

Thanks!
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them

2017-01-04 Thread Eric Sproul

On Wed, Jan 4, 2017 at 1:04 PM, Chris Siebenmann  wrote:
> (I have a crash dump from this panic, so I can in theory use mdb
> to look through it to see just what level an IO appears stuck at
> if I know what to look for and how.)

Hi Chris,
I recently blogged about digging into a deadman crash with mdb:
http://www.circonus.com/blog/crash-dump-necromancy

I'll let others with more direct experience respond about the timeout settings.

HTH,
Eric
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Understanding OmniOS disk IO timeouts and options to control them

2017-01-04 Thread Chris Siebenmann

We recently had a server reboot due to the ZFS vdev_deadman/spa_deadman
timeout timer activating and panicing the system. If you haven't heard
of this timer before, that's not surprising; triggering it requires an
IO to a vdev to take more than 1000 seconds (by default; it's controlled
by the value of zfs_deadman_synctime_ms, in spa_misc.c).

Before this happened, I would not have expected that our OmniOS system
allowed an IO to run that long before timing it out and returning an
error to ZFS. Clearly I'm wrong, which means that I'd like to understand
what disk IO timeouts OmniOS has and where (or if) we can control them
so that really long IOs get turned into forced errors well before 16
minutes go by. Unfortunately our disk topology is a bit complicated;
we have scsi_vhci multipathing on top of iSCSI disks.

In some Internet searching I've found sd_io_time (60 seconds by
default) and the default SD retry count of 5 (I think, it may be
3), which can be adjusted on a per-disk-type basis through the
retries-timeout parameter (per the sd manpage). Searching the kernel
code suggests that there are some hard-coded timeouts in the 30 to 90
second range, which also doesn't seem excessive.

(I have a crash dump from this panic, so I can in theory use mdb
to look through it to see just what level an IO appears stuck at
if I know what to look for and how.)

Based on 'fmdump -eV' output, it looks like our server was
retrying IO repeatedly.

Does anyone know what I should be looking at to find and adjust
timeouts, retry counts, and so on? Is there any documentation that
I'm overlooking?

Thanks in advance.

- cks
PS: some links I've dug up in searches:

http://everycity.co.uk/alasdair/2011/05/adjusting-drive-timeouts-with-mdb-on-solaris-or-openindiana/
https://smartos.org/bugview/OS-2415
https://www.illumos.org/issues/1553
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Happy New Year, and Python2.7

The first of the big changes for this bloody cycle is underway internally, i.e. 
the move from Python2.6 to Python2.7 for OmniOS-internal users of Python.  
Those users are currently:

pkg(5)

traditional installer media (not kayak)

As of now, the pkg5 test suite is mostly passing with Python2.7, and bloody 
users know that Python2.7 is AVAILABLE in the main "omnios" publisher repo.

The installer still needs work, but I'm curious how many bloody users out there 
would be comfortable with having (for now) older install media, but when "pkg 
update" occurs, moving entirely to Python2.7?  The possible answers are:

* We want both:  Basically, don't jump to Python2.7 until all components are 
ready.

* We can cope:  Basically, make the jump for pkg5, but for now, traditional 
install media would be frozen, until the Python2.7 jump has been completed.

Appreciate your feedback, and I have one more longer-term question coming later 
today or tomorrow.

Thanks!
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] uname -v change