From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12367 invoked by alias); 8 Apr 2004 14:13:50 -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 12346 invoked from network); 8 Apr 2004 14:13:49 -0000 Received: from unknown (HELO igw2.watson.ibm.com) (129.34.20.6) by sources.redhat.com with SMTP; 8 Apr 2004 14:13:49 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i38EDgq41972; Thu, 8 Apr 2004 10:13:42 -0400 Received: from makai.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i38EDfK52100; Thu, 8 Apr 2004 10:13:41 -0400 Received: from watson.ibm.com (localhost [127.0.0.1]) by makai.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i38EDeT25894; Thu, 8 Apr 2004 10:13:41 -0400 Message-Id: <200404081413.i38EDeT25894@makai.watson.ibm.com> To: "Frank Ch. Eigler" cc: overseers@sources.redhat.com Subject: Re: gcc.gnu.org CVS meta-data corrupt? In-Reply-To: Message from "Frank Ch. Eigler" of "Thu, 08 Apr 2004 06:44:53 EDT." <20040408104453.GF11002@redhat.com> References: <200404080404.i3844aT26350@makai.watson.ibm.com> <20040408104453.GF11002@redhat.com> Date: Thu, 08 Apr 2004 14:13:00 -0000 From: David Edelsohn X-SW-Source: 2004-q2/txt/msg00114.txt.bz2 >>>>> Frank Ch Eigler writes: >> [...] 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. Frank> By the way, this particular problem did not occur yesterday - Frank> routine du's and cvs lock-file searches proceeded unblocked, Frank> so I doubt it was responsible for the slowdown lately. CVS updates occur alphabetically. I have been seeing long delays between updating "gcc", especially testsuite subdirectory, and "libstdc++-v3". Intevening directories are not modified frequently, so it is hard to determine where the time is being spent without non-quiet mode or "-t" option. I had assumed the delay was the size of testsuite or libjava. Manually updating those directories in non-quiet mode last night (and gcc.gnu.org showing a load of 70), demonstrated that those large directories are updated very rapidly. Therefore, I believe that the long delays were due to some CVS meta-data problem or disk problem which has been lingering over the past few weeks. I do not have enough access to the system or historical information to justify my hypothesis, but I thought my personal observations might be helpful. David