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

David Collier-Brown davecb at sun.com
Fri Feb 29 18:44:25 GMT 2008

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

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.


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#

More information about the samba-technical mailing list