> On Jan 11, 2023, at 9:15 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Tue, Jan 10, 2023 at 2:04 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >>> On Jan 10, 2023, at 1:47 PM, Jorge Mora <jmora1300@xxxxxxxxx> 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. >> 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
