From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24036 invoked by alias); 8 Apr 2004 13:42:24 -0000 Mailing-List: contact overseers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: , Sender: overseers-owner@sources.redhat.com Received: (qmail 24006 invoked from network); 8 Apr 2004 13:42:23 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Apr 2004 13:42:23 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i38DgMGl002297 for ; Thu, 8 Apr 2004 09:42:22 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i389ovj06459; Thu, 8 Apr 2004 05:50:57 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i389oue1030293; Thu, 8 Apr 2004 05:50:56 -0400 Received: from tooth.toronto.redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 741BA80008E; Thu, 8 Apr 2004 05:50:56 -0400 (EDT) Received: from tooth.toronto.redhat.com (localhost [127.0.0.1]) by tooth.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i389on3h000865; Thu, 8 Apr 2004 05:50:49 -0400 Received: (from fche@localhost) by tooth.toronto.redhat.com (8.12.8/8.12.8/Submit) id i389om7i000861; Thu, 8 Apr 2004 05:50:48 -0400 Date: Thu, 08 Apr 2004 13:42:00 -0000 From: "Frank Ch. Eigler" To: David Edelsohn Cc: overseers@sources.redhat.com Subject: Re: gcc.gnu.org CVS meta-data corrupt? Message-ID: <20040408095048.GD11002@redhat.com> References: <200404080404.i3844aT26350@makai.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404080404.i3844aT26350@makai.watson.ibm.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-q2/txt/msg00110.txt.bz2 Hi - > [...] > I suspect that something is broken in the CVS meta-data or the > filesystem backing that directory. This may be a large cause of the > slowdown if every single CVS update is timing out on that directory. The same thing happens to ordinary UNIX file access in the area: processes simply get stuck in "D" state. The system logs are eerily quiet on the subject. I suspect the machine needs a reboot and an fsck. Hmm, while poking around, it just froze. :-( - FChE