]> www.infradead.org Git - nvme.git/commit
btrfs: fix the ram_bytes assignment for truncated ordered extents
authorQu Wenruo <wqu@suse.com>
Tue, 25 Jun 2024 04:10:49 +0000 (13:40 +0930)
committerDavid Sterba <dsterba@suse.com>
Thu, 11 Jul 2024 13:33:29 +0000 (15:33 +0200)
commit896c8b92dda6ca20c6a591db996039aa8931478b
treef59b05c62346fb92f5585edac7f2d30c636f972d
parent1b87d26addd811ac7033720d21def3c4a3ef9fe3
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>
fs/btrfs/inode.c