Dealing with the sendfile mess
abartlet at samba.org
Thu Oct 21 00:34:10 GMT 2004
On Thu, 2004-10-21 at 10:15, Jeremy Allison wrote:
> On Thu, Oct 21, 2004 at 08:51:31AM +1000, Andrew Bartlett wrote:
> > The issue, as Steve discovered, is that on failure, our sendfile code
> > will revert to a *normal* read request, despite having already sent the
> > SMB header. This means the header is sent twice, and it all goes to
> > mush from here.
> Is it a case of sendfile just failing ? I never got a good
> report of the exact problem.
That's why I decided to start discussion here, as I think it's possible
to prove this issue from source code.
Presume that for some reason sendfile fails - Steve claimed it was
possible for it to return ENOSYS in odd situations. Currently, we
exit_server() for any other error, and send headers twice for ENOSYS
(see the goto in the write&X code).
> > As we discussed on IRC, there seem to be two fixes we need. We just
> > need to handle normal error cases better - file truncated under us etc,
> > and the lack of a functioning sendfile() at any given moment.
> Actually we don't have to handle this case, tridge proved that
> returning zeros is ok here.
My point exactly. We just need to actually do this (looking at the
code, I think we exit_server() instead).
> The returning the header twice is just a bug and we should
> be able to fix that. The issue is how do we know the header
> has been returned ? If the sendfile failed - where in the
> returning stream did it fail ?
See, the problem is that linux sendfile does not take a headers
argument, and sys_sendfile() in this case does the write, then asks
sendfile to send the data.
I'm proposing that the 'sendfile failed' code should be specific to the
sys_sendfile() implementation. This will allow us to tell where it
failed, and chose the appropriate recovery. (Which may still be
Andrew Bartlett abartlet at samba.org
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20041021/c420a96c/attachment.bin
More information about the samba-technical