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> 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 > > 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> > 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/28015100-2e068ed4> | > 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
