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.
