Date: Mon, 29 Mar 2004 09:36:56 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Mark Terribile <materribile@yahoo.com> Subject: Re: MS_ASYNC with MS_INVALIDATE Message-ID: <20040329153656.GA14775@dan.emsphone.com> In-Reply-To: <20040329080003.GA72136@server.vk2pj.dyndns.org> References: <20040327195505.13415.qmail@web21113.mail.yahoo.com> <20040328210236.GM3446@dan.emsphone.com> <20040329080003.GA72136@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Mar 29), Peter Jeremy said: > On Sun, Mar 28, 2004 at 03:02:37PM -0600, Dan Nelson wrote: > >In the last episode (Mar 27), Mark Terribile said: > > > A friend asked me to run some Linux source on FreeBSD. It > > > simulates a data pool management system he is using, and it > > > includes a call msync(2) with both the MS_ASYNC and MS_INVALIDATE > > > flags. FreeBSD does not allow this. (I tested it on my 4.8 > > > system; I'll have access to a 5.1 system on Monday.) I ran it > > > without the MS_ASYNC, and got very different results from the > > > ones he reported on Linux. I'd like to be able to explain what's > > > happening. > > My interpretation of the man page suggests that MS_ASYNC should not > have any effect other than timing unless there are race conditions. Me too. No combination of flags to msync() should affect any other processes view of the data IMHO. It just affects how soon the blocks get written to disk. Now, if you're also accessing this file over NFS, that's a different matter. I actually think MS_INVALIDATE might be a no-op on a system with a merged vm/buffer cache. -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040329153656.GA14775>