[OpenAFS-devel] Re: Breaking callbacks on unlink

[Derrick Brashear]

On Tue, Feb 28, 2012 at 12:51 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
> If I ever feel sufficiently motivated, then I suppose I can create a spec=
ial
> ".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 p=
ull
> 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" <adeason@sinenomine.net> wrote:
>>
>> > On Mon, 27 Feb 2012 14:13:09 -0500 (EST)
>> > "Matt W. Benjamin" <matt@linuxbox.com> wrote:
>> >
>> > > Ok, thanks for clarifying. =A0With 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
>> > adeason@sinenomine.net
>> >
>> > _______________________________________________
>> > OpenAFS-devel mailing list
>> > OpenAFS-devel@openafs.org
>> > https://lists.openafs.org/mailman/listinfo/openafs-devel
>>
>> --
>> Matt Benjamin
>> The Linux Box
>> 206 South Fifth Ave. Suite 150
>> Ann Arbor, MI =A048104
>>
>> http://linuxbox.com
>>
>> tel. 734-761-4689
>> fax. 734-769-8938
>> cel. 734-216-5309
>> _______________________________________________
>> OpenAFS-devel mailing list
>> OpenAFS-devel@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
> --
> -------------------------------------------------------------------------=
---
> Troy Benjegerdes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'da hozer' =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0hozer@hozed.org
> 7 elements Farm =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 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
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel



--=20
Derrick