adding l2arc for metadata only

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
Hello,
Following the advice kindly given here I extended a pool. I want to make sure I've done things right. I pressed add cache, then added the disk to read cache. After that I went over to shell and entered the command:
Code:
zfs set secondarycache=metadata misradpool/misraddata 

(misradpool/misraddata is the path to the dataset).
I noticed a warning when I opened up the shell saying:
"Setting changed through the CLI are not written to the configuration database and will be reset on reboot"
So I'm not sure I did everything right and I'm not sure what that warning meant.
I would greatly appreciate any help.
Also if you read the original thread (basically there's a lag when writing and we don't know why) I would appreciate any comment or direction to solving this problem.
Thank you.
 
Last edited:

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
That's telling you you'll need to run the same command after every boot. To automate this, you'll need to add this as an Init/Shutdown task. You could add this as a post-init command.
 

Yorick

Wizard
Joined
Nov 4, 2018
Messages
1,912
That's telling you you'll need to run the same command after every boot

I highly doubt that. This is a property of the pool, not a tunable, isn't it? Pool properties are retained across reboots.
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
Using zfs set to update the property on a pool or dataset is permanent on that pool or dataset (and remains with the pool even in another system), so a one-time operation.

That warning applies to things like changing rc.conf or cron or any of the many things that can be configured in the GUI, which then cause the system files to be re-written at certain moments (like reboots or upgrades).
 

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
Using zfs set to update the property on a pool or dataset is permanent on that pool or dataset (and remains with the pool even in another system), so a one-time operation.

That warning applies to things like changing rc.conf or cron or any of the many things that can be configured in the GUI, which then cause the system files to be re-written at certain moments (like reboots or upgrades).
Thank you all. I understand everything else is fine? One more question: How long will it take for changes to be felt? It is a rather small db, about 30 GB and not that much writing - unless everytime a small change is made, everything is re-written but I don't think it is the case.
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
The setting takes place immediately. As to your L2ARC, that will populate over time based on your usage patterns. The more usage, the faster your L2ARC metadata cache will fill.
 

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
The setting takes place immediately. As to your L2ARC, that will populate over time based on your usage patterns. The more usage, the faster your L2ARC metadata cache will fill.
Is there a rough estimate as to when I call it a fail? Like are we talking a day or two? A week? A month? I'm not talking optimal improvement, just some indication of it.
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Watch zfs-stats, to see if your metadata hit rate improves. For me, after I made the L2ARC change to metadata only, my L2ARC hit rate improved from ~4% to ~70% after watching one movie in Plex.
 

Yorick

Wizard
Joined
Nov 4, 2018
Messages
1,912
Day or two.

Again, we are talking about speed when showing a directory or traversing a list of files, not write speed, right?
 

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
Day or two.

Again, we are talking about speed when showing a directory or traversing a list of files, not write speed, right?
It is actually write speed. Any small change takes a long time (2-3 sec) to complete. If you remember the original post, which you kindly diagnosed - you said this might be due to feedback after writing (I linked above to that post)
 

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
It is actually write speed. Any small change takes a long time (2-3 sec) to complete. If you remember the original post, which you kindly diagnosed - you said this might be due to feedback after writing (I linked above to that post)
Read back after writing*
 

Yorick

Wizard
Joined
Nov 4, 2018
Messages
1,912
Gotcha. Well this will be interesting ....
 

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
I actually prefered switching both wd harddrives (the vdev) to ssd but I have only one SATA interface left, and that means I think that I have to copy the db first to an external drive and then remove the wd-s, install the ssd-s and copy it (which will take quite a long time). So first I want to give a chance to this cache solution which you guys said might help. But from what I understand, I shouldn't be too optimistic
 
Last edited:

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
Like are we talking a day or two?
You can potentially force the directory tree to be read into L2ARC by using an ls command across the whole file tree ls /mnt/poolname -R
 

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
You can potentially force the directory tree to be read into L2ARC by using an ls command across the whole file tree ls /mnt/poolname -R
You guys are great. I called today and they said the problem did not appear today, thanks God. It might be too soon to celebrate, but this a very good indication that you gave me the right solution. That was briliant I think.
 

Yorick

Wizard
Joined
Nov 4, 2018
Messages
1,912
12.0 will have Persistent L2ARC as well, which means this speedup will survive reboot.

Now that you have, knock on wood, a solution, maybe think of mirroring that L2ARC. ZFS survives an L2ARC outage, but then your users have the issue again of course.
 

tomerg

Dabbler
Joined
Mar 9, 2020
Messages
37
12.0 will have Persistent L2ARC as well, which means this speedup will survive reboot.

Now that you have, knock on wood, a solution, maybe think of mirroring that L2ARC. ZFS survives an L2ARC outage, but then your users have the issue again of course.
I'm out if sata interfaces...
 

Yorick

Wizard
Joined
Nov 4, 2018
Messages
1,912
Oh well. SSDs are reliable. Just have one in your back pocket for replacement in case of a case.

And when it's time to move this pool to a new "server", build on a SuperMicro board with IPMI and 8 SATA ports, not some consumer gamer "LED lights" thing. That's my opinionated opinion, for any kind of business use.
 
Top