SD cards for Pinebook Pro

[bcnaz]

  What is the most ideal speed for the Pinebook Pro SD cards  ?  ( without going needlessly over specification )
 
        I read the wiki as it being 50 mb,  would that be correct..?

        Thanks  !  BC

[Arwen]

  What is the most ideal speed for the Pinebook Pro SD cards  ?  ( without going needlessly over specification )
 
        I read the wiki as it being 50 mb,  would that be correct..?

        Thanks  !  BC

Wiki - Pinebook Pro - Expansion Ports - MicroSD cards

So yes, 50MB per second is the top the RK3399 can support.

A bit slow for an OS, but still usable.

[bcnaz]

So a 100 mb/sec sd card is plenty to run that

Thank you

[ElektromAn]

You can add this in your fstab

Code:

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

UUID=$ROOT-UUID /  ext4    defaults,noatime 0 1

This will not update atime on any file and refresh the inode (and do writes)

I use this for around 10 years without any issues in my git trees and build environment

Please change to your $ROOT-UUID

[Arwen]

In some ways, using this is slightly better;

Code:

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

UUID=$ROOT-UUID /  ext4    defaults,relatime 0 1

And it looks like this is the default behaviour when "noatime" is not used.

It basically makes sure that if a file is accessed after last modification, the access time must reflect that. But otherwise, access time is not updated every access, just the first after modification.

[danielt]

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.

[jiyong]

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.

[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

[ElektromAn]

AFAIR

extFAT is in mainline currently in staging
It's worth to mention, that ext4/btrfs and the world famous extFAT (shrugs)
are optimized for rotating rust.

There is some other filesystem, I'm currently looking at F2FS

F2FS is based on Log-structured File System (LFS), which supports
          versatile "flash-friendly" features. The design has been focused on
          addressing the fundamental issues in LFS, which are snowball effect
          of wandering tree and high cleaning overhead.

[z4v4l]

exFAT is optimized for flash storages, was developed for them and indeed is even a part of the SD standard, it's the FS, that should be used with SDXC cards. one should be advised to use it on every removable flash based device for their own comfort. F2FS would be slower for sure, and certainly is a "bye" to interoperability.