Bug 14095 - Use sendfile = yes broken completely as of bug 13537
Summary: Use sendfile = yes broken completely as of bug 13537
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 regression (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-19 21:10 UTC by Jesse Miller
Modified: 2019-08-20 04:44 UTC (History)
1 user (show)

See Also:


Attachments
FreeBSD sys_sendfile() fix - patch (2.34 KB, patch)
2019-08-19 21:10 UTC, Jesse Miller
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Miller 2019-08-19 21:10:04 UTC
Created attachment 15400 [details]
FreeBSD sys_sendfile() fix - patch

Previous to the patch landed in bug 13537, sendfile would cause spinning on EAGAIN/EWOULDBLOCK resulting in excessive CPU usage and poor performance.

The patch in bug 13537 attempted to address this, but it broke the sendfile code almost completely.

On all platforms when EAGAIN or EWOULDBLOCK is encountered, the loop is continue; 'd skipping any accounting of data already sent, resulting in whatever data sent before encountering a blocking situation be re-sent, clients error out on this and the transfer fails.

I will attach a patch, that I am using now on FreeBSD, that works. I can move forward and apply this pattern to the other platforms, but would be limited to testing on FreeBSD and Linux (which appears to be more testing that what was landed in bug 13537).

It is important to note when testing 'use sendfile', you must disable aio as it takes precedence over the sendfile path.

#
aio read size = 0
aio write size = 0
use sendfile = yes
#
Comment 1 Jeremy Allison 2019-08-19 21:20:42 UTC
Sorry about the breakage for bug 13537. Testing this is hard as you need to trigger EAGAIN/EWOULDBLOCK.