Page corruption when writing non-sequential pages in an MLC NAND eraseblock

[Avery Pennarun]

On Thu, Oct 3, 2013 at 12:40 AM, Ricard Wanderlof
<ricard.wanderlof at axis.com> wrote:
> Just because they place the constraint on the user that the pages must be
> written in order doesn't mean that the device necessarily will malfunction
> if the user violates this. It just means that the designers have the freedom
> to introduce dependencies between the page writes if it makes the design
> easier/better/possible/whatever. It could very well be that for a given
> flash it is possible to do some writes out of order, but to avoid a) tying
> down the actual possibilities for a given flash and b) complicating the
> facts for the user they just specify that 'page writes must be executed in
> order'.
>
> I must admit I wasn't aware of this fact either, but I have no hands-on
> experience with MLC flashes on the other hand.

It seems rather under-documented to me, and I wouldn't be overly
surprised if it's not so much "standard behaviour" as "behaviour some
chip makers decided they could get away with based on usage patterns."
 But ok.

>> This makes /dev/mtdblock completely unusable as it reorders writes.
>> Is /dev/mtdblock known to not work with MLC chips?
>
> I don't think /dev/mtdblock reorders writes; isn't it just exposing the
> underlying /dev/mtd device as a block device essentially in order to make
> the mount command happy?
>
> I would think the two most common uses of flash are either using a flash
> file system such as jffs2 or ubifs, and since each data node has its own
> header and identifier, there is no reason to do anything else but write the
> nodes in order within blocks, and the other use would be to store binary
> blobs, in which again the data would just be stored sequentially from start
> to end.

/dev/mtdblock seems to do very complicated things.  For example, when
using it, you don't need to use flash_erase before writing to blocks.
Also, my device has 1024k eraseblocks, but if I do:

   dd if=/tmp/whatever of=/dev/mtdblock9 bs=1024k

it ends up *reading* from the flash, not just writing to it.  Given
how many ECC errors it also produces on my setup, I think it's also
reordering writes.  This isn't particularly surprising to me since as
soon as you go through the Linux block layer, you're at the mercy of
the disk I/O schedulers etc.  Perhaps it *mostly* won't reorder writes
in simple cases, but I don't think there's any guarantee of this.