I ran some more performance tests on this change to ensure it didn't regress during the upstreaming process. I used a VMware VM with 8 vCPUs, 16GB of RAM, a zpool with 8 10k-SAS disks, and populated the pool with the same filesystem hierarchy described in the PR description above (2603 filesystems in total).
The test involved running `zpool import` followed by `zpool export`, and this was repeated 10 times. The latency of each `zpool import` invocation was measured, and the results are below: Latency (s) | Avg. | SD σ | Run 0 | Run 1 | Run 2 | Run 3 | Run 4 | Run 5 | Run 6 | Run 7 | Run 8 | Run 9 | -------------|--------|-------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------| **Before** | 93.559 | 0.821 | 95.329 | 92.564 | 92.758 | 93.363 | 93.192 | 93.504 | 93.580 | 93.720 | 94.492 | 93.088 | **After** | 13.763 | 0.220 | 13.962 | 13.639 | 13.962 | 13.886 | 13.942 | 13.865 | 13.643 | 13.326 | 13.517 | 13.889 | As can be seen in this table, the average latency for `zpool import` of this pool was 93.559 seconds on master (the "Before" row), and only 13.889 seconds with this proposed change applied (the "After" row). That's an 85% decrease in latency, which is roughly the same improvement described in the PR description. -- 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/596#issuecomment-375412621 ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M292ab412ba1c32aba4853ec3 Delivery options: https://openzfs.topicbox.com/groups
