So, "buy in China because there's too many fakes in US store". Ironic isn't it.
Never had an issue.
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.
Almost every time, though, it's because the Amazon official supplier/warehouse was out of stock and I accidentally ordered from one of the secondary suppliers. The problem is, unless you know what to look for in the interface, it's hard to determine if you're buying from Amazon or the manufacturer, or some 3rd party.
Even then, there are many reputable 3rd parties. But there are many who are not.
The worst cases in my experience are ordering 'Apple OEM' type products. I will not buy a charger or any other Apple accessory on Amazon because more than 50% of the time I've gotten a non-Apple-manufactured product.
Also, Amazon sometimes commingles their own stock with that of 3rd-party vendors, so "Ships and Sold by Amazon" doesn't mean what it used to.
EDIT: fixed numerous typos >:(
That you know of.
They price match Amazon, NewEgg, B&H, and lots of other places. A lot of times their prices are already lower than Amazon.
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.
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-s...).
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  mentions it, but doesn't really define it. Neither does the article on the SCSI command  itself.
Another post  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".
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.
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)
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.
I had one fail with a Toshiba card, but at that time I was also using a cheap micro USB power adapter that probably wasn't putting out a solid 2A.
I think the primary reason people have problems with microSD card corruption is the power supply. Even with a good power supply, when you plug in a lot of USB devices and push a Pi to the limits, it can draw ~2+ Amps, and only very good power supplies will not have weird issues at that draw.
The Pi doesn't handle that situation very well (nor do microSD cards).
But running my Pis headless (no USB accessories attached) without any video output keeps the power draw down to 1-1.5A max, even when CPUs are maxed out and I'm saturating the network.
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.
Had good luck with the ones mentioned in https://news.ycombinator.com/item?id=16777238
Further to your link, my experience with Samsung Pro series has been very favourable. YMMV.
One can argue about whether those reasons are in the "but the user should know better" column, but when they result in a corrupted filesystem, they nevertheless add up to a poor user experience.
Hope one day the Rpi has easygoing power requirements and a button you can push for orderly shutdown.
There's so much nice about the industrial cards that have nothing to do with it's ability to endure extreme environments, that I would basically never ship a non consumer product without them at this point.
80kB/s sounds a bit low for a card that is doing full "global" wear leveling; memory cards and SSDs that don't have DRAM often cut corners on the wear leveling, so they aren't as effective as proper mainstream SSDs. Your workload was probably issuing the writes in chunks smaller than the flash memory's page size (typically 16kB these days), so you probably had serious write amplification from the read-modify-write cycles even if that 80kB/s was sequential writes. SSDs with decent-sized write buffers and power loss protection capacitors can do more write combining than a memory card that has to be prepared for sudden power loss at any moment.
You can also reduce risks with your choice of filesystem, read-only partitions, and FS tuning/alignment. I wrote up my findings after looking into it last year: https://kevinlocke.name/bits/2018/04/28/rpi-sd-card-storage-...
For example, this is the standard configuration for openwrt (which you can run on the pi)
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.
m.2 add-on boards, such as https://amzn.com/B01NH2W8NL
boot directly from a good usb flash drive (I like the sandisk cz80, though they seem scarce now)
Once I can fully boot my Pis off USB, I'm planning on reworking my cluster to run off SSD alone to see what kind of performance I can get out of it.
(I am excluding things such as ext4 that are missing data block checksumming, and recovery from disk failure using parity stripes)
That prevents the filesystem from being in a inconsistent state, but doesn't address the issue of data loss. eg. what happens if there's 5M outstanding writes and you get a fysnc? If you wait for everything to be flushed, that's going to produce latency. If you lie and return immediately, and there's a power outage, you now lost those oustanding writes.
"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.
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.
Notably, the Amazon link for the Sandisk Extreme points to an A1 version, not the A2 version
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/articl...
I wonder if A2 support is something that could be added in newer kernels, or whether it requires hardware support.
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.
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.
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.
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.
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.