[OpenAFS] Solaris 10u6: ZFS cache?

[Derrick Brashear]

On Tue, Nov 11, 2008 at 6:34 PM, Buhrmaster, Gary <gtb@slac.stanford.edu> 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.