mtdblock is slow compared to mtd device

Richard Weinberger richard.weinberger at gmail.com
Thu Apr 8 08:26:54 BST 2021


Claus,

On Tue, Apr 6, 2021 at 2:12 PM Claus Stovgaard
<claus.stovgaard at gmail.com> wrote:
> The 512 bytes sector size is for me kind of oldschool where all
> filesystems where working on this. Has there been any work in making a
> translation layer for filesystems block sizes in the 128k or 1024k
> range, like I would create the squashfs?

In MTD we more or less gave up on FTLs, they are toxic (patents).

> Alternative as I already using UBI for parts of the flash, I am
> wondering about using this together with ubiblock. The question is
> though if it is faster, and for the second part how it handle locked
> flash?

ubiblock will read up to LEB size'ed chunks. So, it should be faster.
If not, I'm all open for improvements. :-)

> One of the reason I am looking into the squashfs is the readonly
> nature, where it fits with the locking capability on the flash chip.
> The plan is to write the data as part of production, and afterwards
> lock the flash for any other writes. How would UBI handle it, if the
> flash is physically locked for writing?

UBI can operate in read-only mode when the MTD is write protected.
See MTD_WRITEABLE flag.

> Any comments regarding storing some data (preferable files) in locked
> norflash, where the read bandwidth much be close to the bandwidth of
> the mtd device is very much welcome.

I'd start with ubiblock plus squashfs or erofs.
There is surly room for improvement, but it should be doable.

-- 
Thanks,
//richard



More information about the linux-mtd mailing list