4

My company uses the Raspberry Pi 3 as an embedded controller in a product. User's don't power it off gracefully, they just flip a switch. To avoid corruption, the /boot and /root file systems are read-only. This appears to be bulletproof - we've used test rig to "pull the plug" over and over (2000+ cycles) with no problems.

We are working on a new feature that requires local logging. To do so, we created an additional ext4 read/write partition on the SD card (we are currently using about 2GB on an 8GB card) for the log file. To minimize wear, the application buffers the log data and writes to the card only once every minute. The log file is closed between writes. Nothing else uses that partition. The log file is not written to when the application is in a state that likely indicates the user is about to shut down.

In testing this, we've found that in spite of the rather conservative approach we're using, the read/write partition is always marked as "dirty" after a reboot, frequently contains filesystem errors, and often has a damaged log file. We've also had a number of cards suffer unrecoverable errors which prevent the device from booting up.

Loss of the last set of log entries is not a problem.

Loss of the log file is undesireable but acceptable.

Damage to the /root and /boot filesystems is unacceptable, as is physical damage (other than standard NAND flash wear) to the card.

Short of adding a UPS to gracefully shut down the Pi, is there any approach that will safely allow for read/write operations?

Is there a configuration of the SD card partition "geometry" that would ensure that no two partitions overlap one flash erase block?

Steven Sokol
  • 41
  • 2
  • Interesting question. I have been working on similar things and have read that ext3 is supposedly more resilient to this sort of treatment than ext4 in several places. May be worth a try. – Mark Setchell Feb 03 '18 at 23:16
  • Thanks - I'll take a look at ext3 and see if it is less prone to corruption. An option may be to use a USB flash device to provide a complete "air gap" from the SD card. The filesystem on the USB drive would only need to be mounted when the app needs to access it. – Steven Sokol Feb 04 '18 at 17:06
  • Please ping me by putting my name prepended with `@` in any updates you may post - thanks. – Mark Setchell Feb 04 '18 at 20:03

2 Answers2

1

Just some points:

Dirty flag: I guess that you are not unmounting the filesystem, right? This is a possible reason to see dirty flag after each unclean reboot. Another (probably better way) is to switch filesystem to read-only mode after writing and make it read-write before writing the file.

BTW, ext4 defers writes to the disk. close() on file doesn't mean that the files are written to the disk, you need to call extra fsync() or sync (see Does Linux guarantee the contents of a file is flushed to disc after close()?). So it is better to ask system to really write the file.

Tomas Novotny
  • 1,771
  • 9
  • 11
  • @ThomasNovotny - Correct, the filesystem is not unmounted prior to power off. We've not altered the default configuration for the filesystem, so it's not being fsck'd on a regular basis either. I'm going to do some experimentation with ext3. From what I've read, it commits to the hardware on closure. This can be a disadvantage in some cases but may help in this case. – Steven Sokol Feb 08 '18 at 17:13
  • @StevenSokol You should run fsck on a dirty filesystem prior to mounting. Long term usage of dirty filesystem will definitely lead to problems. Regarding ext3 - it flushes data to disk every 5 seconds by default (which is not case for ext4). But `fsync()` is still a good idea. – Tomas Novotny Feb 09 '18 at 17:30
  • @StevenSokol normally you'd want to remount ro prior to shutdown. I've managed to do that adding some extra circuitry with a couple large capacitors. – Ezequiel Garcia Feb 11 '18 at 16:03
0

I suggest to use UBIFS or JFFS2 or YAFFS2. Its best practics way. Also I heard about LogFS.

All time mount and writing without delay posible because this FS designed to work with hard shutdown.

Copy-Pasted oveview from https://superuser.com/questions/248078/choice-of-filesystem-for-gnu-linux-on-an-sd-card

JFFS2

  • Includes compression and elegant wear leveling protection.

YAFFS2

  • Single thing that makes the difference: short mount times, after successful umount.
  • Implements write once property: once data is written to one block, there is no need to rewrite it. This is important, as it reduces wear.

LogFS

  • Not very mature, but already included in Linux kernel tree.
  • Supports larger filesystems than JFFS2/YAFFS2 without problems.

UBIFS

  • More mature than LogFS
  • Write caching support
  • On scalability: [article][3]. On large disks, better performance than with JFFS2

ext4

  • If no driver or card (for example SSD drives do have internal wear leveling, at least usually) handle wear leveling, then ext4 is not the best idea, as it is not intended for raw flash usage.
eri
  • 3,133
  • 1
  • 23
  • 35
  • 1
    Unfortunately, those are all options for unmanaged flash storage, not for a managed flash storage device like an SD card. The SD card's onboard controller handles all of he wear leveling, bad block management, etc. The issue we're having has more to do with the unclean shutdown than the erase / write wear on the card. – Steven Sokol Feb 04 '18 at 21:30