It's shared among everyone who has a hold on the dbuf. When there are no more holds, the dbuf may be evicted, and call sa_evict() to get rid of the shared sa handle. Saving the sa_handle_t in the dbufs' user pointer allows e.g. zfs_zget() to find it. Although I guess it does use "immediate evict", so you'd probably only find it if 2 threads are concurrently accessing the same object? I would presume that is possible.
Have you tried adding an assertion (or dtracing) that there is no sharing (i.e. that we never find an existing sa handle attached to the dbuf, from zfs_zget() or sa_handle_get_from_db())? You would probably need a workload that accesses the same object concurrently, perhaps over NFS (so it has to use zfs_zget() rather than having the vnode in hand). That should show you if / how the sharing code is exercised. --matt On Fri, Oct 18, 2013 at 3:10 AM, Andriy Gapon <[email protected]> wrote: > > sa_handle_get_from_db can allocate sa_handle_t in two modes: > SA_HDL_PRIVATE and > SA_HDL_SHARED. > > SA_HDL_PRIVATE case is easy -- we just allocate a new handle object with > fields > set to appropriate values. sa_bonus points to a buffer, but the buffer > has no > knowledge of the SA handle. > > In the case of SA_HDL_SHARED we allocate a new handle and associate it > with the > buffer via dmu_buf_set_user_ie, but only if the buffer does not have a SA > already associated with it. In the latter case, sa_handle_get_from_db > simply > returns the associated handle. So, in this sense the handle gets shared. > > What concerns me is that there is no corresponding "unsharing" mechanism in > sa_handle_destroy. It would destroy the handle regardless of any possible > sharing. > > So I suspect that if any actual sharing would ever occur then there could > be a > trouble. > As far as I could see in the code, no actual sharing ever happens (modulo > bugs). > So in the end the only actual purpose of SA_HDL_SHARED seems to be > debugging > via sa_evict -> panic. > > I would like to ask you if my understanding of that code is correct. > Thank you. > -- > Andriy Gapon > > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
