Douglas E. Engert wrote: > > > Derrick Brashear wrote: >>>>> o The ois_DisableAtime routine was trying to update >>>>> the inode. I skipped that part of the code. Is this >>>>> OK or not? Is there another way to update the flag? >>> 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. >> >>>> Perhaps we should use values just shy of 0xffffffff. >>> Yes that would work. >>> >>> 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. >> > > The first patch in effect does not use inodes at all, all operations > on the cache files are done via vn_ or VOP_* operations using the the > vnode. > > I tried creating a /tmp/afscache where /tmp in in swap. and it works! > The /etd/init.d/afs script needs to create the /tmp/afscache directory. > > So are you leaning to using the AFS_CACHE_VNODE_PATH approach > in all cases? > > One of the trade offs is that I had to use the pn_get_buf, lookuppnvp > to get the vnode, so it could pass the afs_osi_cred. > > With the vfs_vget or tmp_vget approach one has to now how > to build the fid_t from the inode as returned by stat. > > I have been looking at the Open Solaris code for all this... On Linux, if you're using tmpfs as the cache, what's the difference between letting the memcache swap out vs a disk cache in tmpfs?
Which option is preferable? Jason _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
