On Mon, 27 Feb 2012 14:13:09 -0500 (EST) "Matt W. Benjamin" <[email protected]> wrote:
> Ok, thanks for clarifying. With this model, are the intended > semantics of unlink/rm that the "operation succeeds, but the object is > still there and will be seen by the next ordinary > lookup/stat/readdir?" No, the parent dir is modified so the entry doesn't exist in the dir (and you still get a callback break on the dir). The vnode just exists on disk, not referenced by any dir in the volume. So the only way you can keep it "alive" from an application-level point of view is by keeping an fd open, which is what we wanted. > (I should say, I did hear Troy's suggestion of a wholly different sort > of use case involving mutating the backup volume, I'm staying entirely > out of that...) Well, I don't think this is entirely different. You do the same thing, but you have some button you can press that says "gimme back the to-be-deleted vnodes". While I can imagine that existing, I have a hard time justfying the effort to create it. And you can do this anyway without extra development by with just a 'pkill -9 fileserver' and then salvaging with '-orphans attach'. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
