Date: Fri, 8 Jan 2010 05:43:19 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alexander Motin <mav@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ivan Voras <ivoras@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r201658 - head/sbin/geom/class/stripe Message-ID: <20100108052300.P4481@besplex.bde.org> In-Reply-To: <4B4612E2.70506@FreeBSD.org> References: <201001061712.o06HCICF087127@svn.freebsd.org> <9bbcef731001060938k2b0014a2m15eef911b9922b2c@mail.gmail.com> <4B44D8FA.2000608@FreeBSD.org> <9bbcef731001061103u33fd289q727179454b21ce18@mail.gmail.com> <4B450F30.20705@FreeBSD.org> <20100108013737.S56162@delplex.bde.org> <4B4612E2.70506@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100108052300.P4481>