Date: Tue, 30 Mar 1999 22:18:28 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: toor@dyson.iquest.net (John S. Dyson) 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: <199903302218.PAA06239@usr04.primenet.com> In-Reply-To: <199903302200.RAA16694@dyson.iquest.net> from "John S. Dyson" at Mar 30, 99 05:00:02 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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903302218.PAA06239>