From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3986 invoked by alias); 7 Apr 2004 19:32:31 -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 3849 invoked from network); 7 Apr 2004 19:32:26 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sources.redhat.com with SMTP; 7 Apr 2004 19:32:26 -0000 Received: (qmail 27340 invoked by uid 10); 7 Apr 2004 19:32:25 -0000 Received: (qmail 12311 invoked by uid 500); 7 Apr 2004 19:32:15 -0000 Mail-Followup-To: overseers@sources.redhat.com, fche@redhat.com, jason-swarelist@molenda.com From: Ian Lance Taylor To: Jason Molenda Cc: overseers@sources.redhat.com, fche@redhat.com Subject: Re: more data re disk i/o References: <20040407190458.GD11209@redhat.com> <20040407122003.A67411@molenda.com> Date: Wed, 07 Apr 2004 19:32:00 -0000 In-Reply-To: <20040407122003.A67411@molenda.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-q2/txt/msg00097.txt.bz2 Jason Molenda writes: > The only caveat here is that you need enough space to store a complete > checkout of a tree, worst-case. I remember a worst-case scenario at > Yahoo where a user did a 'cvs update' on a checkout and cvs thought > every file had been changed (I think his timestamps were off), so it > uploaded all of the files to the server. Or something much like that - > I can look up the e-mails to confirm the details if anyone doubts it. > But the point was that you need a pretty big RAM disk to handle this > worst-case scenario correctly. > > Or we can just declare this scenario an expected failure (it doesn't > come up very often - normal usage is a directory-at-a-time) and clean > up by hand on those rare occasions when it happens. However, if this > ever does come up, cvs will be broken for everyone until someone logs > in and removes the big disk user. It's easy to understand the failure case, but it seems unfortunate that it broke CVS until it was cleaned up. The CVS server is supposed to delete the temporary directory when it exits, even if that is due to a failure, although there is an exception if CVS dumps core. I do have a vague recollection that we used a RAM disk before, but it caused trouble because CVS would eat up all of memory sometimes. Or something. But maybe I misremember. What we really need is a file system which stays in RAM up to a point, and then swaps out to the swap file. But I don't suppose Linux has anything like that. Ian