Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Mar 1999 21:41:58 +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:  <199903312141.OAA21836@usr07.primenet.com>
In-Reply-To: <199903302303.SAA16794@dyson.iquest.net> from "John S. Dyson" at Mar 30, 99 06:03:10 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903312141.OAA21836>