kern/123095: [libc] sendfile(2): Suspected sendfile data corruption

Henrik Nordstrom hno at
Tue Oct 7 11:00:17 UTC 2008

The following reply was made to PR kern/123095; it has been noted by GNATS.

From: Henrik Nordstrom <hno at>
To: Nate Eldredge <neldredge at>
Cc: bug-followup at
Subject: Re: kern/123095: [libc] sendfile(2): Suspected sendfile data
Date: Tue, 07 Oct 2008 12:27:50 +0200

 Content-Type: text/plain; charset=utf-8
 Content-Transfer-Encoding: quoted-printable
 On m=C3=A5n, 2008-10-06 at 19:08 -0700, Nate Eldredge wrote:
 > Hi,
 > I've been looking at another sendfile related bug (127213) and wondering=20
 > if this one is related.  Can you tell me the type of filesystem where the=
 > corrupted files are located?
 Normal ufs with softupdates enabled.
 > Also, it would be interesting to know the following, if you can test=20
 > them:
 > 1. Does it still happen on newer versions?  7.0-RELEASE for example.
 Can't test easily.
 Currently at 6.3-STABLE. /boot/kernel dated 8 April.
 > 2. If you unmount and remount the filesystem, do the files stay corrupted=
 Tested using a mdconfig virtual device with a file as backing store and
 then it stayed corrupted, even after removing the md device and creating
 it again to the backing store file. But I am not sure this says much.=20
 Hmm.. tried again to umount/mount the filesystem after disabling
 softupdates, and now that does seem to clear the error. Confused. Must
 have done something wrong the first time.. Now it's very consistent
 about clearing the error on umount/mount, no matter if soft-updates is
 enabled or not.
 > 3. What happens if the filesystem is mounted read-only?
 Still corrupted.
 > 4. What happens if you mount with -o sync ?
 The corruption still happens. In fact it even happens earlier most of
 the time (or at least bzr notices it earlier).
 Also tried without soft-updates and the error is the same.
 All tests done with a mdconfig device with a file as backing store.
 Can't create a new real slice to test on, but suspect the results would
 be the same.
 The bug is a little elusive. Running the same actions do not always
 produce the same result, and all attempts in creating a isolated
 testcase has failed so far. Well, the bug did manifest itself once in a
 created test case (replay of a specific request to Apache), but never
 again in 20 or so attempts..
 The full bzr checkout run always makes the problem show up however, but
 not always in the same files or locations. The sequence of requests sent
 to Apache by bzr is the same in each run.
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Description: This is a digitally signed message part
 Version: GnuPG v1.4.7 (GNU/Linux)

More information about the freebsd-bugs mailing list