[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#576405: marked as done (linux-image-2.6.26: Deadlock during combined NFS3/NFS4 use)

Your message dated Thu, 22 Sep 2011 13:50:59 -0500
with message-id <20110922185059.GD8656@elie>
and subject line Re: linux-image-2.6.26: Deadlock during combined NFS3/NFS4 use
has caused the Debian Bug report #576405,
regarding linux-image-2.6.26: Deadlock during combined NFS3/NFS4 use
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
576405: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576405
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-2.6.26
Version: nfsfix.1
Severity: important


When an export is exported and mounted via autofs using BOTH
NFSv3 and NFSv4 the NFSv4 one deadlocks.

Setup - transition from v3 to v4.

System A is still perusing the old map:
cat /etc/auto.local | grep iPodResolution
iPodResolution          -rsize=4096,wsize=4096,rw   eden:/exports/md4/videoiPod

System B is using the newever version of same map with a v4 mount:
cat /var/yp/auto.local | grep iPodResolution
iPodResolution          -fstype=nfs4   eden:/md4/videoiPod

If system B is writing to the mount and A is reading from it B starts getting 
I/O errors/BAD FDs. If B is running from disk lots of things fail. If B is
running diskless - total lock up. 

Same setup with V3 only has been working flawlessly for 5+ years. Same setup with 
V4 only (when the v3 machines are off) seems to work OK as well.

Fairly easy to reproduce.

I am not sure at this point if autofs has any role in this and I will not be in 
a position to retest until 19th. Apologies.

Tested with: stock debian, older version with just the nfs regression fix, 
stock recompiled with preempt, 686 and 486 versions.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.26 depends on:
ii  coreutils                     6.10-6     The GNU core utilities
ii  debconf [debconf-2.0]         1.5.24     Debian configuration management sy

linux-image-2.6.26 recommends no packages.

Versions of packages linux-image-2.6.26 suggests:
ii  fdutils                   5.5-20060227-3 Linux floppy utilities
pn  ksymoops                  <none>         (no description available)
pn  linux-doc-2.6.26 | linux- <none>         (no description available)

-- debconf-show failed

--- End Message ---
--- Begin Message --- 
Version: 2.6.32-35squeeze2
found 576405 linux-2.6/2.6.26-22
tags 576405 - moreinfo
quit

Anton Ivanov wrote:

> I cannot reproduce it on 2.6.32 with autofs5 (squeeze). You can close it.
>
> In general 2.6.26/autofs4 (lenny) was quite fragile with automounted nfs4.
> nfs4 itself was OK, autofs itself was OK, together the combination was
> rather "explosive".
>
> Squeeze fixed all of that. I have yet to observe a single problem with nfs4
> + autofs on my squeeze systems.

If I understand correctly, this is not a huge deal for lenny because
anyone attempting such a configuration would have been burned and
backed off quickly.

But it is possible I am understanding incorrectly and that the impact
is worse, in which case we should search for when the bug was fixed to
make a backport.  Advice either way would be welcome.

Thanks,
Jonathan

--- End Message ---
Reply to: