jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24129
Joined: Sat Jul 30, 2011 7:41 pm

Re: High Endurance SD card

Wed Sep 05, 2018 9:13 am

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
maximelebled
Posts: 8
Joined: Sun Mar 04, 2018 2:08 am

Re: High Endurance SD card

Thu Sep 06, 2018 8:51 am

ejolson wrote:
Thu Jan 11, 2018 4:31 am
Morphy99 wrote:
Wed Jan 10, 2018 11:46 pm
however Sandisk aren't honouring this now as its been used as a boot device and it's not designed for that
Using an SD card in a Raspberry Pi voids the warranties from many manufacturers, not just Sandisk. With all the Raspberry Pi computers sold, there should be a market for cards designed to be used as storage in single-board computers. As far as I know, no major manufacturer has marketed such a card. I suspect a number of people would be willing to spend extra on a card with a warranty that covered use in the Raspberry Pi. Therefore, this might be an area where a small company could establish a reputable business. Right now the best solution from a warranty point of view might be to use a SATA SSD connected through a USB adapter.
I have been doing exactly this with an entry-level Kingston A400 SSD that has a capacity of 220 GB, inside a USB-SATA adapter. I would highly recommend that kind of setup. It was 75€ total, but definitely worth it as 220 GB on a SD card would be a fair bit more expensive and much slower (and less reliable).

glenneroo
Posts: 3
Joined: Tue May 29, 2018 10:30 pm

Re: High Endurance SD card

Sat Sep 08, 2018 5:20 pm

maximelebled wrote:
Thu Sep 06, 2018 8:51 am
ejolson wrote:
Thu Jan 11, 2018 4:31 am
Morphy99 wrote:
Wed Jan 10, 2018 11:46 pm
however Sandisk aren't honouring this now as its been used as a boot device and it's not designed for that
Using an SD card in a Raspberry Pi voids the warranties from many manufacturers, not just Sandisk. With all the Raspberry Pi computers sold, there should be a market for cards designed to be used as storage in single-board computers. As far as I know, no major manufacturer has marketed such a card. I suspect a number of people would be willing to spend extra on a card with a warranty that covered use in the Raspberry Pi. Therefore, this might be an area where a small company could establish a reputable business. Right now the best solution from a warranty point of view might be to use a SATA SSD connected through a USB adapter.
I have been doing exactly this with an entry-level Kingston A400 SSD that has a capacity of 220 GB, inside a USB-SATA adapter. I would highly recommend that kind of setup. It was 75€ total, but definitely worth it as 220 GB on a SD card would be a fair bit more expensive and much slower (and less reliable).
How are the speeds with the SSD vs a decent microSD? I'd guess you are saturating USB2 easily but avoiding spinning disks is a huge win. 220GB is a lot of space... 120GB variant goes for 30€ here and would probably be sufficient for many use cases... now I wish I had bought a bunch of those instead of the industrial cards for this last project :( The only drawback I see is the size for ultra compact projects.

chwe
Posts: 128
Joined: Tue Jul 31, 2018 1:35 pm

Re: High Endurance SD card

Sun Sep 09, 2018 11:12 pm

runboy93 wrote:
Sun May 28, 2017 1:59 pm
"SDSQXCG-032G-GN6MA", might be best MicroSD card available and cost around 30€ (but RPi maybe doesn't support A1 standard, so might be same as earlier versions)
A1 has nothing to do with some 'special mode'. There's DDR50 mode (what the RPi is capable of doing it) or UHS104 aka SDR104 mode (1.8V) which the RPi isn't capable... In terms of A1 cards, they also perform better in DDR50 mode, no matter if the interface is capable of maxing the speed out.. See: https://www.raspberrypi.org/forums/view ... 4#p1358694
strawberry wrote:
Sun May 07, 2017 8:19 am
Well i have a Sandisk 64GB I didn't buy it on Ebay and is in my Pi for about 2 years running 24/7. Last week I wanted to create a backup before upgrading the system. I can read the data until +/- 3.8GB then I get an I/O error...
as expected.. running systems normally don't crash.. the reboot is the part where you mostly see that you've file corruption. Or during an update, when files are accessed which weren't during normal usage..
fruitoftheloom wrote:
Sun May 07, 2017 8:42 am
If you own a Raspberry Pi 2B V1.2 or 3B then boot from a USB SSD Drive :D

https://www.scan.co.uk/products/128gb-v ... b-30-super
and waste a lot of money for more or less no gain... There are SBCs where a SSD makes sense, the RPi isn't one of them...
Morphy99 wrote:
Wed Jan 10, 2018 11:46 pm
I've been using Sandisk Ultrafit USB sticks as the main boot device and had a couple brick on me after a few months. They come with a 3 year warranty which I claimed on one successfully however Sandisk aren't honouring this now as its been used as a boot device and it's not designed for that?? Would like to know what they suggest as they also mention cards are not supported under warranty for this application!
Likely that they think you share data on it, not running some os with a bunch of little junk writing every x seconds.. You can even force this by running multiple torrent jobs with seeding on it.. ;) That's not what those sticks are made for..
Paul Hutch wrote:
Tue Jan 30, 2018 2:34 pm
This high endurance card also gives guaranteed operation down to -25°C.
https://www.bhphotovideo.com/c/product/ ... video.html
https://en.wikipedia.org/wiki/Tin_pest

Likely that your RPi won't survive it..

What others do:
[*] zram instead of swap (no idea if raspian uses zram)
[*] log2ram
[*] defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1

all of this should reduce the writings to sd card as much as possible, the less it gets accessed or written to it, the longer it should be in a good shape.. With some drawbacks in case your board isn't properly shut down often..

Buy cards which are bigger than they should be.. So that the card is never full, buy quality cards and not random crap (e.g. A1 from SanDisk perform well) test them before you use it with h2testw or f3.

Heater
Posts: 13877
Joined: Tue Jul 17, 2012 3:02 pm

Re: High Endurance SD card

Mon Sep 10, 2018 5:54 am

If you really want to stop the file system you boot from to becoming corrupted in the face of random power outages and reboots you could make sure it is mounted as read-only. There are some nice instructions as to how to do that here: https://www.raspberrypi.org/forums/view ... p?t=161416
Memory in C++ is a leaky abstraction .

chwe
Posts: 128
Joined: Tue Jul 31, 2018 1:35 pm

Re: High Endurance SD card

Tue Sep 11, 2018 7:38 pm

Heater wrote:
Mon Sep 10, 2018 5:54 am
If you really want to stop the file system you boot from to becoming corrupted in the face of random power outages and reboots you could make sure it is mounted as read-only. There are some nice instructions as to how to do that here: https://www.raspberrypi.org/forums/view ... p?t=161416
well, with the drawback you'll face with a read-only rootfs, and that on a board which has anyway not much ram. IMO stop writing to the SD-card isn't needed. Good quality sd-cards with some tweaks and you never see it dieing.. I've an SBC (not a Raspberry) with these settings applied running ~15 web-crawlers to produce some sort of a personal news-feed.. Everything on one SD-Card (so the crawled garbage isn't stored on a separate one, only back-ups of it) since ~6 months without any problems on the filesystem. Debian on it gets updated weekly (including bootloader and kernel in case new ones are there), the board gets rebooted once a week too just to ensure everything works smoothly on it.

Heater
Posts: 13877
Joined: Tue Jul 17, 2012 3:02 pm

Re: High Endurance SD card

Tue Sep 11, 2018 11:45 pm

chwe,

Interesting anecdote.

Sadly there are contrary anecdotes of root file system corruption and SD card failure after random power downs and resets coming here all the time.

Hence my read-only root suggestion for robust operation and piece of mind.

Yes RAM is limited and that may impact what one can do on the Pi. Everyone has to evaluate that trade off for themselves.
Memory in C++ is a leaky abstraction .

User avatar
HawaiianPi
Posts: 4859
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: High Endurance SD card

Wed Sep 12, 2018 2:41 am

chwe wrote:
Sun Sep 09, 2018 11:12 pm
... and waste a lot of money for more or less no gain... There are SBCs where a SSD makes sense, the RPi isn't one of them...
It still makes sense on the Pi, as SSD has faster random I/O and higher IOPS, so even with the USB 2.0 limitation, it's still faster than micro SD.

There is no comparison between SSD and micro SD cards. An SSD is a far more advanced device with better NVRAM, more powerful controllers, and more sophisticated firmware, which makes SSD more robust than SD card storage, so they will last longer and are less likely to corrupt data. SD cards were never designed to be OS boot drives (which is why that use voids the warranty).

As for wasting money, it depends on storage requirements. For people who need 128GB or more, SSD may actually be cheaper (much cheaper in larger sizes). Some of my Pi computers boot from A1 rated micro SD cards, and others from SATA SSD with USB adapters.

Image

USB-SSD boot takes longer, but once the systems are up and running they feel more responsive. Compared to a standard class-10 micro SD card it's a pretty noticeable difference. A bit more subtle when compared to a good A1 rated card (I have Sandisk Ultra and Ultra Plus A1 rated cards).

I have only tried one "High Endurance" card, and it was very slow compared to an A1 card or USB SSD. Unless I was on a very tight budget, I'd use an SSD over HE micro SD card, or maybe a hard drive, depending on how much data needed to be written (and if performance wasn't a factor).
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

chwe
Posts: 128
Joined: Tue Jul 31, 2018 1:35 pm

Re: High Endurance SD card

Thu Sep 13, 2018 12:02 am

Heater wrote:
Tue Sep 11, 2018 11:45 pm
chwe,

Interesting anecdote.

Sadly there are contrary anecdotes of root file system corruption and SD card failure after random power downs and resets coming here all the time.

Hence my read-only root suggestion for robust operation and piece of mind.

Yes RAM is limited and that may impact what one can do on the Pi. Everyone has to evaluate that trade off for themselves.
for sure.. could be that I'm just lucky.. MIne works as expected.. others might have problems.. Maybe I got a good batch of an SD card here.. No idea.. I don't like the idea of read-only rootfs.. it just sounds not right for me.. (for others it might be exactly what they want). I would never say that everyone has to do the same than me.. I've a quadcore SBC with 256mb ram and it would still run the crawler without major issues with some drawbacks likely..
Did you ever test stuff like log2ram or played with zram? especially when you don't have that much ram (e.g. the Pi and most cheap boards) and doing some ram consuming stuff which would normally blow up your swap zram might help a lot.. ;) You definitively don't want swap on a SD-Card, even on the good ones.
HawaiianPi wrote:
Wed Sep 12, 2018 2:41 am
It still makes sense on the Pi, as SSD has faster random I/O and higher IOPS, so even with the USB 2.0 limitation, it's still faster than micro SD.

There is no comparison between SSD and micro SD cards. An SSD is a far more advanced device with better NVRAM, more powerful controllers, and more sophisticated firmware, which makes SSD more robust than SD card storage, so they will last longer and are less likely to corrupt data. SD cards were never designed to be OS boot drives (which is why that use voids the warranty).

As for wasting money, it depends on storage requirements. For people who need 128GB or more, SSD may actually be cheaper (much cheaper in larger sizes). Some of my Pi computers boot from A1 rated micro SD cards, and others from SATA SSD with USB adapters.

USB-SSD boot takes longer, but once the systems are up and running they feel more responsive. Compared to a standard class-10 micro SD card it's a pretty noticeable difference. A bit more subtle when compared to a good A1 rated card (I have Sandisk Ultra and Ultra Plus A1 rated cards).

I have only tried one "High Endurance" card, and it was very slow compared to an A1 card or USB SSD. Unless I was on a very tight budget, I'd use an SSD over HE micro SD card, or maybe a hard drive, depending on how much data needed to be written (and if performance wasn't a factor).
There's no question that an SSD is the better storage for an OS than any SD card, it's just a question of worthiness. A good SSD and usb-sata bridge costs you ~100$.. Doesn't sound sane if you combine this with a 35$ board.
I'll never agree with you that an RPi with SSD makes sense.. :lol: SSD together with a powerful SBC well, different story. Similar as for SD-Cards I only buy known good SSDs (e.g. Samsung evo).. If I spend 90$ for an SSD I may spend 19$ more for an SBC with a known good SATA-USB bridge a giant heatsink which also acts as a case (for the SSD and the SoC) and sufficient powering and 2GB ram... (If you know other SBCs you probably know which one I mean but promoting other SBCs here isn't my job :lol: ).
The combination of a powerful SSD together with RPis rather slow interfaces just doesn't make sense for me. Towards boottime, I really don't care.. reboots are done during night and my scripts are mostly in rc.local and/or with crontabs. The interesting stuff is delivered either via webinterface (e.g. node-red for IoT stuff, nginx together with Django/plain HTML or for the NAS I use OMV due to simple user management) or tiny SPI displays (I don't use HDMI on all my SBCs at all, reduces once more the overhead for stuff I don't need) for all this stuff the RPi is IMO just not the right board to do the job, e.g. for small lightweight IoT headless servers there are cheaper ones which perform at least similar or even better and for my NAS I want real GbE together with storage which is capable of saturating GbE.
For my use-cases RPis are used for camera related stuff. There's only one SBC I know which would probably outperform the RPi on this field but its ISP driver is a bit picky and prone to crash the kernel at boot, the userspace software needs some manual work to bring it up. The stock ISP driver provided with its stock OS is pure garbage. By using it I would need to compile my own kernel everytime I want to update it, that's not handy for a lazy guy like me.. :D - I did it, it worked but I don't compile new kernels on a weekly basis just to get a slightly better performing camera as I could get out of a 35$ SBC which does a good job here.. Similar to that I would never bottleneck a samsung EVO SSD with a shared USB as you find it on the Pi.
But as said, everyone is free to decide whatever s/he find fits best for her/him. For the RPi you find for more or less everything you need a step by step procedure how to set up things. That makes it easy when you start but sometimes it makes more sense to build something on your own (e.g. there are a bunch of outdated/bad tutorials out there and setting up an own nginx isn't that hard once you realized how this stuff works... even compiling your own kernel isn't that hard as soon as you did it more than once).

ejolson
Posts: 3806
Joined: Tue Mar 18, 2014 11:47 am

Re: High Endurance SD card

Thu Sep 13, 2018 1:39 am

chwe wrote:
Thu Sep 13, 2018 12:02 am
But as said, everyone is free to decide whatever s/he find fits best for her/him.
Where I live the price of a 120 GB SATA III SSD is about the same as a 128 GB SD card. Assuming the USB to SATA converter is not expensive, then cost is not a distinguishing factor between the two options.

On the other hand, the SSD is heavier, so it's better not to send it up in a balloon. For the same reasons, the SSD is less likely to get lost when you sneeze. I have no idea about other reliability and performance trade offs.

User avatar
Gavinmc42
Posts: 4031
Joined: Wed Aug 28, 2013 3:31 am

Re: High Endurance SD card

Thu Sep 13, 2018 2:55 am

I now use A1 rated cards for Raspbian and Gentoo64 but for 24/7 Pi's I use PiCore Linux as it reads the OS into ram and runs from that.
For baremetal Pi gadgets I have less need for massive memory and I prefer smaller sized SLC cards.

The higher capacity cards have less rewrite cycles and cost much more.
SSD would make more sense 64GB and above, even 16-32GB USB stick?
But that goes though the Pi's USB2 port.
Would a SMI parallel interface be better? IDE Compact flash style?

I'm hoping something like NanoRAM shows up in time for Pi4.
Boot from small read only SLC SD card, everything else in SSD?

I would not trust 64GB SDcards yet, that's a lot of money.
Not sure why you need 64GB in a Pi? That's a lot of expensive eggs in a very small, cheap basket.
And Sandisk is known for being cloned, bigger is not always better.
Small SD and network storage?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Heater
Posts: 13877
Joined: Tue Jul 17, 2012 3:02 pm

Re: High Endurance SD card

Thu Sep 13, 2018 4:33 am

Am I to understands that PiCore loads a roof file system image into some kind of "RAM disk" and then boots itself from that?

Isn't that rather wasteful of RAM space?

When running a read-only root Raspbian system everything boots more or less as normal except you can't write back to the root fs on SD (or where ever). There is an overlay file system that shadows the root fs such that if you do write back to root the changes are kept in RAM only.

Isn't that more efficient in terms of RAM usage?
Memory in C++ is a leaky abstraction .

ejolson
Posts: 3806
Joined: Tue Mar 18, 2014 11:47 am

Re: High Endurance SD card

Thu Sep 13, 2018 6:17 am

Heater wrote:
Thu Sep 13, 2018 4:33 am
Am I to understands that PiCore loads a roof file system image into some kind of "RAM disk" and then boots itself from that?
I think PiCore allows you to pull the SD card out after it boots so you can use the built-in SD card slot for other things. For example, it should be possible to format a new card with a standard Raspbian boot image using the built-in SD card slot while running PiCore. This could be useful when lost on a desert island where there is WiFi but no external card readers.

Heater
Posts: 13877
Joined: Tue Jul 17, 2012 3:02 pm

Re: High Endurance SD card

Thu Sep 13, 2018 6:32 am

I hate it when that happens. Being lost on a desert island where there is WiFi but no external card readers is a real pain.

Must remember to take PiCore with me on my travels.
Memory in C++ is a leaky abstraction .

User avatar
HawaiianPi
Posts: 4859
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: High Endurance SD card

Thu Sep 13, 2018 12:51 pm

Heater wrote:
Thu Sep 13, 2018 6:32 am
I hate it when that happens...
Well if you have your phone, you could use that app that makes Raspberry Pi SD cards, at least until your battery goes dead... :P :lol:
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

chwe
Posts: 128
Joined: Tue Jul 31, 2018 1:35 pm

Re: High Endurance SD card

Thu Sep 13, 2018 2:15 pm

ejolson wrote:
Thu Sep 13, 2018 1:39 am
Where I live the price of a 120 GB SATA III SSD is about the same as a 128 GB SD card. Assuming the USB to SATA converter is not expensive, then cost is not a distinguishing factor between the two options.

On the other hand, the SSD is heavier, so it's better not to send it up in a balloon. For the same reasons, the SSD is less likely to get lost when you sneeze. I have no idea about other reliability and performance trade offs.
well, cheap crappy SSDs from 'untrusted' sources are in the same price range.. But I'd rather spend my money in known good ones, they aren't often that cheap. And to be honest.. all my SBCs run with 16 or 32gb SD cards, I don't need that much space.. My nas has spinning rust inside to keep the price acceptable (saturates GbE for large files, and for the small stuff I don't care, OS is on a 16GB SanDisk A1)...

Gavinmc42 wrote:
Thu Sep 13, 2018 2:55 am
And Sandisk is known for being cloned, bigger is not always better.
Small SD and network storage?
that's why you test your card prior to run production stuff on it.. :P e.g. F3/h2testw and IOzone (fake cards often show up with either corrupted sectors and/or bad randomIO performance, if a card doesn't comes near to the 1500 IOPS it should for A1 cards --> back to seller)...

I fully agree that SSD is 'more advanced' than stupid SD-Cards, I just don't see a reason to combine this with a RPi. Different story when we talk about something more advanced like a RK3399 based SBC. Some might prefer read only rootfs, I prefer a 'normal rootfs' but settings which avoid writing to SD-Card whenever possible as discussed above.. Depends on your preferences and your knowledge to play with such settings.

User avatar
maximelebled
Posts: 8
Joined: Sun Mar 04, 2018 2:08 am

Re: High Endurance SD card

Sat Sep 15, 2018 9:32 pm

ejolson wrote:
Thu Sep 13, 2018 1:39 am
chwe wrote:
Thu Sep 13, 2018 12:02 am
But as said, everyone is free to decide whatever s/he find fits best for her/him.
Where I live the price of a 120 GB SATA III SSD is about the same as a 128 GB SD card. Assuming the USB to SATA converter is not expensive, then cost is not a distinguishing factor between the two options.

On the other hand, the SSD is heavier, so it's better not to send it up in a balloon. For the same reasons, the SSD is less likely to get lost when you sneeze. I have no idea about other reliability and performance trade offs.
Yeah. Like I said earlier a Kingston 220GB SSD coupled with a USB to SATA adapter-case (an "UGREEN" one) cost me 75€ total. The price of that particular SSD has gone down since—by 25€!—but let's assume prices when I bought my stuff.

A 256GB Samsung EVO card is 70€ on Amazon in my country.

That's 5€ more for much more reliability and speed.

Coupling a SSD with a Pi is absolutely not as "nonsensical" as it might sound at first!
Last edited by maximelebled on Sat Sep 15, 2018 9:44 pm, edited 1 time in total.

Heater
Posts: 13877
Joined: Tue Jul 17, 2012 3:02 pm

Re: High Endurance SD card

Sat Sep 15, 2018 9:41 pm

I'd like to question the whole concept of "High Endurance" SD card or any other storage media for that matter.

Sure we would like our storage media to be as robust and long lived as possible. But the reality has been, since forever, that storage media has been the most unreliable part of computing.

Perhaps "High Endurance" means that on average it will work ten times longer than "Low Endurance". However one defines those terms.

That does not really help much. It will fail. You need to be prepared for that no matter what you use.
Memory in C++ is a leaky abstraction .

User avatar
ab1jx
Posts: 868
Joined: Thu Sep 26, 2013 1:54 pm
Location: Heath, MA USA
Contact: Website

Re: High Endurance SD card

Wed Mar 27, 2019 1:27 am

I just pre-ordered a 128 GB Sandisk High Endurance at $29.22 https://www.bhphotovideo.com/bnh/contro ... 563&is=REG Sandisk only has up to 64 GB in high endurance so far. But you can also pre-order a 256 GB for $69.95, click on the box at the bottom.

I've been buying mostly the high endurance for a year or so, because if the regular SDs aren't made for frequent writes, especially to the point of voiding the warranty, at least the high endurance is a step in the right direction. I haven't seen one fail yet.

Code: Select all

128GB Storage Capacity
UHS-I / V30 / U3 / Class 10
Max Read Speed: 100 MB/s
Max Write Speed: 40 MB/s

User avatar
shodan_x
Posts: 2
Joined: Fri Apr 19, 2019 5:50 am
Location: Tula, Russia
Contact: Website

Re: High Endurance SD card

Fri Apr 19, 2019 6:12 am

I try Samsung PRO Endurance microSDHC 32 GB [MB-MJ32GA/RU]
It work's fine with Raspberry Pi Zero W.

Samsung tells: up to 17,520 hours (or 2 years) of Full HD recording * Based on Full HD (1920x1080) video content recorded at 26 Mbps Video support.
It means: 26 Mbps / 8bit * 60 sec * 60 min * 17520 hours = 204 984 000 Mbytes total write
204 984 000 Mbytes / 32 000 Mbytes full capacity = 6.4K write per cell.
I think it is MLC flash.

Test result:
Sequential READ speed with big blocks

Code: Select all

# fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
TEST: (g=0): rw=read, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [R(1)] [11.7% done] [22550KB/0KB/0KB /s] [22/0/0 iops] [eta 00m:53s]
Jobs: 1 (f=1): [R(1)] [21.7% done] [22550KB/0KB/0KB /s] [22/0/0 iops] [eta 00m:47s]
Jobs: 1 (f=1): [R(1)] [31.7% done] [22528KB/0KB/0KB /s] [22/0/0 iops] [eta 00m:41s]
Jobs: 1 (f=1): [R(1)] [41.7% done] [22550KB/0KB/0KB /s] [22/0/0 iops] [eta 00m:35s]
Jobs: 1 (f=1): [R(1)] [51.7% done] [22528KB/0KB/0KB /s] [22/0/0 iops] [eta 00m:29s]
Jobs: 1 (f=1): [R(1)] [61.7% done] [23575KB/0KB/0KB /s] [23/0/0 iops] [eta 00m:23s]
Jobs: 1 (f=1): [R(1)] [71.7% done] [23575KB/0KB/0KB /s] [23/0/0 iops] [eta 00m:17s]
Jobs: 1 (f=1): [R(1)] [81.7% done] [23575KB/0KB/0KB /s] [23/0/0 iops] [eta 00m:11s]
Jobs: 1 (f=1): [R(1)] [91.7% done] [23575KB/0KB/0KB /s] [23/0/0 iops] [eta 00m:05s]
Jobs: 1 (f=1): [R(1)] [13.1% done] [6150KB/0KB/0KB /s] [6/0/0 iops] [eta 06m:44s]
TEST: (groupid=0, jobs=1): err= 0: pid=8502: Fri Apr 19 08:58:42 2019
  read : io=1372.0MB, bw=22872KB/s, iops=22, runt= 61425msec
    slat (usec): min=529, max=12653, avg=763.21, stdev=603.71
    clat (msec): min=45, max=2795, avg=1426.99, stdev=297.90
     lat (msec): min=46, max=2795, avg=1427.75, stdev=297.75
    clat percentiles (msec):
     |  1.00th=[  223],  5.00th=[ 1012], 10.00th=[ 1434], 20.00th=[ 1434],
     | 30.00th=[ 1434], 40.00th=[ 1434], 50.00th=[ 1434], 60.00th=[ 1434],
     | 70.00th=[ 1434], 80.00th=[ 1434], 90.00th=[ 1434], 95.00th=[ 1795],
     | 99.00th=[ 2606], 99.50th=[ 2704], 99.90th=[ 2769], 99.95th=[ 2802],
     | 99.99th=[ 2802]
    lat (msec) : 50=0.07%, 100=0.36%, 250=0.66%, 500=1.31%, 750=1.31%
    lat (msec) : 1000=1.24%, 2000=91.11%, >=2000=3.94%
  cpu          : usr=0.31%, sys=1.68%, ctx=1547, majf=0, minf=8213
  IO depths    : 1=0.2%, 2=0.4%, 4=0.9%, 8=1.7%, 16=3.5%, 32=93.2%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=99.8%, 8=0.0%, 16=0.0%, 32=0.2%, 64=0.0%, >=64=0.0%
     issued    : total=r=1372/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
   READ: io=1372.0MB, aggrb=22872KB/s, minb=22872KB/s, maxb=22872KB/s, mint=61425msec, maxt=61425msec

Disk stats (read/write):
  mmcblk0: ios=2751/1, merge=31/1, ticks=3770860/1080, in_queue=3781400, util=100.00%
Sequential WRITE speed with big blocks

Code: Select all

# fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
TEST: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [W(1)] [11.7% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 00m:53s]
Jobs: 1 (f=1): [W(1)] [21.7% done] [0KB/47151KB/0KB /s] [0/46/0 iops] [eta 00m:47s]
Jobs: 1 (f=1): [W(1)] [31.7% done] [0KB/21525KB/0KB /s] [0/21/0 iops] [eta 00m:41s]
Jobs: 1 (f=1): [W(1)] [41.7% done] [0KB/21525KB/0KB /s] [0/21/0 iops] [eta 00m:35s]
Jobs: 1 (f=1): [W(1)] [51.7% done] [0KB/10250KB/0KB /s] [0/10/0 iops] [eta 00m:29s]
Jobs: 1 (f=1): [W(1)] [61.7% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 00m:23s]
Jobs: 1 (f=1): [W(1)] [71.7% done] [0KB/45101KB/0KB /s] [0/44/0 iops] [eta 00m:17s]
Jobs: 1 (f=1): [W(1)] [81.7% done] [0KB/21568KB/0KB /s] [0/21/0 iops] [eta 00m:11s]
Jobs: 1 (f=1): [W(1)] [91.7% done] [0KB/11275KB/0KB /s] [0/11/0 iops] [eta 00m:05s]
Jobs: 1 (f=1): [W(1)] [11.2% done] [0KB/8200KB/0KB /s] [0/8/0 iops] [eta 08m:04s]
TEST: (groupid=0, jobs=1): err= 0: pid=8511: Fri Apr 19 09:02:56 2019
  write: io=1176.0MB, bw=19584KB/s, iops=19, runt= 61491msec
    slat (usec): min=599, max=3019.3K, avg=18489.12, stdev=180958.64
    clat (msec): min=48, max=4742, avg=1651.02, stdev=900.42
     lat (msec): min=49, max=4746, avg=1669.51, stdev=888.93
    clat percentiles (msec):
     |  1.00th=[   90],  5.00th=[  243], 10.00th=[  465], 20.00th=[  857],
     | 30.00th=[ 1352], 40.00th=[ 1532], 50.00th=[ 1532], 60.00th=[ 1532],
     | 70.00th=[ 1958], 80.00th=[ 2376], 90.00th=[ 2868], 95.00th=[ 3458],
     | 99.00th=[ 4555], 99.50th=[ 4752], 99.90th=[ 4752], 99.95th=[ 4752],
     | 99.99th=[ 4752]
    lat (msec) : 50=0.60%, 100=1.28%, 250=3.15%, 500=5.78%, 750=5.27%
    lat (msec) : 1000=7.06%, 2000=48.13%, >=2000=28.74%
  cpu          : usr=0.44%, sys=1.39%, ctx=1020, majf=0, minf=21
  IO depths    : 1=0.3%, 2=0.5%, 4=1.0%, 8=2.0%, 16=4.1%, 32=92.1%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=99.7%, 8=0.0%, 16=0.0%, 32=0.3%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=1176/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: io=1176.0MB, aggrb=19583KB/s, minb=19583KB/s, maxb=19583KB/s, mint=61491msec, maxt=61491msec

Disk stats (read/write):
  mmcblk0: ios=0/2387, merge=0/26, ticks=0/3182870, in_queue=3187590, util=99.94%
Random 4K read QD1

Code: Select all

# fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
TEST: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [r(1)] [11.7% done] [3831KB/0KB/0KB /s] [957/0/0 iops] [eta 00m:53s]
Jobs: 1 (f=1): [r(1)] [21.7% done] [3871KB/0KB/0KB /s] [967/0/0 iops] [eta 00m:47s]
Jobs: 1 (f=1): [r(1)] [31.7% done] [3827KB/0KB/0KB /s] [956/0/0 iops] [eta 00m:41s]
Jobs: 1 (f=1): [r(1)] [41.7% done] [3871KB/0KB/0KB /s] [967/0/0 iops] [eta 00m:35s]
Jobs: 1 (f=1): [r(1)] [51.7% done] [3823KB/0KB/0KB /s] [955/0/0 iops] [eta 00m:29s]
Jobs: 1 (f=1): [r(1)] [61.7% done] [3871KB/0KB/0KB /s] [967/0/0 iops] [eta 00m:23s]
Jobs: 1 (f=1): [r(1)] [71.7% done] [3851KB/0KB/0KB /s] [962/0/0 iops] [eta 00m:17s]
Jobs: 1 (f=1): [r(1)] [81.7% done] [3983KB/0KB/0KB /s] [995/0/0 iops] [eta 00m:11s]
Jobs: 1 (f=1): [r(1)] [91.7% done] [3803KB/0KB/0KB /s] [950/0/0 iops] [eta 00m:05s]
Jobs: 1 (f=1): [r(1)] [100.0% done] [3867KB/0KB/0KB /s] [966/0/0 iops] [eta 00m:00s]
TEST: (groupid=0, jobs=1): err= 0: pid=8516: Fri Apr 19 09:04:07 2019
  read : io=231072KB, bw=3851.2KB/s, iops=962, runt= 60001msec
    slat (usec): min=220, max=7309, avg=300.93, stdev=111.08
    clat (usec): min=43, max=10863, avg=653.38, stdev=177.22
     lat (usec): min=738, max=11096, avg=954.30, stdev=202.51
    clat percentiles (usec):
     |  1.00th=[  438],  5.00th=[  510], 10.00th=[  516], 20.00th=[  532],
     | 30.00th=[  556], 40.00th=[  596], 50.00th=[  612], 60.00th=[  684],
     | 70.00th=[  740], 80.00th=[  756], 90.00th=[  796], 95.00th=[  868],
     | 99.00th=[  980], 99.50th=[ 1128], 99.90th=[ 2480], 99.95th=[ 3920],
     | 99.99th=[ 5984]
    lat (usec) : 50=0.14%, 100=0.01%, 250=0.02%, 500=3.18%, 750=72.81%
    lat (usec) : 1000=23.02%
    lat (msec) : 2=0.68%, 4=0.10%, 10=0.05%, 20=0.01%
  cpu          : usr=10.06%, sys=20.65%, ctx=117683, majf=0, minf=19
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=57768/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=231072KB, aggrb=3851KB/s, minb=3851KB/s, maxb=3851KB/s, mint=60001msec, maxt=60001msec

Disk stats (read/write):
  mmcblk0: ios=57555/9, merge=0/6, ticks=43600/10, in_queue=43250, util=72.38%
Mixed random 4K read and write QD1 with sync

Code: Select all

# fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
TEST: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [m(1)] [11.7% done] [544KB/520KB/0KB /s] [136/130/0 iops] [eta 00m:53s]
Jobs: 1 (f=1): [m(1)] [21.7% done] [472KB/408KB/0KB /s] [118/102/0 iops] [eta 00m:47s]
Jobs: 1 (f=1): [m(1)] [31.7% done] [432KB/400KB/0KB /s] [108/100/0 iops] [eta 00m:41s]
Jobs: 1 (f=1): [m(1)] [41.7% done] [356KB/364KB/0KB /s] [89/91/0 iops] [eta 00m:35s]
Jobs: 1 (f=1): [m(1)] [51.7% done] [412KB/432KB/0KB /s] [103/108/0 iops] [eta 00m:29s]
Jobs: 1 (f=1): [m(1)] [61.7% done] [208KB/252KB/0KB /s] [52/63/0 iops] [eta 00m:23s]
Jobs: 1 (f=1): [m(1)] [71.7% done] [16KB/12KB/0KB /s] [4/3/0 iops] [eta 00m:17s]
Jobs: 1 (f=1): [m(1)] [81.7% done] [20KB/16KB/0KB /s] [5/4/0 iops] [eta 00m:11s]
Jobs: 1 (f=1): [m(1)] [91.7% done] [8KB/8KB/0KB /s] [2/2/0 iops] [eta 00m:05s]
Jobs: 1 (f=1): [m(1)] [100.0% done] [448KB/460KB/0KB /s] [112/115/0 iops] [eta 00m:00s]
TEST: (groupid=0, jobs=1): err= 0: pid=8519: Fri Apr 19 09:05:49 2019
  read : io=14156KB, bw=241587B/s, iops=58, runt= 60002msec
    slat (usec): min=246, max=4757, avg=331.15, stdev=157.16
    clat (usec): min=44, max=5221, avg=837.66, stdev=299.21
     lat (usec): min=753, max=5533, avg=1168.81, stdev=322.74
    clat percentiles (usec):
     |  1.00th=[  466],  5.00th=[  548], 10.00th=[  588], 20.00th=[  692],
     | 30.00th=[  748], 40.00th=[  780], 50.00th=[  820], 60.00th=[  860],
     | 70.00th=[  924], 80.00th=[  972], 90.00th=[ 1020], 95.00th=[ 1048],
     | 99.00th=[ 1464], 99.50th=[ 2192], 99.90th=[ 4960], 99.95th=[ 5152],
     | 99.99th=[ 5216]
  write: io=14104KB, bw=240700B/s, iops=58, runt= 60002msec
    slat (usec): min=285, max=4742, avg=419.99, stdev=141.14
    clat (usec): min=47, max=665704, avg=5495.36, stdev=39337.68
     lat (msec): min=1, max=666, avg= 5.92, stdev=39.34
    clat percentiles (usec):
     |  1.00th=[ 1288],  5.00th=[ 1432], 10.00th=[ 1496], 20.00th=[ 1576],
     | 30.00th=[ 1640], 40.00th=[ 1704], 50.00th=[ 1768], 60.00th=[ 1832],
     | 70.00th=[ 1960], 80.00th=[ 2320], 90.00th=[ 4896], 95.00th=[ 7776],
     | 99.00th=[35072], 99.50th=[75264], 99.90th=[659456], 99.95th=[659456],
     | 99.99th=[667648]
    lat (usec) : 50=0.17%, 100=0.07%, 250=0.01%, 500=0.48%, 750=14.31%
    lat (usec) : 1000=28.24%
    lat (msec) : 2=42.42%, 4=8.99%, 10=3.09%, 20=0.28%, 50=1.61%
    lat (msec) : 100=0.10%, 250=0.04%, 500=0.01%, 750=0.17%
  cpu          : usr=1.54%, sys=4.08%, ctx=19834, majf=0, minf=21
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=3539/w=3526/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=14156KB, aggrb=235KB/s, minb=235KB/s, maxb=235KB/s, mint=60002msec, maxt=60002msec
  WRITE: io=14104KB, aggrb=235KB/s, minb=235KB/s, maxb=235KB/s, mint=60002msec, maxt=60002msec

Disk stats (read/write):
  mmcblk0: ios=3516/8779, merge=0/2637, ticks=4070/51320, in_queue=55300, util=92.56%

User avatar
shodan_x
Posts: 2
Joined: Fri Apr 19, 2019 5:50 am
Location: Tula, Russia
Contact: Website

Re: High Endurance SD card

Mon Jul 29, 2019 11:12 am

I've tested RPi 3B+ with SLC flash - Sandisk SDSDQED-008G-XI, it also work's fine
7dt0awdO4I4.jpg
7dt0awdO4I4.jpg (106.49 KiB) Viewed 848 times

wh7qq
Posts: 1345
Joined: Thu Oct 09, 2014 2:50 am

Re: High Endurance SD card

Mon Jul 29, 2019 9:40 pm

chwe wrote:
Sun Sep 09, 2018 11:12 pm
Buy cards which are bigger than they should be.. So that the card is never full, buy quality cards and not random crap (e.g. A1 from SanDisk perform well) test them before you use it with h2testw or f3.
I am not sure what all the fuss is about. I just have not seen much problem since my early efforts with small uSD cards on the B+. I can't recall the last time a card went south. I don't overclock and if I can, always use software "power off" before pulling the plug but that is frequently not possible with the headless RPi's I run. One headless unit just sits and waits for a "cron" instruction but the other is a pi-hole plugged into the router so that it is the DNS site for all our web requests. Not sure if it is a factor in longevity but this B+ is in a closed case with no sinks or fans and sits at 42.8 C. The zero W is open and sits at 39.0 C. Ambient here is a pretty steady 27 C

Been getting my uSD cards from Amazon...32G SanDisk Ultra A1. They work well in all my RPis including the B+, zero (all), 2B and 3B and failures are not a factor. One of the B+ and one of the Zeros (W) run headless 24/7 except for power failures which are frequent and random here...they just boot right up again when power comes back. I used to run "h2testw" on all as they came in but it just isn't worth it...all are fine. I am careful to buy only cards that are "sold and shipped by Amazon", as they seem to have a reliable supplier and they always send cards in their original factory packaging (definitely not frustration free but worth the trouble)

"h2testw" is a great utility and I suppose it is especially good if you consistently buy from auction house fly-by-night vendors. Use it before you try to load up your data and software to be sure the cards are as advertised.

Paul Hutch
Posts: 412
Joined: Fri Aug 25, 2017 2:58 pm
Location: Blackstone River Valley, MA, USA
Contact: Website

Re: High Endurance SD card

Tue Jul 30, 2019 7:11 pm

wh7qq wrote:
Mon Jul 29, 2019 9:40 pm
<snip>
I am careful to buy only cards that are "sold and shipped by Amazon", as they seem to have a reliable supplier and they always send cards in their original factory packaging (definitely not frustration free but worth the trouble)
<snip>
My employer just started working with Amazon this year and I found out that "Sold & Shipped by Amazon" means the manufacturer supplies the inventory direct to all Amazon warehouses, Amazon does the rest taking a large cut and charging storage fees if the inventory sits too long before selling. So it's a near absolute certainty that a Sandisk card bought from a page with the "Sold & Shipped by Amazon" label is the real deal.

Return to “General discussion”