Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Jan 2000 03:29:03 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Guido van Rooij <guido@gvr.org>
Cc:        Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>, vsilyaev@mindspring.com, dillon@freebsd.org, freebsd-emulation@FreeBSD.ORG, dbutter@wireless.net
Subject:   Re: VMware: Questions... 
Message-ID:  <20000103192903.AEF531CA0@overcee.netplex.com.au>
In-Reply-To: Message from Guido van Rooij <guido@gvr.org>  of "Mon, 03 Jan 2000 19:51:00 %2B0100." <20000103195100.A44079@gvr.gvr.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
Guido van Rooij wrote:
> On Fri, Dec 31, 1999 at 09:02:45AM +0800, Peter Wemm wrote:
> > > a directory entry in the file system. This could even be done for the gen
    eral
> > > mmap call (provided a regular file of course). But it might be a very
> > > specific situation because one usually would not used a file backed
> > > mmap in FreeBSD, yet use an anonymous mmap. 
> > 
> > I had a go, it turned out to be quite easy (so far).  I haven't finished
> > verifying that it's doing everything exactly as expected yet though.
> 
> I am now using the following patch. I had a printf in the if clause
> to see if other processes would use the code, but vmware seems the only one.
> 
> In fact I have been thinking about an fcntl() for files to b able
> to specify the nosync option. This would be handy in mkstemp().
> However Bruceb thinks it would not result in much improvement.
> 
> -Guido
> 
> --- vm_mmap.c.orig	Sun Dec 12 04:19:29 1999
> +++ vm_mmap.c	Fri Dec 24 10:08:37 1999
> @@ -1024,6 +1024,14 @@
>  				return (error);
>  			objsize = round_page(vat.va_size);
>  			type = OBJT_VNODE;
> +			/*
> +			 * if it is a regular file without any references
> +			 * we do not need to sync it.
> +			 */
> +			if (vp->v_type == VREG && vat.va_nlink == 0) {
> +				flags |= MAP_NOSYNC;
> +			}
>  		}
>  	}

Heh, yours is simpler than mine.  I was attempting a more generic solution
that marked a vnode as unlinked in the filesystems and the syncer then took
special care to avoid msyncing them.  Mine would have caught the case where
a file was mmaped first then unlinked and kept open.  If the syncer could
do anything special with unlinked plain files, it would then have the
information to deal with them too.  (It doesn't, so that part is academic).
FFS already discards dirty blocks on last close if the file is already
unlinked.

Cheers,
-Peter




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




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