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

[Henrik Nordstrom]

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

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

 --=-WCRlk/FBae9i/bTPCY/u
 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,
 >=20
 > 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=
 =20
 > corrupted files are located?
 
 Normal ufs with softupdates enabled.
 
 > Also, it would be interesting to know the following, if you can test=20
 > them:
 >=20
 > 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.
 
 Regards
 Henrik
 
 --=-WCRlk/FBae9i/bTPCY/u
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Description: This is a digitally signed message part
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (GNU/Linux)
 
 iQCVAwUASOs5okNPQ5Kbx8daAQJ75wP/WsR8NhTtQvSVyu/gDMAK1QCgvOfyRGiU
 AVmuCqVUj2boHEYfCHfgHFGUx5pKLq6IF7ulxP6+f9JT303hgwI7KQYhs2ps21WB
 5TXYK34LkXCDzNxsseGVfJv95AZVtk7GQSZGncKHqCtHn2fPZGRY5xPV9BqtSPfu
 6IYbcodRVYE=
 =tvim
 -----END PGP SIGNATURE-----
 
 --=-WCRlk/FBae9i/bTPCY/u--