Opened 6 years ago

Last modified 4 years ago

#10406 new bug

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

Reported by: stippi Owned by: pdziepak
Priority: normal Milestone: R1
Component: File Systems/NFS4 Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by 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

Change History (8)

comment:1 by stippi, 6 years ago

Description: modified (diff)

comment:2 by bonefish, 6 years ago

The syslog might still contain useful information.

comment:3 by stippi, 6 years ago

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.

comment:4 by stippi, 6 years ago

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.

comment:5 by stippi, 6 years ago

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.

comment:6 by axeld, 6 years ago

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?

comment:7 by waddlesplash, 4 years ago

Milestone: R1Unscheduled

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

comment:8 by waddlesplash, 4 years ago

Milestone: UnscheduledR1
Note: See TracTickets for help on using tickets.