Damien, > An OPTIMAL TRANSFER LENGTH GRANULARITY field set to 0000h indicates > that the device server does not report optimal transfer length > granularity. > > For a SCSI disk, sd.c uses this value for sdkp->min_xfer_blocks. Note > that the naming here is dubious since this is not a minimum. The > minimum is the logical block size. min_io is a preferred minimum, not an absolute minimum, just like the physical block size. You can do smaller I/Os but you don't want to. > Storage devices may report an optimal I/O size, which is the device's > preferred unit for sustained I/O. This is rarely reported for disk > drives. For RAID arrays it is usually the stripe width or the internal > track size. A properly aligned multiple of optimal_io_size is the > preferred request size for workloads where sustained throughput is > desired. If no optimal I/O size is reported this file contains 0. > > Well, I find this definition not correct *at all*. This is repeating > the definition of minimum_io_size (limits->io_min) and completely > disregard the eventual optimal_io_size limit of the drives in the > array. opt_io defines the optimal I/O size for a sequential/throughput-focused workload. You can do larger I/Os but you don't want to. RAID arrays at the time the spec was written had sophisticated non-volatile caches which managed data in tracks or cache lines. When you issued an I/O which straddled internal cache lines in the array, you would fall back to a slow path as opposed to doing things entirely in hardware. So the purpose of the optimal transfer length and granularity in SCSI was to encourage applications to write naturally aligned full tracks/cache lines/stripes. > For a raid array, this value should obviously be a multiple of > minimum_io_size (the array stripe size), SCSI does not require this but we enforce it in sd.c. -- Martin K. Petersen
