From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1e3bc7798b6eeadd827686536b41ec68@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] QTCTL?
Date: Thu,  1 Nov 2007 12:58:03 -0400
From: Sape Mullender <sape@plan9.bell-labs.com>
In-Reply-To: <CD011460-455B-44B5-9DF3-73BB13EC37D1@lanl.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: e389b7f0-ead2-11e9-9d60-3106f5b1d025

> In the case of read cache (which is probably going to be used more =20
> often than write-cache), the client needs to send two RPC every time =20
> a writer modifies the cached file. What if Rlease doesn't necessary =20
> break the lease, but have an option (negotiated in Tcache) to let the =20
> client know that the file is changed without breaking the lease.
>=20
> Thanks,
> 	Lucho

Another point in this discussion:
1. Most files are not shared
2. Some files are read-shared
3. Very, very few files are read-write shared
(Satya did some research on this at CMU =E2=80=94 quite some time ago)

Having said that, we do want correct semantics all the time,
especially for read-write sharing.
A file server can use heuristics to decide the time out for leases.
For example, it could always grant 10-minute leases to begin with.
Doesn't cost a thing unless the client refuses to return a lease early
(but clients will be rarely asked to do so).
With updates in the recent past, or with the first occurrence of
read-write sharing, lease times can be drastically reduced.

Note that for files not shared or read-shared, call backs do not happen,
so lease calls will occur at the rate of the lease time, which is
once every few minutes.  Big deal.

	Sape