Skip to contentSkip to conversation

btrfs: bug report: reflink racing with async compression forces read-only

DISCUSSION Breno Leitao 2 participants 2 messages Nov 4 Btrfs file system

lore
Share & tools
lore
#0 lore raw

Hi,

We are seeing btrfs go read-only on arm64 production hosts (64K pages, 4K blocks, compress-force=zstd:3), on 6.16-based kernels and up, still being reproduced in linux-next as of today:

BTRFS warning (device nvme0n1p2): no extent map found for inode ... when unpinning extent range [20480, 24576), generation ...
BTRFS: error (device nvme0n1p2 state A) in btrfs_finish_one_ordered:3200:
errno=-2 No such entry
BTRFS info (device nvme0n1p2 state EA): forced readonly

A quick bissection seems to point to commit 1d2fbb7f1f9e ("btrfs: allow compression even if the range is not page aligned")

I've able to come up with a reproducer that hits the issue within seconds with 64K pages:

https://github.com/leitao/btrfs-reflink-async-compress

My robot identified this as the root cause, but I am not smart enough to understand:

A reflink into a range that is still being compressed does not wait for it:

1. Another part of the same folio starts writeback first, which clears the folio's dirty tag.
2. The second filemap_fdatawrite_range() in btrfs_fdatawrite_range() finds folios by that tag, so btrfs_wait_ordered_range() returns before the async extent has an ordered extent.
3. btrfs_clone() drops or splits the extent map pinned for that extent, and the transaction aborts when it completes. If the clone wins the race instead, the compressed write lands after it and the cloned data is silently lost.

Thanks,
--breno

#1 lore raw
Quoted 12 lines · Breno Leitao

Hi,

We are seeing btrfs go read-only on arm64 production hosts (64K pages, 4K blocks, compress-force=zstd:3), on 6.16-based kernels and up, still being reproduced in linux-next as of today:

BTRFS warning (device nvme0n1p2): no extent map found for inode ... when unpinning extent range [20480, 24576), generation ...
BTRFS: error (device nvme0n1p2 state A) in btrfs_finish_one_ordered:3200:
errno=-2 No such entry
BTRFS info (device nvme0n1p2 state EA): forced readonly

Quoted 7 lines

A quick bissection seems to point to commit 1d2fbb7f1f9e ("btrfs: allow compression even if the range is not page aligned")

I've able to come up with a reproducer that hits the issue within seconds with 64K pages:

https://github.com/leitao/btrfs-reflink-async-compress

Thanks for the report.

Quoted 9 lines

My robot identified this as the root cause, but I am not smart enough to understand:

A reflink into a range that is still being compressed does not wait for it:

1. Another part of the same folio starts writeback first, which clears the folio's dirty tag.

This shouldn't happen, as btrfs has per-block dirty tracking, thus the PAGECACHE_TAG_DIRTY should only be cleared when the last dirty block got its dirty flag cleared.

It looks like some part of code doesn't properly handling the folio PAGECACHE_TAG* in a per-block way.

Thankfully you have a reproducer, it should greatly speedup the fix.

And thank you again for doing a proper bug report, instead of creating LLM slop without understanding it. A lot of guys should really adapt your style of bug reporting.

Thanks,
Qu

Quoted 10 lines

2. The second filemap_fdatawrite_range() in btrfs_fdatawrite_range() finds folios by that tag, so btrfs_wait_ordered_range() returns before the async extent has an ordered extent.
3. btrfs_clone() drops or splits the extent map pinned for that extent, and the transaction aborts when it completes. If the clone wins the race instead, the compressed write lands after it and the cloned data is silently lost.

Thanks,
--breno