From: Bart Van Assche <bvanassche@acm.org>
To: Christoph Hellwig <hch@infradead.org>,
Matthew Wilcox <willy@infradead.org>
Cc: Hannes Reinecke <hare@suse.de>,
lsf-pc@lists.linuxfoundation.org, linux-mm@kvack.org,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [LSF/MM/BPF TOPIC] Large block for I/O
Date: Mon, 8 Jan 2024 11:30:10 -0800 [thread overview]
Message-ID: <9b46c48f-d7c4-4ed3-a644-fba90850eab8@acm.org> (raw)
In-Reply-To: <ZYUgo0a51nCgjLNZ@infradead.org>
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?
Thanks,
Bart.
next prev parent reply other threads:[~2024-01-08 19:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7970ad75-ca6a-34b9-43ea-c6f67fe6eae6@iogearbox.net>
2023-12-20 10:01 ` LSF/MM/BPF: 2024: Call for Proposals Daniel Borkmann
2023-12-20 15:03 ` [LSF/MM/BPF TOPIC] Large block for I/O Hannes Reinecke
2023-12-21 20:33 ` Bart Van Assche
2023-12-21 20:42 ` Matthew Wilcox
2023-12-21 21:00 ` Bart Van Assche
2023-12-22 5:09 ` Christoph Hellwig
2023-12-22 5:13 ` Matthew Wilcox
2023-12-22 5:37 ` Christoph Hellwig
2024-01-08 19:30 ` Bart Van Assche [this message]
2024-01-08 19:35 ` Matthew Wilcox
2024-02-22 18:45 ` Luis Chamberlain
2024-02-25 23:09 ` Dave Chinner
2024-02-26 15:25 ` Luis Chamberlain
2024-03-07 1:59 ` Luis Chamberlain
2024-03-07 5:31 ` Dave Chinner
2024-03-07 7:29 ` Luis Chamberlain
2023-12-22 8:23 ` Viacheslav Dubeyko
2023-12-22 12:29 ` Hannes Reinecke
2023-12-22 13:29 ` Matthew Wilcox
2023-12-22 15:10 ` Keith Busch
2023-12-22 16:06 ` Matthew Wilcox
2023-12-25 8:55 ` Viacheslav Dubeyko
2023-12-25 8:12 ` Viacheslav Dubeyko
2024-02-23 16:41 ` Pankaj Raghav (Samsung)
2024-01-17 13:37 ` LSF/MM/BPF: 2024: Call for Proposals [Reminder] Daniel Borkmann
2024-02-14 13:03 ` LSF/MM/BPF: 2024: Call for Proposals [Final Reminder] Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b46c48f-d7c4-4ed3-a644-fba90850eab8@acm.org \
--to=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linuxfoundation.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).