From owner-freebsd-current Sun Jul 26 15:29:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19291 for freebsd-current-outgoing; Sun, 26 Jul 1998 15:29:08 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19273 for ; Sun, 26 Jul 1998 15:28:53 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id PAA18917; Sun, 26 Jul 1998 15:28:09 -0700 (MST) From: Terry Lambert Message-Id: <199807262228.PAA18917@usr01.primenet.com> Subject: Re: MMAP problems To: mike@smith.net.au (Mike Smith) Date: Sun, 26 Jul 1998 22:28:08 +0000 (GMT) Cc: karl@mcs.net, wollman@khavrinen.lcs.mit.edu, dswartz@druber.com, current@FreeBSD.ORG In-Reply-To: <199807261647.JAA10667@antipodes.cdrom.com> from "Mike Smith" at Jul 26, 98 09:47:54 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The data which gets written is usually a block of zeros, but it may not be; > > it can also be random trash. Its also not always one block (it could be > > more than one), but it IS always, at least from what I'm seeing here, a > > multiple of 512 bytes (disk blocksize). > > The significant question in light of Garrett's description seem to be > whether the trash that's written is actually being written by the > process in error because that's what it got from a previous read, or > whether the process is actually writing the right stuff and it's being > corrupted on the way down. See other postings. Because the corrupt data can be non-zero, I do not believe Garrett's explanation is the correct one; instead, I believe the same page is being pointed to by two mappings at the same time because I don't believe that mmap() references are being revoked correctly. If the data were always zero, then Garret would be discussing the correct problem. The problem Garrett notes is, IMO, "pilot error" and has to do with the failure to call msync() when it is necessary. Per the discussion, it can be made possible to not need to call msync(). Note that I have seen the bug I am describing on both 2.2.6 and 3.0 systems. These are production systems that open and hild open the password file a long time, and which access the crontabe with an annoyingly (and probably undesirably) high frequency. This results in corrupt crontabs. On the other hand, corrupt crontabs are much better than silently corrupted user data... 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message