FTL layer & block size

[Carlos Sanchez <ca...@geotab.com>]

Hi all,

I want to request opinions on the block size returned by the FTL layer.

MTD drivers expose two "block sizes" on the geometry data: erase block
size (the "flash page" size, which must be erased before writing) and
the read/write block size (used for read/write operations).

Classical block devices export just one block size. This is normal
because this size is used for random access disks where you do not
need to "erase" before writing.

When the FTL driver exports a MTD "to look like" a block device, it
passes (read/write) block size directly as the "simulated" block
device's block size. This means file systems attaching to the
FTL-exposed block device will typically try to break read/write
operations in chunks of that size. As the underlying MTD requires
erasing before writing, and erase size is typically N * block size,
this results in multiple erase operations per write.

I was thinking it might be better to use "erase block size" as "block
size" when exporting an MTD as a block device through FTL.
Functionality will not be affected; some filesystems (which size their
buffer based on block device size) might use more buffers, but
minimizing erases is usually the goal when accessing an MTD.

Thoughts?

Carlos

Re: FTL layer & block size

[Carlos Sanchez <ca...@geotab.com>]

Not neccesarily. If a program needs to know the block size, it should
request the geometry using ioctl, and use that value. Even without
that change, different block devices have different block sizes that
the programs must work with. IMHO this should affect only memory
consumption by filesystem drivers (and only for those platforms using
the ftl driver to translate mtd2block) and write efficiency (the
latter for the better).

In your opinion, how could this affect an existing program?

Carlos

On Thu, Apr 9, 2026 at 5:39 PM Sebastien Lorquet <se...@lorquet.fr> wrote:
>
> Hello,
>
> My initial feeling just by reading your email is that it could break a
> LOT of existing programs if that was changed without a lot of care.
>
> Sebastien
>
>
> On 4/9/26 17:36, Carlos Sanchez wrote:
> > Hi all,
> >
> > I want to request opinions on the block size returned by the FTL layer.
> >
> > MTD drivers expose two "block sizes" on the geometry data: erase block
> > size (the "flash page" size, which must be erased before writing) and
> > the read/write block size (used for read/write operations).
> >
> > Classical block devices export just one block size. This is normal
> > because this size is used for random access disks where you do not
> > need to "erase" before writing.
> >
> > When the FTL driver exports a MTD "to look like" a block device, it
> > passes (read/write) block size directly as the "simulated" block
> > device's block size. This means file systems attaching to the
> > FTL-exposed block device will typically try to break read/write
> > operations in chunks of that size. As the underlying MTD requires
> > erasing before writing, and erase size is typically N * block size,
> > this results in multiple erase operations per write.
> >
> > I was thinking it might be better to use "erase block size" as "block
> > size" when exporting an MTD as a block device through FTL.
> > Functionality will not be affected; some filesystems (which size their
> > buffer based on block device size) might use more buffers, but
> > minimizing erases is usually the goal when accessing an MTD.
> >
> > Thoughts?
> >
> > Carlos



-- 

Carlos Sanchez
Geotab

Senior Team Lead, Embedded Development | Europe

Visit

www.geotab.com

YouTube | LinkedIn


Celebrating 25 years of innovation and impact

Re: FTL layer & block size

[Sebastien Lorquet <se...@lorquet.fr>]

Hello,

My initial feeling just by reading your email is that it could break a 
LOT of existing programs if that was changed without a lot of care.

Sebastien


On 4/9/26 17:36, Carlos Sanchez wrote:
> Hi all,
>
> I want to request opinions on the block size returned by the FTL layer.
>
> MTD drivers expose two "block sizes" on the geometry data: erase block
> size (the "flash page" size, which must be erased before writing) and
> the read/write block size (used for read/write operations).
>
> Classical block devices export just one block size. This is normal
> because this size is used for random access disks where you do not
> need to "erase" before writing.
>
> When the FTL driver exports a MTD "to look like" a block device, it
> passes (read/write) block size directly as the "simulated" block
> device's block size. This means file systems attaching to the
> FTL-exposed block device will typically try to break read/write
> operations in chunks of that size. As the underlying MTD requires
> erasing before writing, and erase size is typically N * block size,
> this results in multiple erase operations per write.
>
> I was thinking it might be better to use "erase block size" as "block
> size" when exporting an MTD as a block device through FTL.
> Functionality will not be affected; some filesystems (which size their
> buffer based on block device size) might use more buffers, but
> minimizing erases is usually the goal when accessing an MTD.
>
> Thoughts?
>
> Carlos