summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-sqlite.py
diff options
context:
space:
mode:
authorQu Wenruo <wqu@suse.com>2024-06-25 07:10:49 +0300
committerDavid Sterba <dsterba@suse.com>2024-07-11 16:33:29 +0300
commit896c8b92dda6ca20c6a591db996039aa8931478b (patch)
treef59b05c62346fb92f5585edac7f2d30c636f972d /tools/perf/scripts/python/export-to-sqlite.py
parent1b87d26addd811ac7033720d21def3c4a3ef9fe3 (diff)
downloadlinux-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