[OpenAFS-devel] Re: Breaking callbacks on unlink

[Matt W. Benjamin]

Hi,

inline

----- "Jeffrey Altman" <jaltman@your-file-system.com> wrote:

> On 1/26/2012 10:09 AM, chas williams - CONTRACTOR wrote:
> 
> There are two completely different issues here:
> 
> 1. What is the semantic behavior of the existing RPC?
> 
>    It is that the callback break is not issued when the link count
>    hits 0.  This is the behavior of the RXAFS_Removefile RPC and
>    it cannot change.

Actually, I think I would not have said that BCB expresses a semantic
of the _RPC_, but rather of an _event_ (the object is gone).

Cache consistency is a property which, if it holds, involves all the clients 
interacting on the object. I haven't given full consideration of what I would
like to see happen in this scenario in future, but my intuition is that all
cooperating clients need to either see what they would have seen in legacy AFS,
or else something that each has agreed on.

All I'm immediately pointing out here is, just using a new RPC to remove files,
would not make it prima facia to change the obligation to notify other clients
of the event.

> 
> 2. What are the semantics that would be desired by the community?
> 
>    Here there are a couple of possibilities:
> 
>    a. Consistent behavior such that when the link count hits 0
>       file descriptors on UNIX can safely continue to use it.
> 
>    b. Consistent behavior such that when the link count hits 0
>       the callback is broken and cache managers are required to
>       invalidate any open file descriptors or handles.
> 
>    c. Client requested behavior when a client issued an extended
>       FetchStatus request.
> 
>    Any of these can be adopted.  The way they get implemented is
>    by supporting new RPCs.
> 
> OpenAFS cannot stop a site from applying a local patch to do whatever
> they want.  However, OpenAFS will not accept patches that
> intentionally
> modify existing semantics UNLESS the existing semantics pose a
> security
> issue.  Examples where we have done this in the past include access
> control enforcement and setuid functionality.
> 
> Jeffrey Altman

-- 

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