FYI. My xfers still do look 'spikey' so to speak even with these changes.
The crucial part now is that average WRITE speed to the NAS is 80 MB/s...takes < 2 min to do an 8 GB xfer whereas before it was 16 min or longer.
FYI. My xfers still do look 'spikey' so to speak even with these changes.
The crucial part now is that average WRITE speed to the NAS is 80 MB/s...takes < 2 min to do an 8 GB xfer whereas before it was 16 min or longer.
Update:
Pushing NFSv4 over Gigabit to a 5 x 1.5 TB raid 5 array running mdadm:
time dd if=hd1c_8x4GB.mpg of=/mnt/nt_tmp/hd1c_8x4GB.mpg
17676766+1 records in
17676766+1 records out
9050504616 bytes (9.1 GB) copied, 90.6353 s, 99.9 MB/s
real 1m31.555s
99.9 MB/s !!... can't get much faster on gigabit...that's approx 800 Mb/s without the overhead in consideration...
I want to start by restating the original problem:
Large NFS copies locks up/hang desktop
I tried everything suggested up to this point (async, proc changes, etc) without any success; large files still freeze my Lucid desktop - sometimes to the point where a restart is required.
Patching the kernel is hardly a solution; at best it is a workaround.
This seems like a pretty basic and serious bug. If a Linux desktop (client) cannot send a large file via NFS to another Linux desktop (server) without completely locking up, an alarm with flashing red lights and sirens should be going off somewhere.
I would change my shares to use cifs instead, but this has some widespread and unresolved problems of its own (e.g. http://ubuntuforums.org/showthread.php?t=1521653 one of many threads on the topic)
I can't believe Lucid made it out of Beta with these problems. I know this is somewhat of a rant, but this is a bit ridiculous.
What can we do to get this fundamental problem seriously looked at?
brdhse1:
what mechanism are you trying to do the copy with? command line cp, nautilus, rsync, dd? one or all of the above?
have you ever happened to catch anything in dmesg? can you ssh into the box while this happens to see what is transpiring?
If I am not mistaken, this is a know bug, which is fixed in 2.6.35-rc6. So hopefully this is only a matter of time.
In this situation, for some people patching IS the solution.
Its not hard, you can do it, and it will stay with you until you update your kernel, which you should not need to do until Maverick, at which case some other annoyance may creep in and you need to patch the Kernel.
The point here is that
i) This is a solution
ii) This problem does not affect many people, and as it affects YOU it is a damn good one.
I was extreemly grateful that the elite core of NFS devs took time out to give us this solution
Have a go. Its not too hard
Hey
I still have the problem of a NFS client that locks up my whole system on Kubuntu 10.10.
The patch that was posted before seems to be for an older version/revision/whatever of the kernel (.33 instead of .35) so I'm not sure if it would be a good idea to apply it.
Does anyone know how to get a NFS client proberly working in 10.10 od do I have to downgrade to good old 8.04 - the last version without major problems for me.
I seem to have fixed my "NFS client locking while copying large files" problem by applying part of the solution reported in reply #23. In particular, I changed the NFS entry in /etc/fstab as suggested.
Thanks!
[EDIT] Spoke too soon, problem still occurs, possibly with less frequency.
Last edited by dmendels; October 24th, 2010 at 03:17 PM. Reason: Correction
Any news on this issue?
It's still interfering my work with Kubuntu 10.10.
I also tried several things like a fresh installation but the same issue occurs there (while it's still working without problems in Kubuntu 8.04)
I also posted the issue on the Ubuntu Bugtracker ( https://bugs.launchpad.net/ubuntu/+bug/661294 ), but they don't seem to care, that something totally unimportant like NFS doesn't work in their latest release... -.-
Bookmarks