samba - Jan 2005 - sendfile questions...

Why in smbd/reply.c does send_file_readX only use sendfile if write cache
size is 0?

<snip>

if (chain_size ==0 && (CVAL(inbuf,smb_vwv0) == 0xFF) &&
lp_use_sendfile(
SNUM(conn)) &&
                        (lp_write_cache_size(SNUM(conn)) == 0) ) {

</snip>

While its true send_file_readX works regardless of the state of oplocks
(which is cool!) the smb.conf.5 man page still indicates the file must be
exclusively oplocked.


I was researching why an XP client was having 32K reads broken into 28K/4K
pairs (which is mildly bizarre) and ran into this.


[2004/12/30 14:10:35, 3] smbd/reply.c:send_file_readX(2133)
  send_file_readX: sendfile fnum=10940 max=28672 nread=-1
[2004/12/30 14:10:35, 3] smbd/process.c:process_smb(1091)
  Transaction 84503 of length 63
[2004/12/30 14:10:35, 3] smbd/process.c:switch_message(886)
  switch message SMBreadX (pid 450664) conn 0x2010fee8
[2004/12/30 14:10:35, 3] smbd/sec_ctx.c:set_sec_ctx(288)
  setting sec ctx (0, 206) - sec_ctx_stack_ndx = 0
[2004/12/30 14:10:35, 3] smbd/reply.c:send_file_readX(2133)
  send_file_readX: sendfile fnum=10940 max=4096 nread=-1

nread is not captured from the actual sendfile request, which is fine with
me, and the return value is -1 anyway to assure no chaining, but I was
wondering how to find out who's breaking the request down to 28 and 4, the
client or samba?



Bill

On Sun, Jan 02, 2005 at 01:06:47PM -0500, William Jojo
wrote:
> 
> 
> 
> Why in smbd/reply.c does send_file_readX only use sendfile if write cache
> size is 0?
Because it would be difficult to serve the read partially
out of write cache, and partially from the disk. So rather
than work out that complicated logic I decided to only use
sendfile in the non write cache case.
> <snip>
> 
> if (chain_size ==0 && (CVAL(inbuf,smb_vwv0) == 0xFF) &&
lp_use_sendfile(
> SNUM(conn)) &&
>                         (lp_write_cache_size(SNUM(conn)) == 0) ) {
> 
> </snip>
> 
> While its true send_file_readX works regardless of the state of oplocks
> (which is cool!) the smb.conf.5 man page still indicates the file must be
> exclusively oplocked.
It's a little out of date. We used to think this was the case
but experiment with Windows servers showed this is not needed.
> I was researching why an XP client was having 32K reads broken into 28K/4K
> pairs (which is mildly bizarre) and ran into this.
Get a network capture trace and see if the client is requesting
reads of these sizes - if so, then it's the client. In fact I can't
see any way this can be the server only as we only respond to client
read requests.

Jeremy.