[developer] Re: [openzfs/openzfs] 9337 zfs get all is slow due to uncached metadata (#599)

2018-03-25 Thread Brian Behlendorf
And to pull back in to OpenZFS, here's the commit https://github.com/zfsonlinux/zfs/commit/5e021f56d3437d3523904652fe3cc23ea1f4cb70. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[developer] Re: [openzfs/openzfs] 9337 zfs get all is slow due to uncached metadata (#599)

2018-03-25 Thread Richard Elling
In ZoL there is a dbuf_stats kstat that is the appropriate place for these. It will be natural to extend for the ZoL port. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[developer] Re: [openzfs/openzfs] 9337 zfs get all is slow due to uncached metadata (#599)

2018-03-23 Thread Matthew Ahrens
@tcaputi To determine the cache size, you could look at `dbuf_caches[DB_DBUF_METADATA_CACHE].size`. While this is trivial with mdb (assuming you have root access), I agree it would be nice to add a kstat for this. IIRC, it seemed like kind of a pain since the kstats seem to be specific to

[developer] Re: [openzfs/openzfs] 9337 zfs get all is slow due to uncached metadata (#599)

2018-03-23 Thread Tom Caputi
tcaputi approved this pull request. This patch looks good and all the edge cases I could think of are handled appropriately (zfs upgrade, etc). As a minor convenience, I would want a way to determine how much memory my metadata cache is using (in ZoL we would make this a read-only tunable,