sub pagesize write atomicity concern

[Arthur Kunkle]

A project I am currently involved with is considering using a JFFS2
partition on top of a
Spansion NOR flash device.  This file system will be used for storing
critical operation
parameters.  The use of the area will be very similar to the tried and true
Unix "passwd" utility example, i.e.

cp paramA paramA.new
<update paramA.new with new data>
mv paramA.new paramA

With this project (as many other embedded ones), the "either all or nothing"
property of the mv operation is key, expecting that a power failure could occur
anywhere within rename().  In studying the JFFS2 implementation as well as
the mailing list archives, it seems that JFFS2 provides this in my
situation because:

1. The update to the dirent node will be less than a page-size
2. JFFS2 does not buffer writes to NOR chips (as it does for NAND, apparently)

However, the following mailing list entry did raise a red flag:


http://mhonarc.axis.se/jffs-dev/msg00762.html

"Upon reading the checkfs source, I think I know what's happening here. I
may have mislead you about write atomicity. We _normally_ write a whole
page at once, so you will find that writes which don't cross page
boundaries are atomic. _BUT_ when we're at the end of an erase block and
there's insufficient free space to write the whole page, we still split the
data up into two nodes - one filling up the erase block to the end, and the
remainder of the data in the first node of a new block."

--dwmw2

This was from June of 2001.  I wanted to see if this same type of limitation
still existed as of 2.6.28+.  If so, what precautions must be taken to ensure
that this erase block boundary issue is not a problem for this *critical* mv's?

Thanks in advance.

--Arthur