Re: My first attempt to use btrfs failed miserably

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

[-- Attachment #1: Type: text/plain, Size: 4108 bytes --]

On Sun, Feb 02, 2020 at 03:45:00PM +0100, Swâmi Petaramesh wrote:
> Le 02/02/2020 à 13:45, Skibbi a écrit :
> > So I decided to try btrfs on my new portable WD Password Drive
> > attached to Raspberry Pi 4. I created GPT partition, created luks2
> > volume and formatted it with btrfs. Then I created 3 subvolumes and
> > started copying data from other disks to one of the subvolumes. After
> > writing around 40GB of data my filesystem crashed. That was super fast
> > and totally discouraged me from next attempts to use btrfs :(
> 
> For what it's worth, I've been using BTRFS for 5+ *years* on removable,
> encrypted hard disks, and use them daily on Raspberry Pis with 4.19
> kernels and *never* hit a single problem.

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.

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.

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.

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.

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.

> 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.
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]