Seems per-I/O hints are not getting the love they deserve. Apart from the block device, the usecase is when all I/Os of VM (or container) are to be grouped together or placed differently. Per-IO hints are fine-granular (enough for userspace to build per-process/vm/file/whatever etc.) and add the flexibility we have lacked so far. As for conflict, I doubt if that exists. Please see below: > 2) A per-I/O interface to set these temperature hint conflicts badly > with how placement works in file systems. If we have an urgent need > for it on the block device it needs to be opt-in by the file operations > so it can be enabled on block device, but not on file systems by > default. This way you can implement it for block device, but not > provide it on file systems by default. If a given file system finds > a way to implement it it can still opt into implementing it of course. Why do you see this as something that is so different across filesystems that they would need to "find a way to implement"? Both per-file and per-io hints are supplied by userspace. Inode and kiocb only happen to be the mean to receive the hint information. FS is free to use this information (iff it wants) or simply forward this down. Per-file hint just gets stored (within inode) without individual FS involvement. Per-io hint follows the same model (i.e., it is set by upper layer like io_uring/aio) and uses kiocb to store the hint. It does not alter the stored inode hint value! After patch #3, filesystems have both per-file and per-io information available. And as before, they can use that hint info (from kiocb or inode) and/or simply forward. The generic code (like fs/direct-io.c, fs/iomap/direct-io.c etc.,) already forwards the incoming hints, without any intelligence. And we need just that because with user-passed hints, the onus of intelligence is on the userspace. This is how hints work on xfs/ext4/btrfs files at this point. The owner of the file (filesystem, block, whatever) can still use the incoming hints to do any custom/extra feature. Either from inode or from kiocb depending on what information (per-file or per-io hint) it finds more useful for that custom feature. For example, F2FS is using per-inode information to do something custom and that part has not been changed by these patches. Overall, I do not see the conflict. It's all user-driven. No? For the currently uncommon case when FS decides to generate its own hints (as opposed to userspace hint consumer/forwarder), it can directly put the hint value in bio.
