From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <32a4a954d53d3d8797a70dbb178497e7@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] QTCTL?
Date: Thu,  1 Nov 2007 14:35:35 -0400
From: Sape Mullender <sape@plan9.bell-labs.com>
In-Reply-To: <8ccc8ba40711011119r7d7ef3aasb69e04b28b920f49@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: e497a1ac-ead2-11e9-9d60-3106f5b1d025

> I know, I think I was not clear, sorry.
>=20
> The point is that, referring to the
> Tinval-Rinval-Tinval-...
> sequence, a server could afford to consider its Rinval acknowledged
> if the client happens not to respond (by issuing another Tinval)
> within 5 seconds.
> That would "freeze" clients for at most 5 seconds when a client fails
> to respond,
> but that should not happen often, and it would not make other clients s=
low.
>=20
> Also, regarding
>> the irony is, the higher the latency, the greater the cost of syncroni=
zation.
>=20
> if we consider that this would happen only for rw files, and that rd fi=
les would
> be considered as leased up to the next Rinval mentioning them, the cost=
 would
> not probably be too high. But I won=C2=B4t actually know before
> implementing and trying it.

There's a funny obsession in this discussion with optimal performance
in the least common scenarios.
Let me reiterate:
1. 90% (a symbolic number) of files are not shared
2. Of the 10% remaining, 90% of files are read-shared
3. Of the 1 % remaining, 90% of clients are well-behaved
4. In the 0.1% remaining, only the first request in a series
   of requests issued by a badly behaving client will result in
   making the server wait for the lease timeout (in all subsequent cases,
   the server just won't give that client a lease or an extremely short
   one)
5. That leaves 0.01%of files.  Optimize away, guys.

	Sape