-
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
L2ARC restore sometime fails #15202
Comments
@gamanakis any idea on what is the cause of the issue and/or how to reproduce it consistently? Thanks. |
Yes, it has to do probably with the label and the ashift. We pushed a commit a while back and it's not included in 2.1.11. |
Can you try with #14963 applied? |
I can confirm the issue is the one solved by your patch (ie: L2ARC fail to rebuild after first import). Does it means that, after the first failed import, L2ARC is recreated with implicit Also, it seems that your patch is not even in ZFS 2.1.12. It is scheduled for the 2.2 release, or an eventual 2.1.13 will include it? Thanks. |
It will be in 2.1.13.
…On Sat, Aug 26, 2023 at 7:12 PM shodanshok ***@***.***> wrote:
I can confirm the issue is the one solved by your patch (ie: L2ARC fail to
rebuild after first import). Does it means that, after the first failed
import, L2ARC is recreated with implicit ashift=9? If so, it will be
suboptimal for most SSD.
Also, it seems that your patch is not even in ZFS 2.1.12. It is scheduled
for the 2.2 release, or an eventual 2.1.13 will include it?
Thanks.
—
Reply to this email directly, view it on GitHub
<#15202 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2Y2IJKJGEDOGQJN4STD7TXXIU75ANCNFSM6AAAAAA34EAPGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Excellent. Just to be sure to understand: currently, after the first failed import, L2ARC is recreated with implicit If so, when 2.1.13 will be out one has to recreate the L2ARC to get |
Yes, that is correct.
…On Sun, Aug 27, 2023, 1:19 PM shodanshok ***@***.***> wrote:
It will be in 2.1.13.
Excellent.
Just to be sure to understand: currently, after the first failed import,
L2ARC is recreated with implicit ashift=9?
If so, when 2.1.13 will be out one has to recreate the L2ARC to get
ashit=12, right?
—
Reply to this email directly, view it on GitHub
<#15202 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2Y2IONJZPUTM7CY5KRGVLXXMUL3ANCNFSM6AAAAAA34EAPGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I've updated to 2.1.13 and re-attached the cache device with Thanks. |
I don't think I taught zdb to read the ashift of the cache device. Let me take a look. |
I opened #15331 to enable this. |
@gamanakis I tried EDIT: on ZFS 2.2.2 |
@shodanshok I do not think this |
The commit enabling storing of the ashift in the label of cache devices is present in 2.1.14, though. |
I missed that; I was under the impression that it was added to 2.1.14.
I created a test pool on a 2.1.14 machine, added a L2ARC device, updated to 2.2.2 and rebooted. I then used
How can I check if |
See the comments of fe4d055. We need that commit to enable reporting through zdb. Otherwise it remains unaware. I will submit a PR for 2.1.15. |
I opened #15690 |
System information
Describe the problem you're observing
Sometimes, L2ARC restore fails without apparent reason.
/proc/spl/kstat/zfs/dbgmsg
simply showsL2ARC rebuild no valid log blocks
. See below for an example.Describe how to reproduce the problem
No specific reproduced yet, it simply happens.
Include any warning/errors/backtraces from the system logs
None.
The text was updated successfully, but these errors were encountered: