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

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 11 Aug 1999 12:40:19 -0700

> > Before you flush this message, wait.
> > 
> > This is neither a long proposal nor a (portion of) a long
> > discussion between Mike Eisler and me.
> > 
> > It is related to caching and to a discussion between Mike
> > Eisler and me.  If you have the slightest interest in the
> > outcome of the caching discussion read on for a bit.
> > 
> > Mike and I have discussed the issue of write caching that 
> > isn't written through to the server on close.  Mike feels
> > that what I have in this regard isn't good enough and nothing 
> > (all dirty data is flushed to the server on close) is 
> > preferable.  I am prepared to give Mike what he wants,
> > unless I would be taking away something that somebody else
> > wants.  If you object to me doing this, I need to hear
> > from you, real soon now.
> 
> The issue I've been complaining about is that the space 
> reservation scheme in
> the caching proposal is based on file lengths. If a client 
> wants to write cache
> files larger than the maximim file length specified by the 
> server, then, even
> if the client is willing to write cache a subset of an 
> existing large file, it
> is still compelled to flush the cache upon close.
> 
> My opinion is that such an approach puts the whole concept of 
> write caching in
> question. So what I want is to remove write delegations from 
> the proposal as
> it stands.

I keep having trouble with your use of of the term "write 
caching".  To me write caching means caching data that 
has been modififed without immediately writing to the 
server (=writeback caching).  I assume that under all
circumstances (with write delegation or without), you 
would at least want to keep the modified data locally 
until close or unlock.  Is this so?

The question (I think) we are discussing is related
to keeping modified data on the client (without 
flushing it to the server) past close.  Can we call
this writeback-past-close caching, to distiguish
this from other cases?

If I understand you, you are saying that the provisions
that the proposal makes for writeback-past-close
caching, being filesize-based, are therefore inadequate
and, so inadequate that you would argue that they
call into question that concept (the concept of
writeback-past-close caching).  Is this what you are
saying, if you were to accomodate me by expressing things
using my terms?

Although I don't agree, this, eliminating writeback-
past-close caching, is what I was proposing
to do to accomodate your position given that nobody else
objects.  Perhaps I misunderstood your position?
I think after we (finally!) understand one another,
we can come to some agreement on what specifically
should be done.

Where I definitely disagree is when you propose
eliminating write delegations.  Write delegation is
a big win, even if writeback-past-close caching
has been removed (or is simply inactivated by 
the server setting the filesize limit to zero).

Here's why.  If write delegation is in effect,
the client knows nobody else is using this file.
Therefore, he gets the following benefits:

     He doesn't have to send OPEN's and CLOSE's
     to the server.

     He doesn't have to send LOCK and UNLOCK to
     the server and doesn't need to do any
     associated data revalidations.

     He doesn't have to flush data to the server
     on an UNLOCK (as opposed to a CLOSE).

     When he flushes data to the server he doesn't
     have to do a COMMIT and make sure that the data
     gets to stable storage.

> 
> I think the straw poll should be,
> 
> 	Is the proposed space reservation scheme for write 
> delgations inadequate?

I think that would be unanimous (2-0 with a million
abstentions).  I think it's inadequate.  I would like to 
avoid flushing to the server in more cases, as much 
(or almost as much) as you would.

I just don't know how to do it, given that the relation between
the amount of data written and the space required may be
highly idiosyncratic and difficult to manage among client
and server who don't share the same assumptions.  I 
would be delighted if someone were to figure out how to
do this before October.  Given the fabulous amount of
interest that caching issues seem to generate right now,
I'd say if you or I don't do it, it won't get done.

> 
> I.e. if no one responds, silence indicates consent to 
> existing proposal.
 
I think that that (lack of response) is a foregone conclusion.
Apathy keeps winning by a landslide.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 11 Aug 1999 12:58:55 -0700 (PDT)

> saying, if you were to accomodate me by expressing things

Close.

I'm saying that the provisions that the proposal makes for writeback-past-close
caching, being filesize-based, are therefore inadequate and, so inadequate
that I argue that they call into the question the concept of write delegations,
whether writeback-past-close or writeback-flushed-on-close.

> abstentions).  I think it's inadequate. 

But you are willing to run with the proposal nonetheless. So let's rephrase:

	Is the proposed space reservation scheme for write 
	delgations sufficient for the purpose of incorporation
	into the NFS version 4 draft specification?

> Apathy keeps winning by a landslide.

I find the apathy ironic, given that the mood was decidely
unapathetic 6 months ago. But the consensus then was that we
needed a caching proposal. So we have one now, and based on the
consensus 6 months ago, and based on the dearth of opposition, I'd
say it's a go.

	-mre

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 11 Aug 1999 13:17:17 -0700

Based on my understanding of the discussion so far, I have two
questions.

1. If the client has a write delegation, does it still have to flush
to the server on CLOSE?

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?

(Apologies if I'm going back over ground that was already covered in
earlier discussions.  Pointers to archived mail that I should (re)read
are cheerfully accepted.)

mike