Niklas Edmundsson wrote:
On Fri, 16 Feb 2007, Niklas Edmundsson wrote:
At the minimum, sanity.sh should be able to be run on a client.
Start your patchless client, then just
/lustre/tests# sh sanity.sh
Actually, env MOUNT=/path/to/your/filesystem sh sanity.sh, otherwise
it will create a bunch of files in /mnt/lustre, and all
lustre-specific tests will fail ;)
By the way, I don't think that sanity.sh has been sanitized to
support patchless clients... I'm getting a lot of:
./sanity.sh: line 117: [: patchless: integer expression expected
which seems to make it skip all tests that checks for a lustre kernel
version. I suspect that the correct approach is to apply all tests to
patchless clients, not skip them.
right. I'll add a [ $GOT_VER == "patchless"] && return 0
Also, there are a number of funny dependencies... For example, I
can't figure out where it should get socketserver and socketclient from.
On a side note, usleep seems to have been depreceated in modern
distros. Use something like sleep 0.0005 instead.
After hacking around the above problems (always saying that the lustre
kernel version is good enough, installing dependencies, fixing paths,
and editing cfg/local.sh) I'm down to this list of failed sanity.sh
tests:
These are due to using stuff that doesn't exist:
./sanity.sh: FAIL: test_54a
./sanity.sh: FAIL: test_54a exit with rc=255
due to:
./sanity.sh: line 2172: socketserver: command not found
./sanity.sh: line 2173: socketclient: command not found
./sanity.sh: FAIL: test_60 exit with rc=127
due to:
sh: run-llog.sh: No such file or directory
./sanity.sh: FAIL: test_64b exit with rc=127
due to:
sh: oos.sh: No such file or directory
Yes, we should add checks to those.
These tests I don't really understand why/how they should work. My
wild guess is that sysctl -w lustre.fail_loc=0x217 should force a
failure of some kind, but doesn't. Should I care?
./sanity.sh: FAIL: test_69 write succeeded, expect -ENOENT
./sanity.sh: FAIL: test_69 read succeeded, expect -ENOENT
Bug 11565 - it's all marked private and hard to change now, but
essentially it's a bad test:
"hmm, actually it just looks like a bad check for remote osts; test
should be skipped in these cases. signing in a fix..."
To conclude, I think that sanity.sh needs some work before it can be
used to easily verify that a client seems sane.
Ok, thanks for the feedback.
_______________________________________________
Lustre-discuss mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
