I also really like the fact that the Pi is pretty much stateless. So switch SD cards and you can be mostly sure everything still works. If storage is bundled, that's a lot more difficult.
I realize you may be successful in running signage devices, but most people want to simply be able to run common class 10 card (e.g. from Verbatim, Kingston, Sandisk), using a standard OS setup and leave the Pi running without having it corrupting your files. This simply isn't possible, in my experience. Also look at the OpenHAB forums as a reference.
The more regular disk activity, the worse it gets.
We went this route in our office and every 3-6 months we had corruption on each of many dozen Pi's. Once we switched to using USB drives (spinning or SSD) the issues were sorted out.
To be fair: try the same with cellphones. I have a shitload of micro-SD cards gone bad on me, and yes genuine SanDisk not cheap fakes off of Amazon.
microSD cards are the cheapest crappy flash chips you can get with a microcontroller strapped in front for error correction.
If you really need durability, there's also a handful of SLC (single level cell) SD cards on the market which will last an order of magnitude longer in terms of writes as compared to consumer level MLC/TLC cards. SLC cards aren't cheap but you get what you pay for.
Nope, it's mainly marketing. Cards from those brands are fundamentally not great for sub million unit purchases. We tried to use some for the root fs for a fairly high availability appliance. If you don't want one in twenty going out in a month (and we figured out a way to make them go out after 8kb/s for 8 hours with a specific access pattern without power drops), then you need 'industrial SD cards'. They'll treat you like adults when it comes to support, will have lot codes that actually map to internal changes, etc. Trying to sell a product with consumer SD cards (yes, even the ones that call themselves 'Pro') is basically a futile exercise.
LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out
1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that.
2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.
Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity.
With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable.
I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design.
[0] https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md
Personally I want to use it as an internal filesystem for various projects (like games - instead of zip/pak files, which are really read only)
even littlefs over https might be an interesting naval gazing project :D
sudo systemctl stop rsyslog
sudo systemctl disable rsyslog
It does this whether or not a syslog daemon is running. (All messages it captures goes through the journal and then are forwarded along)
You'll still be able to look @ recent logs with journalctl commands.
Set up everything how I like it, set root read-only and mount tmpfs in various areas such as /var/log etc..
I haven't tried them myself, though.
4GB is enough for most Pi projects, and <$20 premium is worth never needing to worry about SD reliability to me. My understanding is they use multi-level cells, which are far less expensive than true industrial grade single level cells, but they only write a single value to each cell, increasing the reliability significantly.
EDIT: I see in other comments that they're worth it, so they're a great option for when I need reliability at a premium, thanks!
Explanations: The script creates a /var/log mount point in RAM. So any writing of the log to the /var/log folder will not actually be written to disk (in this case to the sd card for a raspberry card) but directly to RAM. By default, every hour, the CRON will launch a synchronization of the RAM to the folder located on the physical disk. The script will also make this copy of RAM to disk in case of machine shutdown (but cannot do it in case of power failure). This way you avoid excessive writing on the SD card.
Obviously 4GB is not a lot, so I use tmpfs and USB storage as appropriate.
[0]: https://www.raspberrypi.org/forums/viewtopic.php?p=1257129 (2nd to last comment in the thread)
Also, the Zymbit[1] works nicely with its eMMC.
[1] https://linux-sunxi.org/Linux_mainlining_effort
[2] https://www.kickstarter.com/projects/bootlin/allwinner-vpu-s...
[3] https://twitter.com/marcan42/status/1088472549715918848
[4] https://github.com/raspberrypi/firmware/blob/master/boot/LIC...
I also wish Raspbian had an option to mount all the write-heavy directories (logs, etc) on tmpfs, so they wouldn't wear the card out so quickly.