so if i partition a 16gb card say something like a 6gb root as read only then 10gb fat32 for read/write storage (due it it being a pretty fast fs without logging) would that mean it is safe to power down at any time so long as I am not writing files to the fat32 partition? because that would be perfect!
There is still a risk of corruption to the other partition. It is much lower than if you were writing to the other partition but it isn't zero. Flash memory needs to be erased in blocks which are far bigger than the pages the OS is using so the controller inside will be combining multiple pages together into one big block. The wear leveling algorithms mean data moves around and won't always be sequential on the underlying flash. The end result is that if you interrupt a block write at the wrong time then you'll corrupt multiple pages inside and they may be pages from your read only partition. Read https://en.wikipedia.org/wiki/Write_amplification for better explanation.Leeloo wrote: ↑Wed Aug 21, 2019 5:33 pmso if i partition a 16gb card say something like a 6gb root as read only then 10gb fat32 for read/write storage (due it it being a pretty fast fs without logging) would that mean it is safe to power down at any time so long as I am not writing files to the fat32 partition?
To me that appears to be the inverse of safety. If the boot files are standard they can be replaced easily. Damaged user data might be either irreplaceable or only replaceable with much time and effort.
What are you even trying to argue here?
The difference is that you can make the OS read only and still have a functional system. Making the user data read only kinda defeats the purpose in most use cases. You can solve it somewhat by switching to a journaled file system on a real hard drive for the user data. On an SD you will be at risk of both unflushed writes and wear leveling. The other aspect is that the system will boot as long as the OS in not corrupted.drgeoff wrote: ↑Wed Aug 21, 2019 7:07 pmTo me that appears to be the inverse of safety. If the boot files are standard they can be replaced easily. Damaged user data might be either irreplaceable or only replaceable with much time and effort.
Sure but protecting the OS by separating it onto separate storage isn't detrimental to the user data. "To me that appears to be the inverse of safety." makes it out that doing this is increasing your risk.
As I understand wear leveling and SD cards, partitioning does not protect you. The wear leveling and actual writing operations occur at a low level with the partitioning being a virtual layer on top of this. The OS sees the partitioned view of the storage and behaves as if they were physical partitions. On a physical hard drive, partitions define physical portions of the disk and all writing is constrained by said partitions. The end result is that the SD will happily wear level across the entire SD thus any portion of the entire SD is at risk due to corruption if you power off mid write. If you moved your user data to a USB drive your solution would work. Please correct me if I am wrong about this.tqhien wrote: ↑Fri Aug 23, 2019 11:40 amHello,
For one of my project (embedded rpi on motorbike), I used the following configuration on a single SDCard :
- boot partition (fat)
- root file system read-only (ext2 or ext4)
- 2 btrfs partitions for user data, in raid mode, with 5 seconds cache (data are written to disk every 5 seconds, mirrorring is provided by btrfs). Those partitions are mounted in a directory where I can save user data.
My app doesn't use a graphical environnement : I directly write to the framebuffer.
That config goes well for me and my app.
In addition, the new SanDisk Automotive and Industrial SD cards support Power Protection capability, which prevents data from being corrupted during a write when the power supply is unstable or unexpectedly lost, which is a feature found on several industrial and enterprise SSDs as well, and is required due to the way in which flash memory is written (see here for a quick refresher)
https://www.anandtech.com/show/11889/sa ... eliability