From: Noveck, Dave (dave.noveck@netapp.com)
Date: 08/12/99-10:39:57 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA05D10BC8@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: Caching proposal, take 2 (LONG)
Date: Thu, 12 Aug 1999 08:39:57 -0700
Stuff related to the flush-on-close limit deleted. This has
been resolved (I hope) in another thread.
>
> > > Then there is the situation when the server revokes the write
> > > delegation during partition, and another client write the
> file, and
> > > then tserver reboots before the revoked client determines
> that it lost
> > > its delegation. This can be detected by looking at the change
> > > attribute. Note that I raised this issue in my review fo the first
> > > version of the his document. If it has been addressed
> elsewhere in the
> > > document, my mistake.
>
> > As I see it, this is exactly the problem that is addressed in the
> > last paragraph of section 7.5. By making delegations a species of
> > the lock genus, I get all of the benefits of the work getting the
> > locking model to work. In the context of that paragraph, a
> > delegation is a lock and the write you are woried about is
> > a conflicting IO. Maybe there needs to be a reference back to
> > this section?
> >
> > Or am I missing something?
>
> I think I was missing the discussion in 7.5. I don't
> understand how a lock
> server (in absence of a call back protocol) can detect
> network partition:
>
> "When there is a network partition and the lease expires, the server
> must record on stable storage the client information relating to
> those leases. "
I didn't interpret that as requiring the server to detect network
partition. My paraphrase would be something like:
When the lease expires (as would happen in the event of a
network partition), yada yada yada
>
> The caching proposal might be able to detect partition via
> the call back
> protocol, but since the locking protocol is supposed to work through
> firewalls, it can't count on callbacks. I'll complain about this in a
> separate message.
>
> So your proposal could refer to 7.5, noting that the callback
> protocol is used
> to detect partition.
I think what needs to be done is to clarify 7.5 and then have it
reflect all of the situations in which locks are revoked
(lease expiration, revocation within the lease period without
expiration, revocation of a delegation due to complete or one-way
network partition or any other reason). Assuming I understand
this correctly, the record on stable storage is just as
necessary, for example, for the kinds of revocations discussed
in section 7.6 as it is for lease expiration. The same follows
for revocations of delegations. Then I could refer to section
7.5 or wherever this stuff would go.
>
> > > > A.5. Open delegation
> ...
> > How about:
> >
> > o Availability of disk space on the server to guarantee that
> > when modified files are written to the server, any possible
> > lack of disk space can be detected and reported to the user
> > as part of the close corresponding to the open under which
> > the writes were done.
>
> If there is disk space, then the server delegates the open.
> Then why wouldn't
> there be disk space?
>
> Also the above seems to be sayng that the open will be
> delegated if there
> is sufficient disk space to report a lack of disk space.
A light dawns. This item doesn't belong here. It should
just be deleted. The space availability consideration
governs how the nfs4_space_limit is set and not the fact
of delegation.
>
> > > > A.6.1. Revocation recovery for write open delegation
> ...
> > > > of such a technique may be limited to files under a certain
> > > > size or may only be used when sufficient disk space is
> > > > guaranteed available within the target file system.
> > >
> > > And if sufficient space (disk or otherwise) on the
> client's cache is
> > > guaranteed to be available.
> >
> > You can do this a block at time so it shouldn't be too hard.
>
> I don't understand. I though the issue in A.6.1 is what
> happens when a write
> delegation is revoked, and now the client is trying to write
> its modified
> version to a new file. Such a technique can't work if the
> client didn't have
> enough room to cache the whole file before it dirtied it.
OK. I was just confused. I'll fix it.
>
> > > > struct wcc4_info {
> > > > fattr4_change before;
> > > > fattr4_change after;
> > > > };
> > >
> > > In this version of the document, the wcc4_info struct is
> now part of
> > > the response to several operations. The problems with
> this approach
> > > are:
> > >
> > > - clients that don't want wcc are forced to process it,
> > > even if to
> > > ignore it.
> >
> > True but your proposal below would add to the data that must be
> > processed by clients who do want wcc. I think clients who want
> > it have to process (send or receive) 16 extra bytes they wouldn't
> > have had to process. This is to save clients who don't want wcc
> > 16 bytes. This is exclusive of the discriminated union issue
> > which I'll treat separately.
>
> An issue is not so much extra bytes on the wire, but coding
> complexity.
>
> > I put back wcc_info after asking whether people found it useful.
>
> At issue isn't whether wcc is useful, it is whether the V3
> implementation of
> it is appropriate.
>
> > > - servers that can't or won't support wcc are forced to returns
> > > values for wcc4_info, which while accurate, aren't
> > > atomic with respect to the operation, and so the server
> > > is effectively lying.
>
> > There are a few ways we can deal with this.
> ...
> > I prefer the boolean atomicity field unless we are so concerned
> > about four extra bytes, in which case I would go for the
> > special value approach (Gee, that almost sounds like you get
> > fries with that wcc_info :-)
>
> I still prefer a separate operation for returning the
> information. However, in
> the interest of moving forward with your caching proposal, I
> suggest that we
> add wcc_info with the boolean atomicity (one boolean per wcc4_info).
> Meanwhile, time permitting, I'll prototype wcc_start/wcc_end
> and if I'm right,
> show why it's better.
OK.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:29 AM Z CST