Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Sorry to ask a (probably) stupid question. I am a hardware designer struggling with provision of safe shutdown power to an embedded system. I am aware the Linux normally makes a heavy use of the filesytem and makes metadata updates whenever a file is read -i.e. there is a consequential write for every file access. I believe it is possible to delay this write. I am wondering what happens if this is an indefinate delay (i.e. it never occurs). Some background:

For operational reasons it is preferable not to use battery backup to provide power during system shutdown- which means I am looking at a 1 to 5 second power down hold-up. This doesn't seem long enough for the O/S to shut down form our S/W engineers' testing. We are all "new" to Linux having been using conventional embedded RTOS up to this point.

We will boot from a FLASH drive and run in RAM in the machine so if we have zero FLASH writes then it wouldn't normally be corrupted on a power fail.

We will store system NV data in FLASH that is controlled by a small micro that guarentees a write success in 10ms so that's fine - however I am struggling to understand what, if anything, Linux has to write back to the drive it booted from - and if we prevent it doing so what consequence would there be?

Unfortunately we're running from a uSDHC card at the moment so I can't simply write protect it in hardware to find out :-(

Can anyone help me or point me at where to learn this information.

share|improve this question

from the manpage of mount:

   -r, --read-only
          Mount the filesystem read-only. A synonym is -o ro.

          Note that, depending on the filesystem type, state and kernel
          behavior, the system may still write to the device. For example,
          Ext3 or ext4 will replay its journal  if  the  filesystem  is
          dirty. To prevent this kind of write access, you may want to mount
          ext3 or ext4 filesystem with "ro,noload" mount options or set the
          block device to read-only mode, see command blockdev(8).

some parts of the filesystem hierarchy need to be writeable (e.g. /var/log to put logfiles into; often /tmp to store temporary files). use some non-persistent partitions (aka ramdisk, tmpfs,...) in these cases.

share|improve this answer
that sounds really interesting..are you saying that it is possible to stop execution of a number of processes immediately and then gracefully exit the filesystem? - It's a different view to the software department's at the moment but more in line with what I would expect. As I say we're all new to this and on a steep learning curve. – ian Feb 12 '14 at 11:09
I'm interested in the RAMDisk comment here. As the RAMDisk is volatile and will be corrupted on power fail can I read into this that the reboot would clear all errors provided that the O/S on the FLASH was unchanged? Thanks for the pointer to the manual. – ian Feb 12 '14 at 11:11
@ian There are many Linux systems that run with the main system partition mounted read-only, and all OS data either read-only or in RAM. Any live Linux distribution is an example of this. Android (which is based on a Linux kernel) also works that way. – Gilles Feb 12 '14 at 22:45
@ian I forgot to mention: if you boot from read-only media, one thing you have to take care of is properly seeding the RNG with entropy. If you have a hardware RNG, you can use that, but otherwise you'll need to update your entropy pool (preferably at boot time, just after reading the current state and before generating any random number). – Gilles Feb 12 '14 at 23:44

Linux normally makes a heavy use of the filesytem and makes metadata updates whenever a file is read -i.e. there is a consequential write for every file access.

That is not correct. More precise: This has not been the default any more for years. The default is that the access time is updated only if it is older than mtime or ctime or older than 24 hours. The atime update can be disabled completely by the mount option noatime.

If you need to shutdown really fast then you should determine which steps take long and kill these processes immediately (-SIGKILL). The others should get -SIGTERM and one or two seconds later -SIGKILL, too. Then the kernel should be able to close the file systems very soon.

share|improve this answer
On the other hand, if you use SIGKILL, you may lose data as well. – Simon Richter Feb 12 '14 at 15:59
@SimonRichter You simply cannot enforce a shutdown which is both completely clean and fast. Data loss seems not to be a problem to me from the question. But if the application closes fast then there is no need to kill it. I was thinking of the usual OS stuff which takes an eternity to shutdown. There is no risk of losing relevant data. – Hauke Laging Feb 12 '14 at 16:13

running / in r/o mode is quite normal, this is how ovirt-node works for example. The problem would be having a persistent configuration without remounting to r/w every time. And the solution is to have a small r/w partition for config files and to bind-mount those files over the originals in /etc on boot.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.