Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Jun 1998 16:29:02 -0400
From:      "Allen Smith" <easmith@beatrice.rutgers.edu>
To:        ben@rosengart.com
Cc:        Eivind Eklund <eivind@yes.no>, hackers@FreeBSD.ORG
Subject:   Re: Newbie 3 questions.
Message-ID:  <9806091629.ZM1008@beatrice.rutgers.edu>
In-Reply-To: Snob Art Genre <benedict@echonyc.com>   "Re: Newbie 3 questions." (Jun  9,  1:40am)
References:  <Pine.GSO.3.96.980609013810.21103B-100000@echonyc.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 9,  1:40am, Snob Art Genre (possibly) wrote:
> On Mon, 8 Jun 1998, Allen Smith wrote:
> 
> > Is async necessary/desirable for an MFS, or is it automatic? From the
> > 4.4BSD book, I know that the 4.4BSD MFS is built just like a FFS, only
> > using pageable memory space instead of filesystem space.
> 
> Sync and async refer to policies for when to commit certain writes to
> disk.  MFS lives in RAM, except when it's paged out, and then it's the
> pager algorithm that determines which pages get written to disk, not the
> metadata update scheme.

So far as I can tell, the MFS uses the normal filesystem buffer cache,
with transfers to the mount_mfs process's memory determined by the
policies of that cache. Since some overhead is experienced with the
memory copying, context switching, etcetera, it would be desirable to
delay such as long as possible, or at least to avoid having a writing
process delayed until such was done.

After a closer look at the source code, it appears that
ufs_direnter, ufs_dirremove, and ufs_dirrewrite use the MNT_ASYNC flag
to tell whether to call bdwrite (which will simply mark the buffer
dirty - called with MNT_ASYNC) or bwrite (which will wait on it to be
done - called without MNT_ASYNC). In other words, mounting a MFS
filesystem async may indeed help. (Of course, I'm by no means an
expert, so I'd appreciate corrections to this.) I may later do some
experiments to check on this - we'll be using an MFS for Squid.

	-Allen


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



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