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