[PATCH v7 0/3] FDP and per-io hints
Christoph Hellwig
hch at lst.de
Thu Oct 10 02:13:33 PDT 2024
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.
> 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.
> 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.
More information about the Linux-nvme
mailing list