How can microSD flash memory wear be minimized?

(Tim Everitt) #41

Hi @Nordrunner, for clarity, here is what I use and what it looks like:

RPi 3 model B+ and SANDisk microSD card (GBP£14 on Amazon) per photo.


Latest Raspbian stretch lite ISO image is flashed onto the microSD card using dd. On firstboot the system automatically resizes the Linux partition to fill all the available space. The result is:

$ sudo fdisk --list /dev/mmcblk0
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x04c9550d

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 96663 88472 43.2M c W95 FAT32 (LBA)
/dev/mmcblk0p2 98304 124735487 124637184 59.4G 83 Linux

$ sudo df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 61341180 1220716 57596328 3% /

/dev/mmcblk0p1 43539 22498 21042 52% /boot


No further changes to disk/partition layout, types, etc.

This is very simple to implement and, in my experience, this is a very reliable long-term with moderate write rates. I like simple.


That’s a very interesting price for 64GB.
Do you know what it’s performance is in 4K random and sequential reads and writes?

Results of the Sandisk Ultra 64GB are not included here unfortunately:


(Tim Everitt) #44

Hi @bluejedi, I have not done performance tests.

I can report that the dd command to write the 1.86GBytes Raspbian stretch lite ISO image to the microSD card on a CentOS 7 laptop system takes 62 seconds which looks like 30MBytes per second. The microSD card was in an elago microSD/USB adapter so it appeared on the laptop as /dev/sdb. I don’t follow performance metrics but that looks fast compared to the metrics in the list from your post.


Hi @cultsdotelecomatgmai,

Performing the dd write on a SD card in a microSD/USB adapter on a laptop makes a significant difference with doing the same test with the same SD card in the SD slot on a Raspberry Pi so these will not make a reliable comparison.

The dd write test performs sequential writes of large files, but much more representative for the operational performance are the 4k random reads and writes. A high throughput for sequential writes does not automatically imply a high throughput for 4k random reads and writes (and vice versa). A good example is the Samsung Evo+ 32GB in the list which shines in 4k random reads/writes but not in sequential writes.

(Bobbie Mac) #46

I don’t think USB sticks have wear-leveling.



RPI3 boot from an (old) SSD with the help of this cable

* excuses… a little bit off topic :roll_eyes: