Date: Sun, 26 Jul 1998 22:16:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: green@zone.baldcom.net (Brian Feldman) Cc: andre@pipeline.ch, karl@mcs.net, current@FreeBSD.ORG Subject: Re: MMAP problems Message-ID: <199807262216.PAA18637@usr01.primenet.com> In-Reply-To: <Pine.BSF.4.00.9807251817390.6651-100000@zone.baldcom.net> from "Brian Feldman" at Jul 25, 98 06:20:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807262216.PAA18637>