On Jan 11, 2023, at 9:15 AM, Olga Kornievskaia [off-list ref] wrote:

On Tue, Jan 10, 2023 at 2:04 PM Chuck Lever III [off-list ref] wrote:

quoted

quoted

On Jan 10, 2023, at 1:47 PM, Jorge Mora [off-list ref] wrote:

If multiple bits are set, select just one using a predetermined
order of precedence. If there are no bits which correspond to
any of the advice values (POSIX_FADV_*), the server simply
replies with NFS4ERR_UNION_NOTSUPP.

If a client sends a bitmap mask with multiple words, ignore all
but the first word in the bitmap. The response is always the
same first word of the bitmap mask given in the request.

quoted

Does it provide some
kind of performance benefit, for instance? The patch description
really does need to provide this kind of rationale, and hopefully
some performance measurements.

Do the POSIX_FADV_* settings map to behavior that a client can
expect in other server implementations?

I thought the purpose of IO_ADVISE is to advise but not expect. If the
server wants to do something with the knowledge it can.

Fair enough: what should the Linux server do with these hints?
Show some data that demonstrates a specific benefit to application
workloads for the server implementation choices that Jorge proposed.

I'm not saying NAK, more like "not yet." This work doesn't look ready
to be merged without a way to evaluate whether the proposed design
choices are reasonable and will do little or no harm. There's no
discussion of that in either a cover letter or the patch descriptions,
so it's really hard for me to tell whether this has been thought
through.

In the meantime, the client side is supposed to work correctly
whether the server implements IO_ADVISE or not... so I don't see
a pressing need to merge a server IO_ADVISE implementation until we
have a sensible architectural direction and one or more use cases
that can actually benefit.


--
Chuck Lever