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

zdb: fix BRT dump #16335

Merged
merged 1 commit into from
Jul 18, 2024
Merged

zdb: fix BRT dump #16335

merged 1 commit into from
Jul 18, 2024

Conversation

robn
Copy link
Member

@robn robn commented Jul 10, 2024

[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 actually zdb was just holding it slightly wrong. Phew.

Description

Slightly weirdly, 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.

How Has This Been Tested?

Hand tested on Linux and FreeBSD.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
  • Documentation (a change to man pages or other documentation)

Checklist:

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>
@amotin
Copy link
Member

amotin commented Jul 10, 2024

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.

@robn
Copy link
Member Author

robn commented Jul 10, 2024

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.

@robn robn mentioned this pull request Jul 17, 2024
13 tasks
@tonyhutter tonyhutter added the Status: Code Review Needed Ready for review and testing label Jul 18, 2024
@tonyhutter
Copy link
Contributor

Just looking for one more approval and we can merge it.

@tonyhutter tonyhutter merged commit aea42e1 into openzfs:master Jul 18, 2024
24 of 25 checks passed
lundman pushed a commit to openzfsonwindows/openzfs that referenced this pull request Sep 4, 2024
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>
robn added a commit to robn/zfs that referenced this pull request Nov 5, 2024
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)
@robn robn mentioned this pull request Nov 5, 2024
13 tasks
ptr1337 pushed a commit to CachyOS/zfs that referenced this pull request Nov 14, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Code Review Needed Ready for review and testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants