Hi, Thanks, I think that clarifies.
Matt ----- "Andrew Deason" <[email protected]> wrote: > 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 -- 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
