0

I'm trying to have this done on a debian 9 based embedded system. The fs that come for root is mounted as such in /etc/fstab:

# /etc/fstab: static file system information.
#
/dev/mmcblk1p1  /  ext4  noatime,errors=remount-ro  0  1
debugfs  /sys/kernel/debug  debugfs  defaults  0  0

My current file system looks like this:

Filesystem      Size  Used Avail Use% Mounted on
udev            215M     0  215M   0% /dev
tmpfs            49M  6.0M   43M  13% /run
/dev/mmcblk1p1  3.5G  1.9G  1.4G  59% /
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           242M     0  242M   0% /sys/fs/cgroup
tmpfs            49M     0   49M   0% /run/user/1000

Now what I'm required to do is use unionfs (or aufs) + ext4 to create a more resilient mounting system because /ext4 might fail due to power outage and file corruption might occur. The idea here is to have a readonly file layer at the bottom with a writable one on top for /home/debian as well as any other that might require system writing to them (like var/log dir). What I was told is that ext4 working with an embedded system that might loss power unexpectedly on regular basis, would cause series disk issues/corruption especially since we are going to be writing to disk alot while our Application is running.(Link). IS this completely true even with the presence of Journaling in ext4?

After hours and hours of researching I found that it is suggested to go through the /usr/share/initramfs-tools by creating hooks/scripts and such. After creating new script and booting my system I was able to get something similar to what I had wanted:

Filesystem      Size  Used Avail Use% Mounted on
udev            215M     0  215M   0% /dev
tmpfs            49M  6.0M   43M  13% /run
/dev/mmcblk1p1  3.5G  1.9G  1.4G  59% /ro
root.rw         242M  8.5M  234M   4% /rw
root.union      242M  8.5M  234M   4% /
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           242M     0  242M   0% /sys/fs/cgroup
tmpfs            49M     0   49M   0% /run/user/1000

&& using mount I get the following details for newly added ro && rw file systems:

/dev/mmcblk1p1  on  /ro                              type  ext4        (ro,relatime,data=ordered)
root.rw         on  /rw                              type  tmpfs       (rw,relatime)
root.union      on  /                                type  aufs        (rw,relatime,si=587d3414)

Now this has worked in terms of making my initial / read only system that is in /ro dir && I have installed on top a writable layer in /rw. The issue here is that if I create new files/dir they are all gone after booting the device. Looking deep into this I suspect the fact that I was using tmpfs might have caused that since it is used normally for RAM, but I have tough using aufs on top (root.union) would solce tis issue but it didnt.

How can I solve this issue by making the /rw layer retain any new information/files created even after boot? Keep in mind my system is read only now so everytime I try to go into my script and mount /rw as aufs it is reverted back after booting the device.

Note: Does my current set up mean that logs from my current App are not logged to my /var/log/... and are lost after booting device? some Apps would usually log to /var/log/syslog which is in /rw directory but I can't seem to confirm if they are retaining new logs after boot up or just reverting to what they had at start up in them?

0

AFAIK, ext4's journalling means that actual corruption is rare, and can be fixed with a fsck. I have never encountered an ext4 corruption in anything but a dying disk (literally refused to spin up the next day).

Linux's caching means that the RAM acts as a tmpfs with a backing store. If you find this too slow (which would be surprising, given that you are using a flash disk), you can increase the time taken to flush the data by adding commit=<time> to your fstab, which trades data loss with speed.

Going through trying to find what needs to be written to by programs is a unsolved problem in computer science, above the halting problem in complexity. Why not just store the things you need to persist on a separate partition/disk, so that you can migrate in the case of failure?

  • The only other alternative here is SD card and I found that those can be unreliable at time. – JJ Adams Oct 5 '18 at 17:19
  • @JJAdams you only need them to not fail at the same time, rather than to be completely reliable. – Cyclic3 Oct 5 '18 at 17:32
  • @JJAdams the mad part of my brain is suggesting RAID 1 as an option. Raid 1 with flash improves read performance, but not write. If your worried about disk failure, there is not much better than a mirror (except, perhaps, 2 mirrors) – Cyclic3 Oct 5 '18 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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