From owner-freebsd-chat Wed Mar 31 7:59:51 1999 Delivered-To: freebsd-chat@freebsd.org Received: from geek.grf.ov.com (geek.grf.ov.com [192.251.86.19]) by hub.freebsd.org (Postfix) with ESMTP id 09D741545B for ; Wed, 31 Mar 1999 07:59:38 -0800 (PST) (envelope-from ksmm@threespace.com) Received: from pebbles (pebbles.cam.veritas.com [166.98.49.16]) by geek.grf.ov.com (8.9.0/8.9.0) with SMTP id KAA27202; Wed, 31 Mar 1999 10:59:06 -0500 (EST) Message-Id: <199903311559.KAA27202@geek.grf.ov.com> X-Sender: ksmm@mail.cybercom.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 31 Mar 1999 10:58:53 -0500 To: "John S. Dyson" , tlambert@primenet.com (Terry Lambert) From: The Classiest Man Alive Subject: Re: FreeBSD is running out of time Cc: freebsd-chat@FreeBSD.ORG In-Reply-To: <199903302303.SAA16794@dyson.iquest.net> References: <199903302218.PAA06239@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not pretending to understand all of the issues, but won't this be rendered moot on a 64-bit architecture? Do we still expect people to be running 32-bit FreeBSD in 40 years? (Yeah, yeah, I know...did we expect to be running COBOL on mainframes in 2000?) On that note, does FreeBSD have any timetables in place for moving to 64-bit and/or dropping 32-bit? K.S. At 06:03 PM 3/30/99 , John S. Dyson wrote: >> > > 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. >> >That begs the issue that nothing was broken, because the fields >weren't used. The fix didn't exist at all in FreeBSD. > >> >> >> > 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. >> >Those reserved, unused fields? It makes little difference as to how the >problem is fixed, if the problem isn't fixed :-). > >> >> >> > (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. >> >The framework as it is, is super broken, and any fixes to date are >only expedient and insufficient. It requires total architecture >rewrite if you want reasonable efficiency (not throwing performance >away) and coherency. Half solutions need not apply -- if the framework >as it was conceived and implemented so far in *BSD was fully implemented, >there would either be intractable coherency problems, or probably >intolerable efficiency issues. If one stayed in the SYSVr2 API world, >the framework as-is would be okay -- however, we are far away from those >days. > >> >> 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. >> >Which slow, commercial OS did you work on? Why do you put words in my >mouth about doubling inode size? Straw man... > >> >> > 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. >> >The ODS will need rework before Y2038 anyway. I suspect that if the code >is working by 2010, things will be all well. A UFS2 would eventually be a >good thing. > >> >> >> > 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. >> >Fallacy of appealing to authority? Those fields aren't owned until they are >used. The ODS will be changed in the future anyway. It makes little difference >as to where the data is. There is room in the inode, if needed. > >You are making a mountain out of a molehill. > >John > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-newbies" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message