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

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 11 Aug 1999 10:32:05 -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.

You can get the details from my most recent mail (today)
in the dreaded "RE: Caching proposal, take 2 (LONG)"
thread but everything you need to see is in the first
page (honest) so it won't "take too long" :-)

Thanks.

---

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

> wants.  If you object to me doing this, I need to hear

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 think the straw poll should be,

	Is the proposed space reservation scheme for write delgations inadequate?

I.e. if no one responds, silence indicates consent to existing proposal.

	-mre

---

From: Carl Beame <[email-masked]>
Date: 12 Aug 1999 17:17:14 +0100

I have always had problems with writing after the close() call!

What happens in the following circumstances:

1) Writing to a disk which stores data in compressed form. At the
time of the write it looks like there is enough room on disk given
the current compression ratio, but when the data is actually written
to the disk from the cache manager, the disk can become full because
the compression ratio changes. 

2) Writing to a tape device and a media error occurs.

3) Writing to a CD-RAM or DVD-RAM drive with media errors. This
is exactly where you would want lazy-writing-after-close due to speed
problems.

4) Writing to a floppy disk with media-errors.

A competitor to ours added lazy-write-after-close to their NT NFS
client and made hay about the speed of the drop-and-drag. This was
using NFS V2/3 and if you ran out of disk space no error could be
returned to the application. We responded by providing the same
feature but the user must turn it on to make it work. (And they are
warned about the possible loss of data).

Here is my 0.02 £ worth:

	Lazy-Writes-After-Close are not a secure method of writing to
any media and should be avoided. BUT the administrator should have the
option, for speed over guaranteed writing considerations, to allow
Lazy-Writes-After-Close. This means that no reservation is required to
determine diskspace requirements, because the client knows it is
taking a chance by using Lazy-Writes-After-Close.

- Carl Beame