Errors after kernel panic not addressed during scrub or fsck.

Errors after kernel panic not addressed during scrub or fsck.

[nstgc379]

Hello,

I have an issue that I first experienced a few years back which was
never resolved. The timing was really bad so I just scrapped the
effected volume and made another, but I'd like to actually fix it now.

My system went down as the result of what I assume to be a kernel
panic. After rebooting I ran `dmesg |grep BTRFS` and found two lines
which concerned me.

    [    9.493064] BTRFS info (device sde3): bdev /dev/sde3 errs: wr
432, rd 0, flush 4, corrupt 8, gen 3
    [    3.086233] BTRFS info (device sde1): bdev /dev/sde1 errs: wr
5711892, rd 14399372, flush 104, corrupt 467, gen 2

I then scrubbed the effected volumes (both RAID1s), but no errors were
found. I've gotten messages like that before, and scrub normally
identifies that there are errors and fixes them. I then also tried
running `btrfs check --readonly` on the devices, but again the test
showed everything was okay.

Admittedly everything seems to be working.

$ uname -r
4.20.7-arch1-1-ARCH
$ btrfs --version
btrfs-progs v4.20.1
I don't have any journal logs as a result of the crash. `dmesg -l err`
doesn't show anything out of the ordinary (complaints about not using
ECC memory).

Re: Errors after kernel panic not addressed during scrub or fsck.

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1802 bytes --]



On 2019/2/18 上午9:33, nstgc379@gmail.com wrote:
> Hello,
> 
> I have an issue that I first experienced a few years back which was
> never resolved. The timing was really bad so I just scrapped the
> effected volume and made another, but I'd like to actually fix it now.
> 
> My system went down as the result of what I assume to be a kernel
> panic. After rebooting I ran `dmesg |grep BTRFS` and found two lines
> which concerned me.
> 
>     [    9.493064] BTRFS info (device sde3): bdev /dev/sde3 errs: wr
> 432, rd 0, flush 4, corrupt 8, gen 3
>     [    3.086233] BTRFS info (device sde1): bdev /dev/sde1 errs: wr
> 5711892, rd 14399372, flush 104, corrupt 467, gen 2

That's from old statistics.
You could reset the statistics by "btrfs status -z" and then check if
the stats increase again.

But considering there are so many read/write errors, I really recommend
to check if there is something wrong with the devices (at least check
the SMART info).

> 
> I then scrubbed the effected volumes (both RAID1s), but no errors were
> found. I've gotten messages like that before, and scrub normally
> identifies that there are errors and fixes them. I then also tried
> running `btrfs check --readonly` on the devices, but again the test
> showed everything was okay.

"btrfs check" by default only checks metadata, and since you're using
RAID1, it's possible that btrfs check only check the first copy of
metadata if nothing went wrong.

Thanks,
Qu

> 
> Admittedly everything seems to be working.
> 
> $ uname -r
> 4.20.7-arch1-1-ARCH
> $ btrfs --version
> btrfs-progs v4.20.1
> I don't have any journal logs as a result of the crash. `dmesg -l err`
> doesn't show anything out of the ordinary (complaints about not using
> ECC memory).
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]