Hi Ross,
> Doing a sync for _every_ file created seems like overkill, and if you're
> doing atomic creation is it even useful? The correct file will exist or not
> exist: what does a sync add?
sync is an important part of atomic file creation. It acts as a barrier and
prevents possible reordering on file system level. To demonstrate an issue
without sync I did the following experiment on my board with NAND flash
formatted as UBIFS (simulating populate-volatile.sh behavior):
ssh board "
# some_file* don't exist at this moment.
touch some_file.populate-volatile.tmp # created with default permissions: 644
chmod 600 some_file.populate-volatile.tmp # update permissions
# Note: there is no sync at this moment.
mv some_file.populate-volatile.tmp some_file
ls -l some_file* # Make sure we've updated permissions. Output:
# -rw------- 1 root root 0 Sep 13 08:36 some_file
"
sleep 5 # Give a board some time to write data to flash
# (otherwise some_file* is not preserved at all in my case).
power_off_board.sh # Physically cut board's power.
sleep 15 # Keep the board off for some time..
power_on_board.sh # Turn board's power on, it starts booting automatically.
sleep 40 # Give a board time to boot
ssh board "
ls -l some_file* # Output:
# -rw-r--r-- 1 root root 0 Sep 13 08:36 some_file
"
Above we can observe some_file with wrong (default) permissions. Effect of
chmod has been lost due to power cut. Furthermore since some_file now exists,
it won't be processed by next populate-volatile.sh execution (after reboot) and
hence remains with wrong permissions forever. A behavior with ownership is the
same as with permissions in my case.
Additionally I'd like to quote UBIFS FAQ here (I've provided a link to it in
my patch):
> Changing a file atomically means changing its contents in a way that unclean
> reboots could not lead to any corruption or inconsistency in the file. The
> only reliable way to do this in UBIFS (and in most of other file-systems,
> e.g. JFFS2 or ext3) is the following:
>
> * make a copy of the file;
> * change the copy;
> * synchronize the copy;
> * re-name the copy to the file (using the rename() libc function or the mv
> utility).
>
> Note, if a power-cut happens during the re-naming, the original file will be
> intact because the re-name operation is atomic. This is a POSIX requirement
> and UBIFS satisfies it.
>
> Often applications do not do the third step - synchronizing the copy.
> Although this is generally an application bug, the ext4 file-system has a
> hack which makes sure the data of the copy hits the disk before the re-name
> meta-data, which "fixes" buggy applications. However, UBIFS does not have
> this feature, although we plan to implement it.
I understand that sync implies some performance degradation but IMHO we should
prefer correctness over performance by default. I did some basic performance
experiments: time /etc/init.d/populate-volatile.sh
In my case I didn't notice any measurable difference in execution time with and
without sync command in populate-volatile.sh (22 files were created, which is
not that much, I agree..).
> (also: it's power-cut safe, not save)
Agree, it'd be better to fix it. I'll wait for further feedback before sending
a v2 patch with this fix..
Regards,
Viacheslav
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204470):
https://lists.openembedded.org/g/openembedded-core/message/204470
Mute This Topic: https://lists.openembedded.org/mt/108119948/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
