Xref: utzoo comp.protocols.nfs:1887 comp.arch:21264
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!mips!sdd.hp.com!caen!ox.com!umich!terminator!merit.edu!rsc
From: rsc@merit.edu (Richard Conto)
Newsgroups: comp.protocols.nfs,comp.arch
Subject: Re: disk queues of length zero.....
Message-ID: <1991Mar6.173456.3707@terminator.cc.umich.edu>
Date: 6 Mar 91 17:34:56 GMT
References: <28975@cs.yale.edu> <PCG.91Feb28195347@odin.cs.aber.ac.uk> <PCG.91Mar4210505@aberdb.cs.aber.ac.uk> <1991Mar5.223443.21187@ns.uoregon.edu> <1991Mar6.003008.9131@bellcore.bellcore.com>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rsc@merit.edu (Richard Conto)
Organization: U of Michigan, Merit Network
Lines: 14

In article <1991Mar6.003008.9131@bellcore.bellcore.com> mo@bellcore.com (Michael O'Dell) writes:
>	                 Say you write 50 megabytes.  You now close
>	the file and hence ask for it to really go to disk.
>	WHAM! 50 megabytes goes on the disk queue.

So, when doing memory mapped files like this, why not tell the server to
set aside (preallocate) the disk space as the file is filling up on the
client? That does mean more overhead, but it does make it more certain
that the server won't reject the file when it is placed on the server.

Sounds like a poor implementation to me (or a bad design). The concept
should work, even in extreme cases like the above.

--- Richard    ( rsc@merit.edu, Richard_Conto@um.cc.umich.edu )