On 9/27/23 12:14, Martin K. Petersen wrote:
I don't have any particular problems with your implementation,
although I'm still trying to wrap my head around how to make this
coexist with my I/O hinting series. But I guess there's probably not
going to be a big overlap between devices that support both
features.
Hi Martin,
This patch series should make it easier to implement I/O hint support
since some of the code added by this patch series is also needed to
implement I/O hint support.
However, it still pains me greatly to see the SBC proposal being
intertwined with the travesty that is streams. Why not define
everything in the IO advice hints group descriptor? I/O hints already
use GROUP NUMBER as an index. Why not just define a few permanent
hint descriptors? What's the point of the additional level of
indirection to tie this new feature into streams? RSCS basically says
"ignore the streams-specific bits and bobs and do this other stuff
instead". What does the streams infrastructure provide that can't be
solved trivially in the IO advise mode page alone?
Hmm ... isn't that exactly what T10 did, define everything in the IO
advice hints group descriptor by introducing the new ST_ENBLE bit in
that descriptor?
This patch series relies on the constrained streams mechanism. A
constrained stream is permanently open. The new ST_ENBLE bit in the IO
advice hints group descriptor indicates whether or not an IO advice
hints group represents a permanent stream.
The new ST_ENBLE bit in the IO advice hints group descriptor allows SCSI
devices to interpret the index of the descriptor as a data lifetime.
From the approved T10 proposal:
Table x1 – RELATIVE LIFETIME field
..............................................
Code Relative lifetime
..............................................
00h no relative lifetime is applicable
01h shortest relative lifetime
02h second shortest relative lifetime
03h to 3Dh intermediate relative lifetimes
3Eh second longest relative lifetime
3Fh longest relative lifetime
..............................................
For existing UFS devices which predate RSCS and streams but which
support getting data temperature from GROUP NUMBER, what is the
mechanism for detecting and enabling the feature?
We plan to ask UFS device vendors to modify the UFS device firmware and
to add support for the VPD and mode pages this patch series relies on.
My understanding is that this can be done easily in UFS device firmware.
Although it is technically possible to update the firmware of UFS
devices in smartphones, most smartphones do not support this because
this is considered risky. Hence, only new smartphones will benefit from
this patch series.
I do not want to add support in the Linux kernel for how conventional
UFS devices use the GROUP NUMBER field today. Conventional UFS devices
interpret the GROUP NUMBER field as a "ContextID". The ContextID
mechanism has a state, just like the SCSI stream mechanism. UFS contexts
need to be opened explicitly and are closed upon reset. From the UFS 4.0
specification: "No ContextID shall be open after power cycle."
Please let me know if you need more information.
Bart.
