server tests: remove some redundant documentation

Keeping another list of commandline options here seems pointless, and
it's already bitrotted.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
4.1 server tests: fix reboot script option group

Actually, note the text here isn't quite right.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server tests: delete code, don't comment it out

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server tests: default to non-zero uid/gid

As 4.1 tests do.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server tests: port showtraffic option from 4.1 to 4.0

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server tests: port xmlout option from 4.1 to 4.0

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
4.0 server tests: accept RECLAIM_BAD or NO_GRACE

After working-group review of rfc3530bis: RECLAIM_BAD or NO_GRACE should
be acceptable returns in these case.  (RECLAIM_CONFLICT would make sense
only when the server is actually seeing conflicting reclaims in this
grace period.)

RECLAIM_BAD just means this lock is bad, and NO_GRACE means "don't try
to reclaim anything else either".  Since we're not reclaiming multiple
locks from any one client in any of these tests, the two are equivalent.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server tests: RNM16 should also allow NOTEMPTY

Both posix and the linux man pages accept either error on rename.
Different linux filesystems seem to choose differently.  I can't find
much support in the NFS rfc's for choosing one over the other.  So let's
allow either.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server 4.0 tests: test change attribute granularity

A server that bases its change attribute on time may fail to update the
change attribute correctly if consecutive file modifications come too
quickly.  Test for that case.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server41tests: rebooted clients not destroyed till confirm

Arrrrrrrrgh.  Not only does this test insist on the *opposite* of the
correct behavior, but judging from the comment somebody left it in there
knowing that.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server41tests: a session counts as "state"

For the purposes of rfc 5661 18.3.5.4 I believe that a session counts as
"state".

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
server41tests: make sure reboot *does* destroy client on confirm

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
todo updates
4.1 server tests: EID6e should allow NFS4ERR_PERM

Yes, we're trying to do an update with the wrong verifier.  But we've
also got the principal wrong.  Strictly speaking this falls only under
case 8 of the spec, but I can't see why responding as in case 9 wouldn't
also be acceptable.  (And arguably perhaps there's some benefit to
performing the actual permission check earlier.)

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
RPC: fix rpc hang on large ios

Signed-off-by: Fred Isaman <iisaman@netapp.com>
SRVR: add [r|w]size attributes to root fs

Without this, the linux client ignores [r|w] size atributes on
child filesystems, instead using a default of 1024.

Signed-off-by: Fred Isaman <iisaman@netapp.com>
XDR: Fix bug in xdrgen __repr__ generation

If an enum type is defined as opaque the generated __repr__ function raises
an exception trying to use the list as a key for a dict.get() lookup.

Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Fred Isaman <iisaman@netapp.com>
SRVR: use requested iomode on layoutget

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Fred Isaman <iisaman@netapp.com>
TODO notes

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
4.1 server tests: delete some redundant comments

Signed-off-by: J. Bruce Fields <bfields@redhat.com>