Re: ubifs: handling dirty data (writing back) + power cuts
Hello Rafał,
On Fri, Feb 25, 2022 at 5:26 PM Rafał Miłecki 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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubifs: handling dirty data (writing back) + power cuts
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubifs: handling dirty data (writing back) + power cuts
Rafał, - Ursprüngliche Mail - > Von: "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. 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubifs: handling dirty data (writing back) + power cuts
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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ubifs: handling dirty data (writing back) + power cuts
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? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
