>>Committing a 64k block would require 8 times the overhead of bundling
>>up the RPC as well as transmission and reply, it may be possible
>>to pipeline these commits because you don't really need to wait
>>for one to complete before issueing another request, but it's still
>>8x the amount of traffic.
>
>I agree that it is obvious for NFS, but I don't see it as being
>obvious at all for (modern) disks, so for that case I would like
>to see numbers.
>
>If running without clustering is just as fast for modern disks,
>I think the clustering needs rethought.
Depends on the type of disk drive and how it is configured. Some drives
perform badly (skip a revolution) with back-to-back writes. In all cases,
without aggregation of blocks, you pay the extra cost of additional interrupts
and I/O rundowns, which can be a significant factor. Also, unless the blocks
were originally written by the application in a chunk, they will likely be
mixed with blocks to varying locations, in which case for drives without
write caching enabled, you'll have additional seeks to write the blocks out.
Things like this don't show up when doing simplistic sequential write tests.
-DG
David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
