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
