From owner-freebsd-hackers Fri Feb 12 05:50:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA12613 for freebsd-hackers-outgoing; Fri, 12 Feb 1999 05:50:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA12608 for ; Fri, 12 Feb 1999 05:50:11 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id FAA17752; Fri, 12 Feb 1999 05:49:56 -0800 Date: Fri, 12 Feb 1999 05:49:55 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Dru Nelson cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdates In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Dru! > I'm surprised that there are problems. I have never noticed any. > Also, linux has that 2gig filesize limit, which makes it harder to really > utilize a large 500GB filesystem. Corrected by Matti Aarno's patches. I'm not saying that NASA/Ames has gone with ext2- I'm just saying that of FreeBSD/FFS, NetBSD/FFS and Linux/ext2, Linux/ext2 has shown itself to have the least problems in terms of data corruption or system panics when testing with filesystems > 100GB. Buffer cache suckdown is another problem, and up until Steve Tweedies patches in the last couple of weeks, Linux couldn't possible be considered a real candidate because while writing but large files you'd suck down 95% of primary memory for write behind buffers, making system response go away almost entirely. > > What were the requirements for NASA/Ames? > > Replacement for the Convex (chuck && scott) machines, i.e., > 900GB reliable standard filesystem that you could then put RASH hooks into later. Whether these would be via locally attached disk or via a HIPPI network block device ('raw frame' driver) was/in indeterminate. It's not clear whether anything but NetBSD will be used for these machines, but there had been so many hardware related and also possible FFS related problems with the MSS3 project that I was allowed to go off and search for possible alternatives. Digital Unix/ADVFS as is Solaris/UFS and Solaris/SAMFS (LSC's produce) are also candidates, but those are less attractive because they're not open source solutions. At any rate, at the time I was doing this, I could not demonstrate FreeBSD/FFS to be a superior combo than NetBSD/FFS, hence the term 'loss'. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message