On Thu, Jan 28, 2016 at 12:37 PM, Austin S. Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:
> On 2016-01-28 13:47, Sean Greenslade wrote:
>>
>> On Thu, Jan 28, 2016 at 09:18:06AM -0700, Chris Murphy wrote:
>>>
>>> Those read errors are a persistent counter. Use 'btrfs dev stat' to
>>> see them for each device, and use -z to clear. I think this is in
>>> DEV_ITEM, and it should be dev.uuid based, so the counter ought to be
>>> with this specific device, not merely "sda1". So ... I'd look in the
>>> journal for the time during the replace and see where those read
>>> errors might have come from if this is supposed to be a new drive and
>>> you're not expecting read errors already.
>>>
>>> Like I mentioned in my first reply to this thread, sct erc... it's
>>> very important to get these settings right.
>>
>>
>> I don't see anything that indicates read errors in my journal or dmesg,
>> though it's hard to tell given the rather scary-looking messages I get
>> whenever I eject a drive:
>>
>> [Thu Jan 28 10:38:10 2016] ata6.00: exception Emask 0x10 SAct 0x8 SErr
>> 0x280100 action 0x6 frozen
>> [Thu Jan 28 10:38:10 2016] ata6.00: irq_stat 0x08000000, interface fatal
>> error
>> [Thu Jan 28 10:38:10 2016] ata6: SError: { UnrecovData 10B8B BadCRC }
>> [Thu Jan 28 10:38:10 2016] ata6.00: failed command: READ FPDMA QUEUED
>> [Thu Jan 28 10:38:10 2016] ata6.00: cmd
>> 60/00:18:00:79:02/05:00:00:00:00/40 tag 3 ncq 655360 in
>> res
>> 40/00:18:00:79:02/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
>> [Thu Jan 28 10:38:10 2016] ata6.00: status: { DRDY }
>> [Thu Jan 28 10:38:10 2016] ata6: hard resetting link
>> [Thu Jan 28 10:38:10 2016] ata6: SATA link up 3.0 Gbps (SStatus 123
>> SControl 320)
>>
> If by eject you mean disconnect form the system, this is exactly the output
> I would expect if you haven't done something to tell the kernel the disk is
> disappearing.
How about something like:
# hdparm -Y /dev/sdb
# echo 1 /sys/block/sdb/device/delete
Then physically disconnect the drive, assuming hot-plug is supported
by all hardware?
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
