8 ms·

Raspberry Pi microSD card performance comparison

129 points by geerlingguy 7y ago

geerlingguy 7y ago
tl;dr: the Pi 4 has a much more rosy outlook when it comes to IO both for the microSD card and external drives. The Samsung Evo+ is still the best value for your money.
- Fnoord 7y ago
  Let me prefix saying I appreciated your writing. However you didn't test endurance. You only tested throughput (I/O). Throughput isn't the same as performance. Why call it performance? I had Raspberry Pi's fail from consumer grade microSD cards. Which sucks if its ~4 hrs of travel (one way). This hasn't happened with industrial grade yet. (I buy mine from DigiKey.) I'm curious about throughput differences with regards to filesystems. Two ideas for a follow-up.
  - geerlingguy 7y ago
    The 32GB card I have running in the Pi that often hosts www.pidramble.com has been running on a Pi 2, Pi 3, Pi 3 B+, and now Pi 4 for almost four years and has not had any corruption issues. I also have had a number of other Pis using the Samsung Evo+ and SanDisk extreme cards, many running for one to two years (some doing logging, others saving time-lapse pictures, uploading in batch to an FTP share, then saving more), and have also never encountered a corruption. I think it has a lot more to do with the power supply than the card itself (as long as you're using a SanDisk, Sony, Samsung, etc. and not some no-name card). I think the endurance cards have a little better caching mechanism built into the flash controller itself, so they can kind of paper over flaky power supply issues. So yes, it is definitely better to use endurance class cards. But in my experience, I have not encountered an issue using the typical consumer-grade cards.
- megous 7y ago
  It is not, it's pretty much equal to Sandisk Ultra A1 in performance. (not the same as the one tested in this test) You can get original 32GB Sandisk Ultra A1 for $4.30 (or $8 incl. shipping) on aliexpress. Evo+ is $8.60 (or $15.79 incl. shipping) on Amazon.
  - tristor 7y ago
    Do you trust a microSD card you've bought off Aliexpress? Because I wouldn't. It's questionable if you can even trust one purchased from Amazon, but buying off Aliexpress is next level skeezy. There are a vast amount of fake/counterfeit microSD cars on the marketplace, so this argument is pretty silly if you ask me.
    - megous 7y ago
      See above. https://news.ycombinator.com/item?id=20403155 https://news.ycombinator.com/item?id=20403155 I wouldn't write the comment if I wasn't 100% sure the cards were original. Yes, you can get original Sandisk cards from aliexpress for that price, and actually verify it on the manufacturer's website. You can't do that for Samsung.
- meatmanek 7y ago
  I'm surprised by the lack of mention of the A1/A2 "Application Performance Class"[1]. These classes specify minimum performance numbers for random reads and random writes: 1500/500 read/write for A1, 4000/2000 read/write for A2. Notably, the Amazon link for the Sandisk Extreme points to an A1 version, not the A2 version[2] 1. https://www.sdcard.org/developers/overview/application/index.html 2. https://smile.amazon.com/gp/product/B07FCMBLV6
  - jack12 7y ago
    My understanding is that A2 cards are generally slower than A1 cards IF you don't have host-side support for managing the volatile-RAM caching that A2 requires. So if the Pi 4 only allows you to run in A1 mode anyway, you're better off buying the A1 card and both saving money and getting a faster card. I don't know if that lack of support is true of the Pi 4, but it does seem to be true of most other SBCs according to https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md https://github.com/ThomasKaiser/Knowledge/blob/master/articl...
    - meatmanek 7y ago
      Ah, interesting, I did not realize there was a difference in protocol. I thought A1/A2 were just spec requirements. I wonder if A2 support is something that could be added in newer kernels, or whether it requires hardware support.
- cmurf 7y ago
  I've gone through three Samsung EVO sdcards in an Intel NUC. I was using it as a boot drive. All were replaced under warranty. But they each died, becoming read-only, within about 5 months of use. I don't think these cards are designed as random access devices. I think they're for cameras: video and photos, and also for cell phones, also mostly video and photos, maybe some app offloading also.
gjsman-1000 7y ago
Note to readers: The USB chip does run hot. This is getting fixed in a firmware update that you can test in the RPF Forum which reduces temps.
- gambiting 7y ago
  I wonder if that's the reason for somewhat patchy USB performance. when copying data between two USB HDDs the data goes at 40-50MB/s for a minute or two then drops down to like 500kb/s and then ramps up again after a while. When copying data the USB chip and the ports themselves get stupidly hot.
  - geerlingguy 7y ago
    Yeah... it surprised me that the VLI USB chip was much hotter than the processor even during CPU stress testing. Between that and the little power controller chip by the USB-C power supply port, the Pi 4 pretty much demands active cooling for any but the most mundane tasks.
dmm 7y ago
I wouldn't buy an sd card on amazon because of the risk of getting a fake. There are tons of fake sd cards out there and amazon refuses to take responsibility for their supply chain.
- delish 7y ago
  Where do you buy SD cards?
  - Fnoord 7y ago
    DigiKey
  - antongribok 7y ago
    MicroCenter. They price match Amazon, NewEgg, B&H, and lots of other places. A lot of times their prices are already lower than Amazon.
- snaky 7y ago
  Sandisk cards for domestic sale in China have 18-digit authenticity code on scratchpad, and you can verify it online at verify.sandisk.cn. So, "buy in China because there's too many fakes in US store". Ironic isn't it.
  - megous 7y ago
    I came here to say the same. :) I can attest that this works. I've checked these codes on several cards along with speed and full rewrite/compare tests, to verify capacity and A1 rating. Never had an issue.
    - snaky 7y ago
      I've checked a couple of fake Sundisk cards from Aliexpress as well, detected as fake as they should.
- bradenb 7y ago
  I'm sure there's a name for this effect, but I am always fascinated by the complaints about fake products on Amazon. I have _never_ received one and I spend several thousand on Amazon every year. I _know_ it must be happening, I just can't understand if I'm lucky, if it's an effect of my location, or somehow related to the way in which I shop on Amazon.
mgamache 7y ago
I know embedded systems were not the original purpose of the Raspberry Pi, but so many people are trying to use the pi for just that. I've wanted to use Rpi for that but the SD card failure rates are high. I know the high-end ones are a lot lower, but is it reliable enough? I am not sure. I was hopping for a SD card alternative for the Rpi 4, maybe it's booting from USB 3.0 when that ships?
- orev 7y ago
  You can get “industrial” SD cards that are rated for more severe environmental conditions and more write cycles. They are more expensive though, but probably worth it for commercial applications.
  - cwt137 7y ago
    You can also get "Endurance" SD cards. A lot of failures are due to too many writes. The endurance ones allow many more writes than the regular consumer cards
  - johnnycab 7y ago
    The 'industrial' microSD cards based on MLC or pSLC with controlled or frozen BoM only make sense if you are going to use a device in extreme settings[1]. In most instances, a card in rPi will serve as a boot device, unless someone reappropriates it into a Dashcam or something similar, which has heavy duty write cycles or continuously reads/writes to and from the card; it will be wise to choose something that strikes a balance. At a guess, the Samsung EVO family of consumer based cards, probably ranges between using TLC (older) to 2D or 3D V-NAND (newer). The more robust Pro series, which commands a premium, probably uses MLC or superior.[2] [1] https://www.swissbit.com/products/nand-flash-products/microsd-memory-cards/ https://www.swissbit.com/products/nand-flash-products/micros... [2] https://www.cactus-tech.com/resources/blog/details/slc-pslc-mlc-and-tlc-differences-does-your-flash-storage-ssd-make-the-grade/ https://www.cactus-tech.com/resources/blog/details/slc-pslc-...
    - monocasa 7y ago
k_sze 7y ago
I wonder if Pi 4 supports UASP (USB Attached SCSI Protocol). This may need everything from the VLI VL805-06 USB controller to the firmware to the driver to support it. A preliminary DDG search suggests that the controller probably supports it. My understanding is that, if UASP is supported, you can squeeze even more performance out of a SSD, and it will even properly support the TRIM command because then the SSD is no longer just a dumb USB mass storage device.
- geerlingguy 7y ago
  This would be interesting to check; I know there are few people on the Pi forums exploring some of the outer edges of what's now possible with a decent USB controller.
- bonzini 7y ago
  TRIM is supported by USB mass storage devices since those are _also_ SCSI. It is the bridges that may not support it, and the same is true for USB-attached SCSI. For USB-attached SCSI, what makes a difference in performance is support for USB 3.0 streams, which allow multiple transfers to occur concurrently (https://www.kernel.org/doc/html/latest/driver-api/usb/bulk-streams.html https://www.kernel.org/doc/html/latest/driver-api/usb/bulk-s...).
  - k_sze 7y ago
    Ah. I didn't know that USB mass storage is also SCSI. Is TRIM/UNMAP part of the SCSI Transparent Command Set, which depends on the SCSI Peripheral Device Type reported (by the USB-SATA bridge?) in response to INQUIRY? What exactly is the "SCSI Transparent Command Set" anyway? I haven't been able to find an answer from DuckDuckGo search. The Wikipedia article on USB Mass Storage [1] mentions it, but doesn't really define it. Neither does the article on the SCSI command [2] itself. Another post [3] touches upon SCSI Transparent Command Set, but also says in passing that the SCSI specifications at t10.org don't mention the "SCSI Transparent Command Set". [1] https://en.wikipedia.org/wiki/USB_mass_storage_device_class#Device_access https://en.wikipedia.org/wiki/USB_mass_storage_device_class#... [2] https://en.wikipedia.org/wiki/SCSI_command https://en.wikipedia.org/wiki/SCSI_command [3] http://janaxelson.com/mass_storage_faq.htm http://janaxelson.com/mass_storage_faq.htm
derefr 7y ago
Is there really a need for random 4K writes on the SD card in the Pi? Couldn’t the card use a log-structured filesystem and batch writes in RAM, turning those writes into streaming writes? The new Pi certainly has enough RAM that it could dedicate some to serving as a write cache.
- pjc50 7y ago
  This is the choice that lots of system designers have to make, "low apparent write latency" vs "maximum data at risk of power loss". If there's a database on the Pi you're going to be upset if you call fsync() and it doesn't actually do the writes.
  - rowanG077 7y ago
    if you have implemented fsync() to not sync to actual backing storage you have a bug in your design. That is orthogonal to caching the writes in RAM prior.
    - pjc50 7y ago
      Sure, but for this use case if you're doing a set of database transactions each will be its own write to persistent storage. Which is why you care about the random 4k write speed. "Sequential writes are much faster than random writes" is not at all a new problem, it dates from the hard disk era. Which is why most filesystems will cache as much as they think they can get away with.
      - cmurf 7y ago
        When I do OS updates (Fedora, so that's dnf and rpm) with a system on USB flash or SD Card flash, the write are abysmal. Like, 3-4MB/s, using `iotop -d3 -o`. There's almost no reads suggesting the RPMs that have been downloaded are cached. I experience this with ext4, btrfs, and f2fs. Using strace on both dnf and rpm, there's no appreciable amount of sync(), fsync(), or fdatasync() - so I'm not really sure why there was this persistent ~4MB/s trickle to the card rather than large "state" updates, in particular for f2fs and Btrfs. All three make heavy use of delayed allocation, but in particular f2fs and Btrfs have no specifically designated locations for write, or overwrites. So I'd expect that most update OS type writes should/could be much faster. A sequential write is ~20MB/s on both of these media, and sequential reads are ~150MB/s. I wasn't ever able to profile it well enough to understand why it's so dog slow.
deleted 7y ago
[deleted]
dev_dull 7y ago
I'm a big fan of the RPI, and use them in various home projects, but I'm going to continue to wait out the RPI updates until I can get a proper m.2 slot for a "real" hard drive. Working with SD -- especially when continually developing, is just too slow and painful. Not to mention questions about lifetime and lifecycle. The price of m.2 drives have come down so significantly that I think SD should be slowly phased out, or added as a secondary option.
- m463 7y ago
  There are a few ways to do this now: m.2 add-on boards, such as https://amzn.com/B01NH2W8NL https://amzn.com/B01NH2W8NL boot directly from a good usb flash drive (I like the sandisk cz80, though they seem scarce now)
- kup0 7y ago
  Soon rPi4 will support directly booting from USB3.0 - a USB flash drive (or preferably, SSD) would be a good middle-ground instead of waiting for m.2
LeoPanthera 7y ago
I now only use "Endurance" microSD cards, which I think are supposed to be for dashcams, in my Pi's, because I've never not had a normal microSD card ultimately be killed by the Pi through what I assume is write endurance exhaustion.
- kup0 7y ago
  Did they die pretty early on? Do you use USB port on a hub/PC/etc for power? If answers to both of those questions are YES, over the years in reading forums/comments/etc a common thread between them has been that rPi kills microSD cards, and the commonality between most of those posts has been the use of (low/unstable) power strictly off of a USB port of another device (instead of a wall adapter) Edit: I now see that geerlingguy addresses this elsewhere in the thread too, so he can add at least some anecedotal experience that drawing too much power from a poorly-powered rPi is a recipe for failed SD cards (Sorry if this is completely irrelevant- it may just be that if you write to your cards a lot they're dying from that due to endurance, like you said)
  - LeoPanthera 7y ago
    I generally use a dedicated USB power supply so that should not be the problem. And I haven't yet had an "endurance" card die.
brandmeyer 7y ago
Once upon a time, Linaro produced flashbench, a tool for learning more information about how managed NAND devices (mmc, sdcard, etc) actually manage their flash. LWN did a story on some of their conclusions [1]. One of the standouts for me was that some erase blocks are managed completely differently from others, such that random i/o performance can vary based on the location on the device. Traditional filesystem benchmarks aren't set up to observe this behavior. IIUC, F2FS incorporated some of that information, and not much else has. But in principle, you should manage your device with short extents and inode tables in the small-block-friendly area, and larger extents elsewhere whenever possible. [0]: https://github.com/bradfa/flashbench https://github.com/bradfa/flashbench [1]: https://lwn.net/Articles/428584/ https://lwn.net/Articles/428584/
beezle 7y ago
Not Pi, but related - I gave up on using a 64GB Kingston SDXC in a Lexar reader to play MP3s in my truck. After just a few days it would develop corruption at the end of songs and by a few weeks it was just too annoying to continue using. I looked at some of the files and it appeared to be a bit flip type problem. Went to a dedicated usb thumbdrive (as has been in my car's glovebox for 7 years) and no issues. Really makes me question using these sdxc cards at all.
chayesfss 7y ago
My first time creating s pihole I had everything setup with a nice sd card then proceeded to put this plastic case over it. Seemed a little tough to put on like it was a little pressure fit so I clicked it into place then tried starting it back up. Well it never came up then I started looking at the pi and realized that the case didn’t have a cutout where the sd card protrudes and it cracked the damn card at the tip! Ended up using a cheaper one I had lying around but wow, lesson learned the hard way.

129 points by geerlingguy 7y ago

tl;dr: the Pi 4 has a much more rosy outlook when it comes to IO both for the microSD card and external drives. The Samsung Evo+ is still the best value for your money.

Fnoord 7y ago
Let me prefix saying I appreciated your writing. However you didn't test endurance. You only tested throughput (I/O). Throughput isn't the same as performance. Why call it performance? I had Raspberry Pi's fail from consumer grade microSD cards. Which sucks if its ~4 hrs of travel (one way). This hasn't happened with industrial grade yet. (I buy mine from DigiKey.) I'm curious about throughput differences with regards to filesystems. Two ideas for a follow-up.
- geerlingguy 7y ago
  The 32GB card I have running in the Pi that often hosts www.pidramble.com has been running on a Pi 2, Pi 3, Pi 3 B+, and now Pi 4 for almost four years and has not had any corruption issues. I also have had a number of other Pis using the Samsung Evo+ and SanDisk extreme cards, many running for one to two years (some doing logging, others saving time-lapse pictures, uploading in batch to an FTP share, then saving more), and have also never encountered a corruption. I think it has a lot more to do with the power supply than the card itself (as long as you're using a SanDisk, Sony, Samsung, etc. and not some no-name card). I think the endurance cards have a little better caching mechanism built into the flash controller itself, so they can kind of paper over flaky power supply issues. So yes, it is definitely better to use endurance class cards. But in my experience, I have not encountered an issue using the typical consumer-grade cards.
megous 7y ago
It is not, it's pretty much equal to Sandisk Ultra A1 in performance. (not the same as the one tested in this test) You can get original 32GB Sandisk Ultra A1 for $4.30 (or $8 incl. shipping) on aliexpress. Evo+ is $8.60 (or $15.79 incl. shipping) on Amazon.
- tristor 7y ago
  Do you trust a microSD card you've bought off Aliexpress? Because I wouldn't. It's questionable if you can even trust one purchased from Amazon, but buying off Aliexpress is next level skeezy. There are a vast amount of fake/counterfeit microSD cars on the marketplace, so this argument is pretty silly if you ask me.
  - megous 7y ago
    See above. https://news.ycombinator.com/item?id=20403155 https://news.ycombinator.com/item?id=20403155 I wouldn't write the comment if I wasn't 100% sure the cards were original. Yes, you can get original Sandisk cards from aliexpress for that price, and actually verify it on the manufacturer's website. You can't do that for Samsung.
meatmanek 7y ago
I'm surprised by the lack of mention of the A1/A2 "Application Performance Class"[1]. These classes specify minimum performance numbers for random reads and random writes: 1500/500 read/write for A1, 4000/2000 read/write for A2. Notably, the Amazon link for the Sandisk Extreme points to an A1 version, not the A2 version[2] 1. https://www.sdcard.org/developers/overview/application/index.html 2. https://smile.amazon.com/gp/product/B07FCMBLV6
- jack12 7y ago
  My understanding is that A2 cards are generally slower than A1 cards IF you don't have host-side support for managing the volatile-RAM caching that A2 requires. So if the Pi 4 only allows you to run in A1 mode anyway, you're better off buying the A1 card and both saving money and getting a faster card. I don't know if that lack of support is true of the Pi 4, but it does seem to be true of most other SBCs according to https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md https://github.com/ThomasKaiser/Knowledge/blob/master/articl...
  - meatmanek 7y ago
    Ah, interesting, I did not realize there was a difference in protocol. I thought A1/A2 were just spec requirements. I wonder if A2 support is something that could be added in newer kernels, or whether it requires hardware support.
cmurf 7y ago
I've gone through three Samsung EVO sdcards in an Intel NUC. I was using it as a boot drive. All were replaced under warranty. But they each died, becoming read-only, within about 5 months of use. I don't think these cards are designed as random access devices. I think they're for cameras: video and photos, and also for cell phones, also mostly video and photos, maybe some app offloading also.

gjsman-1000 7y ago

Note to readers: The USB chip does run hot. This is getting fixed in a firmware update that you can test in the RPF Forum which reduces temps.

gambiting 7y ago
I wonder if that's the reason for somewhat patchy USB performance. when copying data between two USB HDDs the data goes at 40-50MB/s for a minute or two then drops down to like 500kb/s and then ramps up again after a while. When copying data the USB chip and the ports themselves get stupidly hot.
- geerlingguy 7y ago
  Yeah... it surprised me that the VLI USB chip was much hotter than the processor even during CPU stress testing. Between that and the little power controller chip by the USB-C power supply port, the Pi 4 pretty much demands active cooling for any but the most mundane tasks.

dmm 7y ago

I wouldn't buy an sd card on amazon because of the risk of getting a fake. There are tons of fake sd cards out there and amazon refuses to take responsibility for their supply chain.

delish 7y ago
Where do you buy SD cards?
- Fnoord 7y ago
  DigiKey
- antongribok 7y ago
  MicroCenter. They price match Amazon, NewEgg, B&H, and lots of other places. A lot of times their prices are already lower than Amazon.
snaky 7y ago
Sandisk cards for domestic sale in China have 18-digit authenticity code on scratchpad, and you can verify it online at verify.sandisk.cn. So, "buy in China because there's too many fakes in US store". Ironic isn't it.
- megous 7y ago
  I came here to say the same. :) I can attest that this works. I've checked these codes on several cards along with speed and full rewrite/compare tests, to verify capacity and A1 rating. Never had an issue.
  - snaky 7y ago
    I've checked a couple of fake Sundisk cards from Aliexpress as well, detected as fake as they should.
bradenb 7y ago
I'm sure there's a name for this effect, but I am always fascinated by the complaints about fake products on Amazon. I have _never_ received one and I spend several thousand on Amazon every year. I _know_ it must be happening, I just can't understand if I'm lucky, if it's an effect of my location, or somehow related to the way in which I shop on Amazon.

mgamache 7y ago

I know embedded systems were not the original purpose of the Raspberry Pi, but so many people are trying to use the pi for just that. I've wanted to use Rpi for that but the SD card failure rates are high. I know the high-end ones are a lot lower, but is it reliable enough? I am not sure. I was hopping for a SD card alternative for the Rpi 4, maybe it's booting from USB 3.0 when that ships?

orev 7y ago
You can get “industrial” SD cards that are rated for more severe environmental conditions and more write cycles. They are more expensive though, but probably worth it for commercial applications.
- cwt137 7y ago
  You can also get "Endurance" SD cards. A lot of failures are due to too many writes. The endurance ones allow many more writes than the regular consumer cards
- johnnycab 7y ago
  The 'industrial' microSD cards based on MLC or pSLC with controlled or frozen BoM only make sense if you are going to use a device in extreme settings[1]. In most instances, a card in rPi will serve as a boot device, unless someone reappropriates it into a Dashcam or something similar, which has heavy duty write cycles or continuously reads/writes to and from the card; it will be wise to choose something that strikes a balance. At a guess, the Samsung EVO family of consumer based cards, probably ranges between using TLC (older) to 2D or 3D V-NAND (newer). The more robust Pro series, which commands a premium, probably uses MLC or superior.[2] [1] https://www.swissbit.com/products/nand-flash-products/microsd-memory-cards/ https://www.swissbit.com/products/nand-flash-products/micros... [2] https://www.cactus-tech.com/resources/blog/details/slc-pslc-mlc-and-tlc-differences-does-your-flash-storage-ssd-make-the-grade/ https://www.cactus-tech.com/resources/blog/details/slc-pslc-...
  - monocasa 7y ago

k_sze 7y ago

I wonder if Pi 4 supports UASP (USB Attached SCSI Protocol). This may need everything from the VLI VL805-06 USB controller to the firmware to the driver to support it. A preliminary DDG search suggests that the controller probably supports it. My understanding is that, if UASP is supported, you can squeeze even more performance out of a SSD, and it will even properly support the TRIM command because then the SSD is no longer just a dumb USB mass storage device.

geerlingguy 7y ago
This would be interesting to check; I know there are few people on the Pi forums exploring some of the outer edges of what's now possible with a decent USB controller.
bonzini 7y ago
TRIM is supported by USB mass storage devices since those are _also_ SCSI. It is the bridges that may not support it, and the same is true for USB-attached SCSI. For USB-attached SCSI, what makes a difference in performance is support for USB 3.0 streams, which allow multiple transfers to occur concurrently (https://www.kernel.org/doc/html/latest/driver-api/usb/bulk-streams.html https://www.kernel.org/doc/html/latest/driver-api/usb/bulk-s...).
- k_sze 7y ago
  Ah. I didn't know that USB mass storage is also SCSI. Is TRIM/UNMAP part of the SCSI Transparent Command Set, which depends on the SCSI Peripheral Device Type reported (by the USB-SATA bridge?) in response to INQUIRY? What exactly is the "SCSI Transparent Command Set" anyway? I haven't been able to find an answer from DuckDuckGo search. The Wikipedia article on USB Mass Storage [1] mentions it, but doesn't really define it. Neither does the article on the SCSI command [2] itself. Another post [3] touches upon SCSI Transparent Command Set, but also says in passing that the SCSI specifications at t10.org don't mention the "SCSI Transparent Command Set". [1] https://en.wikipedia.org/wiki/USB_mass_storage_device_class#Device_access https://en.wikipedia.org/wiki/USB_mass_storage_device_class#... [2] https://en.wikipedia.org/wiki/SCSI_command https://en.wikipedia.org/wiki/SCSI_command [3] http://janaxelson.com/mass_storage_faq.htm http://janaxelson.com/mass_storage_faq.htm

derefr 7y ago

Is there really a need for random 4K writes on the SD card in the Pi? Couldn’t the card use a log-structured filesystem and batch writes in RAM, turning those writes into streaming writes? The new Pi certainly has enough RAM that it could dedicate some to serving as a write cache.

pjc50 7y ago
This is the choice that lots of system designers have to make, "low apparent write latency" vs "maximum data at risk of power loss". If there's a database on the Pi you're going to be upset if you call fsync() and it doesn't actually do the writes.
- rowanG077 7y ago
  if you have implemented fsync() to not sync to actual backing storage you have a bug in your design. That is orthogonal to caching the writes in RAM prior.
  - pjc50 7y ago
    Sure, but for this use case if you're doing a set of database transactions each will be its own write to persistent storage. Which is why you care about the random 4k write speed. "Sequential writes are much faster than random writes" is not at all a new problem, it dates from the hard disk era. Which is why most filesystems will cache as much as they think they can get away with.
    - cmurf 7y ago
      When I do OS updates (Fedora, so that's dnf and rpm) with a system on USB flash or SD Card flash, the write are abysmal. Like, 3-4MB/s, using `iotop -d3 -o`. There's almost no reads suggesting the RPMs that have been downloaded are cached. I experience this with ext4, btrfs, and f2fs. Using strace on both dnf and rpm, there's no appreciable amount of sync(), fsync(), or fdatasync() - so I'm not really sure why there was this persistent ~4MB/s trickle to the card rather than large "state" updates, in particular for f2fs and Btrfs. All three make heavy use of delayed allocation, but in particular f2fs and Btrfs have no specifically designated locations for write, or overwrites. So I'd expect that most update OS type writes should/could be much faster. A sequential write is ~20MB/s on both of these media, and sequential reads are ~150MB/s. I wasn't ever able to profile it well enough to understand why it's so dog slow.

deleted 7y ago

[deleted]

dev_dull 7y ago

I'm a big fan of the RPI, and use them in various home projects, but I'm going to continue to wait out the RPI updates until I can get a proper m.2 slot for a "real" hard drive. Working with SD -- especially when continually developing, is just too slow and painful. Not to mention questions about lifetime and lifecycle. The price of m.2 drives have come down so significantly that I think SD should be slowly phased out, or added as a secondary option.

m463 7y ago
There are a few ways to do this now: m.2 add-on boards, such as https://amzn.com/B01NH2W8NL https://amzn.com/B01NH2W8NL boot directly from a good usb flash drive (I like the sandisk cz80, though they seem scarce now)
kup0 7y ago
Soon rPi4 will support directly booting from USB3.0 - a USB flash drive (or preferably, SSD) would be a good middle-ground instead of waiting for m.2

LeoPanthera 7y ago

I now only use "Endurance" microSD cards, which I think are supposed to be for dashcams, in my Pi's, because I've never not had a normal microSD card ultimately be killed by the Pi through what I assume is write endurance exhaustion.

kup0 7y ago
Did they die pretty early on? Do you use USB port on a hub/PC/etc for power? If answers to both of those questions are YES, over the years in reading forums/comments/etc a common thread between them has been that rPi kills microSD cards, and the commonality between most of those posts has been the use of (low/unstable) power strictly off of a USB port of another device (instead of a wall adapter) Edit: I now see that geerlingguy addresses this elsewhere in the thread too, so he can add at least some anecedotal experience that drawing too much power from a poorly-powered rPi is a recipe for failed SD cards (Sorry if this is completely irrelevant- it may just be that if you write to your cards a lot they're dying from that due to endurance, like you said)
- LeoPanthera 7y ago
  I generally use a dedicated USB power supply so that should not be the problem. And I haven't yet had an "endurance" card die.

brandmeyer 7y ago

Once upon a time, Linaro produced flashbench, a tool for learning more information about how managed NAND devices (mmc, sdcard, etc) actually manage their flash. LWN did a story on some of their conclusions [1]. One of the standouts for me was that some erase blocks are managed completely differently from others, such that random i/o performance can vary based on the location on the device. Traditional filesystem benchmarks aren't set up to observe this behavior. IIUC, F2FS incorporated some of that information, and not much else has. But in principle, you should manage your device with short extents and inode tables in the small-block-friendly area, and larger extents elsewhere whenever possible. [0]: https://github.com/bradfa/flashbench https://github.com/bradfa/flashbench [1]: https://lwn.net/Articles/428584/ https://lwn.net/Articles/428584/

beezle 7y ago

Not Pi, but related - I gave up on using a 64GB Kingston SDXC in a Lexar reader to play MP3s in my truck. After just a few days it would develop corruption at the end of songs and by a few weeks it was just too annoying to continue using. I looked at some of the files and it appeared to be a bit flip type problem. Went to a dedicated usb thumbdrive (as has been in my car's glovebox for 7 years) and no issues. Really makes me question using these sdxc cards at all.

chayesfss 7y ago

My first time creating s pihole I had everything setup with a nice sd card then proceeded to put this plastic case over it. Seemed a little tough to put on like it was a little pressure fit so I clicked it into place then tried starting it back up. Well it never came up then I started looking at the pi and realized that the case didn’t have a cutout where the sd card protrudes and it cracked the damn card at the tip! Ended up using a cheaper one I had lying around but wow, lesson learned the hard way.