Socket draining for sys_recvfile() (patch for 'reverse sendfile')

Andrew Bartlett abartlet at samba.org
Thu Dec 29 20:13:34 MST 2011


On Mon, 2011-12-26 at 08:38 +1100, Andrew Bartlett wrote:
> On Sat, 2011-12-24 at 21:02 -0800, Jeremy Allison wrote:
> 
> > Completely correct. You've found a bug in the splice() codepath !
> > 
> > Well done & thanks.
> 
> No worries!  Now that is fixed up, I'm much more confident to include it
> in the patch for reverse sendfile.
> 
> > The reason this hasn't been an issue up until now is that
> > the splice() codepath is (a) slower than the read/write path,
> > so was never used by default, (b) the Isilon code didn't exercise
> > this codepath at all - they used a custom written sendfile()
> > implementation and (c) it's in an error path rarely taken
> > (probably only on disk full).
> 
> Yeah, and that is the error case I need to test.

I've been testing the disk full semantics, and in 3.5.11, they are
certainly not correct, even when just using the fallback:

Using a small flash drive attached to my NAS, with about 1MB free, with
'min recvfile size = 1':

[abartlet at ruth netgear-src]$ /data/samba/git/samba/bin/smbclient3 //nas-02-22-94/USB_FLASH_1 -Uabartlet%penguin
Domain=[NETGEAR] OS=[Unix] Server=[Samba 3.5.11]
smb: \> rm centos.iso2
smb: \> put /data/vm/cdroms/CentOS-5.5-x86_64-bin-DVD-1of2.iso centos.iso2
cli_push returned NT_STATUS_INVALID_NETWORK_RESPONSE
putting file /data/vm/cdroms/CentOS-5.5-x86_64-bin-DVD-1of2.iso as \centos.iso2 (66.0 kb/s) (average 66.0 kb/s)
smb: \> ^C

with 'min recvfile size = 0':
[abartlet at ruth netgear-src]$ /data/samba/git/samba/bin/smbclient3 //nas-02-22-94/USB_FLASH_1 -Uabartlet%penguin
Domain=[NETGEAR] OS=[Unix] Server=[Samba 3.5.11]
smb: \> rm centos.iso2
smb: \> put /data/vm/cdroms/CentOS-5.5-x86_64-bin-DVD-1of2.iso centos.iso2
cli_push returned NT_STATUS_DISK_FULL
putting file /data/vm/cdroms/CentOS-5.5-x86_64-bin-DVD-1of2.iso as \centos.iso2 (76.0 kb/s) (average 76.0 kb/s)
smb: \> 

I have a capture of both at: http://abartlet.net/recvfile-broken.cap.gz  (I also get similar behaviour with my patch)

Are there any changes to this behaviour since 3.5 I should be aware of?

I'll try out master once I sort out some unrelated loadparm issues on this Sparc based platform

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org




More information about the samba-technical mailing list