sdimitro commented on this pull request.
> + * There should not be anything wrong with having kstats for + * snapshots. Since we are not sure how useful they would be + * though nor how much their memory overhead would matter in + * a filesystem with many snapshots, we skip them for now. + */ + if (zfsvfs->z_issnap) + return; + + /* + * We are limited by KSTAT_STRLEN for the kstat's name here + * which is a lot less that the string length of a dataset's + * path. Thus, we distinguish handles by their objset IDs + * prepended by the pool's load_guid. Note that both numbers + * are formatted in hex. See breakdown in comment below. + * + * We use the pool's load_guid because it is guaranteed to Thank you for looking at the review @Ramzec. Yes. The pool-guid can change without re-import (e.g. we do a `zpool reguid <pool>`). Thus, if we were using the pool-guild as part of the kstat name, if the pool's guid changed, all these kstats would be left off with the old guid. Those kstats are created when a dataset is mounted and destroyed when the dataset is unmounted. So it makes more sense to use the pool's load_guid as this would keep things consistent. Given the above, recreating all these structures every time the guid changes would be very complicated and unnecessary. Does this make sense? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/664#discussion_r201429988 ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Ta167a88bbab5c009-M9b1057e3bdb1b52c87b97469 Delivery options: https://openzfs.topicbox.com/groups
