> > What is this code trying to do? Is it trying to say don't > > update the atime of the cache file as this improves performance? > > That's the goal. The atime on cache inodes is meaningless. They aren't > real files.
And while automatic atimeness suspression is desirable, if one creates a separate zfs file system for the afs cache (which I would recommend so one could provide a reservation for the cache), one can (and should) set the zfs atime value to off. Perhaps this can be finessed by an afs on zfs set of notes for this point of the development? > > It also looks like ZFS is storing the object ID as the > > inode which can be obtained from a stat() with > -D_FILE_OFFSET_BITS=64 > > Can we leverage that? Actually, if we do, we have the issue that we > can no longer use tmpfs as cache, which I assume with your first patch > we can. I would have concern about taking advantage of a zfs internal artifact which is not marked as a stable interface (and I have not found, but that does not mean it does not exist, a document stating the object id/inode relationship is stable.) I think supporting tmpfs would be desirable if it could come "for free". I have had a couple of cases where using tmpfs as the afs cache would have been nice, but it certainly is less important than supporting zfs. Gary _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info