On Tue, Nov 11, 2008 at 6:34 PM, Buhrmaster, Gary <[EMAIL PROTECTED]> wrote: > >> > 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?
As "one big slash" boy I recognize this does not solve the world's problems. > >> > 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". In the open by path model, it does. That model has other issues. > 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. Agreed. The question is how far support goes. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
