Date: Tue, 7 Apr 1998 20:30:02 -0700 (PDT) From: David Greenman <dg@root.com> To: freebsd-bugs Subject: Re: kern/6212: Two bugs with MFS filesystem fixed, two features added Message-ID: <199804080330.UAA03752@hub.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR kern/6212; it has been noted by GNATS.
From: David Greenman <dg@root.com>
To: Peter Wemm <peter@netplex.com.au>
Cc: dyson@freebsd.org, freebsd-gnats-submit@freebsd.org
Subject: Re: kern/6212: Two bugs with MFS filesystem fixed, two features added
Date: Tue, 07 Apr 1998 20:25:39 -0700
>David Greenman wrote:
>> > Although, I'm puzzled why the msync() is needed at all, since it's just a
>> > mmap'ed file. Perhaps there is some new lurking problem with synchronizing
>> > of mmap'ed files... :-/
>>
>> We've gone both ways with this issue in the past, but the final resolution
>> was that it is better to require the msync() rather than automatically
>> flushing VM system managed pages to the backing store.
>
>Hmm.. Matt points out that a 'sync' command will cause the writeback, the
>dirty pages will get written to the file providing the mmap() backing
>store. The pre-softdep code ran a sync every 30 seconds in process 3
>(update) so this was being "handled".
>
>However, the syncer process doesn't seem to do this any more.. It looks
>like the syncer is not doing that old 30-second sync did.
>
>I suspect that this is a result of the differences between the FreeBSD vs.
>the 4.4Lite2 derived systems that Kirk wrote the code on.
>
>Hmm.. the old update() called 'vfs_msync(mp)' for each mountpoint every 30
>seconds, and this does a walkthrough of the vnodes with OBJ_MIGHTBEDIRTY
>and does a vm_object_page_clean() on them. This is no longer happening
>after softdep, and probably explains the failure to write out dirty mmap
>regions. vfs_msync() (called at sync(2), unmount(2) and from the old update
>process) is documented as:
>/*
> * perform msync on all vnodes under a mount point
> * the mount point must be locked.
> */
>
>I think the loss of this call that is the culprit.
I was confused by the behavior at unmap time - we used to sync out dirty
VM objects then as well, but people using INN (I think) found that this does
bad things to performance. I don't know how this should be handled in the
presense of softupdates, but the non-softupdates case should do the periodic
sync, I think.
-DG
David Greenman
Core-team/Principal Architect, The FreeBSD Project
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804080330.UAA03752>