On Sat, 2024-02-17 at 12:05 -0500, Chuck Lever wrote: > On Fri, Feb 16, 2024 at 06:57:16PM +0000, Trond Myklebust wrote: > > On Fri, 2024-02-16 at 18:25 +0000, Chuck Lever III wrote: > > > > > > > > > > On Feb 16, 2024, at 1:19 PM, Chuck Lever III > > > > <chuck.lever@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > On Feb 16, 2024, at 1:18 PM, Trond Myklebust > > > > > <trondmy@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > On Fri, 2024-02-16 at 08:33 -0500, Chuck Lever wrote: > > > > > > On Thu, Feb 15, 2024 at 08:24:50PM -0500, > > > > > > trondmy@xxxxxxxxxx wrote: > > > > > > > From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > > > > > > > > > > > > > > Commit bb4d53d66e4b broke the NFSv3 pre/post op > > > > > > > attributes > > > > > > > behaviour > > > > > > > when doing a SETATTR rpc call by stripping out the calls > > > > > > > to > > > > > > > fh_fill_pre_attrs() and fh_fill_post_attrs(). > > > > > > > > > > > > Can you give more detail about what broke? > > > > > > > > > > Without the calls to fh_fill_pre_attrs() and > > > > > fh_fill_post_attrs(), we > > > > > don't store any pre/post op attributes and we can't return > > > > > any > > > > > such > > > > > attributes to the NFSv3 client. > > > > > > > > I get that. Why does that matter? > > > > > > Or, to be a little less terse... clients rely on the pre/post > > > op attributes around a SETATTR, I guess, but I don't see why. > > > I'm missing some context. > > > > 1. SETATTR is not atomic, and is not implemented as being atomic > > in > > Linux. It is perfectly possible for, say, the file to get > > truncated, but for the other attribute changes to get dropped > > on > > the floor. NFSv4 communicates that information via the > > bitmap. > > NFSv3 does it using the pre/post attributes. > > 2. When doing a guarded SETATTR, if the server returns > > NFS3ERR_NOT_SYNC, the client may want to update its cached > > ctime > > and resend. > > All granted, but I'm still not clear. Let me ask this a different > way. > > As far as I can tell, it's always been optional for an NFSv3 server > to include pre- and post-op attributes in wcc_data. Both the > pre_op_attr and post_op_attr XDR types start with an > "attribute_follows" discriminator. Therefore clients cannot rely on > receiving those attributes. > > The patch description says that "Commit bb4d53d66e4b broke the NFSv3 > ^^^^^ > pre/post op attributes ...". And I think you also used the word > "nasty" in an earlier email. So what is broken if the server /never/ > returns those attributes? What are the application-visible effects > of the server behavior change in bb4d53d66e4b ? > > I don't have a problem reverting that part of bb4d53d66e4b, but > "broke" is doing some heavy lifting here. I want to understand why > we need to revert. Because it seems to me the server's current NFSv3 > SETATTR implementation is spec-compliant. As far as I can tell, > bb4d53d66e4b might result in a little more network traffic in some > cases, but it won't impact interoperability or outcome. > As I said above, you broke the NFSv3 client's ability to determine whether or not the SETATTR was a failure, success or a partial success. That's not heavy lifting, it is a fact. The function nfsd_setattr() uses two different calls to notify_change() in order to perform its function. Either one of them can return an error. Either one of them can fail, and the way that the client finds out whether or not the operation was a partial success is by examining the pre/post op attributes (NFSv3) or the returned bitmap (NFSv4). The patch does not try to fix NFSv4, since AFAICS, that code has always been broken. However, the NFSv3 code was not broken prior to bb4d53d66e4b. It was correctly returning pre/post op attributes that reflected the success/failure of the setattr operation. That is therefore a regression. Furthermore, it is a totally unnecessary regression. The whole point of SETATTR is to change the value of the attributes of the exact same file for which the pre/post op attributes are being retrieved. There is no extra disk access required to retrieve those attributes, nor should there be any other overhead other than copying them into the buffer. > Do you mean that you want to restore the previous, more optimized, > server behavior to return pre- and post-op attributes when they are > available? And if so, what is the application-visible benefit? Application correctness: the ability to see that your file got truncated despite the RPC call returning an error. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
