-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3525 persistent l2arc. #1823
3525 persistent l2arc. #1823
Conversation
This patch seems to be pretty much functional now, although the numbers in arcstats are completely insane. Still looking for the cause, any suggestions? |
I think I fixed the stat numbers |
I've been using this for several months. It seems to be mostly fine, but has lock-ups during boot which I can't locate in the code. Could anyone help me test and review the code? |
Do you have stack traces obtained during the lockups? (SysRq keys!) It happened during pool import or after? |
any updated feedback on this ? did anyone figure out why it locks up ? @yshui about what kind of lock-ups are we talking about ? the system completely locks up/hardlocks ? currently I'm also using an l2arc and its kind of counterproductive that it needs to refill anew after every reboot (I need to reboot often into windows, so it takes a while until l2arc is full and fully beneficial again) |
Sorry, I won't be able to do it for now. Anyone who is interested should take this. |
I rebased it again. It seems to work in my virtual machine. For now I don't have other test environments. |
For details, see: https://www.illumos.org/issues/3525 v2: Change two KM_SLEEP to KM_PUSHPAGE. v3: Change one more KM_SLEEP. v4: Fix log buffer alignment in l2arc_dev_log_commit. v5: Fix style. v6: l2arc vdev can go away, remove ASSERT in l2arc_spa_rebuild_start. Close #925 Ported-by: Yuxuan Shui <yshuiv7@gmail.com>
Hi @yshui Could you give us a little test procedure ? I did warm up the cache, then try an export / import after which I found an empty l2arc ?! Any clues ? |
@edillmann Can you post the content of /proc/spl/kstat/zfs/arcstats? It's probably a bug. Thanks |
5 1 0x01 100 4800 37707460085 172635741662342 |
@edillmann Is this the result after you export/import the pool? |
@yshui yes, it's after export / import |
@yshui is there anything I can do to help you to track down this bug ? |
@edillmann This is weird. Even if the rebuild failed, at least one of these should be non-zero: l2_rebuild_successes 4 0 I'll see if I can reproduce this. |
I'm tried a vanilla 3.16.1 kernel, with only this patch and obtain the same result |
@yshui I tried all this again from scratch, fresh pull, rebase against master, and it work's :-) I think I had some weird build environnment After export / import a get the following stats: l2_rebuild_successes 4 2 |
@yshui rebase to master can be found at https://github.com/edillmann/zfs/tree/illumos-3525 |
@edillmann if you opened a pull request with the latest change we could get some testing result from it. Or @yshui could refresh this one. |
Sorry I closed this pull request by accidentally deleting the branch. I'll create a new one. |
This commit makes the L2ARC persistent across reboots. We implement a light-weight persistent L2ARC metadata structure that allows L2ARC contents to be recovered after a reboot. This significantly eases the impact a reboot has on read performance on systems with large caches. Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Co-authored-by: Saso Kiselkov <skiselkov@gmail.com> Co-authored-by: Jorgen Lundman <lundman@lundman.net> Co-authored-by: George Amanakis <gamanakis@gmail.com> Ported-by: Yuxuan Shui <yshuiv7@gmail.com> Signed-off-by: George Amanakis <gamanakis@gmail.com> Closes #925 Closes #1823 Closes #2672 Closes #3744 Closes #9582
This commit makes the L2ARC persistent across reboots. We implement a light-weight persistent L2ARC metadata structure that allows L2ARC contents to be recovered after a reboot. This significantly eases the impact a reboot has on read performance on systems with large caches. Reviewed-by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Co-authored-by: Saso Kiselkov <skiselkov@gmail.com> Co-authored-by: Jorgen Lundman <lundman@lundman.net> Co-authored-by: George Amanakis <gamanakis@gmail.com> Ported-by: Yuxuan Shui <yshuiv7@gmail.com> Signed-off-by: George Amanakis <gamanakis@gmail.com> Closes openzfs#925 Closes openzfs#1823 Closes openzfs#2672 Closes openzfs#3744 Closes openzfs#9582
Details: https://www.illumos.org/issues/3525
This patch compiles, but haven't been tested. I will when I get time.
If anyone spent their time to review this, that will be appreicated.