From owner-freebsd-bugs  Tue Apr  7 20:50:04 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id UAA07016
          for freebsd-bugs-outgoing; Tue, 7 Apr 1998 20:50:04 -0700 (PDT)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id UAA06985;
          Tue, 7 Apr 1998 20:50:01 -0700 (PDT)
          (envelope-from gnats)
Date: Tue, 7 Apr 1998 20:50:01 -0700 (PDT)
Message-Id: <199804080350.UAA06985@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Peter Wemm <peter@netplex.com.au>
Subject: Re: kern/6212: Two bugs with MFS filesystem fixed, two features added 
Reply-To: Peter Wemm <peter@netplex.com.au>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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