JFFS2: truncated files after power loss scenario

[Albrecht Dreß]

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:
> 
> http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions
> 
> 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);
write();
fsync();
close();
sync();		// #1
rename(scratch, realname);
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,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20110206/48cc614c/attachment.sig>