From owner-freebsd-chat  Tue Mar 30 15: 6:28 1999
Delivered-To: freebsd-chat@freebsd.org
Received: from implode.root.com (root.com [209.102.106.178])
	by hub.freebsd.org (Postfix) with ESMTP id E843214F8D
	for <freebsd-chat@FreeBSD.ORG>; Tue, 30 Mar 1999 15:06:25 -0800 (PST)
	(envelope-from root@implode.root.com)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA13468;
	Tue, 30 Mar 1999 15:03:32 -0800 (PST)
Message-Id: <199903302303.PAA13468@implode.root.com>
To: Terry Lambert <tlambert@primenet.com>
Cc: unknown@riverstyx.net, dyson@iquest.net, freebsd-chat@FreeBSD.ORG
Subject: Re: Linux vs. FreeBSD: The Storage Wars 
In-reply-to: Your message of "Tue, 30 Mar 1999 22:07:43 GMT."
             <199903302207.PAA05079@usr04.primenet.com> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Tue, 30 Mar 1999 15:03:32 -0800
Sender: owner-freebsd-chat@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

   I really shouldn't get into this, but a couple of points:

1) According to people who should know, John H. did the implementation and
   integration of the stackable filesystems support in 4.4BSD himself, so if
   you have a complaint about they way it was done, then blame him and not
   anyone else.
2) If (1) "works" in BSD/OS (and after hearing what Mike K. has to say, I'm
   certainly not convinced of this), it's only because they spent a lot of
   time making it work.
3) There were/are a lot of architectural problems in the LFS code. That it
   takes 1MB of RAM per mounted filesystem is one of them. Its amusing
   buffer management mechanisms are another. Margo knows this as well as
   anyone. LFS was never production quality; it was written as a proof of
   concept that worked well enough to get some benchmark numbers from and
   that's about it. The benchmark numbers weren't that great, so there wasn't
   sufficient interest to put in that last 10% that takes 90% of the time.
4) The use of the spare time field in FFS for sub-second time keeping is
   consistent with what BSD/OS (and apparantly Solaris and others) have done.
   Kirk's of the opinion that we'll have to move to larger inodes anyway
   due to the limitations of [32bit] block pointers, so using the spare
   field for sub-second time keeping, rather than Y2038, isn't an issue in
   his opinion.
5) Kirk is ready to see your generalized "soft updates", so get busy.
6) Regarding IPv6: Time has proven that we made the right decision by waiting.
   It was sufficient motivation to get the various camps to merge their
   efforts. The merged IPv6 will be brought into FreeBSD as soon as it is
   ready.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message