> On Mar 8, 2019, at 11:36 AM, Ciprian Dorin Craciun
> <ciprian.crac...@gmail.com> wrote:
>
> On Fri, Mar 8, 2019 at 6:19 PM Ciprian Dorin Craciun
> <ciprian.crac...@gmail.com> wrote:
>> (B) Using `-files` and `-chunksize` so that their product is larger
>> than `-blocks` means that the cache can hold up to as many `-files`
>> actual AFS files, but their total size can't be larger than `-blocks`?
>> (I.e. if one has a cell with lots of small files, it is OK to
>> configure a largish `-chunksize` and `-files` because they will be
>> cached up to `-blocks`.)
>
>
> I've found the http://docs.openafs.org/Reference/5/afs_cache.html
> documentation that states:
> ~~~~
> Vn files expand and contract to accommodate the size of the AFS
> directory listing or file they temporarily house. As mentioned, by
> default each Vn file holds up to 64 KB (65,536 bytes) of a cached AFS
> element. AFS elements larger than 64 KB are divided among multiple Vn
> files. If an element is smaller than 64 KB, the Vn file expands only
> to the required size. A Vn file accommodates only a single element, so
> if there many small cached elements, it is possible to exhaust the
> available Vn files without reaching the maximum cache size.
> ~~~~
>
> This would imply that:
>
> * there is no 1-to-1 relation between "chunks" and "Vn files", one
> chunk could be stored in multiple "Vn files"; (however one "Vn file"
> never stores multiple chunks in case the chunk size is bellow 64K?)
No, the doc is referring to a default chunksize of 64k.
There is indeed a 1-to-1 relation between chunks and Vn files.
A Vn file may be up to a maximum of chunksize.
One exception is for AFS directories - an AFS directory object is always
stored in a single Vn file, even if the directory object size exceeds the
chunksize.
>
> * by explicitly setting `-files` one can set a limit to the maximum
> number of actual AFS files to cache; (i.e. if all files are smaller
> than 64K and the `-blocks` is larger than `-files * 64K`, then no more
> than `-files` AFS files would be stored;)
Correct.
--
Mark Vitale
mvit...@sinenomine.net
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
