[OpenAFS-devel] Re: Breaking callbacks on unlink

[Matt W. Benjamin]

Hi,

I partly fell into the polling trap, and necessarily moved back to, we must=
 not go there.  I don't see completely how we will go there, as the feature=
 is currently explained.

You mentioned that a client won't renew it's registration unless F_deleted =
is accessed, so for some undefined period, temporal insofar as it is bounde=
d by the clients registration, the client may succeed in prolonging access =
to F_deleted, or not.  Case 1, F_deleted expires from the delete queue, and=
 we now send BCB(F_deleted), and the client cannot re-establish a callback,=
 because F_deleted is gone.  Case 2, the client continues to access F_delet=
ed.  This suggests that the client is extending its registration on F_delet=
ed, I think, and possibly we can do this for any client until F_deleted lea=
ves the delete queue, and as someone said, we could also expand the window =
when this occurs.  As Andrew said, if we omit to place an upper bound on li=
fetimes in the deleted queue, this has the effect of delaying storage recla=
im (but we could set an upper bound)?  Case 3, all clients cease operating =
on F_deleted, all registrations expire, and F_deleted leaves the delete que=
ue, and is really-deleted.  This case presents no difficulty?

Matt

----- "Jeffrey Altman" <jaltman@your-file-system.com> wrote:

> On 2/28/2012 11:28 AM, Andrew Deason wrote:
> > On Tue, 28 Feb 2012 07:26:32 -0500
> > Jeffrey Altman <jaltman@your-file-system.com> wrote:
> >=20
> >> It occurred to me last night why the callback is not broken on the
> >> last unlink .  Because it is a wasted message.  Breaking the
> callback
> >> does not guarantee that the object will in fact be deleted on the
> >> client in a timely manner because unlike with XCB there is no
> context
> >> to say that it has in fact been deleted.
> >=20
> > ? It's "deleted on the client" as much as any callback break does;
> all
> > of the cached information for that file would be discarded.
> >=20
> > It's not a waste, since the file has changed; the nlink count has
> gone
> > to 0 and the contents are gone.
>=20
> The callback does not result in the client having this information.=20
> The
> client only obtains this information when the client returns to the
> file
> server to request it.
>=20
> >> When the callback is received or it expires does not trigger a
> polling
> >> to the server.  Therefore there is no guarantee of constant
> behavior
> >> in any case.
> >=20
> > Yes, and as far as I can tell nobody mentioned anything like a
> polling
> > behavior. If you don't do anything with the file for 2 hours but
> keep it
> > open, it could still go away, but it's a lot more likely to work
> than
> > the current situation.
>=20
> Go back and re-read this thread.  Polling was brought up in
> discussion
> yesterday in the exchanges between Troy and Simon.

--=20
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309