On 9/17/2024 9:33 PM, Kanchan Joshi wrote: > On 9/17/2024 11:50 AM, Christoph Hellwig wrote: >>>> But if we increase this to a variable number of hints that don't have >>>> any meaning (and even if that is just the rough order of the temperature >>>> hints assigned to them), that doesn't really work. We'll need an API >>>> to check if these stream hints are supported and how many of them, >>>> otherwise the applications can't make any sensible use of them. >>> - Since writes are backward compatible, nothing bad happens if the >>> passed placement-hint value is not supported. Maybe desired outcome (in >>> terms of WAF reduction) may not come but that's not a kernel problem >>> anyway. It's rather about how well application is segregating and how >>> well device is doing its job. >> What do you mean with "writes are backward compatible" ? >> > Writes are not going to fail even if you don't pass the placement-id or > pass a placement-id that is not valid. FDP-enabled SSD will not shout > and complete writes fine even with FDP-unaware software. > > I think that part is same as how Linux write hints behave ATM. Writes > don't have to carry the lifetime hint always. And when they do, the hint > value never becomes the reason of failure (e.g. life hints on NVMe > vanish in the thin air rather than causing any failure). > FWIW, I am not sure about current SCSI streams but NVMe multi-stream did not tolerate invalid values. Write command with invalid stream was aborted. So in that scheme of things, it was important to be pedantic about what values are being passed. But in FDP, things are closer to Linux hints that don't cause failures. With the plain-numbers interface, the similarities will increase.
