Re: parent transid verify failed

[Eric Levy <contact@ericlevy.name>]

On Sat, 2022-01-01 at 13:49 -0700, Chris Murphy wrote:


> OK except we've got kernel messages clearly showing /dev/sdc is
> rejecting writes, and that's what btrfs is complaining about. Since
> there's only a partial dmesg to go on, I can really say if there's
> something else going on, but pretty straightforward when there's
> multiple of these:

All I'm suggesting is that the write issue is far more likely to be
occurring at the layer of logical volumes than physical media, based on
the symptoms.
 
If you go back a few messages, you can find one with the full output,
attached as a file. 


> Dec 30 03:47:10 hostname kernel: blk_update_request: I/O error, dev
> sdc, sector 523542288 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio
> class 0
> 
> That it will result in these:
> 
> Dec 30 03:47:10 hostname kernel: BTRFS error (device sdc1): bdev
> /dev/sdc1 errs: wr 10, rd 0, flush 0, corrupt 0, gen 0
> 
> Btrfs is telling us that writes are being dropped. I'm not sure why
> /dev/sdc is dropping writes but the block layer also knows they're
> being rejected and what sector, so I kinda suspect the block device
> itself is aware of and reporting the write failures with sector
> address to the kernel.

If the problem is at the logical layer, then I would suspect the same,
that the block layer knows whether block writes are committed.


> I can't tell if you've tried umounting this file system and then
> mounting it again cleanly (not remount) and what messages appear in
> dmesg if it fails.

Yes. Clean mount/umount only. No remount option.


> It's definitely an issue with /dev/sdc, but I can't tell from the
> available info why it's dropping writes, only that two parts of the
> kernel are seeing it, btrfs and blk_update_request

I'm simply giving the inference that there must have been some bock
writes on sdc(1) following the addition of sdd as a system device,
otherwise we would have seen failures trying to join the two devices
into the same file system. Right?

So there was some interval during which both block devices were
writable. Right?


> > If the problem is device-level, then there is much to try,
including
> 
> > renewing the iSCSI login. I can also restart the daemon, reboot the
> > host, even restart the iSCSI backend service or appliance.
> > 
> > Would any operations of such a kind be helpful to try?
> 
> iSCSI isn't my area of expertise, someone else might have an idea
> what
> could be going on.

Nor mine, but I'm trying to make infereences based on how the parts
fit together.