[SCM] Samba Shared Repository - branch v3-2-test updated - initial-v3-2-test-2626-g719527f

[David Collier-Brown]

No, Solaris does read ahead rather enthusiastically: I think three
sequential read requests of more than 4KB in total guarantees
read-ahead. 

Sequential reads of large amounts of data causes larger amounts to
be read ahead in, as shown by the experiment, and I/O coalescence
seems to cut in around then and make things unexpectedly nice (;-))

I *think* Linux around 2.6 shows a similar effect, but the data
I have was third-hand and I couldn't prove it. I suspect someone
on this list could discover it's speedup  with a similar experiment,
and therefor the good buffer-size numbers for it.

--dave

Volker Lendecke wrote:
> On Fri, Feb 29, 2008 at 10:57:03AM -0500, David Collier-Brown wrote:
> 
>> In tests with both ufs and qfs many moons ago, we found that
>>the speed *leaped* up for large files and large read sizes: 
>>gifs attached.
>>
>>
>>>We could pass io_bufsize to cli_pull, but then I would
>>>really like to increase the default value of io_bufsize to
>>>at least half a meg.
>>
>>Big buffers only *start* helping at 64 KB.  Large is good,
>>and it's especially good if the read size is bigger than the 
>>file (;-)) 
>>
>>The reason they help independent of the network speed
>>is that large reads and writes trigger both read ahead
>>add I/O coalescing, which work together to produce
>>and M * M kind of an improvement.
> 
> 
> The async code should eliminate the network round trips, so
> the server-side pread calls should fly in as quickly as the
> CPU allows. Are you saying that small sequential reads will
> never trigger any kernel-level readahead?
> 
> Volker

-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb at sun.com                 |                      -- Mark Twain
(905) 943-1983, cell: (647) 833-9377, home off: (416) 223-5943 
(800) 555-9786 x56583, bridge: (877) 385-4099 code: 506 9191#