Date: Mon, 5 Dec 2005 21:50:04 GMT From: David Kelly <dkelly@hiwaay.net> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/89100: premature EOF with ftpd on some large files Message-ID: <200512052150.jB5Lo4LS025761@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/89100; it has been noted by GNATS. From: David Kelly <dkelly@hiwaay.net> To: Deomid Ryabkov <myself@rojer.pp.ru> Cc: bug-followup@FreeBSD.org Subject: Re: bin/89100: premature EOF with ftpd on some large files Date: Mon, 5 Dec 2005 15:39:36 -0600 On Mon, Dec 05, 2005 at 11:44:05PM +0300, Deomid Ryabkov wrote: > i have similar problem: sendfile(2) returns prematurely, > when exactly 2^32 bytes left to transfer. > this is demonstrated by ftpd (which uses sendfile), but applies to > apache too (if configured with enablesendfile yes). > in my case, sendfile misbehaves only when asked to send file residing on > NFS-mounted filesystem. > this seems to happen to all files > 4G resiging on NFS-mounted > filesystems. those same files can be read without problem with read(2), > therefore copying with cp(1) succeeds. What I find is that the files "break" somehow for sendfile() once they have aged a bit on the filesystem. "cp -p" the problem file to the same filesystem and sendfile() (via ftpd) sends the copied file correctly today but won't a day or two later. Guess I should try a reboot after copy to see if that breaks the file. Its as if sendfile() doesn't know that it has not finished its job. Possibly a fresh copy has metadata cached by the kernel but sendfile() quits rather than fetch needed metadata if its missing. Of course this worked in RELENG_5. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512052150.jB5Lo4LS025761>