[LSF/MM/BPF TOPIC] Large block for I/O

[Matthew Wilcox]

On Mon, Jan 08, 2024 at 11:30:10AM -0800, Bart Van Assche wrote:
> On 12/21/23 21:37, Christoph Hellwig wrote:
> > On Fri, Dec 22, 2023 at 05:13:43AM +0000, Matthew Wilcox wrote:
> > > It clearly solves a problem (and the one I think it's solving is the
> > > size of the FTL map).  But I can't see why we should stop working on it,
> > > just because not all drive manufacturers want to support it.
> > 
> > I don't think it is drive vendors.  It is is the SSD divisions which
> > all pretty much love it (for certain use cases) vs the UFS/eMMC
> > divisions which tends to often be fearful and less knowledgeable (to
> > say it nicely) no matter what vendor you're talking to.
> 
> Hi Christoph,
> 
> If there is a significant number of 4 KiB writes in a workload (e.g.
> filesystem metadata writes), and the logical block size is increased from
> 4 KiB to 16 KiB, this will increase write amplification no matter how the
> SSD storage controller has been designed, isn't it? Is there perhaps
> something that I'm misunderstanding?

You're misunderstanding that it's the _drive_ which gets to decide the
logical block size.  Filesystems literally can't do 4kB writes to these
drives; you can't do a write smaller than a block.  If your clients
don't think it's a good tradeoff for them, they won't tell Linux that
the minimum IO size is 16kB.

Some workloads are better with a 4kB block size, no doubt.  Others are
better with a 512 byte block size.  That doesn't prevent vendors from
offering 4kB LBA size drives.