NFS4: System hangs after copying gigabytes of data (?)

[stippi]

I don't know if this is a bug in NFS4 or not. I copied gigabytes worth of data from my Haiku box to the server and let it run over night. In the morning, the Haiku box was frozen up. Due to how my keyboard is connected, I could not enter KDL, unfortunately.

It could be something in the kernel that was just triggered by the copy process, or it could be something in NFS4. 354 GiB worth of files were copied, the last file is half-finished, so it definitely froze up during copying. Sorry I don't have more info, I just wanted it logged that there is a problem somewhere.

The revision I used was d1c7f766fde371e1b4a7e188e3889f26ebdd04a8

[bonefish]

The syslog might still contain useful information.

[stippi]

I've had a closer look at the syslog and syslog.old, but did not find anything suspicious before the lines that indicate the next session has started.

[stippi]

Maybe something worth exploring: Last night, I copied the rest of the data, which again was many gigabytes. This time the process went smooth. I observed that when the Tracker window is open which shows the target folder (the share), it shows weird redraw-behaviour. It does not redraw, even other windows don't redraw correctly, updated window contents appear below the mouse cursor when moving the mouse. When closing the Tracker window, the weird behaviour stops. So last night, I didn't have that open, while the other night, I did leave it open. I am suspecting that NFS4 sends notifications too fast, it should probably throttle them (though app_server should be fixed, too, to handle it fine). Otherwise I observed that the copy process is very fast, going at about 80 MiB/s or even slightly more on my Gigabit Ethernet. I think it might even be the peek read speed of the harddrive.

[stippi]

Forgot to mention: the CPUs are nowhere peeked when the target Tracker window is open. The CPU with the most activity is at about 15% load, the other CPUs are well below that. The theory about too many notifications might not hold, but the weird redraws are definitely there. Something is saturated.

[axeld]

Even if it's off-topic: the rendering update does not sound pretty familiar; Tracker is obviously accessing the file system from the window thread, and does not update the window even though it should update it. If you mouse-over it, the app_server will copy the window contents from an offscreen buffer which might hold old or in progress data.

The same happens sometimes when you open the Deskbar menu, and it'll take some time until the menu is drawn (only the window frame is there) -- you can then draw the contents of that menu when using the mouse, too. Of course, it would be great if that could be fixed, too :-)

Or did you experience any other issues?

[waddlesplash]

Moving NFS4 tickets out of R1; BeOS didn't have this