[OpenAFS] Re: AFS handling of deleted open files
J. Bruce Fields
Mon, 18 Jan 2021 15:20:04 -0500
The one other offlist response I got was that behavior can depend on the
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?
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?
> 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.