:I had the hunch that the problem I am dealing with related to the unlink
:portion of NFS... So I have simplified the code down to this tiny snipet which
:will reliably crash the system (I left it running by accident and it brought
:my test machine down 3 times before I remembered to kill it :). This is only
:3 lines of code, and a for loop to iterate it.
:
:int main(int argc, char **argv)
:{
: int fd;
: int counter;
: char newfilename[1024];
:
: strcpy(newfilename,argv[1]);
: strcat(newfilename,".old");
: for(counter=0;counter<1000000;counter++) {
: fd=open(argv[1], O_CREAT, 600);
: close(fd);
: unlink(argv[1]);
: }
: return 0;
:}
:
:Again, this appears to need to be run from multiple machines at once to cause
:the problem (running from 2 dual-ultra 2s running solaris 2.6 in this case).
:I will attempt to reproduce it with FreeBSD clients later today. In the
:meantime I am getting down and dirty with the NFS kernel routines.
:...
:--
:David Cross | email: cro...@cs.rpi.edu
I think you said it was the server that crashed? Are you sure? I know
for a fact that it is possible to crash a FreeBSD client when the server
( or another client ) renames-over or unlinks files rapidly that are
also being accessed by the client. If it is the server crashing rather
then the client we have a new bug. It should still hopefully be
relatively easy to locate. Potential races in the server are much
more confined ( in regards to areas of the code that might race ) then on
the client.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
