svn commit: r201658 - head/sbin/geom/class/stripe

[Bruce Evans]

On Thu, 7 Jan 2010, Alexander Motin wrote:

> Bruce Evans wrote:
>> On Thu, 7 Jan 2010, Alexander Motin wrote:
>>> One thing IMHO would be nice to see there is the alignment of the
>>> read-ahead requests to the array stripe size/offset. Dirty hack I've
>>> tried there, reduced number of requests to the array components by 30%.
>>
>> ffs thinks that bsize alignment is adequate.
>
> Alignment definitely should be adequate, but it is a different task. I
> say that bsize and stripe size are not needed to be equal, as they serve
> different purposes. Even with perfectly aligned usual 16K bsize and 64K
> stripe size we will have 75% chance of misaligned I/O.

That's what I meant by bsize alignment (only) being thought to be
adequate (by ffs, not us).

>> It doesn't try to align
>> files any more than that.  Then for sequential reads from the beginning
>> of the file, vfs read clustering tries to read MAXPHYS bytes at a time,
>> so it perfectly preserves any initial misalignment.

Even with alignment by vfs, with misalignment by ffs we would get
things like an inital 64K read being split up into 48K (to reach a
stripe alignment boundary), then 16K (since that is all that is left
to read).  For larger files starting with this misalignment, we would
get i/o sizes like 48K+128K+...+128K+trailingK, except with ffs there
is also the pessimal allocation of indirect blocks, which will put a
bubble in the i/o at 12*bsize (default 192K) to seek far away to the
indirect block.

> I think we would benefit, if vfs could shrink first request of long
> read-ahead session a bit, to get all further MAXPHYS-sized reads to not
> cross more stripe boundaries then really required. In worst case it can
> generate one extra request to array, in best case it can twice reduce
> number of requests to the array components.

Yes, that is the only relatively easy thing to change.

Bruce