Most recent kernel where this bug did not occur: Distribution: Tested both on Gentoo and a Debian 4.0-based distribution Hardware Environment: i386 (two different hardware setups) Software Environment: Problem Description: NFS mounts lead to system lockups if the share is mounted locally and massive amounts of data are copied to the share. I.e. the system running the kernel NFS server mounts one of it's exported shares instead of accessing the exported filesystem locally. Writing on the share from remote hosts works fine. For reference the line from /etc/exports: /test 10.1.71.251(rw,sync,fsid=0,no_root_squash,no_subtree_check) /test 10.1.71.252(rw,sync,fsid=0,no_root_squash,no_subtree_check) /test 10.1.71.250(rw,sync,fsid=0,no_root_squash,no_subtree_check) Disabling/enabling subtree_check and sync/async don't make a difference. These lockups can be reproduced with 2.6.18, 2.6.20 and 2.6.22 and as it occurs on two systems with different hardware a hardware bug seems unlikely. The symptoms occur both with NFS4 and NFS3, although NFS3 appears more stable. Steps to reproduce: 1. Create a /etc/exports with the line above 2. Run NFS kernel server 3. Mount the above share somewhere, e.g. /mnt/nfstest 4. Run dd if=/dev/zero of=/mnt/nfstest bs=1024k count=4048 This should lead to a lockup pretty soon.
Why would you need to do this? We have bind mounts which avoid the need for using loopback NFS altogether.
(In reply to comment #1) > Why would you need to do this? We have bind mounts which avoid the need for > using loopback NFS altogether. The intended use case is a failover system based on NFS. If the local NFS share is no longer available, the remote share is about to be used. (I've noticed the recent mail on linux-kernel with the subject "NFS on loopback locks up entire system(2.6.23-rc6)?" in which you explain that the lockups are more or less expected with the current NFS code. We'll followup in this thread where necessary.)
Any update on this please. have you been able to find a solution to your environment? Thanks.
Herr Wiegand ist aus unserem Unternehmen ausgeschieden und daher unter dieser Adresse nicht mehr erreichbar. Ihre Mail wird weitergeleitet. Bei zukünftigen Fragen wenden Sie sich bitte an einen anderen Ansprechpartner oder die für Sie zuständige Support- bzw. Technik-Hotline. Falls Ihnen keine andere Kontaktadresse bekannt ist, wenden Sie sich bitte an info@univention.de Univention GmbH http://www.univention.de