SD cards for Pinebook Pro

[Arglebargle]

I bought a bunch of cards that meet the A1 standard (the new standard to help qualify the speed of SD cards for use as Android auxiliary storage).

It made a big difference for me although I can only speak anecdotally. Anyhow using my Debian installer to these new A1 cards just feel snappy and comfortable. When I used one of my older class 10/UHS-1 cards it was very obviously much slower to complete the install process (and running a debootstrap from scratch was downright sluggish).

The workload the PBP is likely to put on SD cards is likely to be similar to Android (or at least more like Android than a camera) so using the A1/A2 standard makes sense to me.

Like you mentioned IOPS are the most important metric for flash storage on an SBC containing a Linux root filesystem. You really aren't going to be doing that many large sequential transfers, and the SD reader on most SBCs is capped at 50MB/s, so speeds above 50MB/s are basically meaningless. I look at 4k IOPS almost exclusively when I'm spec'ing SD cards for Linux systems.

@bcnaz --

I've been using Sandisk A1/A2 cards for the last couple of years on all of my linux SBCs with pretty good results. I bought a handful of random A1 cards from Amazon for $8-9/ea to test against the Sandisk/Samsung I usually use  and spent an hour benching them last month: https://gist.github.com/foundObjects/c02...09b555a9e6

tl;dr - If you can find Sandisk A1 Extreme cards from around 2017 they're the best performers. Sandisk A2 Extreme and Samsung EVO cards are solid as well.

I've spent the last couple of years tinkering with improving disk io on all of my SBCs and here are the things I've found that have the biggest impact:

• Mount everything noatime, this will chop out a significant chunk of metadata io load. Small frequent writes are the worst-case io load for sd cards.
  
• Set a decently long commit interval for all of your filesystems, something between 3 and 10 minutes. This will cause transient io operations to complete in the filesystem cache rather than making multiple small updates to the media.
  
• If possible use a filesystem with transparent compression; this can drastically reduce real io on flash media and net a significant speed boost on highly compressible data. I run ZFS or btrfs with lz4/lzo/zstd on all of my flash nand machines.
  
• I also put heavily used compressible data like swap and /var/log on zram. Mounts like /var/log work really well with a combination of zram, overlayfs, overlayfs-tools to commit data from the upper to the lower and systemd timers to do the commit work behind the scenes when needed. tmpfs is even better if you have a lot of ram, but most SBCs don't.
  

FWIW I run all of my SBCs on battery backup power so I can get away with a lot of caching tricks that would otherwise be risky. Fortunately the PBP has a built in UPS so everything above is pretty safe, just try not to crash your kernel unexpectedly.

ZFS and btrfs have some performance costs vs ext4, if snapshots don't matter to you it might be worth looking into LVM/VDO for transparent compression. I haven't done that, for me snapshots and send/receive outweigh the small performance cost.

Those read and write speeds are only under ideal conditions, in other words, reading and writing large files.
When you use a micro SD as boot device, IOPS (input/output operations per second) will become more important.
And as danielt mentions, you still can notice the difference in IOPS.

Update: Would be nice when exFAT will be included in the standard image.

Try this: https://github.com/barrybingo/exfat-nofuse with dkms.

https://github.com/ayufan-rock64/linux-b...fat-nofuse