From owner-freebsd-newbies Wed Mar 31 13:42:39 1999 Delivered-To: freebsd-newbies@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 376ED14C25; Wed, 31 Mar 1999 13:42:28 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA25147; Wed, 31 Mar 1999 15:52:27 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd025093; Wed Mar 31 15:52:19 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id OAA21836; Wed, 31 Mar 1999 14:41:59 -0700 (MST) From: Terry Lambert Message-Id: <199903312141.OAA21836@usr07.primenet.com> Subject: Re: Linux vs. FreeBSD: The Storage Wars To: toor@dyson.iquest.net (John S. Dyson) Date: Wed, 31 Mar 1999 21:41:58 +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: <199903302303.SAA16794@dyson.iquest.net> from "John S. Dyson" at Mar 30, 99 06:03:10 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 > > 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. ??? The disk had the correct data on it. The only bug was that it wouldn't be updated until the OS went to an int64_t for time_t. > > 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 :-). Ugh. Now you're just trying to get my goat. > > > (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. And or "too complicated to swallow in a small amount of time without fully understanding the problem". > 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. Any putative efficiency penalties (granting their existance for the sake of discussion) would be paid only by the stacking layers themselves, and as it currently doesn't work, you aren't going to be paying an efficiency penalty for anything you currently use. So efficiency is a NULL argument. The coherency and efficiency issues which do exist are related to object coherency between layers for very special cases, such as your and Matt's MFS design. I think the intentional intorduction of VM alias objects, given the year or more that FreeBSD has struggled with the *unintentional* introduction of aliases, and the problems that result from such things existing (file corruption, page alises, page not present errors when an alias is used to reap a page in a low memory situation, etc.) are sufficiently negative that it is *worth* the inefficiency in this special case. At the very least, it's no less performant than what exists today. IF VM alias objects are to be introduced (and that's a big mother "if", in my opinion), it should only be done *after* it is proven, using formal analysis methods, that unintentional aliases have been rendered impossible. I think that trying to track an unintentional alias problem would be, frankly, damn near impossible, if there were no way to distinguish an unintentional one from an intentional one. The only way I see clear for this to happen is if they don't both exist in the code at the same time. As an aside, the MFS issues you and Matt are hung up on, and which seem to be the driving force behind the object alias design, could be adequately addressed by creating a device that uses anonymous kernel memory in place of anonymous swap, and putting the FS on that device instead. > If one stayed in the SYSVr2 API world, > the framework as-is would be okay -- however, we are far away from those > days. The framework as-is is inadequate. At best, it kind-of works for some limited cases that people are too afraid to do anything which might preterb them for the situation to get any better. At worst, it fails to match the design document from which it was instanced, and therefore fails any reasonability test. You can't get somewhere using a map in hand unless you know where on the map you are starting. > > 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? SVR4 ES/MP. I also did kernel work in SunOS, AIX, and Solaris as part of a number of products. > Why do you put words in my mouth about doubling inode size? Straw man... You are mentioning ACL's. The most current FS ACL work is being done in NetBSD (not FreeBSD). I thought you were referencing a modern research project when you referenced ACL's. My mistake. > > 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. Fie. You are the one who originally posted about seeing years of work frittered away. I am not prepared to repeat that journey; it is a fool's quest. > > > 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? Fallacy of implied ownership of an issue, merely because I raised it in this forum instead of the original authors of the issue? > Those fields aren't owned until they are used. Those fields were used. That's why they were marked "reserved", not "spare"; an intentional semantic distinction. Do not confuse a field as unused merely because all current instances of the field are zero-valued. By that argument, I could claim that all values that are currently less than Log2 50% of their maximum magnitude are twice as large as they need to be, and those bits are "spare" for me to use. There is a difference between "range" and "allowed range". > 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. I think you need to go byte counting in the inode structure looking for the room you claim is there. Without modifying the inode into incompatability with existing FS's, it's just not there. 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