Re: [developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

[Igor Kozhukhov]

about libfakekernel dependencies.

to me - it is not good code design.
we have dependency to libfakekernel everywere we need just taskq.
why not use shared sources for taskq in places where we need it?
or i have missed something?

we no need duplicate code with taskq - we can use the same sources if possible, 
but we can build sources with libs where we really need it.

best regards,
-Igor

> @prakashsurya  Thanks for splitting out the 
> change regarding the file system part, that makes things clearer.
> 
> Honestly though, no, I still feel like this is the wrong approach in terms of 
> leveraging the fake kernel library. But the fake kernel and libzpool are 
> similar to me in so far as their goal is to emulate the kernel. This is a 
> user land program which really shouldn't need any of these and while 
> portability isn't my first concern, starts making things pretty odd for those 
> porting this.
> 
> Honestly, if we take a step back at the original version, the only thing I 
> was unhappy with was saying that we had a general purpose taskq user library 
> because you weren't giving control to applications about how to handle memory 
> allocation by using the umem fatal stuff. If we had scoped that to be private 
> just for zfs or private in so far as just the fake kernel and the zfs user 
> land commands using it, it probably would be a better approach. I'm sorry 
> that I haven't been as active in the other parts. When I saw the fake kernel 
> bits going on, I hadn't realized it was going on for use here.
> 
> I'm not sure if it makes sense. I see that there's now been Andy's changes 
> and breaking it up further. But honestly, this still feels like a lot of 
> complexity that we're introducing into the headers and builds and 
> complications. I'll take a look at this current version and try to evaluate 
> it. I'll try and hold my breath about the fake kernel bits.
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> , or mute 
> the thread 
> .
> 
> openzfs-developer | Archives 
> 
>  | Powered by Topicbox 

--
openzfs-developer
Archives: 
https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-M058018ee57b462f2f21d712a
Powered by Topicbox: https://topicbox.com

Re: [developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

[Prakash Surya]

On Fri, Feb 9, 2018 at 7:33 AM, Schweiss, Chip  wrote:

> I've been following this review for a while.   Sorry, if this is not the
> correct place for this comment.
>
> Personally, I've been doing similar outside zpool import by doing a 'zpool
> import -N' then parallel executing 'zfs mount {folder}' followed by
> parallel executing 'zfs share {folder}'.  My zpool import times were over
> an hour and reduced to less than 2 minutes with parallel mounting and
> sharing.
>
> I'm sure this proposed parallel mount will outperform the multiple
> executions of 'zfs mount', but doesn't help with the subsequent sharing of
> folders. Currently, zpool import has '-N' to not mount folders.  However,
> with the addition of this parallel mount, it would be best if zpool import
> got a new feature to not share any folders upon importing.
>

​Could you elaborate a little more on why you think that feature should be
a prerequisite of landing this change?​


> Does this patch address unmount in a parallel fashion?
>
​
No. This only changes mount.
​

>
> Cheers!
> -Chip
>
> On Thu, Feb 8, 2018 at 2:02 PM, Prakash Surya 
> wrote:
>
>> @prakashsurya  pushed 1 commit.
>>
>>- c8a3e65  Fix
>>cstyle; use tab for indentation, not spaces
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> View it on GitHub
>> 
>> or mute the thread
>> 
>> .
>>
>>
> *openzfs-developer* | Archives
> 
> | Powered by Topicbox 

--
openzfs-developer
Archives: 
https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-M55c3fca96626fae8044173d8
Powered by Topicbox: https://topicbox.com

Re: [developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

[Schweiss, Chip]

I've been following this review for a while.   Sorry, if this is not the
correct place for this comment.

Personally, I've been doing similar outside zpool import by doing a 'zpool
import -N' then parallel executing 'zfs mount {folder}' followed by
parallel executing 'zfs share {folder}'.  My zpool import times were over
an hour and reduced to less than 2 minutes with parallel mounting and
sharing.

I'm sure this proposed parallel mount will outperform the multiple
executions of 'zfs mount', but doesn't help with the subsequent sharing of
folders. Currently, zpool import has '-N' to not mount folders.  However,
with the addition of this parallel mount, it would be best if zpool import
got a new feature to not share any folders upon importing.

Does this patch address unmount in a parallel fashion?

Cheers!
-Chip

On Thu, Feb 8, 2018 at 2:02 PM, Prakash Surya 
wrote:

> @prakashsurya  pushed 1 commit.
>
>- c8a3e65  Fix
>cstyle; use tab for indentation, not spaces
>
> —
> You are receiving this because you are subscribed to this thread.
> View it on GitHub
> 
> or mute the thread
> 
> .
> *openzfs-developer* | Archives
> 
> | Powered by Topicbox 
>
>

--
openzfs-developer
Archives: 
https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-M965c9648a227b358a076917e
Powered by Topicbox: https://topicbox.com