Thanks to kind help from Peter Wemm and John Baldwin from the FreeBSD
project, we now the cause of the sendfile corruption:
Sendfile moves the filebuffers to the socket and as soon as it has
done this, it returns, and the buffers may not have been processed
by TCP yet.
With the recent change to make pass mode use the same codepath as
a normal cached transaction, the filebuffers will get recycled
as soon as sendfile returns, and any other transaction that grabs
that piece of filebuffer may write new data in it, before the
TCP stack is done.
For a normal cached operation, the data in the filebuffer lives on,
until the object expires. and therefore corruption will be a lot
less likely, but not impossible in that case.
I'm investigating the options we have, but for now we can't use
sendfile.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
project, we now the cause of the sendfile corruption:
Sendfile moves the filebuffers to the socket and as soon as it has
done this, it returns, and the buffers may not have been processed
by TCP yet.
With the recent change to make pass mode use the same codepath as
a normal cached transaction, the filebuffers will get recycled
as soon as sendfile returns, and any other transaction that grabs
that piece of filebuffer may write new data in it, before the
TCP stack is done.
For a normal cached operation, the data in the filebuffer lives on,
until the object expires. and therefore corruption will be a lot
less likely, but not impossible in that case.
I'm investigating the options we have, but for now we can't use
sendfile.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.