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 OpenAFS-info@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info