mtdblock is slow compared to mtd device

[Claus Stovgaard]

On Thu, 2021-04-08 at 09:26 +0200, Richard Weinberger wrote:
> 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).

Nice information. This means that it is not with FTLs one need to work.
Just FYI, my coworker Edgar did a quick test of mtdblock with changing
the 512 block size to page size of 4k (above the page size it did not
work) resulting in an improvement from around 4.2 MB/s to 33.2 MB/s for
our flash

> 
> > 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. :-)
> 
> > ...
> 
> UBI can operate in read-only mode when the MTD is write protected.
> See MTD_WRITEABLE flag.
> 
> > ....
> 
> I'd start with ubiblock plus squashfs or erofs.
> There is surly room for improvement, but it should be doable.
> 

Thanks for all your help. I did a test with ubiblock together with a
squashfs. This improved the performance significant. A quick dd on the
ubiblock device resulted in around 70 to 80 MB/s for 1Mb blocksize
depending on the amount of data.
I will look into the MTD_WRITABLE flag later. As I am currently forced
to use an older kernel in the form of version 4.19, I will wait and
hope that I can get it upgraded to 5.10 later this year. Therefrom it
would be easier if I could get time to improve the performance in the
code, so it is more upstream friendly. At least I can always hope that
I can have the time for it.

Thanks again Richard.

/Claus