Date: Wed, 31 Mar 1999 10:58:53 -0500 From: The Classiest Man Alive <ksmm@threespace.com> To: "John S. Dyson" <toor@dyson.iquest.net>, tlambert@primenet.com (Terry Lambert) Cc: freebsd-chat@FreeBSD.ORG Subject: Re: FreeBSD is running out of time Message-ID: <199903311559.KAA27202@geek.grf.ov.com> In-Reply-To: <199903302303.SAA16794@dyson.iquest.net> References: <199903302218.PAA06239@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903311559.KAA27202>