Re: CRC error when mounting UBIFS

[Artem Bityutskiy <dedekind1@gmail.com>]

On Fri, 2010-06-04 at 18:18 +0200, Leo Barnes wrote:
> You were completely right that the errors were driver related. I
> created a test that tested page-aligned/unaligned reads of different
> lengths and then managed to spot the error in the driver. I will send
> in the test once I have cleaned up the code a bit. Might be useful for
> someone else.

Could you please patch mtd_readtest and send the patch?

> A new question:
> Background:
> The driver in use in the device does all communication with the
> NAND-chipset/controller via DMA. Some of the problems I had with the
> driver was that UBI in some cases sends vmalloc'd buffers to the
> mtd-driver for reading and writing which failed spectacularly (it
> might have been kmalloc'd buffers that were not allocated with
> GFP_DMA, I'm unsure if DMA would succeed in this case). Since I dont
> know exactly how UBI manages it's memory buffers, my question might be
> impossible to implement efficiently.

Yes, both UBI and UBIFS use vmalloc() buffers when they manage whole
eraseblocks - e.g., in UBIFS garbage collector when scanning the
journal, or in UBI when moving eraseblocks for wear-leveling purposes.
The reason is that eraseblocks may be large (e.g., 256 KiB), and
kmalloc() that much of contiguous physical memory is prone to fail.

The way to fix this is to make UBI/UBIFS use arrays of pages instead. Or
array of 2, 4, 8, etc pages, or it may be flexible and contain a field
which describes the allocation order. And then UBI/UBIFS code should be
amended correspondingly.

This will need some effort, but I think a skilled engineer would do this
relatively quickly. We are not actively working on UBI/UBIFS now, so we
will unlikely implement this, but I'd be happy to help someone else to
do this.

Many people ask about small features like security xattrs, or NFS
support, or DMA friendliness, but it is strange that people want ready
solutions instead of investing a bit of time and just implementing this.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)