Btrfs not well suited for usb drive

Having opted to utilise the TO’s eMMC partition only as emergency fall-back I was left with two choices to run the OS off:

  • an interior SSD, or
  • an interior USB drive

Since u-boot as currently implemented has GPT not enabled and not wanting to partition the SSD with legacy MBR I was left with the USB drive option, also requiring an adapter to host the USB drive.

That said and having deployed this

usb drive
Bus 001 Device 002: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x090c Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)
  idProduct          0x1000 Flash Drive
  bcdDevice           11.00
  iManufacturer           1 SMI Technology
  iProduct                2 Intenso Micro Line
  iSerial                 3 19041700008101
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval             255
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval             255

I have noticed that with prolonged, and quite extensive read/write operations due to frequent updates/rollbacks in the TOS developments branches, the disk I/O operations turned increasingly sluggish and at some point the node would fail to boot entirely.

Having searched the public domain it would appear that BTRFS and USB drives are not a particular good match in light of:

  • BTRFS’s metadata (superblock) operations
  • (cheap) USB hardware implementations

If the boot fails there is no way to revive the node other than via UART serial cable and restore to the default boot environment - that being the eMMC partition. From there then I reformatted the USB partition and restored a previously exported snapshot.

IIRC the ssd_spread option should improve these cases, but I have no idea if the difference is significant.

Just out of curiosity - do you have more than 4 partitions and don’t want to use logical ones or is this disk larger than 2TB or did you consider data integrity reasons?

Yes


That too, legacy MBR is know for performance/integrity issues. But I would appreciate if this thread is not not turned into a discussion of MBR vs. GPT.


Thanks for the tip but I am not sure whether/how u-boot implements such option.

I don’t think you need it during boot itself; I expect it’s enough to have it when doing (most of) the writing.

It seems to be mount option, reading from the link you cited

Mount -o ssd_spread

and since u-boot is mounting the partition it would have to be set somewhere in the env variables, if such is provided indeed.

Notwithstanding, it seems to be pertinent to mounting a SSD but not an USB drive.

Maybe btrfs scrub will alleviate the issue, considering[1]

The user is supposed to run it manually or via a periodic system service. The recommended period is a month but could be less.


[1] https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub