Subject: RE: Caching issue (SHORT, really, I swear)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Aug 1999 06:46:30 -0700

> > > 2. What would happen if Dave's proposal were modified so 
> that instead
> > > of the server expressing a limit in terms of file size, the server
> > > expresses the limit in terms of how much unwritten 
> (dirty) data the
> > > client can accumulate before writing back to the server?
> > 
> > My answer is it that it would cease to work.  The problem is that
> > the mapping from amount of dirty data to amount of disk depends
> > (in a large way) on where specifically, the data is to be written.
> > If I am allowed to write 1000 bytes, if I were to write one thousand
> > very dispersed one-byte areas, the amount of space required might be
> > enormous and it would depend on lots of things, depending on the
> > type of server.  Things like indirect block structures and 
> how holes are
> > handled would all come into play.
> 
> I've come to agree that the file size limit for write caching is too
> restrictive and that a flush on close requirement would be better.

But a flush-on-close requirement is more restrictive??

> I also don't see a way for the server to specify an a priori limit
> other than by file size.
> 
> Here is my understanding of the problem in the context of the current
> proposal:
> 
> 	1) when a write open delegation is granted to a client, the
> 	   client is not required to a close or write back data (up to
> 	   a specified file size);

Just to clarify, the lack of need to send a close to the server is 
absolute while the lack of need to write back data is contingent
on the filesize limit.

> 	2) space availability (or lack thereof) for dirty data is
> 	   guaranteed to be determined by close time at the latest;
> 	3) since closes are not being sent to the server, the client
> 	   must be able to determine on its own what to do with dirty
> 	   data.

On his own, given some small set of data from the server.

> 
> >From these three things comes the file size limitation in write
> delegations.
> 
> Is my statement of the problem correct?

Yes.

> 
> -- 
> James Yarbrough
> 
> [email-masked]
> 
> Blues, an important part of a balanced psyche.

Yes, indeed.

---

From: James Yarbrough <[email-masked]>
Date: Fri, 13 Aug 1999 16:31:25 -0700

> But a flush-on-close requirement is more restrictive??

I may not understand the caching proposal properly.

	1) If a client does not have a write open delegation, is it
	   still allowed to cache writes until the file is closed
	   (ignoring file locking issues)?
	2) If a client has a write open delegation for files up to
	   a particular size, is it still allowed to cache writes
	   until the file is closed for files larger than the size
	   specified for the write open delegation?

The answer to 1 appears to be "yes" from the text in section A.4.1
of the proposal.  The answer to 2 appears to also be "yes" from the
text in the last paragraph of section A.5.1.  I would find it helpful
to have the caching constraints for write open delegations made
more explicit.  For example, something like the following might
work:

	For modified files whose size is less than or equal to the
	size specified in the write open delegation, the client is
	not required to flush dirty data back to the server when the
	files are closed.  For those files larger than the specified
	size, all dirty data must be flushed to the server when the
	files are closed.

-- 
James Yarbrough

[email-masked]