From: Hans Reiser <reiser@namesys.com>
To: curtis@integratus.com
Cc: Anton Altaparmakov <aia21@cam.ac.uk>,
Nathan Scott <nathans@sgi.com>,
Andreas Gruenbacher <ag@bestbits.at>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-xfs@oss.sgi.com
Subject: Re: reiser4 (was Re: [PATCH] Revised extended attributesinterface)
Date: Wed, 12 Dec 2001 02:28:28 +0300 [thread overview]
Message-ID: <3C16969C.3070508@namesys.com> (raw)
In-Reply-To: <20011205143209.C44610@wobbly.melbourne.sgi.com> <20011207202036.J2274@redhat.com> <20011208155841.A56289@wobbly.melbourne.sgi.com> <3C127551.90305@namesys.com> <20011211134213.G70201@wobbly.melbourne.sgi.com> <5.1.0.14.2.20011211184721.04adc9d0@pop.cus.cam.ac.uk> <3C166920.77F644F@integratus.com> <3C167BF1.6090301@namesys.com> <3C1690E6.914911A2@integratus.com>
curtis@integratus.com wrote:
>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.
>
#define PIZZA F_OLIVES|F_PEPPERONI|F_ANCHOVIES|F_PINEAPPLE
#define EDIBLE_PIZZA F_OLIVES|F_PEPPERONI|F_PINEAPPLE
Your way allows for PIZZA but not EDIBLE_PIZZA to be selected by users.
Both
are easy to specify.
You cannot know in advance what a user will consider to be EDIBLE_PIZZA.
Not allowing choice is for, umh, better I not say what OS likes to
prevent choice......;-)
Ok, so I understand that what I am advocating is a lot of work, and a
much harder path to take,
and I understand why you feel you have enough work, and I think we can
both respect each
other for our positions.
I'll try to convince you again when I have working code that isn't
monstrous code, but allows
users full choice, ok?
Best,
Hans
next prev parent reply other threads:[~2001-12-11 23:30 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-05 3:32 [PATCH] Revised extended attributes interface Nathan Scott
2001-12-05 9:08 ` Anton Altaparmakov
2001-12-06 5:46 ` Nathan Scott
2001-12-06 3:05 ` Daniel Phillips
2001-12-06 5:41 ` Nathan Scott
2001-12-06 15:25 ` Daniel Phillips
2001-12-06 23:15 ` Nathan Scott
2001-12-07 1:45 ` Daniel Phillips
2001-12-07 2:03 ` Daniel Phillips
2001-12-07 3:51 ` Nathan Scott
2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08 4:58 ` Nathan Scott
2001-12-08 20:17 ` Hans Reiser
2001-12-11 2:42 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
2001-12-11 12:02 ` Hans Reiser
2001-12-11 19:23 ` Anton Altaparmakov
2001-12-11 20:14 ` reiser4 (was Re: [PATCH] Revised extended attributesinterface) curtis
2001-12-11 21:34 ` Hans Reiser
2001-12-11 23:04 ` curtis
2001-12-11 23:28 ` Hans Reiser [this message]
2001-12-11 23:46 ` Anton Altaparmakov
2001-12-12 1:00 ` curtis
2001-12-11 21:21 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Hans Reiser
2001-12-11 23:33 ` Anton Altaparmakov
2001-12-11 23:59 ` Hans Reiser
2001-12-12 2:16 ` Anton Altaparmakov
2001-12-12 12:02 ` Hans Reiser
2001-12-12 13:34 ` Anton Altaparmakov
2001-12-12 15:40 ` Hans Reiser
2001-12-13 1:43 ` Andrew Pimlott
2001-12-13 9:23 ` Hans Reiser
2001-12-13 10:36 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37 ` Ragnar Kjørstad
2001-12-13 16:06 ` Romano Giannetti
2001-12-13 18:58 ` Ragnar Kjørstad
2001-12-18 0:17 ` Pavel Machek
2001-12-13 23:24 ` David Wagner
2001-12-21 21:28 ` Andreas Ferber
2001-12-13 15:27 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Andrew Pimlott
2001-12-13 20:47 ` Hans Reiser
2001-12-13 21:01 ` Anton Altaparmakov
2001-12-10 11:52 ` [PATCH] Revised extended attributes interface Stephen C. Tweedie
2001-12-10 15:00 ` Peter J. Braam
2001-12-10 15:56 ` Stephen C. Tweedie
2001-12-10 16:00 ` Mr. James W. Laferriere
2001-12-10 16:15 ` Stephen C. Tweedie
2001-12-10 19:01 ` John Stoffel
2001-12-11 1:22 ` Timothy Shimmin
2001-12-11 11:33 ` Stephen C. Tweedie
2001-12-11 13:30 ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11 14:34 ` Stephen C. Tweedie
2001-12-11 15:15 ` Anton Altaparmakov
2001-12-11 1:41 ` Nathan Scott
2001-12-11 13:47 ` Stephen C. Tweedie
2001-12-11 18:23 ` Hans Reiser
2001-12-11 18:46 ` Anton Altaparmakov
2001-12-11 23:37 ` Implementing POSIX ACLs - was " Nathan Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C16969C.3070508@namesys.com \
--to=reiser@namesys.com \
--cc=ag@bestbits.at \
--cc=aia21@cam.ac.uk \
--cc=curtis@integratus.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=nathans@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.