Last week's "Windows Server 2003 better than Linux" test

David Collier-Brown -- Customer Engineering David.Collier-Brown at
Tue May 13 13:58:08 GMT 2003

   I'm testing away on it, but not making blinding progress (;-))
The dbench test were favorable, though...


jra at wrote:
> On Mon, May 12, 2003 at 03:52:10PM -0400, David Collier-Brown -- Customer Engineering wrote:
>>jra at wrote:
>>>Hmmm. To be honest I think this is due to the Solaris UFS 
>>>behavour - it seems to be very sensitive to write sizes
>>>(that's why I added the write cache code). Linux doesn't
>>>seem to need this as the kernel does the buffering.
>>   Yes, I can confirm that in part: up to 8 update 3 UFS (actually
>>an updated ffs, not the old old ufs) wasn't particularly good at
>>coalescing writes.
>>   That changed a lot about then, and I found in traces that
>>ufs was putting together some very nice large chunks. However,
>>that mostly avoids small fragmented writes and excess seeks.
>>Handing ufs multiples of the (block size * stripe width) is
>>still a **very** good thing on a filesystem residing on
>>a RAID array.
>>   On a brand new filesystem, unrelated to ufs, the same is
>>still true: RAID and big buffers beats ufs and small ones
>>by ten to one.
>>   And it applies to read as well: reading large amounts
>>gets a lot of parallelism on the initial reads, and uses
>>the readahead well thereafter.
>>[Just FYI: I've changed my strategy so that samba reading from
>>a readahead cache so as never to give a "short read", and
>>the code got simpler...]
> Can you send me a patch for the read cache code. I'd like
> to get this into 3.0 if possible.
>>   A question for the Linux aficionados: can the OS get
>>knowledge of the "best size" for RAID devices from the device?
>>That sound like something a filesystem might be able to know
>>and use...  albeit not ufs (;-))
> Nope - no syscall I think.
> Jeremy.

David Collier-Brown,           | Always do right. This will gratify
Sun Microsystems DCMO          | some people and astonish the rest.
Toronto, Ontario               |
(905) 415-2849 or x52849       | davecb at

More information about the samba-technical mailing list