call trace when btrfs-check tries to write on ro-blockdev

call trace when btrfs-check tries to write on ro-blockdev

[Christoph Anton Mitterer]

Hey.

Not really a big problem but a but "ugly"...

When trying to do some write operation with btrfs check on a blockdev
that is set read-only, one gets a call trace like the following:


# btrfs check --clear-space-cache v1 /dev/mapper/data
Opening filesystem to check...
Checking filesystem on /dev/mapper/data-b-1
UUID: 18343f60-3955-11ed-a6c8-38afd7a81270
Error writing to device 1
kernel-shared/transaction.c:156: __commit_transaction: BUG_ON `ret`
triggered, value 1
btrfs(+0x3683b)[0x55c75780483b]
btrfs(__commit_transaction+0xc6)[0x55c757804b32]
btrfs(btrfs_commit_transaction+0x130)[0x55c757804ca0]
btrfs(+0x61963)[0x55c75782f963]
btrfs(+0x6e297)[0x55c75783c297]
btrfs(main+0x318)[0x55c7577e6138]
/lib/x86_64-linux-gnu/libc.so.6(+0x2920a)[0x7f6fd6ff920a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x7c)[0x7f6fd6ff92bc]
btrfs(_start+0x21)[0x55c7577e6171]
Aborted


Cheers,
Chris.

PS: That was with progs 5.19.

Re: call trace when btrfs-check tries to write on ro-blockdev

[Qu Wenruo]

On 2022/9/21 10:29, Christoph Anton Mitterer wrote:
> Hey.
>
> Not really a big problem but a but "ugly"...
>
> When trying to do some write operation with btrfs check on a blockdev
> that is set read-only, one gets a call trace like the following:

BUG_ON() is definitely something we should fix.

But my concern is, why this is not reported at fs open time?

As for repair we should open the device with O_RDWR, and if that device
is RO, we should error out at open() time.

Let me dig deeper into the case.

Thanks for the report,
Qu

>
>
> # btrfs check --clear-space-cache v1 /dev/mapper/data
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/data-b-1
> UUID: 18343f60-3955-11ed-a6c8-38afd7a81270
> Error writing to device 1
> kernel-shared/transaction.c:156: __commit_transaction: BUG_ON `ret`
> triggered, value 1
> btrfs(+0x3683b)[0x55c75780483b]
> btrfs(__commit_transaction+0xc6)[0x55c757804b32]
> btrfs(btrfs_commit_transaction+0x130)[0x55c757804ca0]
> btrfs(+0x61963)[0x55c75782f963]
> btrfs(+0x6e297)[0x55c75783c297]
> btrfs(main+0x318)[0x55c7577e6138]
> /lib/x86_64-linux-gnu/libc.so.6(+0x2920a)[0x7f6fd6ff920a]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x7c)[0x7f6fd6ff92bc]
> btrfs(_start+0x21)[0x55c7577e6171]
> Aborted
>
>
> Cheers,
> Chris.
>
> PS: That was with progs 5.19.

Re: call trace when btrfs-check tries to write on ro-blockdev

[Christoph Anton Mitterer]

On Wed, 2022-09-21 at 10:40 +0800, Qu Wenruo wrote:
> But my concern is, why this is not reported at fs open time?

At first I also wanted to suggest to not even do the (possibly lengthy
opening) if it's anyway "clear" that it would fail (because of the --
clear-space-cache request and the blockdev being ro).

However... if e.g. --clear-space-cache is used, but the device wouldn't
have any space cache... then it could still succeed, even if it was ro,
right?
So maybe for that case it would make sense to try.


> Let me dig deeper into the case.

Thanks.


Chris.

Re: call trace when btrfs-check tries to write on ro-blockdev

[Qu Wenruo]

On 2022/9/21 11:43, Christoph Anton Mitterer wrote:
> On Wed, 2022-09-21 at 10:40 +0800, Qu Wenruo wrote:
>> But my concern is, why this is not reported at fs open time?
>
> At first I also wanted to suggest to not even do the (possibly lengthy
> opening) if it's anyway "clear" that it would fail (because of the --
> clear-space-cache request and the blockdev being ro).
>
> However... if e.g. --clear-space-cache is used, but the device wouldn't
> have any space cache... then it could still succeed, even if it was ro,
> right?
> So maybe for that case it would make sense to try.
>
>
>> Let me dig deeper into the case.

Got the reason.

With block device set to RO (blockdev --setro), we can still open it RW,
only when we decides to write it, it return -EIO.

Thus the open() call with O_RDWR doesn't ensure we can write it, and we
should handle the BUG_ON() during metadata writeback.

Thanks,
Qu

>
> Thanks.
>
>
> Chris.

Re: call trace when btrfs-check tries to write on ro-blockdev

[Christoph Anton Mitterer]

On Fri, 2022-09-23 at 18:39 +0800, Qu Wenruo wrote:
> Got the reason.

As so often:

thanks for your efforts :-)


Cheers,
Chris.