Date: Tue, 7 Apr 1998 20:50:01 -0700 (PDT) From: Peter Wemm <peter@netplex.com.au> To: freebsd-bugs Subject: Re: kern/6212: Two bugs with MFS filesystem fixed, two features added Message-ID: <199804080350.UAA06985@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/6212; it has been noted by GNATS.
From: Peter Wemm <peter@netplex.com.au>
To: dg@root.com
Cc: Peter Wemm <peter@netplex.com.au>, dyson@freebsd.org,
freebsd-gnats-submit@freebsd.org
Subject: Re: kern/6212: Two bugs with MFS filesystem fixed, two features added
Date: Wed, 08 Apr 1998 11:44:09 +0800
David Greenman wrote:
> >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 synchroniz
ing
> >> > of mmap'ed files... :-/
[..]
> >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.
I don't think the softupdates have much effect on that, do they?
softupdates is supposed to be about fs metadata, not data pages - we can
write the dirty data pages any time without too much concern for
softupdates.
> -DG
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804080350.UAA06985>