Skip to content
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

Add zfs feature flag for arc memory #784

Merged
merged 5 commits into from
Aug 22, 2022

Conversation

jamartin9
Copy link
Contributor

@jamartin9 jamartin9 commented Aug 17, 2022

Description

Adds arc support for linux and freebsd.
This is enabled by default with the zfs feature flag but only shown at runtime when arc collection support is detected.

Linux with arc:
linux-arc
linux-arc-basic

Linux no arc:
linux-noarc
linux-noarc-basic

FreeBSD with arc:
freebsd-arc

FreeBSD no arc:
freebsd-noarc

Windows no arc:
windows-bottom

Issue

This does not include extra arc information like compression ratio.

refs: #688

Testing

If relevant, please state how this was tested. All changes must be tested to work:

If this is a code change, please also indicate which platforms were tested:

I did not test for macOS arc support...(it may work with sysctl like freebsd?)

  • Windows
  • macOS
  • Linux
  • FreeBSD

Checklist

If relevant, ensure the following have been met:

  • Areas your change affects have been linted using rustfmt (cargo fmt)
  • The change has been tested and doesn't appear to cause any unintended breakage
  • Documentation has been added/updated if needed (README.md, help menu, etc.)
  • The pull request passes the provided CI pipeline
  • There are no merge conflicts

Feel free to close the PR if the implementation is too erroneous

@ClementTsang
Copy link
Owner

ClementTsang commented Aug 17, 2022

Thanks for the PR! Will take a look in a bit. I can test on macOS as well (EDIT: at least to make sure nothing broke, will probably have to look into arc for macos in a separate PR).

@codecov-commenter
Copy link

codecov-commenter commented Aug 17, 2022

Codecov Report

Merging #784 (92ddbff) into master (658b8c7) will decrease coverage by 0.38%.
The diff coverage is 2.11%.

@@            Coverage Diff             @@
##           master     #784      +/-   ##
==========================================
- Coverage   24.04%   23.66%   -0.39%     
==========================================
  Files          60       60              
  Lines       13008    13239     +231     
==========================================
+ Hits         3128     3133       +5     
- Misses       9880    10106     +226     
Impacted Files Coverage Δ
src/app/data_harvester.rs 0.00% <0.00%> (ø)
src/app/data_harvester/memory/general/heim.rs 0.00% <0.00%> (ø)
src/bin/main.rs 13.11% <0.00%> (-0.68%) ⬇️
src/canvas.rs 15.94% <0.00%> (-0.37%) ⬇️
src/canvas/widgets/mem_basic.rs 0.00% <0.00%> (ø)
src/canvas/widgets/mem_graph.rs 0.00% <0.00%> (ø)
src/constants.rs 0.00% <0.00%> (ø)
src/data_conversion.rs 12.94% <0.00%> (-1.46%) ⬇️
src/lib.rs 6.85% <0.00%> (-0.09%) ⬇️
src/options.rs 61.24% <ø> (ø)
... and 3 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

src/canvas.rs Outdated Show resolved Hide resolved
src/data_conversion.rs Show resolved Hide resolved
src/data_conversion.rs Show resolved Hide resolved
src/app/data_harvester/memory/general/heim.rs Outdated Show resolved Hide resolved
src/app/data_harvester/memory/general/sysinfo.rs Outdated Show resolved Hide resolved
@ClementTsang
Copy link
Owner

Mostly just some nits. Otherwise looks fine. Will run on macOS and check it off if it seems fine later tomorrow.

@jamartin9
Copy link
Contributor Author

jamartin9 commented Aug 18, 2022

Mostly just some nits. Otherwise looks fine. Will run on macOS and check it off if it seems fine later tomorrow.

@ClementTsang Thanks for your timely response and great feedback!

I have tried to address the comments raised. If more is needed please let me know.
I gave the code changes a quick cargo clippy and cargo run on the three platforms I have access to again.

Additionally I would like to know if you think this approach would be satisfactory for say Video Card RAM with the gpu feature flag?(I would extract out the initialization into a once_cell or something like the nvml-wrapper docs say of course) I can raise this in the feature request issue 298 if you would rather answer there instead...

EDIT: forgot a feature flag... You may want to squash if you merge.

@ClementTsang
Copy link
Owner

LGTM. Thanks for the PR!

@all-contributors please add @jamartin9 for code.

@allcontributors
Copy link
Contributor

@ClementTsang

I've put up a pull request to add @jamartin9! 🎉

@ClementTsang ClementTsang merged commit 6e0bc96 into ClementTsang:master Aug 22, 2022
@ClementTsang
Copy link
Owner

Additionally I would like to know if you think this approach would be satisfactory for say Video Card RAM with the gpu feature flag?(I would extract out the initialization into a once_cell or something like the nvml-wrapper docs say of course) I can raise this in the feature request issue 298 if you would rather answer there instead...

I think that could work, yeah.

ClementTsang added a commit that referenced this pull request Aug 23, 2022
@Lyndeno
Copy link

Lyndeno commented Mar 25, 2024

Does zfs expose similar information for L2ARC? If so, maybe that could be shown as well?

@jamartin9
Copy link
Contributor Author

@Lyndeno Does zfs expose similar information for L2ARC? If so, maybe that could be shown as well?

Yes arcstats has l2 information like l2_size/l2_asize, l2_write_bytes,l2_read_bytes.
The information could be added in the disk widget. ( Like the iostats for zfs zpools in #1248 ; by adding an entry to DiskHarvest and IoHarvest for the device/usage. )
The feature could be added by anyone inclined to do so. I do not use l2 at this moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants