Having same problem on
Client: Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-69-generic-pae i686)
Server: Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-77-generic x86_64)
This is frighteningly bad.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I also have this problem. Even when writing to different shares: Saving
a big download (8GB) to /pub/games results in a lockup of my desktop.
Programs are unable to access /home (cannot launch any programs, kde
plasma does not respond anymore, new page in chrome results in Waiting
for the cache).
Having the same problems:
NFS (v4) share on freeBSD 8.03 up-to-date (Jan 2013)
Ubuntu 12.10 64bit up-to-date (Jan 2013)
I can copy (read) big files with consistant rates at about 70MB/s from the NFS
share.
But when I write to the share it starts with 70MB/s for about 3 seconds, then
transfer
This bug is also a problem in Ubuntu 12.10.
Linux zoop 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
I am fully updated to today.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Also seeing this bug on 12.04.
When copying large files, the speed of the copy drops of dramatically
until at some point it freezes completely and I loose nautilus and any
networking activity/access to the server. I have to reboot the server to
get it back on the network.
This issue makes NFS
Bug affects 12.04 aswell:
# uname -a
Linux vm-orion 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
# lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 12.04 LTS
Release:12.04
Codename: precise
Hi,
I have the same NFS problem with 12.04 and kernel 3.2.0-25. Symptoms are very
same described above and easy to re-produce.
I'd like to know if there is a cure by now.
Thanks.
PS: In order to assist, I can deliver logs or make test progress if
needed.
--
You received this bug
Having similar problem on:
Linux chris-laptop 3.0.0-19-generic #32-Ubuntu SMP Thu Apr 5 18:22:38
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux.
The wired Ethernet interface seems to fail until the system is rebooted.
(The slower wireless interface - which is running in parallel to the
same switch -
Bug is back in 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
When copying a large file over nfs4v, Nautilus reports 606.6MB in the
first progress bar update to the GUI then hangs forever. The rest of my
desktop remains responsive. Nautilus, however,
Dear All,
I'm having this issue as well but I don't understand what is the
proposed solution. Where is that 2.6.35.something kernel that fixes the
problem ?
Please help!
I can see the bug with those two kernels :
2.6.35-020635rc1
2.6.32-30.59
Thanks
--
You received this bug notification
This is fixed with 2.6.32-31
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/561210
Title:
Writing big files to NFS target causes system lock up
--
ubuntu-bugs mailing list
Seeing this on Maverick - especially when booting KVM images over NFS,
server is almost unusable and system never recovers until a reboot..
Linux enterprise 2.6.35-27-server #47-Ubuntu SMP Fri Feb 11 23:09:19 UTC
2011 x86_64 GNU/Linux
--
You received this bug notification because you are a
This is truly insane. We have a support contract, *and* we've provided
Canonical with a patch that solves the problem, but we still can't get
them to add it into the mainline kernel.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
'NFS: kswapd must not block in nfs_release_page' was released as part of
the 2.6.32 stable update series and was released in 2.6.32-25.44
** Also affects: linux (Ubuntu Lucid)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Lucid)
Status: New = Fix Released
**
b608b283a962caaa280756bc8563016a71712acf was released as part of 2.6.35
** Changed in: linux (Ubuntu Maverick)
Status: New = Fix Released
** Changed in: linux (Ubuntu Maverick)
Assignee: (unassigned) = Tim Gardner (timg-tpi)
** Changed in: linux (Ubuntu Natty)
Status: In
I'm sorry my comment sounded snarky--this caught me on an (unrelated)
bad day. I ran 2.6.32.27-generic, and the problem occurred almost
immediately. This problem appears to be in nfs_do_fsync(), not
nfs_release_page().
--
You received this bug notification because you are a member of Ubuntu
(i.e., please reopen this bug)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/561210
Title:
Writing big files to NFS target causes system lock up
--
ubuntu-bugs mailing list
David - I think you should start a new bug. Though the symptoms are
similar, it appears to be a different bug. Also, how about asking Trond
Myklebust trond.mykleb...@netapp.com if he agrees with your assessment
re: nfs_do_fsync().
--
You received this bug notification because you are a member of
Actually, I think you might be correct, although it looks like bug
585657 could be the one.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/561210
Title:
Writing big files to NFS target causes system
(and the patch was actually a backport of a patch that Trond committed
to 2.6.35.something)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/561210
Title:
Writing big files to NFS target causes system
Still having this problem almost on a daily basis (lucid 10.04 amd64),
tried all the workarounds (sysctl, newer 2.6.35-23-generic kernel, etc),
none worked.
** Attachment added: dmesg.txt
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561210/+attachment/1841522/+files/dmesg.txt
--
You
Your wifi card is likely a _lot_ slower than the ethernet. This only
seems to manifest at high throughputs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/561210
Title:
Writing big files to NFS
Hi everyone,
I've got the same problem, and if I use my WIFI card, it's solved.
My ethernet card is :
09:00.0 Ethernet controller: Atheros Communications Atheros AR8132 / L1c
Gigabit Ethernet Adapter (rev c0)
--
Writing big files to NFS target causes system lock up
Just in case this can help someone (if not sorry for my frequent spam):
After long time of investigation, which clients really have that look-
ups and which not i concluded that in my case the problem was caused by
the simple fact, that those clients where solely NATed (most of them
VMs, Ubuntu
I had the same issue with all of my linux clients here accessing a
gigabit NAS. However after messing around the last weeks with this issue
i finally found this hint:
Ok sorry @ all - i fooled myself. After breaking the nfs mounts with
this incompatible option i was writing to local storage...please forget
about this. At all i'm now on the list and looking forward to a solution
of this issue.
--
Writing big files to NFS target causes system lock up
I'm having a similar problem but copying a file from Ubuntu to a Windows share
using smb/CIFS (as a result of a backup triggered from a cron job).
The problem occurs erratically and after hours I have to reboot the machine
(only a 'ping' from another machine reveals that the system is alive...).
also reported here..
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/394413
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
The large size file transfer mentioned in the original posting sounds
like the problem I'm having, too, but I'm not using NFS, I'm using an
mdadm RAID1 setup. When a large file is copied, only the
dpkg/apt/synaptic packages run slowly. The rest of the system seems to
function well, including text
Medium priority
The flagship server edition hangs on NFS writes is a MEDUIM
priority!!
This has been broken since 10.04 was released and 10.04.1 still has it
and it's MEDIUM prio !???
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You
0 % uname -a
Linux topaz 2.6.32-24-server #43-Ubuntu SMP Thu Sep 16 16:05:42 UTC 2010
x86_64 GNU/Linux
New hardware, new Ubuntu = can't use NFS:
Sep 28 10:12:50 topaz kernel: [604724.768485] SGI XFS with ACLs, security
attributes, realtime, large block/inode numbers, no debug enabled
Sep 28
Hi Thag,
I don't know if this helps you, but I'm currently running NFS servers
and clients successfully on 10.04 after having replaced the kernel with
Linus's upstream 2.6.35.6.
When testing with 2.6.35, enabling Forced pre-emption appeared to
expose similar in-kernel deadlocking bugs which did
I just received an email titled Ubuntu 9.04 reaches end-of-life on
October 23, 2010 on the Ubuntu Security mailing list. 9.04 is the most
recent version of Ubuntu that does not exhibit the NFS locking symptom
as described in this bug (I have experienced this bug with both Lucid
and Maverick
@BlueBuntu -- is the NFS server going non-responsive in that dmesg
output the location from which the mounts are made? If so the behaviour
on the client is likely correct. I would look to see why the server is
non-responsive in that case:
Sep 18 02:03:01 stratos kernel: [21811.409952] nfs:
@Andy Whitcroft, yes the nfs server in my situation (192.168.14.4) is
the location from which the mounts are made by the workstation that
locked up, sorry I should have specified that.
Whenever the nfs client running the lucid/maverick kernel locked up I
first checked all the other nfs client
This case is the sole reason I have had to skip upgrading to Lucid. And
as the problem seems to be also in Maverick, it seems that I will be
stuck with Karmic for even longer.
Please find below a recapture of my findings, hope it would help in
investigating this.
I can reliable repro this case
A week ago I installed a fresh lucid 10.04 amd64 desktop onto a
workstation (Athlon II 240, 4GB ECC RAM, 1TB SATAII disk). Within a day
this machine locked up with no response to keyboard or mouse. I could
ping it yet I couldn't ssh to it, luckily Magic sysrq + REISUB was able
to sync the local
@Alex
You are quite right, just using cp is enough to trigger this. I ran it three
times in Maverick beta, and it stalled every time.
-
File copy count: 450 Elapsed: 150 s
File copy count: 252 Elapsed: 85 s
File copy count: 972 Elapsed: 325 s
-
--
Writing big files to NFS target
@Timo Harmonen
I reverted my sysctl settings and indeed it stalled again when using
your cp-script. After reenabling the sysctl settings and copying about
40GB I still could not get it to stall. So it seems that the sysctl
settings really fixed the problem for me. At least with Lucid kernel
@Andy Whitcroft
Your sysctl setting on its own did not solve the problem for me. However
while I was googling for vm.min_free_kbytes to check out what it
actually does, I came across this site:
http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/
So I set these values on both, the server
Sorry for spaming but there is no edit function.
@Andy Whitcroft
I did not try vm.min_free_kbytes = 65536 on its own.
So maybe your value of 8080 was not high enough for my system.
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received
I tried adjusting vm.min_free_kbytes, and also those other settings
suggested by Alex. They didn't seem to have any impact, still the test
script hanged as earlier. I tried with 8080, 65536 and 80800, and also
with the suggested TCP settings.
It seems that I can repro this case 100% with my wget
@Timo Harmonen
I tried your test case but my internet connection is by far too slow to
trigger the problem with your script. However I modified your script by
using cp instead of wget. So instead of fetching the file from a remote
server I just copy it from the local harddisc to the NFS
We have had some success preventing this behaviour by adjusting a kernel
tunable. If those who are able to reproduce this could try increasing
the sysctl 'vm.min_free_kbytes' and see how that affects their tests.
We have been running with this value approximatly 10x its default value
for our
So this fix is also in Maverick beta? Unfortunately then it does not
seem to fix those problems I'm having.
I installed Maverick beta (2.6.35-19-server, amd64, clean installation)
under kvm and was able to repro some of my earlier problems.
I see this most often when using torretflux to download
Tim - yes I was still doing it over the loopback interface. Thanks for
that link, I guess that all kind of makes sense.
Part of my problem also stems from the change to autofs5 from autofs4.
This has a separate bug
(https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/517139) filed
against it.
Tim:
I managed to get your dd testcase to trigger the issue on a VM running
Ubuntu 10.04, Kernel 2.6.32-24.42, 8 CPUs, 512MB RAM, 8GB HDD. I've
attached the dmesg output from that test.
I downloaded the latest daily snapshot of Maverick Ubuntu 10.10 (kernel
2.6.35-19.28) and installed it onto
FYI. Looking at David McBride's comments to this bug report,
particularly #30, and checking the current kernel source package for
Ubuntu 10.04 it appears that patch identified in
https://bugzilla.kernel.org/show_bug.cgi?id=16056 (comments 1718) has
not been back ported to the 2.6.32 kernel. I
JimWright - That particular patch just arrived via stable updates.
Please try Ubuntu-2.6.32-25.43 which was just uploaded to -proposed
yesterday.
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a
Tim - thanks I have tried upgrading my virtual machine to the
2.6.32-25.43 kernel as you suggested. I now believe I experience the
same failure that you observed on bare metal using the maverick 2.6.35
kernel - see the attached dmesg log from my latest test. So it is
definitely an improvement of
JimWright - But you're still doing the loop mount test, right? Upstream
has indicated that its not a supportable case, i.e., http://marc.info/?l
=linux-kernelm=128335681711984w=2
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug
It may be related to LVM - I get the issue on my root disk. This is
mounted via an LVM. If I run an update the update stalls with these
errors
kernel: [ 2281.420086] dpkg D 0 24196 24133 0x
[ 2281.420090] 880168c87db8 0082 00015bc0
TimGardner - From your dmesg output it appears your bare metal test was
running kernel version 2.6.35, is that correct? Also the stack trace
looks noticeable different. Is there an easy way I can test that kernel
version on my 10.04 LTS setup (i.e. is there a package I can install on
Lucid
Hi,
For me NFS locks up most often with large files when Gnome is running.
eg, I have two machines, one with a 4 core CPU/4GB RAM running Gnome
(machine A) and much smaller system single core/1GB RAM (machine B)
Same kernel version, copying the same file.
Machine A to B NFS pauses
Machine B to
JimWright: - After not being able to repro the problem using a 10.04 VM
with -updates applied (8 CPUs, 512MB, 20GB) using VmWare Workstation as
the hypervisor on a 10.04 host, I decided to try Maverick on bare metal.
I'll have a better shot at enlisting upstream help if I can demo the
problem on a
JimWright - I was focused on the original reporter's setup, so I missed
your comments in #23. It does appear that this seems to happen most when
the NFS server is saturated, so it makes sense that a loopback mount
would do it. I'll give your setup a try.
--
Writing big files to NFS target causes
JimWright - I never did manage to reproduce your lockup using a VM, but
I was able to do it on bare metal; a dual CPU 6 core machine (24
threads) with 16GB RAM. It took 48 instances of 'dd if=/dev/zero
of=test.$i bs=1M count=512' over an NFS local mount to get it to lockup
(after about 5
I'm not having any luck reproducing this problem on a 2.6.32-24.41 NFS
server, using a simple mount from the client thusly: 'sudo mount
10.0.2.210:/export /mnt' and blasting a 90GB file onto the server: 'dd
if=/dev/zero of=/mnt/users/rtg/bf.txt bs=512 count=188743680'. This is
over a 100Mb switch.
Hi Tim,
After your post I retried my test case (see comment #23 above), except
this time using KVM instead of VMWare Server. All details of the
virtual machine, i.e. 2xCPU/512MB RAM/8GB HDD are the same - it's just
using KVM instead of VMWare.
I can confirm that under KVM and a vanilla install
@Tim
i double the problem would exhibit itself on a 100mb switch unless your
nfs server was writing to a storage media with a lower throughput . ...
unless you are writing to a USB flash drive ... i'm pretty sure your
storage can keep up with a 100mb switch
...
i only see this problem when my
If this is truly a duplicate of bug #585657, I can verify that I see
this problem in 10.04 with both Ubuntu's 2.6.32-24.39 and with the stock
kernel.org 2.6.32.18.
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification
Is there a specific patch that addresses our problem?
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Will the fix from 2.6.35-rc6 be backported to Lucid?
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I've compiled up and retried my test transfers with Linus's current
latest RC, 2.6.35-rc6, and found that this problem does not recur.
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of
Applying the patch referenced in the previous comment, the situation
with regards to NFS deadlocking is improved -- the local terminal no-
longer locks up -- but there are continued issues with processes
blocking in 'D' (disk-wait) when they should not.
(For example, automounted NFS volumes not
And, indeed, if the umount process is stuck for long enough, the
following kernel stack-trace is emitted:
Jul 26 21:38:49 illustrious kernel: [ 838.729063] INFO: task umount.nfs:2570
blocked for more than 120 seconds.
Jul 26 21:38:49 illustrious kernel: [ 838.729069] echo 0
(My test machine eventually unblocked when the 90GB NFS transfer finally
finished. Still, that took a long time, and it was totally unusable
until then.)
Checking the current kernel sources, the kernel patches referenced in
bug #585657 are clearly already applied. Reviewing recent development
Just ran into this bug, affecting me on a new Lucid 64-bit install.
Memory exhaustion is unlikely, as the machine has 8GB of RAM and a fast
network link.
This may be related to bug #585657.
Remote SSH still works, and the NFS transfer I started a couple of hours
ago is still running, slowly,
** Changed in: linux (Ubuntu)
Importance: Undecided = Medium
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I can repro this issue quite easily with my setup. I'm running two amd64
kvm guests on amd64 host system with 8GB of memory. Nfs server is
running on the host, and guests heavily rely on it. All systems are up-
to-date, kernel is 2.6.32-23.
So the guests hang when they heavily access nfs mounts,
** Tags added: kernel-candidate kernel-reviewed
** Tags removed: kernel-needs-review
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
** Tags removed: kernel-candidate
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
I have the same problem on my machine (10.04 LTS, linux-
image-2.6.32-23-server 2.6.32-23.37, 64Bit). My system is up-to-date.
During the last system freeze, I discovered that no data was written to
the nfs share for at least 15 minutes.
I tried to login at the console and got a lot of messages
I'm running
Linux io 2.6.32-23-server #37-Ubuntu SMP Fri Jun 11 09:11:11 UTC 2010 x86_64
GNU/Linux
with all upgrades installed and I got a freeze today. Since this is a
multi-user file server I'm not sure what exactly was going on at the time.
Unfortunately, I cannot try out different kernels
** Attachment added: /var/log/dmesg
http://launchpadlibrarian.net/51493244/dmesg
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
** Tags added: kernel-fs kernel-needs-review
** Tags removed: needs-kernel-logs needs-upstream-testing
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Changed in: linux (Ubuntu)
Status: Fix Released = Triaged
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
@Jim: That looks to me like a test case :)
All this information leads me to the same conclusion that those blocking
behavior occurs most commonly when the system runs out of free RAM and starts
to swap heavily.
I'm currently running a vanilla kernel 2.6.35-rc3 and with that I wasn't
able to
Ancoron,
Per the new kernel team policy, I'd like to close this issue out for you
as fix released.
jjbig / Christoph,
Also, per ubuntu kernel team policy, could I get the two of you to file new
bugs for your issues? This will enable us to approach your bugs from an
individual
Jeremy,
I disagree with the status change to Fix Released as it is not
fixed. The problem still occurs. It didn't occur for my main
workstation here as I have raised the rsize/wsize to 32MB on the NFS
mounts here and I am just issuing one to two NFS transactions at a
time, so it didn't come up in
I believe we have also been affected by this issue. I've managed to
recreate it using a single virtual machine running on VMWare server and
only using the loopback interface.
First I created a 64-bit VM using VMWare Server with 2 CPUs, 512MB RAM
and 8GB disk. Into that I performed a fresh
I have to confirm this bug as well. Same effekt, everything hangs for
some time while transfering biger data to NFS I'm using Ubuntu 10.04 64
(2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64
GNU/Linux). dmesg does't report anything.
--
Writing big files to NFS target causes
Today I tried copying very large files to a NFS share mounted with
rsize=64,wsize=64 and I could reproduce freezes of about 30 secs, but no
120-sec-freezes and nothing in dmesg' output.
I am on lucid's amd64 kernel 2.6.32-22.
--
Writing big files to NFS target causes system lock up
Well, today on one of my machine here at home this issue is back:
[616201.460064] INFO: task kswapd0:52 blocked for more than 120 seconds.
[616201.460072] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
[616201.460079] kswapd0 D 052 2
My Desktop also did freeze for those 120 seconds.
I use a Gnome but there are KDE based widgets running, namely klipper.
Ac. buffer size: Larger write buffers (backed by enough RAM) defer or
eventually avoid the point at which the buffer runs full.
I think we agree that's when the freeze occurs.
If my assumption of the freeze trigger is correct, it should be possible to
provoke the problem even against fast NFS servers by setting the buffer size
extremly low, i.e. to the minimum allowed by the NFS driver.
I 'll try this out, but due to a business trip I won't happen before the end of
I only had the problem with an extremely slow NAS as target, I have given the
damn thing away a wee ago.
So I have no easy way of reproducing it now, sorry.
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because
Hi Ancoron,
This bug was reported a while ago and there hasn't been any activity in it
recently. We were wondering if this is still an issue? Can you try with the
latest development release of Ubuntu? ISO CD images are available from
http://cdimage.ubuntu.com/releases/ .
If it
@Christoph: If you still experience this bug please do that apport-
collect thing.
For me it is fine here. Tested with two different amd64 machines
accessing a single NAS (1 Gb network, software-RAID-5 on busybox NAS,
write speed 20 - 30 MiB/s). Also simultaneous read/write access doesn't
yield
I seem to suffer from the same problem in up-to-date lucid x86_64 with Ubuntu
kernel 2.6.32-21-generic.
I assume the problem only occurs when the target server is considerable slower
than the local machine, like an ultra slow NAS serving for a SSD boosted
developer machine.
--
Writing big
** Tags added: kj-triage
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Just made some tests with some ISO's (690 MiB - 3.7 GiB) and the issue
seems to be fixed.
Now I got consistent read/write speed back again.
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member
On 22.04.2010 22:57, Ancoron Luziferis wrote:
Well, just to see that 2.6.32.11 is already the current version for
Lucid. So it should be fine.
If it is not then it is a problem elsewhere.
Where did you find this information ?
I tried to build a vanilla kernel and patching it with the
Yepp, the upstream commit seams to be this one:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bb6fbc4548b9ae7ebbd06ef72f00229df259d217
But in addition this one should also be considered for a backport:
Well, just to see that 2.6.32.11 is already the current version for
Lucid. So it should be fine.
If it is not then it is a problem elsewhere.
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a
Our NFS Boot environment is affected by the same problem, as we are trying to
get the lucid lynx ready.
Apparently this has been fixed on kernel versions 2.6.33.2 and 2.6.32.11
according to:
http://bbs.archlinux.org/viewtopic.php?pid=739477
I really hope this will be patched in the ubuntu
I have the same problem in lucid.
Mounting nfs in fstab via
192.168.1.128:/mnt/Array1 /media/Array1 nfs
rsize=8192,wsize=8192,timeo=14,intr,noatime,nodiratime
Transfer of files larger than 1gb cause system to lock up when it
transfers the first 1gb.
Base install of 10.04 beta 2 with nfs-common
** Attachment added: uname -a
http://launchpadlibrarian.net/43888905/uname-a.log
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
** Attachment added: dmesg
http://launchpadlibrarian.net/43888909/dmesg.log
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
** Attachment added: cat /proc/version_signature
http://launchpadlibrarian.net/43888977/version.log
--
Writing big files to NFS target causes system lock up
https://bugs.launchpad.net/bugs/561210
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
1 - 100 of 102 matches
Mail list logo
