diff options
author | Qu Wenruo <wqu@suse.com> | 2024-06-25 07:10:49 +0300 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2024-07-11 16:33:29 +0300 |
commit | 896c8b92dda6ca20c6a591db996039aa8931478b (patch) | |
tree | f59b05c62346fb92f5585edac7f2d30c636f972d /tools/perf/scripts/python/export-to-sqlite.py | |
parent | 1b87d26addd811ac7033720d21def3c4a3ef9fe3 (diff) | |
download | linux-896c8b92dda6ca20c6a591db996039aa8931478b.tar.xz |
btrfs: fix the ram_bytes assignment for truncated ordered extents
[HICCUP]
After adding extra checks on btrfs_file_extent_item::ram_bytes to
tree-checker, running fsstress leads to tree-checker warning at write time,
as we created file extent items with an invalid ram_bytes.
All those offending file extents have offset 0, and ram_bytes matching
num_bytes, and smaller than disk_num_bytes.
This would also trigger the recently enhanced btrfs-check, which catches
such mismatches and report them as minor errors.
[CAUSE]
When a folio/page is invalidated and it is part of a submitted OE, we
mark the OE truncated just to the beginning of the folio/page.
And for truncated OE, we insert the file extent item with incorrect
value for ram_bytes (using num_bytes instead of the usual value).
This is not a big deal for end users, as we do not utilize the ram_bytes
field for regular non-compressed extents.
This mismatch is just a small violation against on-disk format.
[FIX]
Fix it by removing the override on btrfs_file_extent_item::ram_bytes.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions