A packet or streams layer for GENSEC/SASL?

[David Collier-Brown]

Jeremy Allison wrote:
> Ah, I thought that might be the case. Yes, we take the
> client request size and only coalesce it if the write
> cache is enabled. "By design" I think is the answer here.
> 
> Just one reason we can't deprecate the write cache code.

   Once upon a time we discussed making it a VFS, as I
suspected it might only apply if the underlying filesystem
was sensitive to read/write sizes.
   The degree of improvement with a single-disk system was
an argument against doing so..

   Thus this possibility: Samba uses the size it thinks
best. For oplocked files, which have a high probability
of being read and written sequentially, Samba might
use a fairly large value. A user could request a different
size on a per-share basis.
   For non-oplocked files, Samba might use a size that
it thinks is appropriate. A user could similarly set
it to known "good" values. My leaky memory says 4KB is
what Oracle like (;-))

   Anyone need special handling, such as smaller sizes,
is free to write a VFS. For example, if one had a very
high-performance use, such as the video streamer that
exposed this problem, they could write a vfs that
uses forcedirectio and a specific read/write size,
thus avoiding the entire filesystem cache.

   I suspect this would lead to a path where the write
cache code falls out of use and can be deprecated, and
to
- a possible simplification of the existing various-sizes
   buffer code, and
- a general performance benefit if those buffers are being
   allocated/reallocated often,
- reuse of common buffer code in many modules (gensec?).

--dave (in "cool algorithms lead to work avoidance" mode) c-b
-- 
David Collier-Brown,      | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb at canada.sun.com     |                      -- Mark Twain
(416) 263-5733 (x65733)   |