[OpenAFS] Re: AFS handling of deleted open files

[J. Bruce Fields]

The one other offlist response I got was that behavior can depend on the
client.

I guess what I'd really be most interested in is users' perspectives: is
a "vos release" something you do you routinely with no special
precautions?  Or do you have to, say, schedule them for times when
client applications aren't running to prevent crashes?

--b.

On Mon, Jan 11, 2021 at 10:30:11AM -0500, J. Bruce Fields wrote:
> Is there a better forum for this kind of question?  I'm most interested
> in the case where an in-use file is absent in a new version.
> 
> Summarizing a few points from a side conversation from Matt Benjamin.
> (But any misunderstandings are mine, as my only AFS experience is purely
> as a user 20+ years ago!):
> 
> AFS, like NFS, has "silly rename".  The open happens on a read-only
> replica, and the unlink on the read-write volume, so it's not obvious to
> me when the silly rename would happen:
> 
> If it happens at the time of the unlink, I think that requires some sort
> of protocol ensuring we know about the opens at unlink time.
> 
> Maybe it could instead happen at "vos release" time, silly-renaming on
> the read-only replicas as necessary.  That would mean different replicas
> would no longer be identical--in-use but unlinked files could be present
> on some replicas but not others.
> 
> Or maybe the client (cache manager) could handle this somehow.  That
> would require it to cache whole files.
> 
> Is AFS's handling of this case documented somewhere?
> 
> --b.
> 
> On Wed, Jan 06, 2021 at 09:20:39AM -0500, bfields wrote:
> > When a read-only replica is updated, and files still in use by processes
> > are modified or absent from the new version, what behavior do those
> > processes see?
> > 
> > What about in normal operation, if a file is in use while it's deleted
> > by the same client or a different client?
> > 
> > I'm working on the NFS behavior and just looking for a comparison.
> > Thanks in advance for any pointers.  This is probably all pretty
> > elementary, but my searches weren't turning up answers....
> > 
> > --b.