On 2019/2/18 上午9:33, nstgc379@xxxxxxxxx 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:
signature.asc
Description: OpenPGP digital signature
