Date: Tue, 21 Mar 2006 17:47:35 -0500 From: Mikhail Teterin <mi+mx@aldan.algebra.com> To: stable@freebsd.org Cc: alc@freebsd.org Subject: more weird bugs with mmap-ing via NFS Message-ID: <200603211747.36251.mi%2Bmx@aldan.algebra.com> In-Reply-To: <200603211607.30372.mi%2Bmx@aldan.algebra.com> References: <200603211607.30372.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> When I mount with large read and write sizes: > > mount_nfs -r 65536 -w 65536 -U -ointr pandora:/backup /backup > > it changes -- for the worse. Short time into it -- the file stops growing > according to the `ls -sl' run on the NFS server (pandora) at exactly 3200 > FS blocks (the FS was created with `-b 65536 -f 8129'). > > At the same time, according to `systat -if' on both client and server, the > client continues to send (and the server continues to receive) about 30Mb > of some (?) data per second. When the client is in this state it remains quite usable except for the following: 1) Trying to start `systat 1 -vm' stalls ALL access to local disks, apparently -- no new programs can start, and the running ones can not access any data either; attempts to Ctrl-C the starting systat succeed only after several minutes. 2) The writing process is stuck unkillable in the following state: CPU PRI NI VSZ RSS MWCHAN STAT TT TIME 27 -4 0 1351368 137764 nfs DL p4 1:05,52 Sending it any signal has no effect. (Large sizes are explained by it mmap-ing its large input and output.) 3) Forceful umount of the share, that the program is writing to, paralyzes the system for several minutes -- unlike in 1), not even the mouse is moving. It would seem, the process is dumping core, but it is not -- when the system unfreezes, the only message from the kernel is: vm_fault: pager read error, pid XXXX (mzip) Again, this is on 6.1/i386 from today, which we are about to release into the cruel world. Yours, -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603211747.36251.mi%2Bmx>