Date: Tue, 30 Mar 1999 18:03:10 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: tlambert@primenet.com, dyson@iquest.net, hamellr@dsinw.com, unknown@riverstyx.net, freebsd-newbies@FreeBSD.ORG, freebsd-chat@FreeBSD.ORG Subject: Re: Linux vs. FreeBSD: The Storage Wars Message-ID: <199903302303.SAA16794@dyson.iquest.net> In-Reply-To: <199903302218.PAA06239@usr04.primenet.com> from Terry Lambert at "Mar 30, 99 10:18:28 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903302303.SAA16794>