2

I'm developing an embedded linux system running on a SD card.

To protect the SD against corruption I've used a read only root filesystem as well as an extra partition where I mount /home, also in read only mode. It is in /home where the program runs and performs read-write operations.

When the software needs to write some data on the disk, it echoes these two commands and saves the data between them:

mount -o remount,rw /dev/mmcblk0p3 /home
mount -o remount,ro /dev/mmcblk0p3 /home

I'm doing this to ensure maximum prevention agains corruption if power goes down. But, I don't know if the cure may be worse than the disease.

Is it dangerous for the filesystem or the SD card to perform such a frequent partition remounting each time I want to save some data?

Another question. Is it dangerous to remount a partition where a program is running? I mean, not writing data on the disk, just running with the own program variables.

fmoralesalcaide
  • 23
  • 3

3 Answers3

2

The remount itself ought to be fairly safe, though of course its a less-tested path in the kernel than, say, write(2). You may be causing a few extra writes (to mark the filesystem dirty/clean, etc.) You can you use the block dump feature (/proc/sys/vm/block_dump) to find out if you're causing any extra writes.

It's also possible, if you're doing it a lot, that you're forcing smaller writes than would otherwise occur (e.g., no way a write can be combined across two rw-ro cycles). That may mean you cause more erases on the flash. (Of course, if you're doing it that often, then the fs will hardly ever be ro, and its pointless).

This assumes you need to worry about corruption from those writes—if your flash controller handles powerfail during wear leveling (etc.) correctly, then you don't need to. A journaled filesystem will prevent corruption, provided you use update semantics that it supports. Of course, journaling amplifies writes.

derobert
  • 107,579
  • 20
  • 231
  • 279
1

To protect against corruption, just call sync to commit all the changes to disk (when needed). Also, journalled filesystems are pretty resilient and you really don't need to do this.

Otherwise this is not dangerous (it syncs and changes the flags within the kernel, doesn't do much to the drive itself), but it is annoying to do all the time and isn't really necessary.

orion
  • 12,302
  • 2
  • 31
  • 41
  • This depends on how the wear leveling on the card works. Flash is *not* a hard disk, and, especially in various failure modes, acts very differently. – derobert Mar 05 '14 at 11:49
1

I think you're over-thinking things. I've been using Linux for 20 years and Unix systems for more than that. I've only seen one or two corrupted file systems in that time (and I'm a UNIX admin by trade so I deal with dozens of systems per day).

Now, if you're talking security, there's something to that.

Having most of the system read only is a good protection scheme. In your scenario, though, where do you log to? You have to have a writable logging partition that's available.

Making /home read only and forcing the application to switch between read only and writable really seems like overkill and overhead.

ELadner
  • 11
  • 1