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> 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
