Trond Myklebust wrote: > On Sun, 2021-11-07 at 00:03 +0000, Rick Macklem wrote: > > Hi, > > > > I ran a simple test using a Linux 5.12 client NFSv4.2 mount > > against a FreeBSD pNFS server, where the DS is out of space > > (intentionally, by creating a large file on it). > > > > I tried to write a file on the Linux NFS client mount and the > > mount point gets "stuck" (will not <ctrl>C nor "umount -f"). > > --> The client is attempting writes against the DS repeatedly, > > with the DS replying NFS4ERR_NOSPC. (Same byte offsets, > > over and over and over again.) > > --> The client is repeatedly sending RPCs with LayoutError in > > them to the MDS, reporting the NFS4ERR_NOSPC. > > > > I'll leave it up to others, but failing the program trying to > > write the file with ENOSPC would seem preferable to the > > "stuck" mount? > > --> Removing the large file from the DS so that the Writes > > can succeed does cause the client to recover. > > > > The client expectation is that the MDS will either remedy the > situation, or it will return an appropriate application-level error to > the LAYOUTGET. Thanks Trond, that worked fine for NFSv4.2. I tweaked the pNFS server to reply NFS4ERR_NOSPC to LayoutGet and that worked fine. (This is triggered by the LayoutError.) For NFSv4.1, things don't work as well, since there is no LayoutError operation. The LayoutReturn has the NFS4ERR_NOSPC error in it, but that doesn't happen until it finishes (which doesn't happen until I free up space on the DS). But I can live with only 4.2 working well. I can't be bothered endlessly probing the DSs to see if they are out of space. rick What we do not expect is for the client to have to handle DS level errors. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
