[OmniOS-discuss] Ang: COMSTAR and blocksizes

[Stephan Budach]

----- Ursprüngliche Mail -----
> Von: "Stephan Budach" <stephan.budach at jvm.de>
> An: "Johan Kragsterman" <johan.kragsterman at capvert.se>
> CC: omnios-discuss at lists.omniti.com
> Gesendet: Donnerstag, 7. September 2017 12:22:06
> Betreff: Re: [OmniOS-discuss] Ang:  COMSTAR and blocksizes
> 
> 
> 
> ----- Ursprüngliche Mail -----
> > Von: "Johan Kragsterman" <johan.kragsterman at capvert.se>
> > An: "Stephan Budach" <stephan.budach at jvm.de>
> > CC: omnios-discuss at lists.omniti.com
> > Gesendet: Donnerstag, 7. September 2017 12:08:45
> > Betreff: Ang: [OmniOS-discuss] COMSTAR and blocksizes
> > 
> > 
> > Hi!
> > 
> > -----"OmniOS-discuss" <omnios-discuss-bounces at lists.omniti.com>
> > skrev: -----
> > Till: omnios-discuss at lists.omniti.com
> > Från: Stephan Budach
> > Sänt av: "OmniOS-discuss"
> > Datum: 2017-09-07 10:38
> > Ärende: [OmniOS-discuss] COMSTAR and blocksizes
> > 
> > Hi,
> > 
> > I am having trouble getting an issue sorted out, where omniOS
> > 151020
> > complaints about mismatched blocksizes on some COMSTAR iSCSI LUNS,
> > like this:
> > 
> > Sep  7 08:52:07 zfsha02gh79     104 I/O requests are not aligned
> > with
> > 8192 disk sector size in 10 seconds. They are handled through Read
> > Modify Write but the performance is very low!
> > Sep  7 08:52:07 zfsha02gh79 scsi: [ID 107833 kern.warning] WARNING:
> > /scsi_vhci/disk at g600144f0564d504f4f4c3037534c3033 (sd94):
> > Sep  7 08:52:07 zfsha02gh79     79 I/O requests are not aligned
> > with
> > 8192 disk sector size in 10 seconds. They are handled through Read
> > Modify Write but the performance is very low!
> > Sep  7 08:52:16 zfsha02gh79 scsi: [ID 107833 kern.warning] WARNING:
> > /scsi_vhci/disk at g600144f0564d504f4f4c3037534c3132 (sd88):
> > Sep  7 08:52:16 zfsha02gh79     20 I/O requests are not aligned
> > with
> > 8192 disk sector size in 10 seconds. They are handled through Read
> > Modify Write but the performance is very low!
> > Sep  7 08:52:17 zfsha02gh79 scsi: [ID 107833 kern.warning] WARNING:
> > /scsi_vhci/disk at g600144f0564d504f4f4c3038534c3033 (sd110):
> > Sep  7 08:52:17 zfsha02gh79     1 I/O requests are not aligned with
> > 8192 disk sector size in 10 seconds. They are handled through Read
> > Modify Write but the performance is very low!
> > Sep  7 08:52:17 zfsha02gh79 scsi: [ID 107833 kern.warning] WARNING:
> > /scsi_vhci/disk at g600144f0564d504f4f4c3037534c3033 (sd94):
> > Sep  7 08:52:17 zfsha02gh79     24 I/O requests are not aligned
> > with
> > 8192 disk sector size in 10 seconds. They are handled through Read
> > Modify Write but the performance is very low!
> > 
> > These COMSTAR LUNs are configured to export a blocksize 8k like
> > this:
> > 
> > LU Name: 600144F0564D504F4F4C3037534C3132
> >     Operational Status: Online
> >     Provider Name     : sbd
> >     Alias             : nfsvmpool07Slot12
> >     View Entry Count  : 1
> >     Data File         : /dev/rdsk/c3t50015178F364A264d0p1
> >     Meta File         : not set
> >     Size              : 200042414080
> >     Block Size        : 8192
> >     Management URL    : not set
> >     Vendor ID         : SUN
> >     Product ID        : COMSTAR
> >     Serial Num        : not set
> >     Write Protect     : Disabled
> >     Writeback Cache   : Enabled
> >     Access State      : Active
> > 
> > Now, the system seems to recognize the 8k, but for whatever reason,
> > doesn't adjust the block size accordingly. It does that for the 4k
> > LUNs, however, so I am unsure, on how to tackle this? Any tipp,
> > anyone could share?
> > 
> > Thanks,
> > Stephan
> > 
> > 
> > 
> > 
> > 
> > 
> > What's in the bottom here?
> > 
> > Data File         : /dev/rdsk/c3t50015178F364A264d0p1
> > 
> > It dosesn't look like a zvol?
> > 
> > /Johan
> 
> It isn't one - it's a raw partition, an Intel SSD in this case.
> 
> Cheers,
> Stephan
> 

Hi all,

I just exported this zpool from my omniOS 020 and imported it on a recent oi box and the issue with the 8k writes doesn't seem to be present on oi. Any thoughts on this?

Thanks,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20170908/c69d8c85/attachment.bin>