> On Jul 21, 2022, at 2:04 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Thu, Jul 21, 2022 at 03:14:30PM +0000, Chuck Lever III wrote: >>> - 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. >> > > I believe Boyang has stated that this has been seen both in loopback > and in an externally mounted configuration. > > Boyang, in your external exported configuration, was the lockup > happening on the client or server system? > > - Ted > > P.S. I just don't have the capability of testing NFS on separate VM's > for the client and server using gce-xfstests. It's on my list of > things to implement someday, but I just don't have time at the moment. > Maybe a GSOC project someday... Or if someone has time, patches or > pull requests to https://github.com/tytso/xfstests-bld are gratefully > accepted. :-) I agree that Q/A and dev testing needs are distinct, so a dev might have a simpler series of tests to run and fewer resources to run them in. That said, I've had it on my to-do list for some time to find an easy way to run automated multi-host tests, and I've been told it should be straight-forward, but I've been swamped lately. Many of us in the NFS community actually don't run the tests that require a scratch dev, because many of them don't seem relevant to NFS, or they take a long time to run. Someday we should sort through all that :-) For the particular issue with generic/476, I would like to see if there's a reason that test takes a long time and fails with a small scratch dev before agreeing that excluding it is the proper response. -- Chuck Lever
