Re: Re: AFS handling of deleted open files

On Mon, Jan 18, 2021 at 12:33:49PM -0800, Benjamin Kaduk wrote:
> 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.)

Oh, that makes sense, I didn't think of that approach, thanks.

So you don't depend on AFS to do anything fancy to keep
unlinked-but-in-use files around because you're keeping the old files
around yourself.

--b.

> 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