Power-fail safe writes

Sebastian Brand sebastian.brand at axis.com
Tue Apr 2 12:28:13 UTC 2019


On 04/02/2019 07:41 AM, Sebastian Brand wrote:
> > Hello,
> >
> > I recently had problems when updating a configuration file using sed
> > with in-place edit option (-i), shortly followed by a power fail, which
> > has the end result of an empty configuration file and a system that
> > won't boot.
> > The reason behind this is me relying on sed and sed in-place editing not
> > using a power-fail safe write pattern (copy, edit copy, synchronize
> > copy, rename, synchronize folder).
> > I have locally written a feature to enable "safe write" for sed, but
> > since this is a problem for many flash filesystems there might be more
> > people interested in this? (Perhaps especially people using Busybox for
> > embedded systems?) And this is probably not only relevant for sed?
> 
> All writes are affected I believe, so there is no point in modifying
> such or such command to perform sync writes, especially as it is
> counterperformant. There are power safe systems that don't require that.
> 
> On our boards, what we do is simply mounting flash filesystems in sync mode:
> 
> mount -t ubifs -o sync ubi0:rootfs /rootfs
> 
> Christophe

I also believe that all file writes are affected in one way or the other, but I feel that the situation is a bit different when editing system critical files.
Any file write that needs to be power-fail safe should follow the pattern "copy, edit, move" regardless of filesystem, which is already done by many applications that edit critical files.
Synchronizing the copy is not needed on synchronus filesystems or on ext4 that does the syncronization for you (after a long discussion between ext4 developers and application developers), but for most asynchronus filesystems it needs to be manually synchronized.
Since the purpose of "copy, edit, move" in sed probably(?) is to make a fail safe file update, is it not out of interest to have a feature for supporting asynchronus filesystems?

The performance gain from using asynchronus filesystems is big enough that I feel that just forcing systems to be synchronus perhaps not is the correct way? (In my view it is safe to run embedded systems on filesystems like ubifs, as long as critical files are updated with care.)

Regards
Sebastian

> >
> > There is also a part 2 that arises when trying to "manually" do a safe
> > write: since the fsync applet uses the O_NOATIME flag it is impossible
> > for user1:group1 to synchronize a directory owned by user2:group1 (you
> > get an "Operation not permitted" error from fsync). Is this intended?
> > (Using gnu sync [8.26] and synchronizing on a specific folder works for
> > the same situation.)
> >
> > Regards
> > Sebastian Brand
> >
> >
> >
> > _______________________________________________
> > busybox mailing list
> > busybox at busybox.net
> > http://lists.busybox.net/mailman/listinfo/busybox
> >


More information about the busybox mailing list