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?
