on 21st of March I posted an emergency message concerning
a quite reproduceable kernel freeze of the recent kernel.
Since I did not get any response, I try to explain the
problem once more.
Here again the main statement of that posting:
--- previous positing starts here ---
I experienced several system freezes in the last days (SuSE 6.0,
glibc, SMP kernel-nfs, kernel 2.2.2 and 2.2.3-ac3). Apparently
these freezes happen under heavy NFS traffic. More precise, from
the last lines found in the message file I conclude it might be
a problem which is NFS-lockd related. I appended the last minute
of the message file from the last three crashes. The last message
is in any case:
kernel: lockd: attempt to release unknown file!
--- previous positing ends here ---
In the mean time I successfully checked that the program which
tends to crash the nfs-server works perfectly fine with the
working directory being located on a Solaris nfs-server rather
than a Linux nfs-server.
Could someone tell me, what this kernel message "lockd: attempt
to release unknown file!" means? Is it a diagnostic, warning
or error message? As I said, I find this message in the message
file from time to time. And not always the kernel freezes right
after that message.
I would be happy to do any testing in order to trace down the
bug. I mean things like including some debug print out in the
kernel. But I would need assistence from kernel hackers to do
so.
The only hint I can give to give you a clue what the system is
doing when it crashes is, that several ten (maybe 50 or 100)
processes on ten attached number crunchers start at about the
same time to create files and directories on the common
nfs-mounted directory. About 120 files and 80 directories
and sub-directories in about one minute. These processes also
make havy use of lockf system calls to synchronize their
activities. Finally, there are quite some symlinks to be
followed by the nfs-server at the moment of kernel freeze.
The latter might be a problem, since the number of nested
symlinks is limitted to 5 in the kernel source (hard coded,
not a well define parameter!). This magic number of 5 nested
symlinks might indicate that the kernel cannot cope with too
many concurrent processes which want to resolve nested symlinks
at a time? Just an idea, of course...
As it might have become evident, I'm talking about a quite
big project which is based on Linux. Whether I can solve that
problem or not, will be of general interested and importance,
I guess.
Thanks,
Ruben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/