Greets, I have read a couple of earlier posts by Jeff and Mark Maybee explaining how Arc reference counting works. These posts did help clarifying this piece of code ( a bit complex, to say the least). I would like to solicit more comments elucidating ARC reference counting.
The usage pattern I see in arc.c does not seem to be following a simple pattern, like the one we see in VFS. The crux of the matter: who are the "users" that own these references? Perhaps I am misreading the code but this is how it looks to me: arc_buf_hdr->b_count keeps track of simultaneous readers of an arc_buf_hdr who called with a non-null callback parameter. The expected scenario is simultaneous access from 2 or more files (which are clones or snapshots). The reason for the ref count and the buffer cloning: to maintain cache integrity when multiple readers access the same arc cache entry, and one of these modifies the entry and ultimately ends up releasing the arc entry from the cache. At such time, one of the "users" needs an anonymous entry that can be dirtied and written out to a different spot, while the other needs an unchanged ARC entry. This was probably expected to be a relatively rare occurrence, and it is not expected that a large number of simultaneous readers would access the same ARC entry. I am a bit puzzled why a new ARC entry could not be cloned in arc_release, but perhaps there is a good reason why pre-allocating this data is better than the JIT alternative. I notice that prefetch functions (dbuf_prefetch and traverse_prefetcher) call arc_read_nolock without a callback parameter, I wonder if this could create a problem if a prefetch function, and a "regular" read simultaneously access the same ARC cache entry. (Cloning in this case would not happen, so one thread could end up releasing the entry from the cache while the other is messing with it). Comments and corrections to my interpretation are cordially solicited. -- This message posted from opensolaris.org
