From: Trond Myklebust Subject: Re: Null characters in files on NFS mounted volume.... Date: 13 May 2002 17:08:11 +0200 Sender: nfs-admin@lists.sourceforge.net Message-ID: References: <3CDFCE9F.2BE050D5@fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: nfs list Return-path: Received: from pat.uio.no ([129.240.130.16]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 177HQy-0005Ik-00 for ; Mon, 13 May 2002 08:08:21 -0700 To: Dan Yocum In-Reply-To: <3CDFCE9F.2BE050D5@fnal.gov> Errors-To: nfs-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Unsubscribe: , List-Archive: >>>>> " " == Dan Yocum writes: > Hi all, I've got a "New and Exciting" bug using 2.4.18 > with Trond's client patches (sans the rpc_tweaks dif), but I'm > not sure it's a client side problem. > This is an intermitent problem: When attempting to read a file > (any file) on an NFS mounted volume, there appear to be "holes" > in the file filled with ASCII NULL characters. Reading the > file on the local machines shows no such holes, and other NFS > clients don't see the holes, either. A simple umount/remount > solves the problem. Any details? Are these for instance ordinary files? Are you perhaps engaging in some multiple NFS client read/writes to the same file? ... Is it tied to the client patches, or does it occur with stock 2.4.18 fresh off the l-k presses? Cheers, Trond _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs