Re: [PATCH v7 0/3] FDP and per-io hints

Kanchan Joshi
2024-10-17T14:35:47Z

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.