Date: Sun, 26 Jul 1998 19:16:21 -0500 From: Karl Denninger <karl@mcs.net> To: Terry Lambert <tlambert@primenet.com> Cc: Mike Smith <mike@smith.net.au>, wollman@khavrinen.lcs.mit.edu, dswartz@druber.com, current@FreeBSD.ORG, dillon@best.net Subject: Re: MMAP problems Message-ID: <19980726191621.59383@mcs.net> In-Reply-To: <19980726181555.49644@mcs.net>; from Karl Denninger on Sun, Jul 26, 1998 at 06:15:55PM -0500 References: <199807261647.JAA10667@antipodes.cdrom.com> <199807262228.PAA18917@usr01.primenet.com> <19980726181555.49644@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 26, 1998 at 06:15:55PM -0500, Karl Denninger wrote: > On Sun, Jul 26, 1998 at 10:28:08PM +0000, Terry Lambert wrote: > > 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. > > Hmmm... > > Yes, I can confirm (for certain) that the corrupt data is not always zero. > It FREQUENTLY is zero, but not always. If it is non-zero it generally is > identifyable as a chunk of another message (unfortunately I haven't gotten > a HEADER yet; if I do, I will be able to track down where the chunk of data > actually came from). I saw Matt's posting on this. The corrupt data is USUALLY zero. HOWEVER it is not ALWAYS zero. Sometimes it is another random set of data, and so far that has always been identifyable as a piece of another message. > I suspect the real culprit is that I'm running basically all my feeds in > "realtime" mode - if I was delaying by 10 minutes, diablo would never be > writing to the same file that the feeder program was reading at a given time > (ie: the file that was open for MMAP would never be open for write at the > same time). > > I *can* confirm that the files where the corruption is being seen absolutely > ARE open for write when the errors occur; I've managed to catch the system > "in the act" doing this, and have found the file open at the time. > > I'm going to put a "q1" flag on all the feeds (which should effectively > force the system to not "chase its tail" so effectively) and see if the > problem goes away. Doing that should prevent the software from attempting > to read via mmap in the last-written (by write(2)) page. > > If you're right then this should make the problem disappear. Adding "q1" to all the feeds has basically stopped the complaints and corruption. Now the question is how to fix it so that I can run with realtime enabled :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980726191621.59383>