-
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
l2_asize corrupted in e0b0ca983 #1990
Milestone
Comments
behlendorf
added a commit
to behlendorf/zfs
that referenced
this issue
Feb 1, 2014
Commit e0b0ca9 accidentally corrupted the l2_asize displayed in arcstats. This was caused by changing the l2arc_buf_hdr.b_asize member from an int to uint32_t type. There are places in the code where this field is cast to a uint64_t resulting in the b_hits member being treated as part of b_asize. To resolve the issue the type has been changed to a uint64_t, and the b_hits member is placed after the enum to prevent the size of the structure from increasing. This is a good example of exactly why it's a bad idea to use ambiguous types (int) in these structures. Signed-off-by: Brian Behlendorf <[email protected]> Issue openzfs#1990
l2_size 4 3145230336 l2_asize 4 547742208 l2_hdr_size 4 58055696 Been running for 20 minutes so far. Looking good! |
@DeHackEd Still good 2 days later I trust? |
l2_size 4 71782336000 l2_asize 4 8791361536 ... arc_meta_max 4 18446744073709551520 Since I'm mixing and matching patches I can't tell who's at fault for that metadata one. Since I have the ARC improvements patch loaded I would assume that's the case. |
@DeHackEd Yes, I'm sure the meta_max is related to the other changes. Thanks. |
FransUrbo
pushed a commit
to FransUrbo/zfs
that referenced
this issue
Feb 6, 2014
Commit e0b0ca9 accidentally corrupted the l2_asize displayed in arcstats. This was caused by changing the l2arc_buf_hdr.b_asize member from an int to uint32_t type. There are places in the code where this field is cast to a uint64_t resulting in the b_hits member being treated as part of b_asize. To resolve the issue the type has been changed to a uint64_t, and the b_hits member is placed after the enum to prevent the size of the structure from increasing. This is a good example of exactly why it's a bad idea to use ambiguous types (int) in these structures. Signed-off-by: DHE <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#1990
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you're running the latest git head and have an L2ARC, check out your
l2_asize
arcstat. Look a little broken? Especially immediately after booting up and importing? I bisected it and happened in e0b0ca9This is what I did for a little analysis, but I doubt much below here will be useful for fixing it.
21486145024-11100672+1024+10240+512+512+2048-55296-33280-68096-67584
= 21474834432
= 2^31 * 10 - 2048 (??)
The text was updated successfully, but these errors were encountered: