Re: Re: AFS handling of deleted open files

Hi Bruce,

Off the top of my head, the "vos release" workflows I deal with all involve
adding new data, not removing any. [0]  So, in some cases it is prudent to send
a best-effort notification to potential consumers that they may experience
a pause in access, there's not a real need to specifically schedule the
release to avoid harming client applications.  (In other cases I just do
the release whenever I want, such as when preparing new releases of OpenAFS
itself.)

It would probably be more interesting to hear about other workflows...

-Ben

[0] Even when updating software binaries, the binary or library is
typically installed at a versioned path, with an unversioned symlink that
gets updated to point to the "latest" version.

On Mon, Jan 18, 2021 at 03:20:04PM -0500, J. Bruce Fields wrote:
> 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.
> _______________________________________________
> OpenAFS-info mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-info