From owner-freebsd-current Sun Jul 26 15:17:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA17468 for freebsd-current-outgoing; Sun, 26 Jul 1998 15:17:04 -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 PAA17463 for ; Sun, 26 Jul 1998 15:17:03 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id PAA18637; Sun, 26 Jul 1998 15:16:22 -0700 (MST) From: Terry Lambert Message-Id: <199807262216.PAA18637@usr01.primenet.com> Subject: Re: MMAP problems To: green@zone.baldcom.net (Brian Feldman) Date: Sun, 26 Jul 1998 22:16:21 +0000 (GMT) Cc: andre@pipeline.ch, karl@mcs.net, current@FreeBSD.ORG In-Reply-To: from "Brian Feldman" at Jul 25, 98 06:20:19 pm 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 > Hmm, what is the default behavior of msync()? Is it handled automatically, > say, in-kernel? If so, maybe it needs to be explicitly called; also is > this daemon using a drive with async/softupdates by any chance? It is supposed to be automatic in the case of a unified VM and buffer cache, by definition. The one place that this is not true is non-fault based file extension, ie: when you extend a file within the last page of the file, while the file is memory mapped. Probably the correct thing to do in this case is to think of backing objects in terms of pages instead of thinking of them in terms of variable length anonymous memory. This would mean that you would grab a full page *and note that you had done so* to back frags in an mmap'ed region. Then if an extension occurs, the changes are made to the page as a page instead of as a frag, and coherency is maintained. The final issue is that when you write fault in the partial page, you look at the backing object to determine the length so that you don't fault zero-filled partial objects out, ending up with your last 0-7 physical blocks getting zeroed. This is more an issue of whether or not the additional overhead is worth avoiding the msync() or not... It is interesting to note that incoherent VM systems (ie: non-unified VM and buffer cache 8-)) do not have this problem. By definition, they will copy only the data from the region into the buffer cache from teh VM. This will result in "correct" (user expected) behaviour on file extension, without needing msync(). 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