Date: Fri, 14 Aug 1998 11:00:00 -0700 (PDT) From: Matthew Dillon <dillon@backplane.com> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/7418 (file corruption on mmap-based-read during file write()) Message-ID: <199808141800.LAA25684@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/7418; it has been noted by GNATS.
From: Matthew Dillon <dillon@backplane.com>
To: Luoqi Chen <luoqi@chen.ml.org>
Cc: luoqi@chen.ml.org, freebsd-gnats-submit@freebsd.org,
luoqi@watermarkgroup.com
Subject: Re: kern/7418 (file corruption on mmap-based-read during file write())
Date: Fri, 14 Aug 1998 10:51:24 -0700 (PDT)
:>
:Even if the buffer header is thrown away, the data should be still in
:the vm cache. But I could imagine one scenario that could lead to data loss.
:...
:>
:IO_VMIO flag is only set from getpages/putpages calls, as a result of direct
:mmapped access. We don't need to keep the buffer headers around, and as I
:mentioned before, this won't result in any data loss, the data are still intact
:in vm cache.
:
:-lq
I've noticed something else in regards to the corruption which might
throw more light on the problem.
[one page]
A,B,C,D ... discrete usenet articles stored in file.
[AAAAAAA][AAABBBBBB][BBBBBBBB][BBBBCCCCCCdddddd][DDDDDD...]
page #1 #2 #3 #4 #5
The lower case 'd's indicate corruption... that is, areas of the file
that were corrupted to 0x00. The interesting item is that not only does
the corruption end at a page boundry, it *begins* at the beginning of
an article. That is, article 'C' does not get corrupted at all, nor
is there a piece of the beginning of D that is not corrupted... the
corruption begins at the beginning of article D and ends at the page
boundry (article D continues past the page boundry. The portion after
the page boundry is not corrupted).
So what about this possibillity (this is only a possibility, not an actual
trace):
* process 1 write()'s article B to the file
* process 1 write()'s article C to the file
* process 2 mmap's and faults pages associated with C (i.e. page #4)
(at this point, 'D' has not been written yet and no corruption
has yet occured, page #4 properly contains 00's after the end
of article C). This is a PROT_READ,MAP_SHARED map.
* kernel starts writing page #4 to disk (or kernel starts writing
page #4 to disk and then process #2 faults it in for reading).
* process 1 write()'s article D to the file while page #4 is
dirty and the I/O is in progress. Corruption somehow occurs.
Is there anything fishy in this sequence of events that could cause the
corruption? The corruption I see occurs at least a dozen times a day,
probably more. But that is out of 800,000 article appends to spool files
(per day). Thus, the window of opportunity would be relatively small.
The machine in question is heavily IO loaded... it has lots of memory
and there isn't much pageout/swap activity, but the memory is being
exercised very heavily due to the news spool and reading functions.
There is very heavy read-only mmap'ing of the spool files as well. I
can well imagine this creating concurrency situations that would not
otherwise occur in other setups. For example, disk-write latency
increases severely, creating a larger potential window of opportunity then
if the disks were less heavily loaded.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808141800.LAA25684>