From: 小太 <nospam@kota.moe>
To: linux-btrfs@vger.kernel.org
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: Re: Buggy behaviour after replacing failed disk in RAID1
Date: Sat, 31 Dec 2022 21:03:57 -0800 (PST) [thread overview]
Message-ID: <63b1143d.170a0220.9d74e.f651@mx.google.com> (raw)
In-Reply-To: <d13c2454-b642-2db7-371e-b669fdf24279@gmx.com>
> Weirdly, the dmesg is not showing devid 1 missing, in fact, it still
> shows the devices is there, just tons of IO errors (ata4, sd 3:0:0:0)
> If you initially removed the hard disk completely, btrfs then can handle
> it well.
> (Sure, this is a bug in btrfs and we should be able to fix it).
I did completely remove the drive. In fact, I used the very same SATA port for
the replacement drive. See my dmesg lines:
> [1744757.386462] ata4: SATA link down (SStatus 0 SControl 300)
> [1744762.810285] ata4: SATA link down (SStatus 0 SControl 300)
> [1744768.190059] ata4: SATA link down (SStatus 0 SControl 300)
> [1744768.190072] ata4.00: disable device
> [1744768.190097] ata4.00: detaching (SCSI 3:0:0:0)
> [1744768.295895] sd 3:0:0:0: [sda] Stopping disk
> [1744768.295913] sd 3:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
> ...
> [1745523.320657] ata4: found unknown device (class 0)
> [1745527.965324] ata4: softreset failed (1st FIS failed)
> [1745533.288241] ata4: found unknown device (class 0)
> [1745533.452246] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [1745533.453025] ata4.00: ATA-9: MB2000ECWCR, HPG4, max UDMA/133
> [1745533.453306] ata4.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 32), AA
> [1745533.454136] ata4.00: configured for UDMA/133
> [1745533.464339] scsi 3:0:0:0: Direct-Access ATA MB2000ECWCR HPG4 PQ: 0 ANSI: 5
> [1745533.464556] sd 3:0:0:0: Attached scsi generic sg3 type 0
> [1745533.464652] sd 3:0:0:0: [sdd] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
> [1745533.464667] sd 3:0:0:0: [sdd] Write Protect is off
> [1745533.464671] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
> [1745533.464684] sd 3:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [1745533.464700] sd 3:0:0:0: [sdd] Preferred minimum I/O size 512 bytes
> [1745533.492586] sd 3:0:0:0: [sdd] Attached SCSI disk
I also verified that the device file /dev/sda was also gone at the time (despite
"btrfs fi show" thinking it still exists).
Maybe there's some other bug where the kernel still thinks the drive exists, even
though it was disconnected?
next prev parent reply other threads:[~2023-01-01 5:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACsxjPaFgBMRkeEgbHcGwM7czSrjtakX9hSKXQq7RL2wJZYYCA@mail.gmail.com>
2023-01-01 0:05 ` Buggy behaviour after replacing failed disk in RAID1 小太
2023-01-01 0:38 ` Qu Wenruo
2023-01-01 5:03 ` 小太 [this message]
2023-01-01 9:27 ` Qu Wenruo
2023-01-01 23:31 ` 小太
2023-01-02 0:15 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63b1143d.170a0220.9d74e.f651@mx.google.com \
--to=nospam@kota.moe \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox