Callbacks in current AFS have a lifetime on the order of minutes. They are not renewed by the client until after they expire and then only on next access to the file.
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. 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. The addition of XCB changes the landscape because clients can request an extended lifetime. However, XCB is a new RPC that does not exist with current deployments. Sent from my iPad On Feb 28, 2012, at 6:43 AM, "Matt W. Benjamin" <[email protected]> wrote: > Hi, > > I tend to share your feelings about .trash and .backup. I would also agree, > potentially, that a snapshot AFS would solve in particular this formulation of > file recovery better than another magic clone. > > However, I'm not sure I agree that Andrew hasn't made a fairly good case that > the "object could persist as long as a registration on it exists" is > consistent > with current semantics of AFS3. The containing directory is permanently > changed, > all clients share a consistent view, which corresponds to the unlinked state. > The side effect--the extra BCB on the file being unlinked--might be just that, > an implementation side effect. The registrations on the file belong to both > the > client(s) and fileserver. If the fileserver chooses to keep the registration > alive, > how exactly does AFS3 forbid it doing so? Correspondingly, as was indeed > noted at > the start of this discussion, Unix clients, in particular, actually would > expect > a behavior closer to the one Andrew and Troy are proposing (files are > reclaimed > on last unlink) than the "files are immutably gone on first unlink" > semantics, and > on other platforms, the impossibility of producing the case perhaps makes the > question moot? > > I apologize in advance if I'm still missing something obvious, or just > wrong... > > Regards, > > Matt > > ----- "Jeffrey Altman" <[email protected]> wrote: > >> Troy: >> >> With all due respect, what you are describing is an utter hack. >> What >> you are looking for is called "snapshots" and the fact is that AFS as >> it >> is currently designed cannot support an arbitrary number of them. >> But >> if any protocol design efforts are going to be made, they should be >> made >> in that direction. >> >> A ".trash" volume cannot be added to the AFS protocol because >> ".trash" >> may already be in use in volume names. In any case, creating a new >> volume would change the File ID required to access the object and >> that >> would defeat the entire goal of maintaining the file so that active >> users could continue to do so. >> >> Callbacks are not kept alive on deleted objects. They were deleted, >> their status can no longer change. >> >> As for pulling the data into the cache, whose to say that there even >> is >> a cache (cache bypass) or that the cache is even large enough to hold >> the file? What about a file that is open for append only? Or >> accessed >> over a very slow and expensive link? >> >> In the AFS protocol, the file server does not maintain open file >> handles. It is not possible for the file server to know of a file is >> actively in use. The existing AFS unlink RPC has the semantics that >> it >> has. If new semantics are to be implemented, a new unlink RPC must >> be >> created to support them. That is not only OpenAFS policy but a >> requirement of the need for backward compatibility between clients >> and >> servers. >> >> "vos backup" creates a snapshot of the volume at the time the command >> is >> executed. To put objects into the snapshot that do not exist at the >> time the snapshot is created makes taking the snapshot (a) a >> non-atomic >> operation; and (b) utterly unpredictable as to the resulting data >> contents. >> >> If you want files to be in the .backup, you could conceivably take a >> new >> .backup on every unlink operation. That would provide the human user >> the ability to undelete but would do nothing to address the problem >> of >> unpredictability of when a file will become unavailable to a cache >> manager. Of course, the correct long term answer to that problem is >> treating every change to a volume as a snapshot just as ZFS and ReFS >> do >> and then providing a cache manager that has to satisfy an open file >> handle request the ability to read from the snapshot prior to the >> deletion. Of course, none of the protocol support to do this has >> been >> designed yet. >> >> Jeffrey Altman >> >> >> On 2/28/2012 12:51 AM, Troy Benjegerdes wrote: >>> If I ever feel sufficiently motivated, then I suppose I can create a >> special >>> ".trash" volume, which basically holds all the orphaned vnodes until >> 'vos >>> backup' is run, at which time they can be moved into the backup >> volume. >>> >>> It seems like no new RPCs are needed at all, just keep the callback >> alive, and >>> maybe some hooks for a client process disconnected operation manager >> to pull >>> all files for open FD's into cache. >>> >>> (I'm also thinking a short doc page summarizing our discussion here >> would be >>> usefull) >>> >>> Now.. to throw another wrench in the works... does this make >> read/write >>> replication more or less complicated? > > -- > 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
