On 10.10.2024 11:13, Christoph Hellwig wrote:
On Thu, Oct 10, 2024 at 09:07:36AM +0200, Javier González wrote:
I think we should attempt to pursue that with an example in mind. Seems
XFS is the clear candidate. You have done work already in enable SMR
HDDs; it seems we can get FDP under that umbrella. This will however
take time to get right. We can help with development, testing, and
experimental evaluation on the WAF benefits for such an interface.
Or ZNS SSDs for that matter.
Maybe. I do not see much movement on this.
However, this work should not block existing hardware enabling an
existing use-case. The current patches are not intrusive. They do not
make changse to the API and merely wire up what is there to the driver.
Anyone using temperaturs will be able to use FDP - this is a win without
a maintainance burden attached to it. The change to the FS / application
API will not require major changes either; I believe we all agree that
we cannot remove the temperatures, so all existing temperature users
will be able to continue using them; we will just add an alternative for
power users on the side.
As mentioned probably close to a dozen times over this thread and it's
predecessors: Keeping the per-file I/O hint API and mapping that to
FDP is fine. Exposing the overly-simplistic hints to the NVMe driver
through the entire I/O stack and locking us into that is not.
I don't understand the "locking us into that" part.
So the proposal is to merge the patches as they are and commit to work
together on a new, better API for in-kernel users (FS), and for
applications (syscall, uring).
And because of that the whole merge it now and fix it later unfortunately
doesn't work, as a proper implementation will regress behavior for at
least some users that only have the I/O hints API but try to emulate
real stream separation with it. With the per-I/O hints in io_uring that
is in fact almost guaranteed.
I do not thing this argument is valid. These patches are not a merge now,
fix later. It is ma: use the current interface, work together on a new
one, if needed.
The new interface you are talking about is not clear to me, at all. If
you could share some patches on how that would look like, then it would
give a much clearer idea of what you have in mind. The whole idea of
let's not cover an existing use-case because we might be able to do
something in the future is not very tangible.
