aio_read template.

[James Peach]

On Wed, Jun 08, 2005 at 03:15:55PM +0200, Volker Lendecke wrote:
> Hi, David!
> 
> On Wed, Jun 08, 2005 at 08:49:49AM -0400, David Collier-Brown wrote:
> >   Interesting!  
> >   I had a similar problem about a year ago with I/O from a large 
> > array, where either misordering or reads of ridiculous sizes coming
> > from NT Media Server (of all the things that should try to stream reads!) 
> > would result in pessimal throughput.
> >  I found that a simple buffered read of the stripe width would
> > make it optimal, and that had the side-effect of improving
> > normal I/O from Solaris UFS and QFS.
> 
> When you look at the pattern XPSP2 gives you, this does not really work that
> way, at least I don't know how to keep sanity. The following table shows the
> read pattern I see coming from XPSP2 when the Win32 app reads 256k blocks, the
> tables shows offset/length:
> 
> 0 61440
> 61440 4096
> 65536 61440
> 126976 4096
> 131072 61440
> 192512 4096
> 196608 61440
> 258048 4096

I never understood why Windows clients do things like this. It's clearly
trying to to 64K I/Os, which can be nicely stripe-aligned and will
trigger the zero-copy path in XFS. Samba offers a 64K buffer and the
large readX capability bit, so why doesn't the client do something sane?

> Ok, so far it's sequential. But now something weird happens:
> 
> 524288 61440
> 262144 61440
> 585728 4096
> 323584 4096
> 589824 61440
> 327680 61440
> 651264 4096
> 389120 4096
> 655360 61440
> 393216 61440
> 716800 4096
> 454656 4096
> 720896 61440
> 458752 61440
> 782336 4096
> 520192 4096
> 
> This looks like two threads reading in parallel, blocks starting at 256k and
> 512k. This happens for example with cygnus dd bs=256k which most probably does
> not issue multi-threaded requests, as well as with the XDD tool from
> ioperformance.com with explicit setting to sequentially read.
> 
> 786432 61440
> 847872 4096
> 851968 61440
> 913408 4096
> 917504 61440
> 978944 4096
> 983040 61440
> 1044480 4096
> 1048576 61440
> 1114112 61440
> 1110016 4096
> 1175552 4096
> 1179648 61440
> 1241088 4096
> 1245184 61440
> 1306624 4096
> 
> Ok, this was 2 256k blocks sequentially, and we're back to parallel reads
> again:
> 
> 1572864 61440
> 1310720 61440
> 1634304 4096
> 1372160 4096
> 1638400 61440
> 1376256 61440
> 1699840 4096
> 1437696 4096
> 1703936 61440
> 1441792 61440
> 1765376 4096
> 1503232 4096
> 1769472 61440
> 1507328 61440
> 1830912 4096
> 1568768 4096
> 
> .... And sequential again (not shown anymore). This pattern proceeds until the
> file is ended.

Yes, this looks a lot like 2 asynchronous 256K I/Os in flight. Each one
is being broken up into 4 61440/4096 pairs.

> Now tell me how I can sanely detect this kind of pattern with a cache... :-)
>
> De-install SP1 or use any other Windows version and you're fine.

Do they still do the 61440/4096 pattern, or do they just not issue
multiple I/Os?

-- 
James Peach | jpeach at sgi.com | SGI Australian Software Group
I don't speak for SGI.