From owner-freebsd-hackers Wed Apr 19 10: 9:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B479637BB88 for ; Wed, 19 Apr 2000 10:09:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA23683; Wed, 19 Apr 2000 10:09:28 -0700 (PDT) (envelope-from dillon) Date: Wed, 19 Apr 2000 10:09:28 -0700 (PDT) From: Matthew Dillon Message-Id: <200004191709.KAA23683@apollo.backplane.com> To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Questions of the syncer process References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I have two questions related to the syncer process that replaces the old :update process: : :(1) The syncer process is waken up once a second (it sleeps on lbolt). If :I have more than 30 mounted filesystems, then each filesystem's dirty data :will stay more than 30 seconds. If I only have a couple of filesystems, :then the syncer will run more frequenty than the old update process. Is :this a good choice? The filesystem sync time has nothing to do with the number of mounted filesystems. Every dirty vnode is added to the syncer list and placed in a specific delay slot. The syncer gets to it in that amount of time no matter how many mounted filesystems there are - usually every 30 seconds or so. :(2) I do not understand why vfs_msync(mp, MNT_NOWAIT) is called before :VFS_SYNC(mp, MNT_LAZY,...). It seems to me that the latter includes the :work done by the former. : :Thanks for any insights into this subject. : :-Zhihui Even though we have a unified buffer cache, we do not have unified bookeeping. vfs_msync() is responsible for converting the bookeeping on dirty VM pages into bookeeping on filesystem buffers. That is, if it finds a dirty VM page it ensures that there is a dirty filesystem buffer header associated with it. Otherwise the filesystem will not know they are dirty. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message