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.
