[PATCH v7 0/3] FDP and per-io hints
Christoph Hellwig
hch at lst.de
Mon Oct 14 04:50:52 PDT 2024
On Mon, Oct 14, 2024 at 09:08:24AM +0000, Javier Gonzalez wrote:
[can you fix your mailer please, no full quotes, and especially not
quotes of the mail headers]
> > What do you gain from that? NVMe does not understand data temperatures,
> > so why make up that claim?
>
> I expressed this a couple of times in this thread. It is no problem to
> map temperatures to a protocol that does not understand the semantics.
And I've agreed every time with you. But the important point is that we
must not do it in the driver where all context is lost.
> > Especially as it directly undermindes any file system work to actually make use of it.
>
> I do not think it does. If a FS wants to use the temperatures, then they
> would be able to leverage FDP besides SCSI.
What do you mean with that? This is a bit too much whitepaper vocabularly.
We have code in XFS that can make use of the temperature hint. But to
make them work it actually needs to do real stream separation on the
device. I.e. the file system consumes the temperature hints.
> And if we come up with a better interface later on, we can make the changes then.
> I really do not see the issue. If we were adding a temperature abstraction now, I would agree with
> You that we would need to cover the use-case you mention for FSs from the beginning, but this
> Is already here. Seems like a fair compromise to support current users.
Again, I think the temperature hints at the syscall level aren't all
bad. There's definitively a few things I'd like to do better in hindsight,
but that's not the point. The problem is trying to turn them into
stream separation all the way down in the driver, which is fundamentally
broken.
> - How do we convince VFS folks to give us more space for hints at this point?
What space from VFS folks do you need for hints? And why does it
matter?
More information about the Linux-nvme
mailing list