Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: Input is not proper UTF-8, indicate encoding ! Bytes: 0xB3 0x20 0x43 0x69 in Entity, line: 2 in /srv/lkml.org/scripts/getmail.php on line 208

Warning: XSLTProcessor::transformToXml() expects parameter 1 to be object, boolean given in /srv/lkml.org/scripts/getmail.php on line 211
This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sat Nov 22 18:33:55 2008 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8IIhcX19926 for ; Wed, 18 Sep 2002 20:43:39 +0200 Received: (qmail 27869 invoked from network); 18 Sep 2002 08:25:03 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 18 Sep 2002 08:25:03 -0000 Received: (qmail 10304 invoked by uid 1000); 17 Sep 2002 21:34:56 -0000 Received: (maildatabase); juh Received: (qmail 13476 invoked by alias); 21 Jun 2002 05:58:12 -0000 Received: (qmail 13281 invoked from network); 21 Jun 2002 05:58:08 -0000 Received: from unknown (HELO mayo.ds9a.nl) (3ffe:8280:10:360:2e0:4cff:fe39:26ca) by spaans.ipv6.ds9a.nl with SMTP; 21 Jun 2002 05:58:08 -0000 Received: (qmail 27756 invoked from network); 21 Jun 2002 01:58:14 -0000 Received: from unknown (HELO dipsaus.ds9a.tudelft.nl) (3ffe:8280:10:360:2a0:cff:fe14:9dde) by mayo.ipv6.ds9a.nl with SMTP; 21 Jun 2002 01:58:14 -0000 Received: (qmail 5562 invoked from network); 21 Jun 2002 01:58:12 -0000 Received: from unknown (HELO vger.kernel.org) (::ffff:209.116.70.75) by dipsaus.ds9a.tudelft.nl with SMTP; 21 Jun 2002 01:58:12 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 20 Jun 2002 21:56:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 20 Jun 2002 21:56:05 -0400 Received: from tone.orchestra.cse.unsw.EDU.AU ([129.94.242.28]:61128 "HELO tone.orchestra.cse.unsw.EDU.AU") by vger.kernel.org with SMTP id ; Thu, 20 Jun 2002 21:56:04 -0400 Received: From notabene ([129.94.242.45] == bartok.orchestra.cse.unsw.EDU.AU) (for ) (for ) (for ) By tone With Smtp ; Fri, 21 Jun 2002 11:53:45 +1000 Received: from neilb by notabene with local (Exim 3.35 #1 (Debian)) id 17LDcv-0001BP-00; Fri, 21 Jun 2002 11:54:17 +1000 From: Neil Brown To: =?ISO-8859-1?Q?Micha=B3?= =?ISO-8859-1?Q?Cie=B6lakiewicz?= Date: Fri, 21 Jun 2002 11:54:12 +1000 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <15634.34628.841757.197117@notabene.cse.unsw.edu.au> Cc: linux-kernel@vger.kernel.org, Alan.Cox@linux.org Subject: Re: [2.2.21] nfsd crash & workaround In-Reply-To: message from =?ISO-8859-1?Q?Micha=B3?= =?ISO-8859-1?Q?Cie=B6lakiewicz?= on Thursday June 20 References: <20020620111209.0b55c5a4.Michal.Cieslakiewicz@comarch.pl> X-Mailer: VM 6.72 under Emacs 20.7.2 X-Face: [Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D Hi all! > > When accessing NFS (server on a Linux box running 2.2.21, client on Solaris 8) I've encountered a following problem: attempt to copy a not-so-small file (around 150MB) from cdrom leads to nfsd crash after some time (depends on transport and network load) with file being only partially copied. The crash occurs regardless of either of NFS version (v2,v3) or transport (UDP,TCP). > Cause this problem never happened to me on 2.2.20, I spent some time to eventually find a 'solution' which is as simple as using mm/vmscan.c from 2.2.20 (changing the position of a call to shrink_dcache_memory() in fact). I'm not a kernel hacker (not yet :) ) but looks like VM issue rather than NFS to me. > Below I post a standard lk bug report (assumig NFS v2 over UDP when not stated otherwise). > This surpised me a little but not a lot. If you are exporting a CDROM, then I assume it is an ISOfs filesystem. The current ISOfs code doesn't support lookup("..") properly (it appears to try, but it is all wrong) so if something falls out of cache, you can loose. If you aren't already, try exporting with "no_subtree_check". This will be more reliable as it doesn't bother with the ".." lookups as much. The reason that it surprised me as little, rather than not-at-all is that you get an oops, and you getan oops which seems to be miles from the filesystem or NFS code. Possibly the current code for ".." actually corrupts memory and that only hits later. I have no plans to "fix" ISOfs. If someone else wants to I can be more specific about the problem, the requirements, and the approach. Your VM hack presumably leaves things in cache for longer and so you don't actually hit the problem. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/