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

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

[Rafał Miłecki]

Hi,


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?

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

[Rafał Miłecki]

On 25.02.2022 15:17, Rafał Miłecki wrote:
> 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).

FWIW I get acceptable ubifs behaviour if power cut happens in less than
5 seconds after saving a file. For example:
date > /mount/ubifs/foo.txt && sleep 4 && echo CUT POWER *NOW*

On the next boot foo.txt simply doesn't exist.


Everything works fine for power cuts happening after 30 + 5 seconds:
date > /mount/ubifs/bar.txt && sleep 35 && echo CUT POWER *NOW*

On the next boot bar.txt exists and it contains a date.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

[Richard Weinberger]

Rafał,

----- Ursprüngliche Mail -----
> Von: "Rafał Miłecki" <zajec5@gmail.com>
> On 25.02.2022 15:17, Rafał Miłecki wrote:
>> 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).
> 
> FWIW I get acceptable ubifs behaviour if power cut happens in less than
> 5 seconds after saving a file. For example:
> date > /mount/ubifs/foo.txt && sleep 4 && echo CUT POWER *NOW*
> 
> On the next boot foo.txt simply doesn't exist.
> 
> 
> Everything works fine for power cuts happening after 30 + 5 seconds:
> date > /mount/ubifs/bar.txt && sleep 35 && echo CUT POWER *NOW*
> 
> On the next boot bar.txt exists and it contains a date.

See:
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file

Please let me know whether this helped.
I guess mounting UBIFS in sync mode is what you want.
But please also keep this in mind:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_semantics

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

[Rafał Miłecki]

On 25.02.2022 15:17, Rafał Miłecki wrote:
> 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.

To make it clear what I meant by dealing with existing files:


[fist boot]

# echo foo > /mount/ubifs/test.txt
# sync
# cat /mount/ubifs/test.txt
foo
# busybox sed -i 's/foo/bar/' /mount/ubifs/test.txt && sleep 10 && echo CUT POWER NOW
CUT POWER NOW


[next boot]

# ls -l /mount/ubifs/test.txt
-rw-------    1 root     root             0 Feb 28 02:26 /mount/ubifs/test.txt

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: 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@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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/