> On Jul 21, 2022, at 11:12 AM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > >> On Jul 21, 2022, at 10:03 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: >> >> Following up, using NFS loopback with a 5GB scratch device on a Google >> Compute Engine VM, generic/476 passes using a 4.14 LTS, 4.19 LTS, and >> 5.4 LTS kernel. So this looks like it's a regression which is in 5.10 >> LTS and newer kernels, and so instead of patching it out of the test, >> I think the right thing to do is to add it to a kernel >> version-specific exclude file and then filing a bug with the NFS >> folks. > > Quite apart from the question of whether to exclude that test > rather than troubleshoot, I would like to state that testing NFS > in loopback, while possibly convenient for Q/A, is pretty fraught. > > - Loopback means the client and server are part of the direct > reclaim path on the same system, which makes livelock or deadlock > much more likely. Given that these test systems are typically > small, that pushes the stack even further into this territory. > > - Loopback means there's often no way to know which part of > the stack (client or server) is the problem. And by the way, it's even worse if that single system acts as both the NFS server scratch device and the server under test. > Any NFS test needs to have no less than two test systems, > otherwise what you're really testing is how the system handles > memory exhaustion. An important test, no doubt, but it doesn't > paint a full picture. > > > -- > Chuck Lever > > > -- Chuck Lever
