search

linux-nfs / nfsd

Linux kernel source tree
Other
0 stars 0 forks source link

NFSD should support a truly atomic OPEN(CREATE) #18

Closed chucklever closed 7 months ago

chucklever commented 7 months ago

This was bugzilla.linux-nfs.org 382

[Chuck Lever 2022-02-18 19:30:35 UTC] Bruce says: "It seems to me a fundamental design flaw that we're creating the file and then opening it as two separate operations. If the former succeeds but the latter fails, we're stuck without any reasonable reply to the client.

We should instead be calling into the vfs once to ask it to open the file and create it as one step. That will require some reorganization of the NFSv4 open code. And I'm not sure what the right vfs call is."

We also need one or more additions to the pynfs suite to test the existence and correct operation of atomic OPEN(CREATE).

chucklever commented 7 months ago

[Chuck Lever 2022-02-18 19:34:29 UTC] Bruce suggests lowering the max files number to an artificially small value to induce an OPEN failure under intensive workloads. Another option would be to put an artificial delay between the VFS open and create calls in the server.

chucklever commented 7 months ago

[J. Bruce Fields 2022-02-18 21:40:30 UTC] Note in the bad case, do_open_lookup() succeeds and then nfsd4_process_open2() fails--this is the case identified by the "failed to open newly-created file!" WARNing at the end of nfsd4_file.

Red Hat QE is hitting this case (at least intermittently) with the lustre-racer test; see https://bugzilla.redhat.com/show_bug.cgi?id=1905809.

chucklever commented 7 months ago

[Chuck Lever 2022-02-18 21:55:02 UTC] The goal is to ensure that OPEN with OPEN4_CREATE is guaranteed to succeed whenever the target file is successfully created. It's a bug that the target file is created but the OPEN fails.

chucklever commented 7 months ago

[Chuck Lever 2022-05-27 18:15:16 UTC] Fix merged into v5.19