On Fri, Dec 25, 2020 at 7:45 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > 2. A lot of the time a package is building the CPU is waiting on the SD card even though it's a class 10. I'm betting IO would be faster over my gigabit Ethernet. AND save all the writing to the SD card, extending it's life. USB stick and SD Card flash media are simultaneously remarkably cool technologies, very inexpensive, but also unreliable. They have firmware on them just like any other SSD, except it's quite unsophisticated. I've never seen either one report a read error, they just return garbage or zeros when blocks begin to fail. And these failures can even be transient. The write performance is pretty horrible too. Even the ones that can do decent writes are designed for single queue, heavy sequential writes like you'd expect from a camera. They are horrible at random writes, or even a mix of random and sequential. And yes they are much more write sensitive than non-removable SSD and NVMe. They will eventually fail. So far I go through a USB stick or SD Card used as sysroot about once every 7 months. They're that bad. HN is full of these kinds of experiences, and the best work around is to get so called "industrial" SD Cards specifically for the embedded use case. There's nothing that special about them other than they're using more expensive single layer NAND with higher wear capacity. So they write even slower than the consumer SSDs but they last a lot longer. My workaround is I use Btrfs with compression, and with cheap snapshots and btrfs send/receive it's easy to keep backups. Eventually I'll start to see Btrfs report csum errors (corrupt data) and then I know I'm getting close to the time when the media will pancake itself. The most typical scenario I've seen is the media goes read-only. Not the file system, but the media itself. Write to a block, no error. Read that block, get back old data. File systems will get deeply confused by this eventually. But the errors they report will be non-obvious because all it's saying is "haha wut?! that ain't right!" over and over again. I didn't figure out the media had gone read-only until I did my own write and read tests independent from the file system. The first time it happened I even reformatted one of the partitions with a different file system, wrote stuff, and no errors. Then unmounted it, mounted it again, and saw it was the old file system and old data. i.e. the media is accepting write commands without error, basically saying "yeah I've got your data" but then failing to actually commit it to the media. Without a single error reported. It's really funny how bad the error reporting is for this class of media. Plausibly I could write some important files to such a device and have no idea at all it was not committed. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
