Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 May 1995 12:00:47 -0700 (PDT)
From:      John Dyson <dyson@Root.COM>
To:        peter@nmti.com (Peter da Silva)
Cc:        jkh@FreeBSD.org, hackers@FreeBSD.org
Subject:   Re: Ron Minnich in comp.os.research: Status of Linux/FreeBSD/NetBSD buffer/vm page integration
Message-ID:  <199505181900.MAA12649@Root.COM>
In-Reply-To: <9505181800.AA03902@sonic.nmti.com.nmti.com> from "Peter da Silva" at May 18, 95 01:00:24 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> Suppose you do the following:
> 
> int fd;
> int *ptr;
> fd = open("something", 2);
> ptr = mmap(0, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> 
> *ptr = 1;
> 
> Then you do either:
> msync(ptr, sizeof(*ptr), MS_INVALIDATE)	-or-	fsync(fd);
> 
> On SunOS and many systems, you will see the same result when watching
> over the net: an nfs write at the point of the msync OR the fsync, for
> the "dirty" pages only. It's pretty much what you want: sync the
> modified pieces of the file back to their home.
> 
> On FreeBSD, you don't get the same things at all: fsync and msync are
> very different in freebsd. They are concerned with totally different
> pieces of the kernel and if you depend on the "right thing" happening
> you're in for a surprise.  Specifically, if you use an fsync in the
> above sequence there can still be (lots) of dirty pages for that file
> in you machine, if they apply to mmap'ed files.
This is not a problem on UFS on FreeBSD, and we found out about the bug
very recently.  The fix is minor and not a major problem in the FreeBSD merged
VM buffer cache scheme.  The only reason that it hasn't been fixed is that
it is too close to release.  It'll sure be fixed soon.

So, this is NOT an architecture flaw as much as a programming booboo.
If you are using mmap with NFS -- make sure that you msync!

John
dyson@root.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505181900.MAA12649>