pon., 3 lut 2020 o 00:34 Zygo Blaxell <ce3g8jdj@xxxxxxxxxxxxxxxxxxxxx> napisał(a): > > Same here, except I have seen problems as well as successes. Some hints: > > The log is incomplete but there is some evidence of USB disconnects. > These are bad. Fix those before you try to use this hardware to store > data. Yeah, I found out some errors in dmesg suggesting this: [ 370.569700] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 428.820969] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 473.621875] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 618.254211] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd [ 664.334958] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd > Disable write caching (hdparm -W0). The worst case is a USB disconnect > while there are uncompleted writes still in the drive memory. Filesystems > get severely damaged when that happens. Most filesystems silently > corrupt your data when that happens. If write cache is disabled (and > the USB-SATA bridge firmware isn't garbage) then a disconnect doesn't > do as much damage and most filesystems can recover from it. btrfs is > very good at batching up writes so write caching does not contribute > significantly to performance. Thanks for the tip - will try this. > Cables can be a near-bottomless source of problems, because a bad > cable will trigger USB disconnects. I find that a USB data cable will > work for a certain number of connections and disconnections, and once > that number is exceeded the cable is garbage and should be recycled. > For cheaper cables that number can be as low as 5. Some even fail on > the first connection. The disk is brand new so I don't expect that cable is broken. I tested the drive under windows and it was working OK. > Some USB->SATA bridge firmwares are broken, just swap it out with a > different model and it'll be fine (though it may be difficult to do this > with a WD Passport drive without taking the drive apart and placing the > drive in a generic USB drive enclosure). It is not possible to tell > what board revision or chip/firmware revision is used from the outside, > you have to open the drive and look at the USB-SATA bridge electronics. > Sometimes you can buy two of the same model USB-SATA bridges from > the same shop on the same day and the boards (and bugs) are completely > different inside. You may find one drive mysteriously works and another > "identical" drive does not. Yeah, WD Passport Drives are using USB-SATA. I will experiment a bit more with that. > If the drive disconnects, umount it before reconnecting. Disable any > configuration settings that might try to hide a USB device disconnection > from the upper storage layers. btrfs normally detects this and sets > itself read-only, but if somehow that doesn't happen, the filesystem will > be destroyed because part of the commit history will be missing on disk. > On RAID1 arrays of USB devices it's more complicated, you need to run > replace or scrub on the disk that disconnected to reconstruct the > missing data from drives that didn't disconnect. > > Once you've purged your setup of broken firmware and cables, it can run > for years without incident. > > 4.19 doesn't have metadata-corrupting bugs that I know of. > > I would be wary of 32-bit ARM. btrfs is most tested on amd64, and > other architectures sometimes have problems that amd64 simply does not, > especially on large (8T+) filesystems where uint32 isn't enough for a > device address. That said, I have a dozen Raspberry Pis on 5.0.21 and > haven't encountered issues other than the usual SD card failure every > few years--but the largest filesystem on these is 128GB. > > Also watch out for weak power supplies on Raspberry Pi boards. The CPU > and memory run at a significantly lower voltage than the USB interface, > and one symptom of a power supply that is too small or too old is that > all the USB devices stop working reliably. Yeah, I need to check if my Pi is not having power issues under heavy load (save data on encrypted partition). > > The only time I lost a filesystem whas when I got hit by the infamous > > 5.2 bug, and it was on a classical laptop, not on a pi... > > > > Kind regards. > > Best regards
