[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
Closed #596 via a3f0e2b569d32793de88fe09fdd964cf818d3109. -- 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#event-1628400140 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M71a9b53116e1149e5e5093ae Delivery options: https://openzfs.topicbox.com/groups
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
what is status of this PR? -- 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-384450444 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M220f42e6095fb91a863849ea Delivery options: https://openzfs.topicbox.com/groups
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
Apart from the typo @andy-js mentioned, should I go ahead and RTI this? @andy-js do you have any feedback? were you able to give this a look? @gwr @rmustacc do either of you want to review this iteration? -- 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-379396128 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M3b5678730cff8839606e81b4 Delivery options: https://openzfs.topicbox.com/groups
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
I have been doing my own testing with parallel mounts and have observed that enabling SMB shares is a significant bottleneck. From looking at the code it's not clear to me that this will help. -- 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-376534304 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M27036db2bc5530b9a2e78fae Delivery options: https://openzfs.topicbox.com/groups
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
andy-js commented on this pull request.
> @@ -73,6 +74,13 @@ struct libzfs_handle {
int libzfs_storeerr; /* stuff error messages into buffer */
void *libzfs_sharehdl; /* libshare handle */
boolean_t libzfs_mnttab_enable;
+ /*
+* We need a lock to handle the case where parallel mount threads
+* are populating the mnttab cache simultaneously. The lock only
+* protects the integrity of of the avl tree, and does not protect
"of of the avl tree"
--
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#pullrequestreview-107029958
--
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-Mc26bb697c4b1168a22dc654c
Delivery options: https://openzfs.topicbox.com/groups
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
@pbhenson I agree that it'd be great to also improve the NFS sharing part of the process; unfortunately though, I don't know of any existing plans to do that work. -- 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-375481600 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M075fea496a3f83b734aaa7e5 Delivery options: https://openzfs.topicbox.com/groups
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
This is great stuff, thanks. We've always left mountpoint set to legacy and used our own custom mounting script to do it in parallel because of the horrid performance for a large number of filesystems. Any chance you might look at the NFS sharing piece next :)? That also takes forever and a day, so we have sharenfs set to off and again have a custom script to do it. -- 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-375438409 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M7a503486b32a9bd14b2c89bf Delivery options: https://openzfs.topicbox.com/groups
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
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
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v3) (#596)
@andy-js @gwr @rmustacc Here's another iteration of this change. What I'm proposing in this version, is introducing a couple new files: `libzfs_taskq.h` and `libzfs_taskq.c`. These files introduce a new taskq implementation that is internal to the `libzfs` library. Thus, with this change, we end up with a taskq implementation in `libfakekernel` which already exists and is used by `libzpool` (and others), and this new taskq implementation in `libzfs` (that's only used by `libzfs`). I didn't make any other changes compared to the prior iterations. Please let me know what y'all think. I've successfully run this through `zloop` and `zfstest` using our internal Delphix automation. -- 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-375199748 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T593c4e9268e77564-M244ae3d286ddce7a417db7be Delivery options: https://openzfs.topicbox.com/groups
