Any pointer to the r151014 tree ?

Giving you a patch should be something easy :)

Ben

> On 30 Nov 2016, at 14:40, Schweiss, Chip <c...@innovates.com> wrote:
> 
> Sounds like you're no better prepared to pull this in to OmniOS than I am.   
> I would need a patch against the latest r151014 to test this out.   
> 
> This along with a lot of other features that have been hanging in review 
> state for a long time is where OpenZFS really needs a testing branch.   Often 
> the best expert on the feature is the developer who wrote it and the code 
> really needs some real world testing to make sure it is sound.
> 
> -Chip
> 
> 
> On Wed, Nov 30, 2016 at 6:57 AM, Ben RUBSON <ben.rub...@gmail.com 
> <mailto:ben.rub...@gmail.com>> wrote:
> Hi Chip,
> 
> Yes sounds like this PR should help you improving performance.
> You would also need PR #222 which assigns correct L2CACHE flag to prefetched 
> buffers :
> https://github.com/openzfs/openzfs/pull/222 
> <https://github.com/openzfs/openzfs/pull/222>
> 
> Regarding the OmniOS build, unfortunately, I never used OmniOS, so I'm not 
> really comfortable with it :)
> I use ZFS with FreeBSD.
> However, what do you mean by making a build ? You need a patch file ? Against 
> which tree ?
> 
> Thank you !
> 
> Ben
> 
>> On 30 Nov 2016, at 13:11, Schweiss, Chip <c...@innovates.com 
>> <mailto:c...@innovates.com>> wrote:
>> 
>> Ben,
>> 
>> Would you be able make a build that I could test this on OmniOS r151014?   
>> I'd love to test this out.
>> 
>> This seems to be exactly the tuning knob I need in my environment.   All my 
>> pools are 0.4 - 1 PB in size with billions of files. Metadata performance is 
>> always an issue for us even with secondarycache=metadata.  It never seems to 
>> get enough metadata into L2ARC.
>> 
>> -Chip
>> 
>> On Tue, Nov 29, 2016 at 6:52 PM, Matthew Ahrens <notificati...@github.com 
>> <mailto:notificati...@github.com>> wrote:
>> @ahrens requested changes on this pull request.
>> 
>> Overall, I am not comfortable making this semantic change without more 
>> extensive real-world testing. I would suggest that you get someone who uses 
>> L2ARC in production on general-purpose workloads (or a wide variety of 
>> workloads) to at least review this code, and better yet to test it. 
>> Unfortunately I (and Delphix) do not use L2ARC so we aren't in a good 
>> position to test this.
>> 
>> In usr/src/uts/common/fs/zfs/arc.c 
>> <https://github.com/openzfs/openzfs/pull/189#pullrequestreview-10672665>:
>> 
>> > @@ -2931,9 +2943,34 @@ arc_evict_hdr(arc_buf_hdr_t *hdr, kmutex_t 
>> > *hash_lock)
>>      return (bytes_evicted);
>>  }
>>  
>> +/*
>> + * Based on l2arc_spa_list, returns true if the
>> + * given spa has an alive (!dead) L2 device,
>> + * false otherwise.
>> + */
>> +static boolean_t
>> +l2arc_alive(uint64_t spa)
>> Could you do this by walking the existing l2arc_dev_list? This mechanism 
>> seems quite complicated.
>> 
>> That said, I'd be concerned about the performance of this either way, it's 
>> in a pretty hot path.
>> 
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub 
>> <https://github.com/openzfs/openzfs/pull/189#pullrequestreview-10672665>, or 
>> mute the thread 
>> <https://github.com/notifications/unsubscribe-auth/AOi0KxUyEPcJCUF72uKn7lwR54VY2gUoks5rDMjdgaJpZM4J2shF>.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> openzfs-developer | Archives 
> <https://www.listbox.com/member/archive/274414/=now>  
> <https://www.listbox.com/member/archive/rss/274414/28096361-a0698fd1> | 
> Modify <https://www.listbox.com/member/?&;> Your Subscription        
> <http://www.listbox.com/>



-------------------------------------------
openzfs-developer
Archives: https://www.listbox.com/member/archive/274414/=now
RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c
Powered by Listbox: http://www.listbox.com

Reply via email to