Various work on OpenZFS and ZFS/FreeBSD.
Wed, Aug 29
- ARC don't rised, memory pressure does not arise, page daemon not activated.
The ARC is not growing after 8, but the ARC hit rate is too low. Why is it not growing? Is it because the free_memory < (arc_c >> arc_no_grow_shift) condition is true, or is there some other reason?
Tue, Aug 28
Thu, Aug 23
To be clear, I'm just stating that r332365 changed zfs_arc_free_target to be equal vm_cnt.v_free_target. It looks to me that this is equivalent to the change you made to arc_available_memory(EXCLUDE_ZONE_CACHE), where v_free_target is referenced directly.
Wed, Aug 22
Sorry that this review has stalled lately. I would like to compare this patch to what's in -CURRENT, which has evolved a fair bit since the patch was updated. Once that picture is more clear, we can focus on stable/11.
Aug 7 2018
I can confirm that the patch solves the issues as described in the "lightly loaded system eats swap space" thread on freebsd-stable mailing list.
On one of my desktop systems the issue is particularly noticeable as the disk subsystem is rather slow, the system became unusable after a
weekend sitting idle. I have not experienced the issues anymore after applying the patch
Jul 9 2018
Jul 7 2018
What else is preventing this from getting merged?
Jun 30 2018
Jun 18 2018
I have come to realise that there is another issue related to this, the default arc_max being wired ram that is not counted in max_wired means a default setup is allowed to wire more than the physical ram installed.
See my comment here for more explanation.
I have applied this patch to stable/11 r334820 and have been running without issue for 10 days.
Jun 16 2018
Jun 14 2018
Checked all 'Done' boxes, hope this is the way to use Phabricator ¯\_(ツ)_/¯
Apply suggestions from review round 0.
Jun 12 2018
Thanks for the screenshot comparing the two man page renderings. I'm good with both ways.
Addressed all complaints marked 'Done' in my private tree, will post a revision once @bcr responds to how I should handle the newline style vs. whitespace issue.
Jun 11 2018
Man page nit.
Adding range support for holds and bookmarks has been on my todo list for a while now.
Jun 10 2018
Jun 8 2018
Alexander pointed out that what I'd undone a change (range_tree_create()) because I'd ported from our 11-base system. Fixed that, and scrubbed a system a few times.
May 26 2018
I don't think it is a very good idea to merge two pretty much independent ZoL commits into one FreeBSD commit. It could have sense if the first one would be significantly broken and second fixed the issue, but priority upgrade implemented in second commit is only a performance optimization, mostly unrelated to scrub even, in which case having it separate would make commit history cleaner for later comparison.
A late sequential-scan-related patch was mentioned when I created the PR for OpenZFS, it's at https://github.com/zfsonlinux/zfs/commit/a8b2e30685c9214c
May 25 2018
Just a quick question, is this the same change that was recently presented at OpenZFS summit (http://open-zfs.org/w/images/a/a0/Saso_-_resilver_update.pdf)?
Or an alternative to it?
May 24 2018
May 22 2018
Unified for -stable and current now
It is only solution to live-lock problem I encounter on my server when there are massive-parallel fast download.
May 15 2018
May 11 2018
Update to latest -STABLE changes
Apr 27 2018
Mar 14 2018
Mar 12 2018
Jan 22 2018
@allanjude / @mahrens , it's worth pointing out that we eventually abandoned this change and went back to a 4K ABD chunk size. So while1K may have been more memory efficient in the short term, it ended up being suboptimal in the long run. I'm abandoning this issue and hoping no one repeats our lessons.
Dec 19 2017
just for whom it may concern: I've rolled back r326619 and reapplied slw patch on top - again, on "works for me" basics.
Dec 17 2017
Dec 7 2017
Nov 19 2017
I'll try to get some time allocated to that - right now the machine that
I use for this effort is busy doing other things but I may be able to
free up some time on it in the next week or two.