I am working on an embedded Linux project that it is important to be sure that the file system won't be destroyed when some unexpected thing occurs (e.g., power failure during a write operation on SD Card). For this purpose, I am trying to implement a possible failure scenario.
I have read that there is sdctl for this purpose, but in the article, it says that it may take approximately 4 weeks, which is very long time for a single test.
Do you know, or think of, any good scenarios or special combinations (writing data to a certain place etc.) to speed up this fail process?
By the way, I also appreciate the "corruption-immune combination for SD card" ideas (e.g., using a journaling file system). Thanks in advance.
Edit: Preventing (minor) data loss is not the priority for me. When
corruption occurs, file system gets destroyed. So, I have to set the
file system on SD card all over again, manually. This is what I want
to prevent at least. And the question above is about setting a good
test environment to shorten the test time.
Best Answer
If the data is really important, you should use a modern checksumming CoW (copy-on-write) file system like btrfs or ZFS. A recent kernel+btrfs can do "raid" on a single device, storing the data twice with checksumming to determine if one block is damaged, and repair from the (hopefully correct) copy if it happens. Copy-on-write guarantees that data is never overwritten and any eventual changeover happens atomically. Combined with features like snapshots for reliable factory reset, and automatic compression makes it a good choice for space-constrained storage in embedded systems. The main drawback is that it hasn't seen nearly as much testing as "less reliable" file systems, which can be a huge turn-off.
To answer your first question about data corruption, you need to add more details. It is unclear what you expect to happen. The failure mode for Flash storage is typically that you can no longer change a bit from 1 to 0; they are permanently 1. You also haven't told us which file system you are currently using, so I can't advice on sectors and places where you could write random data. Liberal sprinkling of
0xFFto random bytes in the card should do it, perhaps even0xFF..FFon whole sectors.