> @@ -2058,6 +2058,24 @@ zfs_ioc_objset_stats_impl(zfs_cmd_t *zc, objset_t *os)
> error = zvol_get_stats(os, nv);
> if (error == EIO)
> return (error);
> + /*
> + * If the zvol's parent dataset was being destroyed
> + * when we called zvol_get_stats, then it's possible
> + * that the ZAP still existed but its blocks had
> + * been already been freed when we tried to read it.
> + * It would then appear that the ZAP had no entries.
> + */
> + if (error == ENOENT)
> + return (error);
> + /*
> + * a zvol's znode gets created before its zap gets
> + * created. So there is a short window of time in which
> + * zvol_get_stats() can return EEXIST. Return an
> + * error in that case
Perhaps my analysis is wrong. My memory is certainly fuzzy, because I made
this change to SpectraBSD a long time ago. But I certainly did get occasional
panics while running zfs tests that create zvols while a parallel process did
"zfs list" and "zpool status" and "zfs get all <fsname>" and stuff like that.
Handling EEXIST and ENOENT stopped the panics.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/60/files#r50330053
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
