kern/123095: [libc] sendfile(2): Suspected sendfile data
hno at squid-cache.org
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 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
Date: Tue, 07 Oct 2008 12:27:50 +0200
Content-Type: text/plain; charset=utf-8
On m=C3=A5n, 2008-10-06 at 19:08 -0700, Nate Eldredge wrote:
> 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
> 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?
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the freebsd-bugs