-
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
zdb: fix BRT dump #16335
zdb: fix BRT dump #16335
Conversation
BRT refcounts are stored as eight uint8_ts rather than a single uint64_t. This means that za_first_integer is only the first byte, so max 256. This fixes it by doing a lookup for the whole value. Sponsored-by: Klara, Inc. Sponsored-by: Wasabi Technology, Inc. Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
I'd prefer we actually fix BRT (at this point probably with another feature flag for backward compatibility) to store one integer of 8 bytes rather than 8 integers of one byte. It is trivial to make code compatible on read, repeating read if we receive respective error, while for write we'd use feature flag to decide which way to write it. Aside of being just right it would fix endianness compatibility, which I think is broken now. I've noticed this few month ago, but haven't got to it yet. |
I mean, I agree, but unless someone is working on it (I'm not) it'd be good to at least get this merged so it does the right thing. |
Just looking for one more approval and we can merge it. |
BRT refcounts are stored as eight uint8_ts rather than a single uint64_t. This means that za_first_integer is only the first byte, so max 256. This fixes it by doing a lookup for the whole value. Sponsored-by: Klara, Inc. Sponsored-by: Wasabi Technology, Inc. Signed-off-by: Rob Norris <rob.norris@klarasystems.com> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Alexander Motin <mav@FreeBSD.org>
BRT refcounts are stored as eight uint8_ts rather than a single uint64_t. This means that za_first_integer is only the first byte, so max 256. This fixes it by doing a lookup for the whole value. Sponsored-by: Klara, Inc. Sponsored-by: Wasabi Technology, Inc. Signed-off-by: Rob Norris <rob.norris@klarasystems.com> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Alexander Motin <mav@FreeBSD.org> (cherry picked from commit aea42e1)
BRT refcounts are stored as eight uint8_ts rather than a single uint64_t. This means that za_first_integer is only the first byte, so max 256. This fixes it by doing a lookup for the whole value. Sponsored-by: Klara, Inc. Sponsored-by: Wasabi Technology, Inc. Signed-off-by: Rob Norris <rob.norris@klarasystems.com> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Alexander Motin <mav@FreeBSD.org>
[Sponsors: Klara, Inc., Wasabi Technology, Inc.]
Motivation and Context
I was using
zdb -TTT
to watch refcount changes as I did some file copies. To my horror, they wrapped from 255 to 0. After I calmed down and start reading the code, it turns out that actuallyzdb
was just holding it slightly wrong. Phew.Description
Slightly weirdly, BRT refcounts are stored as eight
uint8_t
s rather than a singleuint64_t
. This means thatza_first_integer
is only the first byte, so max 256. This fixes it by doing a lookup for the whole value.How Has This Been Tested?
Hand tested on Linux and FreeBSD.
Types of changes
Checklist:
Signed-off-by
.