ubifs: handling dirty data (writing back) + power cuts

[Sergey Ryazanov]

Hello Rafał,

On Fri, Feb 25, 2022 at 5:26 PM Rafał Miłecki <zajec5 at gmail.com> wrote:
> my system is setup as follows:
>
> # mount | grep ubifs
> /dev/ubi0_1 on /mount/ubifs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=1)
>
> # cat /proc/sys/vm/dirty_writeback_centisecs
> 500
> # cat /proc/sys/vm/dirty_expire_centisecs
> 3000
>
> (5 s and 30 s respectively) and I'm currently debugging some data issues
> related to power cuts.
>
>
> My actual problem is related to ubifs behaviour for power cuts happening
> between 5 and 35 seconds after saving a file:
> date > /mount/ubifs/test.txt && sleep 15 && echo CUT POWER *NOW*
>
> On the next boot test.txt exists but it's EMPTY (file size 0).
>
> For newly created files above behaviour is not the worst one - however
> I'd expect such file to not exist at all.
>
> The biggest problem is when dealing with existing files. In such case
> power cut means loosing it completely. I don't get *old* content nor
> *new* content.
>
>
> I noticed this behaviour with kernel 5.10 and also reproduced it with
> 5.4, 4.14 and 4.4.
>
> Is this a bug or some quirky feature? Can I do anything to avoid such
> situations except modifying all user space to call fsync() when needed?

I experienced a similar issue with F2FS on a x86 board on first boot
after sysupgrade. If the power loss happens within some time window,
then all old configuration files that were extracted from the
sysupgrade.tar archive become empty. Which effectively makes the
device inaccessible via the network.

The best thing I could come up with in that situation is to sync FS
just after the sysupgrade.tar archive extraction, see 880c1f0336
("base-files: prevent issues w/ overlay on powerloss after
sysupgrade"). And according to the documentation Richard pointed out,
this is the only solution from the filesystem developers point of view
- http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions

--
Sergey