On Tue, Feb 28, 2012 at 12:51 AM, Troy Benjegerdes <[email protected]> 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?
the code to do it is in gerrit; you can determine it empirically. > > > On Mon, Feb 27, 2012 at 02:50:04PM -0500, Matt W. Benjamin wrote: >> 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 > > -- > ---------------------------------------------------------------------------- > Troy Benjegerdes 'da hozer' [email protected] > 7 elements Farm TerraCarbo biofuels > > If you're going through hell, keep going. ~ Winston Churchill > > The challenge in changing the world is not in having great ideas, it's in > having stupid simple ideas, as those are the ones that cause change. > > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel -- Derrick _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
