kern/92243: sendfile(2) returns early on files > 4GB

[David Kelly]

>Number:         92243
>Category:       kern
>Synopsis:       sendfile(2) returns early on files > 4GB
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 24 04:30:08 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     David Kelly
>Release:        6.0-STABLE
>Organization:
self
>Environment:
FreeBSD Grumpy.DynDNS.org 6.0-STABLE FreeBSD 6.0-STABLE #9: Tue Jan 17 19:25:47 CST 2006     dkelly at Grumpy.DynDNS.org:/usr5/obj/usr/src/sys/OPUS  i386

>Description:
This is a restatement of bin/89100 as I now believe it is a kernel problem rather than an application problem.  Am now convinced it is a problem with either vm or the way sendfile(2) talks to the vm system. Sendfile(2) works correctly with a fresh large file. Files older than the last reboot (possibly filesystem umount/mount will age sufficiently) always fail. Files newer than the latest mount fail after an unknown amount of activity on that filesystem.

If file size is > 4G then sendfile(2) returns to caller (wrongly) when exactly 4G is remaining. Have not experimented with 8G files.

>How-To-Repeat:
Get a file which is larger than 4G via ftpd, apache, or anything else which uses sendfile(2).

The file must have aged a bit on the filesystem. A reboot is a sure way to age the file enough. Sendfile(2) works perfectly with a new file or fresh copy.

ftp to localhost and get a big file to /dev/null to quickly reproduce the problem.
>Fix:
If ftpd and ftp client work well together then a "reget" will complete the truncated download. Not a fix.

If enough space exists on the filesystem a fresh copy of the file will transfer correctly, yet the original still will not transfer completely.
>Release-Note:
>Audit-Trail:
>Unformatted: