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 bounded 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_deleted. This suggests that the client is extending its registration on F_deleted, I think, and possibly we can do this for any client until F_deleted leaves 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 lifetimes in the deleted queue, this has the effect of delaying storage reclaim (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 queue, and is really-deleted. This case presents no difficulty? Matt ----- "Jeffrey Altman" <[email protected]> wrote: > On 2/28/2012 11:28 AM, Andrew Deason wrote: > > On Tue, 28 Feb 2012 07:26:32 -0500 > > Jeffrey Altman <[email protected]> wrote: > > > >> 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. > > > > ? It's "deleted on the client" as much as any callback break does; > all > > of the cached information for that file would be discarded. > > > > It's not a waste, since the file has changed; the nlink count has > gone > > to 0 and the contents are gone. > > The callback does not result in the client having this information. > The > client only obtains this information when the client returns to the > file > server to request it. > > >> 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. > > > > 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. > > Go back and re-read this thread. Polling was brought up in > discussion > yesterday in the exchanges between Troy and Simon. -- 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
