On 2020/2/3 下午2:38, Skibbi wrote: > niedz., 2 lut 2020 o 20:56 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> napisał(a): >> >> On Sun, Feb 2, 2020 at 5:45 AM Skibbi <skibbi@xxxxxxxxx> wrote: >> >>> root@rpi4b:~# dmesg |grep btrfs >>> [223167.290255] BTRFS: error (device dm-0) in >>> btrfs_run_delayed_refs:2935: errno=-5 IO failure >>> [223167.389690] BTRFS: error (device dm-0) in >>> btrfs_run_delayed_refs:2935: errno=-5 IO failure >>> root@rpi4b:~# dmesg |grep BTRFS >> >> The entire unfiltered dmesg is needed. This older kernel doesn't have >> new enough Btrfs tree checker code to help determine what the problem >> is. > > OK, I need to reformat my drive and reproduce the issue again. > >>> [203285.351377] BTRFS error (device sda1): bad tree block start, want >>> 31457280 have 0 >> >>> [203285.466743] BTRFS info (device sda1): read error corrected: ino 0 >>> off 32735232 (dev /dev/sda1 sector 80320) >> >>> [218811.383208] BTRFS error (device dm-0): bad tree block start, want >>> 50659328 have 7653333615399691647 >> >> These happening together suggest lower storage stack failure. Since >> kernel messages are filtered it only shows that Btrfs is working as >> designed, complaining about known bad file system metadata. But >> because it's filtered, it's not clear why the metadata has gone bad. >> >>> [223167.290255] BTRFS: error (device dm-0) in >>> btrfs_run_delayed_refs:2935: errno=-5 IO failure >> >> More suggestion of IO failure, whether physical device or logical >> layer in between Btrfs and physical device. Btrfs trusts the storage >> stack *less* than other file systems, by design. It's a kind of canary >> in the coal mine. Other file systems assume the storage stack is >> working, so they're less likely to complain. Only recent versions of >> e2fsprogs will format ext4 using metadata checksumming enabled. The >> kind of problems you're reporting look so bad and happen so fast I'd >> expect a good chance you'd reproduce the same problem with any >> metadata checksumming file system, if you have new enough progs to >> enable them. > > I removed luks encryption and had the same btrfs errors after several > GB of writes. Then I reformatted drive to ext4 and was able to save > 60GB without hiccups. Of course, you may be right that ext4 silently > damages my data, but at least I was able to see it on the drive after > remount/reboot. BTW, still the same USB related error when the write to btrfs fails? Or just plain btrfs errors without any other USB/block layer related error messages? > I'm beginning to think that my Pi draws more power when used with > external drive (I used only pendrives so far) so I need to investigate > for power issues. That also looks promising. But since it's a USB hdd, what about try it with regular PC? IIRC, if you can prove that the same disk work fine with PC (even with the same kernel version), then it's obvious who is to blame. > And also I need to figure out how to get newer kernel. Raspbian is not > the freshest distro... > Just as mentioned, Archlinux ARM has the latest kernel. But it's a pain in the ass to setup, especially when RPI4 is not officially supported, you have to go through something even harder than regular Archlinux insitallation procedure. Another recommendation is Manjaro ARM, which has just slightly older kernels, but much easier to use I guess. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
