在 2024/12/4 10:47, Christoph Hellwig 写道:
On Tue, Dec 03, 2024 at 06:01:20PM +0100, David Sterba wrote:
On Fri, Nov 08, 2024 at 03:48:57PM +0100, Christoph Hellwig wrote:
On Mon, Nov 04, 2024 at 07:26:28AM +0100, Christoph Hellwig wrote:
Hi Jens, hi Damien, hi btrfs maintainers,
How should we proceed with this? Should Jens just pick up the block
bits and the btrfs maintainers pick up the btrfs once they are
ready and the block bits made it upstream?
The block layer patches are now in master, I'm adding the remaining
patches to btrfs for-next.
Thanks. I wanted to resend them, but my baseline testing still showed
crashes in generic/475 so I was looking into an expunge config to
check if there are no regressions first (there really shouldn't, but
I wanted to double check).
Talking about generic/475 crash, it looks like there is something wrong
inside btrfs' space reservation code, which causes run_delalloc_range()
to fail with ENOSPC (which should not happen).
If my memory works correctly, at least 3 release ago we didn't hit such
ENOSPC during run_delalloc_range().
I'm working on fixing the involved error handling, there are some
patches to reduce involved crashes:
For ordered extent double freeing:
https://lore.kernel.org/linux-btrfs/cover.1732695237.git.wqu@xxxxxxxx/
For ENOSPC error handling in run_delalloc_range():
https://lore.kernel.org/linux-btrfs/0b4675971b718709497ca35c0d69e06db0c69d58.1732867087.git.wqu@xxxxxxxx/
https://lore.kernel.org/linux-btrfs/3e5d5665ef36ee43e310be321073210785b89adc.1733273653.git.wqu@xxxxxxxx/
Which can help you to continue, but at least on my aarch64 VMs with 64K
page size and 4K block size, I can still hit random failures related to
unfinished iput or run-away locked pages.
Unfortunately I'm not educated enough to pin down the
run_delalloc_range() ENOSPC errors, but only use this chance to fix the
error handling...
Thanks,
Qu
