Re: absurdly high "optimal_io_size" on Seagate SAS disk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/06/2014 07:56 PM, Martin K. Petersen wrote:
"Chris" == Chris Friesen <chris.friesen@xxxxxxxxxxxxx> writes:

Chris,

Chris> For a RAID card I expect it would be related to chunk size or
Chris> stripe width or something...but even then I would expect to be
Chris> able to cap it at 100MB or so.  Or are there storage systems on
Chris> really fast interfaces that could legitimately want a hundred meg
Chris> of data at a time?

Well, there are several devices that report their capacity to indicate
that they don't suffer any performance (RMW) penalties for large
commands regardless of size. I would personally prefer them to report 0
in that case.

I got curious and looked at the spec at "http://www.13thmonkey.org/documentation/SCSI/sbc3r25.pdf";. I'm now wondering if maybe linux is misbehaving.

I think there is actually some justification for putting a huge value in the "optimal transfer length" field. That field is described as "the optimal transfer length in blocks for a single...command", but then later it has "If a device server receives a request with a transfer length exceeding this value, then a significant delay in processing the request may be incurred." As written, it is ambiguous.

Looking at "ftp://ftp.t10.org/t10/document.03/03-028r2.pdf"; it appears that originally that field was the "optimal maximum transfer length", not the "optimal transfer length". It appears that the intent was that the device was able to take requests up to the "maximum transfer length", but there would be a performance penalty if you went over the "optimum maximum transfer length".

Section E.4 in "sbc3r25.pdf" talks about optimizing transfers. They suggest using a transfer length that is a multiple of "optimal transfer length granularity", up to a max of either the max or optimal transfer lengths depending on the size of the penalty if you exceed the optimal transfer length. This reinforces the idea that the "optimal transfer length" is actually the optimal *maximum* length, but any multiple of the optimal granularity is fine.

Based on that, I think it would have been clearer if it had been called "/sys/block/sdb/queue/optimal_max_io_size".

Also, I think it's wrong for filesystems and userspace to use it for alignment. In E.4 and E.5 in the "sbc3r25.pdf" doc, it looks like they use the optimal granularity field for alignment, not the optimal transfer length.


So for the ST900MM0006, it had:

# sg_inq --vpd --page=0xb0 /dev/sdb
VPD INQUIRY: Block limits page (SBC)
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 0 blocks
  Optimal transfer length: 4294967295 blocks

In this case I think the drive is trying to say that it doesn't require any special granularity (can handle alignment on 512-byte blocks), and that it can handle any size of transfer without performance penalty.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux