UBIFS power cut issues

JiSheng Zhang jszhang3 at gmail.com
Fri Sep 11 05:33:38 EDT 2009


Hi Artem,


2009/9/10 Artem Bityutskiy <dedekind1 at gmail.com>:
>
>      * User creates an empty file f.dat. The file is synchronous, or
>        UBIFS is mounted in synchronous mode. User calls the write()
>        function with a 10MiB buffer.
>      * The kernel first copies all 10MiB of the data to the page cache.
>        Inode size is changed to 10MiB as well and the inode is marked
>        as dirty. Nothing has been written to the flash media so far. If
>        a power cut happens at this point, the user will end up with an
>        empty f.dat file.
>      * UBIFS sees that the I/O has to be synchronous, and starts
>        synchronizing the inode. First of all, it writes the inode node
>        to the flash media. If a power cut happens at this moment, the
>        user will end up with a 10MiB file which contains no data
>        (hole), and if he read this file, he will get 10MiB of zeroes.
>      * UBIFS starts writing the data. If a power cut happens at this
>        point, the user will end up with a 10MiB file containing a hole
>        at the end.
>
> Note, if the I/O was not synchronous, UBIFS would skip the last step and
> would just return. And the actual write-back would then happen in
> back-ground. But power cuts during write-back could anyway lead to files
> with holes at the end.

Thanks very much for this document, excellent document, I like it very much.
>
> Thus, synchronous I/O in UBIFS provides less guarantees than JFFS2 I/O -
> UBIFS has an effect of holes at the end of files. In ideal world
> applications should not assume anything about the contents of files
> which were not synchronized before a power-cut has happened. And
> "mainstream" file-systems like ext3 do not provide JFSS2-like
> guarantees.
>
> However, UBIFS is sometimes used as a JFFS2 replacement and people may
> want it to behave the same way as JFFS2 if it is mounted synchronously.
> This is doable, but needs some non-trivial development, so this was not
> implemented so far. On the other hand, there was no strong demand. You
> may implement this as an excercise, or you may try to convince UBIFS
> authors to do this.

Hmmm, this style(there's hole at the end of file) can be accepted.

Thanks again,
Jisheng



More information about the linux-mtd mailing list