JFFS2: truncated files after power loss scenario
albrecht.dress at arcor.de
Sun Feb 6 13:40:10 EST 2011
Am 06.02.11 18:39 schrieb(en) Artem Bityutskiy:
> Well, there was a huge debate about this. Rename does not ensure sync in many file-systems, and posix does not require this. But user-spaces relies on this and many people believe this should obviously be guaranteed. So ext4 and may be some other FSes adjusted accordingly. I wrote about this in UBIFS FAQ:
> You'll find all the relevant links there.
Thanks a lot for the pointers!
Unfortunately, they are more more about ubi & ext4, but I am in particular interested in JFFS2's behaviour, so please excuse my questions, but it's a really critical point... Currently, I use the following sequence to write my configs to jffs2 (both NOR flash and mtd-ram):
open(scratch, O_RDWR | O_CREAT | O_TRUNC, perms);
sync(); // #1
sync(); // #2
As far as I understand the information you cited, this should be safe under all circumstances for jffs2. Is that assumption correct?
As calling sync() might be a lot more expensive than fsync() if other file systems are used simultaneously (I have a vfat fs on a CF card open), my question is now if I can safely omit either sync() #1 or #2 or both?
When reading, I first try realname, and if that fails scratch, as to cover the case that rename() was killed in mid-air so realname has already been removed from the directory, but scratch is still there. Can this case happen at all for jffs2?
Thanks in advance,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: not available
More information about the linux-mtd