From owner-freebsd-current Sun Jul 26 14:28:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10565 for freebsd-current-outgoing; Sun, 26 Jul 1998 14:28:33 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles247.castles.com [208.214.165.247]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10546 for ; Sun, 26 Jul 1998 14:28:29 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id OAA11981; Sun, 26 Jul 1998 14:27:19 -0700 (PDT) Message-Id: <199807262127.OAA11981@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Karl Denninger cc: Mike Smith , Garrett Wollman , Dan Swartzendruber , current@FreeBSD.ORG Subject: Re: MMAP problems In-reply-to: Your message of "Sun, 26 Jul 1998 13:46:52 CDT." <19980726134652.16525@mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Jul 1998 14:27:19 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, Jul 26, 1998 at 09:47:54AM -0700, Mike Smith wrote: > > > And I can confirm that the trash IS being written to disk; its definitely > > > there on stable storage when you go look for it later. > > > > > > 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. > > Its relavent data (its not COMPLETE junk; rather, its pieces of another > article), so I would say its probably being written in error from a previous > read. It would, naturally, be useful to verify this. Can you instrument your application to check the data as they're read? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message