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