Re: reiser4 (was Re: [PATCH] Revised extended attributesinterface)

Hans Reiser wrote:
> What I am saying is that each of the N permutations required to
> transform a file into an extended attribute should be separately
> selectable.  Theory guys would call this orthogonalizing the primitives.
>  (I am a theory guy.;-) ).

Applying such rigor in the architecture design phase is probably a good
idea.  Doing it at application run time is not so clear to me.

If you think of files and EAs as apples and oranges, knowing the minimal
set of orthogonal steps to turn an apple into an orange is good when
designing, but I hesitate to burden an app with having to select the
"skin-color" characteristic separately from the "ascorbic acid content"
characteristic.  IMHO, files and EAs are "package deals" where we have
chosen a different set of characteristics for each, ones that we believe
will be useful to an app.

At bottom, a file holds an uninterpreted data stream.  You have to ask
yourself whether you want that to change or not.  If not, then you
build any additional functionality in selectable layers on top of the
filesystem, not in it.  If you do want it to change, then you are
headed down the path of pulling a database into the filesystem.  Come
to think of it, I believe that someone is already doing that.  :-)

Having an interface such that an app can ask for
	open("pizza-pie", F_OLIVES|F_PEPPERONI|F_ANCHOVIES|F_PINEAPPLE...)
where each of the "F_*" options are orthogonal and ask the filesystem to
layer in a different "filter" between the raw data and the app, or to
change the access characteristics (eg: block alignment, non-buffered,
etc), sounds overly complex.  I believe that this would be better done
by explicitly stacking filesystems in a per-process namespace.

Thanks,

	Curtis

-- 
Curtis Anderson						[e-mail]