smb read/write block size
skendric at fhcrc.org
Tue Jan 17 00:13:25 GMT 2006
i'm analyzing read/write performance to various CIFS servers. the largest
read block size i'm seeing is 61,440 bytes and the largest write block
size is 32,768 bytes
SMB Write AndX FID: 0x0009, 61440 bytes at offset 0
SMB Read AndX Request, FID: 0x000b, 32768 bytes at offset 0
what drives this choice? is this something hard-wired into Microsofts
implementations of CIFS and the rest of us have just copied it? does this
relate to how frequently CIFS wants to commit bytes to disk? is there
some way to increase this (registry hacks under Windows, smb.conf fiddles
under Samba, etc.)? [i'm not looking for specific registry hacks or
smb.conf lines here ... just a conceptual understanding of the magic
around '61440' and '32768'.]
i've found a thread driven by hertel, with urban, minshall, and others
involved, which suggests that a 64K ceiling exists because
SMB_COM_WRITE/READ_ANDX is a USHORT, i.e. can only acknowledge 64K bytes
... so since CIFS can't acknowledge more than 64K bytes, therefore CIFS
can't send more than 64K bytes.
"Once again, that suggests that you could send a write of more than 64K.
The thing is, the SMB_COM_WRITE_ANDX response does *not* have an extension
field according to the docs:
USHORT Count; Number of bytes written
So the server can only report up to 64K written. There's no way to report
that more than 64K were written unless one of the Reserved fields is
actually the upper 16 bits of the Count."
would i be correct in pointing to the USHORT definition of
SMB_COM_WRITE_ANDX/SMB_COM_READ_ANDX as the proximate cause for a 64K
read/write limitation in CIFS?
i can see room to improve CIFS performance significantly in the LAN
environment, and dramatically in the WAN environment (long, fat pipes), if
i can hack my clients and servers to increase their CIFS Read/Write block
size above 61440 ==> ergo my queries.
More information about the samba-technical