Re: [PATCH 0/2] btrfs: fixes for subpage which also affect read-only mount
On Mon, Mar 15, 2021 at 01:39:13PM +0800, Qu Wenruo wrote: > During the fstests run for btrfs subpage read-write support, generic/475 > crashes the system with a very high chance. > > It turns out the cause is also affecting btrfs subpage read-only mount > so it's worthy a quick fix. > > Also the crash call site shows a new rabbit hole of hard coded > PAGE_SHIFT in readahead. > This reada problem does not only greatly slow down my test on my ARM > board, but also affects read-only mount. > > So this patchset is here to address the problems, and hope these fixes > can fit into current merge window. Now added to the -rc queue, thanks.
Re: [PATCH 0/2] btrfs: fixes for subpage which also affect read-only mount
On Tue, Mar 16, 2021 at 08:29:35AM +0800, Qu Wenruo wrote: > > > On 2021/3/15 下午11:42, David Sterba wrote: > > On Mon, Mar 15, 2021 at 01:39:13PM +0800, Qu Wenruo wrote: > >> During the fstests run for btrfs subpage read-write support, generic/475 > >> crashes the system with a very high chance. > >> > >> It turns out the cause is also affecting btrfs subpage read-only mount > >> so it's worthy a quick fix. > >> > >> Also the crash call site shows a new rabbit hole of hard coded > >> PAGE_SHIFT in readahead. > > > > There's still a lot of PAGE_SHIFT use, not all of them are wrong but I > > think we'll need to do an audit and categorize the valid uses, otherwise > > it'll be a whack-a-mole. > > > > Already did that. > > The current valid use case for PAGE_SHIFT are: > - Grab page >Including: >* compression >* raid56 >* relocation >* buffered write in file.c >* sb cross page check in volumes.c >* send >* zoned >* sb rw in disk-io.c >* tree csum in disk-io.c >* free space cache v1 > - Some legacy code still runs in full page mode >Including: >* defrag > > - Verification code >That part has way more hardcoded part to be addressed. >Will be addressed in the final part, along with selftest enhancement. > > Although there can be something missing, I believe it shouldn't be that > hard to hit during fstests then. Great, please put that to subpage.c as first comment, and anything that documents the high level topics regarding subpage. Lots of that is in changelogs but we want that readily available in the sources too. Thanks.
Re: [PATCH 0/2] btrfs: fixes for subpage which also affect read-only mount
On 2021/3/15 下午11:42, David Sterba wrote: On Mon, Mar 15, 2021 at 01:39:13PM +0800, Qu Wenruo wrote: During the fstests run for btrfs subpage read-write support, generic/475 crashes the system with a very high chance. It turns out the cause is also affecting btrfs subpage read-only mount so it's worthy a quick fix. Also the crash call site shows a new rabbit hole of hard coded PAGE_SHIFT in readahead. There's still a lot of PAGE_SHIFT use, not all of them are wrong but I think we'll need to do an audit and categorize the valid uses, otherwise it'll be a whack-a-mole. Already did that. The current valid use case for PAGE_SHIFT are: - Grab page Including: * compression * raid56 * relocation * buffered write in file.c * sb cross page check in volumes.c * send * zoned * sb rw in disk-io.c * tree csum in disk-io.c * free space cache v1 - Some legacy code still runs in full page mode Including: * defrag - Verification code That part has way more hardcoded part to be addressed. Will be addressed in the final part, along with selftest enhancement. Although there can be something missing, I believe it shouldn't be that hard to hit during fstests then. Thanks, Qu
Re: [PATCH 0/2] btrfs: fixes for subpage which also affect read-only mount
On Mon, Mar 15, 2021 at 01:39:13PM +0800, Qu Wenruo wrote: > During the fstests run for btrfs subpage read-write support, generic/475 > crashes the system with a very high chance. > > It turns out the cause is also affecting btrfs subpage read-only mount > so it's worthy a quick fix. > > Also the crash call site shows a new rabbit hole of hard coded > PAGE_SHIFT in readahead. There's still a lot of PAGE_SHIFT use, not all of them are wrong but I think we'll need to do an audit and categorize the valid uses, otherwise it'll be a whack-a-mole.
