From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 22 Jun 2001 18:58:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 22 Jun 2001 18:58:43 -0400 Received: from mons.uio.no ([129.240.130.14]:52209 "EHLO mons.uio.no") by vger.kernel.org with ESMTP id ; Fri, 22 Jun 2001 18:58:36 -0400 To: Christian Robottom Reis Cc: , , Subject: Re: [NFS] NFS Insanity, v2 In-Reply-To: From: Trond Myklebust Date: 23 Jun 2001 00:58:15 +0200 In-Reply-To: Christian Robottom Reis's message of "Fri, 22 Jun 2001 16:52:09 -0300 (BRT)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >>>>> " " == Christian Robottom Reis writes: > Every day at the same time I pull mozilla-latest through http, > and untar it into a directory that is served by nfs. The file > isn't too big - around 9MB. It creates a set of files inside > /mondo/local/mozilla. One of the files (same one for some > reason), components/libgkcontent.so, always ends up corrupted > on the client side. There is no server-side corruption. > Remounting (and thus rebooting) the client mount gets things > back to normal. Anyone willing to track this down with me? Or > is it something known (and being worked on, hopefully)? Is libgkcontents.so in use on the client? If so it's a known problem: mmap() screws up the page cache invalidation routine invalidate_inode_page(). If you do the untar on the client, then all will be fine... However the last time your report was of a problem in which the server was corrupted, and the client was good. Was that a typo, or is it still the case? Cheers, Trond