UBIFS robustness questions
Adrian Hunter
adrian.hunter at nokia.com
Fri Jul 24 06:03:40 EDT 2009
Adrian Hunter wrote:
> Hunter Adrian (Nokia-D/Helsinki) wrote:
>> Charles Manning wrote:
>>> This is probably documented somewhere but I could not find it...
>>>
>>> What operations in UBIFS are robust to power failure and which are not?
>> Only sync operations guarantee that changes have reached the flash.
>> There are all the usual ways to sync:
>> fsync/fdatasync a file/directory
>> open a file as synchronous
>> mark a file with the sync flag
>> sync the filesystem
>> mount the file system as synchronous
>>
>>> I know for example that writing a file into flash does not mean it has been
>>> completely written to flash until after a sync, but what about other
>>> operations such as mv?
>> After mv, the containing directory must be sync'd to be sure the change reaches the
>> flash. But rename is atomic so there will always be either the old
>> naming or the new naming
>>
>>> The reasonn I'm asking this is that I want to be able to "hot-swap" a
>>> directory of files without losing any file state.
>> Should be no problem if you sync correctly.
>>
>>> What I'm considerings doing is something like:
>>>
>>> Start with ~/runtime having a sane set of files
>>>
>>> untar etc into ~/updated
>>> sync
>>> mv ~/updated ~/run-time
>>> sync
>>>
>>> What is unacceptable is that, at any time, a power failure/reboot results in
>>> ~/runtime having a non-sane set of files.
>>>
>>> * Does the above sequence look safe?
>> Yes
>
> Well, safe but not possible. You cannot rename over the top
> of a non-empty directory. Sorry I was misleading.
Sorry to drag this out but it seems like it can be done with symlinks
e.g.
/ # mkdir test
/ # cd test
/test # mkdir version1
/test # mkdir version2
/test # echo "This is version 1" > version1/afile
/test # echo "This is version 2" > version2/afile
/test # ln -s version1 current
/test # ln -s version2 next
/test # cat current/afile
This is version 1
/test # cat next/afile
This is version 2
/test # mv -T next current
/test # ls -al
drwxr-xr-x 4 root root 432 Jan 2 01:57 .
drwxrwxrwx 25 root root 1704 Jan 2 01:44 ..
lrwxrwxrwx 1 root root 8 Jan 2 01:46 current -> version2
-rwxr-xr-x 1 root root 261307 Jul 24 2009 mv
drwxr-xr-x 2 root root 224 Jan 2 01:47 version1
drwxr-xr-x 2 root root 224 Jan 2 01:45 version2
/test # cat current/afile
This is version 2
/test #
Note that busybox's 'mv' does not support the -T option
>>> * Is the second sync required?
>> It is required to guarantee that the mv has reached the flash at that
>> point in time i.e. power loss before the second sync => same as if mv
>> was not done
>
More information about the linux-mtd
mailing list