[PATCH] base-files: call "sync" after initial setup

[Koen Vandeputte]

On 01.03.22 19:57, Hauke Mehrtens wrote:
> On 3/1/22 18:46, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal at milecki.pl>
>>
>> OpenWrt uses a lot of (b)ash scripts for initial setup. This isn't the
>> best solution as they almost never consider syncing files / data. Still
>> this is what we have and we need to try living with it.
>>
>> Without proper syncing OpenWrt can easily get into an inconsistent state
>> on power cut. It's because:
>> 1. Actual (flash) inode and data writes are not synchronized
>> 2. Data writeback can take up to 30 seconds (dirty_expire_centisecs)
>> 3. ubifs adds extra 5 seconds (dirty_writeback_centisecs) "delay"
>>
>> Some possible cases (examples) for new files:
>> 1. Power cut during 5 seconds after write() can result in all data loss
>> 2. Power cut happening between 5 and 35 seconds after write() can result
>>     in empty file (inode flushed after 5 seconds, data flush queued)
>>
>> Above affects e.g. uci-defaults. After executing some migration script
>> it may get deleted (whited out) without generated data getting actually
>> written. Power cut will result in missing data and deleted file.
>>
>> There are three ways of dealing with that:
>> 1. Rewriting all user-space init to proper C with syncs
>> 2. Trying bash hacks (like creating tmp files & moving them)
>> 3. Adding sync and hoping for no power cut during critical section
>>
>> This change introduces the last solution that is the simplest. It
>> reduces time during which things may go wrong from ~35 seconds to
>> probably less than a second. Of course it applies only to IO operations
>> performed before /etc/init.d/boot . It's probably the stage when the
>> most new files get created.
>>
>> All later changes are usually done using smarter C apps (e.g. busybox or
>> uci) that creates tmp files and uses rename() that is expected to be
>> atomic.
>>
>> Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
>
> Acked-by: Hauke Mehrtens <hauke at hauke-m.de>
>
> This is not the best solution as you said but a simple one.
>
> How do we handle the situation in the first boot when the overlay file 
> system is not ready yet and we are in a ramdisk in the beginning?
>
> Hauke

As a small addendum on this topic:

There is another way:

I also have issues with data loss on power cuts using ubifs since a few 
years now,
exactly as described above.

As in my usecase writes are only happening at the absolute minimum (the 
user changing a config setting), I 'solved' it by simply adding 
rootflags=sync to the kernel cmdline.

This seems to force immediate flushed to nand (at the cost of maybe a 
little bit faster wear) and reduced the issue with a huge factor.

In the past before this flag, it happened nearly every powercut that 
some file got corrupted.
after using this .. I can only recall a single case in roughly 3 years.


[    0.000000] Kernel command line: console=ttymxc4,115200 ubi0:ubi 
ubi.mtd=2 rootfstype=squashfs,ubifs rootflags=sync pci=nomsi
[    2.298922] UBIFS: parse sync


Regards,

Koen