From owner-freebsd-newbies Tue Mar 30 14:19: 4 1999 Delivered-To: freebsd-newbies@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 42AEA15C13; Tue, 30 Mar 1999 14:19:01 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA10504; Tue, 30 Mar 1999 15:18:41 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd010408; Tue Mar 30 15:18:32 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA06239; Tue, 30 Mar 1999 15:18:29 -0700 (MST) From: Terry Lambert Message-Id: <199903302218.PAA06239@usr04.primenet.com> Subject: Re: Linux vs. FreeBSD: The Storage Wars To: toor@dyson.iquest.net (John S. Dyson) Date: Tue, 30 Mar 1999 22:18:28 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, hamellr@dsinw.com, unknown@riverstyx.net, freebsd-newbies@FreeBSD.ORG, freebsd-chat@FreeBSD.ORG In-Reply-To: <199903302200.RAA16694@dyson.iquest.net> from "John S. Dyson" at Mar 30, 99 05:00:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-newbies@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Well, as long as we are beating dead horses here... > > > > IMO, it is *silly* that FreeBSD coopted the fields in FFS that were > > reserved for dealing with the Y2038 "bug", which technically didn't > > exist in BSD 4.4 until these fields were coopted. > > > > But then, who am I to look 39 years into the future, instead of only > > 6 months ahead, like everyone else. > > Since the *fix* wasn't implemented, then the fix wasn't broken. Since the "fix" contradicted a clear architectural direction set by CSRG with clear foresight of the Y2038 problem, it violated the architectural principles which resulted in the field reservation. > Nothing additional was broken, and a better fix will eventually be > created Excuse me, ask Kirk. He designed the damn FFS with those reserved fields for a reason. > (e.g. changed inode structure for ACL support?) This is what stacking layers and namespace escapes were invented for. This is why John's students have been able to implement such VFS stacking layers (albeit, not in FreeBSD, where layer stacking is broken), but the architectural principles are surely not that difficult to grasp. I am aware of the ideas being floated to support ACL's in NetBSD; an implementation that doubles the size of the inode is a bad idea. Take it from me; I doubled the size of the inode for a commercial FS, so I well know of that which I speak. > If you think that the ODS needs to be fixed, then fix it!!! :-). If > it ends up being a solution rather than a hack, then it might just be > adopted. If the "fix" ends up requiring lots of support from others, > then the chance of the "idea" being adopted is lessened. How could the intended use of the fields, now that they contain non-zero data instead of zeros, per the backward compatability requirement of the original design for the Y2038 fix, be anything *but* a hack? The data is on the disks; the damage is done. > But, please don't proclaim an idea as an implementation, and don't > proclaim a piece of hackery as a "solution." I understand your frustration, > but because YOUR projects don't get the highest priority doesn't mean > that you are being ignored. It seems odd to me that some people think > that others should support their works. What about CSRG's project? Those spare fields were intentional, not accidental. Rail as you might, those fields were coopted, not architected, away. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-newbies" in the body of the message