* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-09 9:03 ` silent semantic changes in reiser4 (brief attempt to document the idea ofwhat " Theodore Ts'o
@ 2004-09-09 17:23 ` William Lee Irwin III
2004-09-09 18:09 ` Gunnar Ritter
` (2 subsequent siblings)
3 siblings, 0 replies; 46+ messages in thread
From: William Lee Irwin III @ 2004-09-09 17:23 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Robin Rosenberg, William Stearns, Linux Kernel
On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
>> Maybe file/./attribute then. /. on a file is currently meaningless.
>> That does not avoid the unpleasant fact that has been brought up by
>> others (only to be ignored), that the directory syntax does not
>> allow metadata on directories.
On Thu, Sep 09, 2004 at 05:03:42AM -0400, Theodore Ts'o wrote:
> *Not* that I am endorsing the idea of being able to access metadata
> via a standard pathname --- I continue to believe that named streams
> are a bad idea that will be an attractive nuisance to application
> developers, and if we must do them, then Solaris's openat(2) API is
> the best way to proceed --- HOWEVER, if people are insistent on being
> able to do this via standard pathnames, and not introducing a new
> system call, I would suggest /|/ as the separator as the third least
> worst option. Why?
I believe this debate is counterproductive while there are far more
basic and serious issues with reiser4, such as architecture-neutrality
of the interpretation of the on-disk format, still pending.
-- wli
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-09 9:03 ` silent semantic changes in reiser4 (brief attempt to document the idea ofwhat " Theodore Ts'o
2004-09-09 17:23 ` William Lee Irwin III
@ 2004-09-09 18:09 ` Gunnar Ritter
2004-09-09 19:15 ` Hans Reiser
2004-09-10 9:42 ` Helge Hafting
3 siblings, 0 replies; 46+ messages in thread
From: Gunnar Ritter @ 2004-09-09 18:09 UTC (permalink / raw)
To: Theodore Ts'o, Robin Rosenberg; +Cc: William Stearns, Linux Kernel
Theodore Ts'o <tytso@mit.edu> wrote:
> Any such scheme will violate POSIX and SUS, since we are stealing from
> the filename namespace,
Not forcibly. POSIX does not give guarantees that everybody can access
existing files with arbitrary names. If there is a metafile in a directory
which can be looked up using the regular pathname hierarchy but requires
certain conditions to be accessed, there is principally nothing wrong
with this. It would likely be wrong if accessing the name for a
non-existent metafile using one of the POSIX interfaces (e.g. creat())
would result in other than one of the defined actions.
> and thus could cause a previously working program to stop working
POSIX holds a barrier against this. It just does not work using the
pathname resolution specification alone. It works by defining certain
actions for certain file type/system interface combinations. For
example, it is demanded that chdir() fails with ENOTDIR if the target
name is not a directory. Thus if the target is a regular file, chdir()
is required to fail.
If, however, the type of the file in question is neither S_IFREG
nor S_IFDIR nor another of the standardized file types, there are
no prescriptions about what system interfaces must do on them.
POSIX (IEEE Std 1003.1, 2004 Edition) explicitly allows to support
non-standard file types in its Base Definitions, 3. 'Definitions',
3.163 'File'.
Also (Base Definitions, 2.1 'Implementation Conformance', 2.1.1
'Requirements'):
# 4. The system may provide additional utilities, functions, or facilities
# not required by IEEE Std 1003.1-2001. Non-standard extensions of the
# utilities, functions, or facilities specified in IEEE Std 1003.1-2001
# should be identified as such in the system documentation. Non-standard
# extensions, when used, may change the behavior of utilities, functions,
# or facilities defined by IEEE Std 1003.1-2001. The conformance document
# shall define an environment in which an application can be run with the
# behavior specified by IEEE Std 1003.1-2001. In no case shall such an
# environment require modification of a Strictly Conforming POSIX
# Application (see Strictly Conforming POSIX Application ).
For example, Unix domain sockets were not part of POSIX until 2001,
but none of the existing systems violated POSIX by refusing to open()
them.
I'm not sure about the results of pathname lookup using the names of
such implementation-defined file types with slashes attached, but it
would probably be worth to file an interpretation request for this
once there is sufficient demand to support it in Linux.
> --- however, assuming that we don't care about
> this, the virtical bar is the least likely to collide with existing
> file usages, because of its status as a shell meta-character (i.e.,
> pipe). This means that in order to use it on the shell command line,
> programs will have to quote it:
>
> cat /home/tytso/word.doc/\|/meta/silly-stupid-metadata-or-named-stream
POSIX certainly requires this to fail with ENOTDIR if 'word.doc' is
S_IFREG, but if it is something like S_IFSTR, there might be a realistic
chance to have it as an implementation extension without violating POSIX.
Gunnar
--
http://omnibus.ruf.uni-freiburg.de/~gritter
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-09 9:03 ` silent semantic changes in reiser4 (brief attempt to document the idea ofwhat " Theodore Ts'o
2004-09-09 17:23 ` William Lee Irwin III
2004-09-09 18:09 ` Gunnar Ritter
@ 2004-09-09 19:15 ` Hans Reiser
2004-09-09 20:45 ` Paul Jakma
2004-09-12 20:43 ` Davide Inglima
2004-09-10 9:42 ` Helge Hafting
3 siblings, 2 replies; 46+ messages in thread
From: Hans Reiser @ 2004-09-09 19:15 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Robin Rosenberg, William Stearns, Linux Kernel
Putting \ into filenames makes windows compatibility less trivial.
Putting | into filenames seems like asking for trouble with shells.
Asking users to keep track of multiple levels of escapes imposed by
shells and such is hard on them.
If you think \| is user friendly, oh god, people like you are the reason
why Unix is hated by many.
Having to explain filename/metas/owner or filename/.../owner or
filename/..metas/owner (I don't deeply care what string is used in place
of "metas") is hard enough.
All of that said, if "|" was what people preferred, I could live with it.
Stealing from the namespace has a long history behind it (see WAFL,
Clearcase, many others), and has never been a real world problem. It is
not so bad. If you manage to find a historical case where someone made a
mistake in the past, go ahead and name it, but I think moderate caution
in such thievery is enough, paranoia is not required. Frankly I think
the people who get paranoid about stealing a little bit from the
namespace just aren't experienced enough in such matters.
Making an omelette requires breaking eggs. Making a new semantic layer
(or adding features to languages generally) requires stealing from the
namespace. POSIX is a least common denominator of operating systems, not
something for innovators to follow.
Ted, I encourage you to not innovate and stick with POSIX.;-)
(Oh, and yes, I understand that minimizing the cost of change by being
artful is desirable.)
Streams are a bad idea. The additional features required to emulate
streams using files and directories are interesting though. Putting
metafiles in the fs namespace is an increase in closure for the OS, and
thus a good thing, because more closure means more connectivity between
OS components.
Rather few people understand closure though, so I don't expect to do
well in the politics of this. It is a bit like being for free trade,
most people will never understand why it is so important because their
mental gifts are in other matters, and the notion that people need to be
well connected and free to interact is just way too abstract. That it is
the single most important determinant of a nation's wealth, oh well.
Namespace connectivity is the single most important determinant of an
OS's expressive power.
Hans
Theodore Ts'o wrote:
>On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
>
>
>>Maybe file/./attribute then. /. on a file is currently meaningless. That does
>>not avoid the unpleasant fact that has been brought up by others (only to be
>>ignored), that the directory syntax does not allow metadata on directories.
>>
>>
>
>*Not* that I am endorsing the idea of being able to access metadata
>via a standard pathname --- I continue to believe that named streams
>are a bad idea that will be an attractive nuisance to application
>developers, and if we must do them, then Solaris's openat(2) API is
>the best way to proceed --- HOWEVER, if people are insistent on being
>able to do this via standard pathnames, and not introducing a new
>system call, I would suggest /|/ as the separator as the third least
>worst option. Why?
>
>Any such scheme will violate POSIX and SUS, since we are stealing from
>the filename namespace, and thus could cause a previously working
>program to stop working --- however, assuming that we don't care about
>this, the virtical bar is the least likely to collide with existing
>file usages, because of its status as a shell meta-character (i.e.,
>pipe). This means that in order to use it on the shell command line,
>programs will have to quote it:
>
> cat /home/tytso/word.doc/\|/meta/silly-stupid-metadata-or-named-stream
>
>This may seem to be inconvenient, but one very good thing about this
>is that PHP and existing Perl scripts already already treat pathnames
>that contain pipes with a certain amount of suspicion --- and this is
>a good thing! Otherwise, programs that take input from untrusted
>sources (say, URL's or http form posts), may convert such input into a
>metadata access, and that may be a very, very, very bad thing. (For
>example, it may mean that you will have accidentally allowed a web
>user to read or possibly modify an ACL with whatever privileges of the
>CGI-perl or php script.) By using a pipe character, it avoids this
>problem, since secure CGI scripts must be already checking for the
>pipe character anyway.
>
>
>
>>I'm not convinced that totally transparent access to meta-data actually
>>benefits anyone. If metadata is that useful (which I believe) it may well be
>>worth fixing those apps that need, and can use them. The rest should just
>>ignore it, even loose it.
>>
>>
>
>Totally agreed. As I said above, I would prefer openat(2) to trying
>to do this within a standard pathname, and I would prefer not doing it
>all since aside from Samba, which is simply trying to maintain
>backwards compatibility with a Really Bad Idea, the number of
>protocols and data formats (ftp, tar, zip, gzip, cpio, etc., etc.,
>etc.) that would need to be revamped is huge.
>
> - Ted
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-09 19:15 ` Hans Reiser
@ 2004-09-09 20:45 ` Paul Jakma
2004-09-10 0:57 ` Hans Reiser
2004-09-12 20:43 ` Davide Inglima
1 sibling, 1 reply; 46+ messages in thread
From: Paul Jakma @ 2004-09-09 20:45 UTC (permalink / raw)
To: Hans Reiser
Cc: Theodore Ts'o, Robin Rosenberg, William Stearns, Linux Kernel
On Thu, 9 Sep 2004, Hans Reiser wrote:
> Putting \ into filenames makes windows compatibility less trivial.
Err, I think Ted used \ as an example of how to escape |. It is not
part of the filename.
> Putting | into filenames seems like asking for trouble with shells.
I think that was Ted's precise reason for arguing that | be used. Did
you even read his rationale? :)
> If you think \| is user friendly, oh god, people like you are the
> reason why Unix is hated by many.
I think he was arguing | (not \|) is the least worst seperator to
use.
> Rather few people understand closure though, so I don't expect to
> do well in the politics of this. It is a bit like being for free
> trade, most people will never understand why it is so important
> because their mental gifts are in other matters,
Lots of people understand why free-trade is important. It's taught in
introductory economics/business classes in secondary school.
If you are similarly underestimating the understanding of those who
are debating merits of in-name-space streams with you, and
overestimating your own understanding, you're not going make progress
in convincing people of their merit (if at all).
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
The only way to keep your health is to eat what you don't want, drink what
you don't like, and do what you'd rather not.
-- Mark Twain
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-09 20:45 ` Paul Jakma
@ 2004-09-10 0:57 ` Hans Reiser
2004-09-10 1:15 ` Paul Jakma
2004-09-10 3:22 ` Horst von Brand
0 siblings, 2 replies; 46+ messages in thread
From: Hans Reiser @ 2004-09-10 0:57 UTC (permalink / raw)
To: Paul Jakma
Cc: Theodore Ts'o, Robin Rosenberg, William Stearns, Linux Kernel
Paul Jakma wrote:
> On Thu, 9 Sep 2004, Hans Reiser wrote:
>
>> Putting \ into filenames makes windows compatibility less trivial.
>
>
> Err, I think Ted used \ as an example of how to escape |. It is not
> part of the filename.
It is not part of it at one level, but in the shell it is part of it.
>
>> Putting | into filenames seems like asking for trouble with shells.
>
>
> I think that was Ted's precise reason for arguing that | be used. Did
> you even read his rationale? :)
That trouble is desirable? Yes, I can understand why he might not want
things to work well.;-)
>
>> If you think \| is user friendly, oh god, people like you are the
>> reason why Unix is hated by many.
>
>
> I think he was arguing | (not \|) is the least worst seperator to use.
>
>> Rather few people understand closure though, so I don't expect to do
>> well in the politics of this. It is a bit like being for free trade,
>> most people will never understand why it is so important because
>> their mental gifts are in other matters,
>
>
> Lots of people understand why free-trade is important. It's taught in
> introductory economics/business classes in secondary school.
Have you looked at the political process at all? Or by lots of people,
do you mean a sizable minority?
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 0:57 ` Hans Reiser
@ 2004-09-10 1:15 ` Paul Jakma
2004-09-10 5:04 ` Hans Reiser
2004-09-10 3:22 ` Horst von Brand
1 sibling, 1 reply; 46+ messages in thread
From: Paul Jakma @ 2004-09-10 1:15 UTC (permalink / raw)
To: Hans Reiser
Cc: Theodore Ts'o, Robin Rosenberg, William Stearns, Linux Kernel
On Thu, 9 Sep 2004, Hans Reiser wrote:
> It is not part of it at one level, but in the shell it is part of it.
Just one of many applications. Watch Joe-user save their word
processing file sometime, they'll use spaces, quotes, etc.
> Have you looked at the political process at all? Or by lots of
> people, do you mean a sizable minority?
Kernel development does require deep understanding by the majority of
computer users. Only kernel developers need deep understanding. ;)
The real question though is: Have you given Al Viro technical answers
to his technical questions?
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Malek's Law:
Any simple idea will be worded in the most complicated way.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 1:15 ` Paul Jakma
@ 2004-09-10 5:04 ` Hans Reiser
2004-09-10 5:53 ` viro
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Hans Reiser @ 2004-09-10 5:04 UTC (permalink / raw)
To: Paul Jakma
Cc: Theodore Ts'o, Robin Rosenberg, William Stearns, Linux Kernel
Paul Jakma wrote:
> On Thu, 9 Sep 2004, Hans Reiser wrote:
>
>> It is not part of it at one level, but in the shell it is part of it.
>
>
> Just one of many applications. Watch Joe-user save their word
> processing file sometime, they'll use spaces, quotes, etc.
With great unhappiness they will.
>
>> Have you looked at the political process at all? Or by lots of
>> people, do you mean a sizable minority?
>
>
> Kernel development does
did you mean to have a "not" here?
> require deep understanding by the majority of computer users. Only
> kernel developers need deep understanding. ;)
What makes you think kernel developers have a deep understanding of the
value of connectivity in the OS? They don't. The average kernel
developer is not particularly bright. Just ask Ted why htrees are slower
than reiser4, or ext2 tail combining is slower, and, well, he has no
clue. He is happy to explain how architects don't do real work and
should not attend the Linux Kernel Summit, and then when reiser4 blows
htrees away he undoubtedly still thinks I just take the credit away from
the programmers who do the real work. They did real work, and they are
the best in the field, but architecture also matters --- quite a lot
actually.
Maybe instead of free trade, I should have used anti-trust laws as my
example. The percentage of persons who analytically understand both that
free trade is vital and that anti-trust laws are a good thing is very
small (and especially small at Harvard Law School). Average people can
understand freedom. Understanding that one is not really free to choose
to not purchase from a cartel is hard for many. Understanding that free
markets are only a first approximation and that is why we need
anti-trust laws is beyond perhaps even most economics PhDs.
This is not due to a lack of education. I once had a boss explain to me
how many people have trouble understanding orders of magnitude and
ratios. He particularly meant his boss, who was having trouble
understanding my report.
We all have mental defects, we just have them in different areas from
each other. (Forgive me for not enumerating mine....;-) ) Some technical
matters are understood by much less than 50% of the population. Closure
is one of them. For most people the value of closure can only be
understood by using and liking a system that has it, and they are not
capable of wanting it in advance during the design stages. Codd
understood the importance of closure. You could sense his frustration at
being unable to convey it to others in his writings. The search engine
industry completely misses the importance of closure.
This is why I just want to be left alone to tinker with reiser4. It is
faster than other filesystems. People should assume I know what I am
doing, and leave me to tinker in my little fs. 5 years later others will
follow, or not, I don't care.
>
> The real question though is: Have you given Al Viro technical answers
> to his technical questions?
Yes, I did. Got no response. Would you like me to post something nice
and technical to this thread?;-) I can send a summary of my design, and
the answers I sent to Viro and Linus.
>
> regards,
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 5:04 ` Hans Reiser
@ 2004-09-10 5:53 ` viro
2004-09-10 6:52 ` Hans Reiser
2004-09-10 7:21 ` Hans Reiser
2004-09-10 9:20 ` Alan Cox
2004-09-10 13:08 ` Horst von Brand
2 siblings, 2 replies; 46+ messages in thread
From: viro @ 2004-09-10 5:53 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
> >The real question though is: Have you given Al Viro technical answers
> >to his technical questions?
>
> Yes, I did. Got no response.
Liar.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 5:53 ` viro
@ 2004-09-10 6:52 ` Hans Reiser
2004-09-10 7:05 ` viro
2004-09-10 7:21 ` Hans Reiser
1 sibling, 1 reply; 46+ messages in thread
From: Hans Reiser @ 2004-09-10 6:52 UTC (permalink / raw)
To: viro
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
viro@parcelfarce.linux.theplanet.co.uk wrote:
>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
>
>
>>>The real question though is: Have you given Al Viro technical answers
>>>to his technical questions?
>>>
>>>
>>Yes, I did. Got no response.
>>
>>
>
>Liar.
>
>
>
>
What was your technical response then?
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 6:52 ` Hans Reiser
@ 2004-09-10 7:05 ` viro
2004-09-10 7:30 ` Hans Reiser
0 siblings, 1 reply; 46+ messages in thread
From: viro @ 2004-09-10 7:05 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
On Thu, Sep 09, 2004 at 11:52:46PM -0700, Hans Reiser wrote:
> viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> >On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
> >
> >
> >>>The real question though is: Have you given Al Viro technical answers
> >>>to his technical questions?
> >>>
> >>>
> >>Yes, I did. Got no response.
> >>
> >>
> >
> >Liar.
> >
> >
> >
> >
> What was your technical response then?
20040908093624.GW23987@parcelfarce.linux.theplanet.co.uk, written in assumption
that the only reply I've got regaring the Message-ID of your "answers" had
been correct.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 7:05 ` viro
@ 2004-09-10 7:30 ` Hans Reiser
2004-09-10 16:49 ` Lee Revell
0 siblings, 1 reply; 46+ messages in thread
From: Hans Reiser @ 2004-09-10 7:30 UTC (permalink / raw)
To: viro
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
viro@parcelfarce.linux.theplanet.co.uk wrote:
>On Thu, Sep 09, 2004 at 11:52:46PM -0700, Hans Reiser wrote:
>
>
>>viro@parcelfarce.linux.theplanet.co.uk wrote:
>>
>>
>>
>>>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
>>>
>>>
>>>
>>>
>>>>>The real question though is: Have you given Al Viro technical answers
>>>>>to his technical questions?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Yes, I did. Got no response.
>>>>
>>>>
>>>>
>>>>
>>>Liar.
>>>
>>>
>>>
>>>
>>>
>>>
>>What was your technical response then?
>>
>>
>
>20040908093624.GW23987@parcelfarce.linux.theplanet.co.uk, written in assumption
>that the only reply I've got regaring the Message-ID of your "answers" had
>been correct.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Not found in my folder, perhaps you could just forward it.....
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 7:30 ` Hans Reiser
@ 2004-09-10 16:49 ` Lee Revell
2004-09-10 17:23 ` viro
0 siblings, 1 reply; 46+ messages in thread
From: Lee Revell @ 2004-09-10 16:49 UTC (permalink / raw)
To: Hans Reiser
Cc: viro, Paul Jakma, Theodore Ts'o, Robin Rosenberg,
William Stearns, Linux Kernel
On Fri, 2004-09-10 at 03:30, Hans Reiser wrote:
> viro@parcelfarce.linux.theplanet.co.uk wrote:
> >On Thu, Sep 09, 2004 at 11:52:46PM -0700, Hans Reiser wrote:
> >
> >>viro@parcelfarce.linux.theplanet.co.uk wrote:
> >>
> >>>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
> >>>
> >>>>>The real question though is: Have you given Al Viro technical answers
> >>>>>to his technical questions?
> >>>>>
> >>>>Yes, I did. Got no response.
> >>>>
> >>>Liar.
> >>>
> >>What was your technical response then?
> >
> >20040908093624.GW23987@parcelfarce.linux.theplanet.co.uk, written in assumption
> >that the only reply I've got regaring the Message-ID of your "answers" had
> >been correct.
> >
> >
> Not found in my folder, perhaps you could just forward it.....
There was a list outage lasting several hours at the height of the
reiser4 thread. So, before you start with the name calling, please
check the archives to see if your post made it.
Lee
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 16:49 ` Lee Revell
@ 2004-09-10 17:23 ` viro
0 siblings, 0 replies; 46+ messages in thread
From: viro @ 2004-09-10 17:23 UTC (permalink / raw)
To: Lee Revell
Cc: Hans Reiser, Paul Jakma, Theodore Ts'o, Robin Rosenberg,
William Stearns, Linux Kernel
On Fri, Sep 10, 2004 at 12:49:50PM -0400, Lee Revell wrote:
> There was a list outage lasting several hours at the height of the
> reiser4 thread. So, before you start with the name calling, please
> check the archives to see if your post made it.
http://marc.theaimsgroup.com/?l=linux-kernel&m=109463636524917&w=2
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 5:53 ` viro
2004-09-10 6:52 ` Hans Reiser
@ 2004-09-10 7:21 ` Hans Reiser
2004-09-10 7:33 ` viro
1 sibling, 1 reply; 46+ messages in thread
From: Hans Reiser @ 2004-09-10 7:21 UTC (permalink / raw)
To: viro
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
viro@parcelfarce.linux.theplanet.co.uk wrote:
>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
>
>
>>>The real question though is: Have you given Al Viro technical answers
>>>to his technical questions?
>>>
>>>
>>Yes, I did. Got no response.
>>
>>
>
>Liar.
>
>
>
>
I don't think that "Liar." is an appropriate response. If you sent a
response, just quote it.
I must say that your attitude towards persons contributing to Linux (of
which this email is the least of it) has over the years lost Linux
persons much more talented than yourself. We lost the opportunity to
have one of DARPAs hot young security researchers contribute to us
because his experience was that Linux maintainers are a collection of
assholes hostile to new contributors, and he had too much self respect
to deal with the likes of you. He was a very nice and talented young
man. Frankly, I look at Linux, and I see all the reasons why I decided
not to develop for BSD coming to life in Linux now that Linux is more
successful than BSD. Inner circle, hostility to newcomers, patch
acceptance based on whose nose is in whose ass, etc., etc.
Hans
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 7:21 ` Hans Reiser
@ 2004-09-10 7:33 ` viro
2004-09-10 7:46 ` Hans Reiser
0 siblings, 1 reply; 46+ messages in thread
From: viro @ 2004-09-10 7:33 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
On Fri, Sep 10, 2004 at 12:21:50AM -0700, Hans Reiser wrote:
> I don't think that "Liar." is an appropriate response.
To a bold-faced lie? Yes, it is.
> If you sent a
> response, just quote it.
I've already posted Message-Id, but if you prefer a quote, fine, here it is:
============================================================================
On Wed, Sep 08, 2004 at 01:21:45PM +0530, Sriram Karra wrote:
> Perhaps this is one? Message-ID: <413578C9.8020305@namesys.com>
OK...
One note before replying: current code deadlocks even if you make ->link()
*ALWAYS* return an error. It doesn't get to calling the method. No amount
of "disallow hard links to <something>" is going to help here, obviously.
<quote>
Cycle detection:
We should either 1) make hard links only link to the file aspect of the
file-directory duality, and persons who want to link to the directory
aspect must use symlinks (best short term answer), or 2) ask Alexander
Smith to help us with applying his cycle detection algorithm and gain
the benefit of being able to hard link to directories (if it works well,
best long term answer).
</quote>
... which doesn't address the problem at all. The question is what to do
with seeing directory "aspect..." in more than one place when we have many
links to file in question. So much for (1). And (2) is not feasible with
on-disk fs both due to memory, CPU and IO costs _and_ due to exclusion from
hell you'll need to make it safe.
Re: ambiguity - lots and lots of handwaving on both sides. FWIW, I agree
with Hans in one (and only one) respect here - openat() as a primary API
(and not a convenient libc function) is an atrocity. Simply because it
doesn't address operations beyond open (unlinkat(2), anyone?).
However, I still haven't seen any strong arguments for need of this "metas"
stuff _or_ the need to export mode/ownership as files, both for regular
files and for directories. Aside of "we can do that" [if we solve the
locking issues] and "xattrs are atrocious" [yes, they are; it doesn't make
alternative mechanism any better] there was nothing that even pretended to
be a technical reason.
Note that we also have fun issues with device nodes (Linus' "show partitions"
vs. "show metadata from hosting filesystem"), which makes it even more dubious.
We also have symlinks to deal with (do they have attributes? where should
that be exported?).
Reserved names have one more problem: to be useful, they'd have to be
hardcoded into applications. And that will create hell with use of
such applications on existing filesystems. Again, no feasible scheme
to deal with that in userland code had been proposed so far, AFAICS.
Locking: see above - links to regular files would create directories seen
in many places. With all related issues...
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 7:33 ` viro
@ 2004-09-10 7:46 ` Hans Reiser
2004-09-10 8:18 ` viro
0 siblings, 1 reply; 46+ messages in thread
From: Hans Reiser @ 2004-09-10 7:46 UTC (permalink / raw)
To: viro
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
Well I didn't get this response, so whether or not you sent it, it was
not a lie. Drink less coffee.
viro@parcelfarce.linux.theplanet.co.uk wrote:
>On Fri, Sep 10, 2004 at 12:21:50AM -0700, Hans Reiser wrote:
>
>
>>I don't think that "Liar." is an appropriate response.
>>
>>
>
>To a bold-faced lie? Yes, it is.
>
>
>
>>If you sent a
>>response, just quote it.
>>
>>
>
>I've already posted Message-Id, but if you prefer a quote, fine, here it is:
>
>============================================================================
>On Wed, Sep 08, 2004 at 01:21:45PM +0530, Sriram Karra wrote:
>
>
>>Perhaps this is one? Message-ID: <413578C9.8020305@namesys.com>
>>
>>
>
>OK...
>
>One note before replying: current code deadlocks even if you make ->link()
>*ALWAYS* return an error. It doesn't get to calling the method. No amount
>of "disallow hard links to <something>" is going to help here, obviously.
>
><quote>
>Cycle detection:
>
>We should either 1) make hard links only link to the file aspect of the
>file-directory duality, and persons who want to link to the directory
>aspect must use symlinks (best short term answer), or 2) ask Alexander
>Smith to help us with applying his cycle detection algorithm and gain
>the benefit of being able to hard link to directories (if it works well,
>best long term answer).
></quote>
>
>... which doesn't address the problem at all. The question is what to do
>with seeing directory "aspect..." in more than one place when we have many
>links to file in question.
>
You don't allow people to see the directory aspect in more than one
place.....
> So much for (1). And (2) is not feasible with
>on-disk fs both due to memory, CPU and IO costs _and_ due to exclusion from
>hell you'll need to make it safe.
>
>
Your statement regarding 2) is unsupported by technical argument and I
think wrong as well.
>Re: ambiguity - lots and lots of handwaving on both sides. FWIW, I agree
>with Hans in one (and only one) respect here - openat() as a primary API
>(and not a convenient libc function) is an atrocity. Simply because it
>doesn't address operations beyond open (unlinkat(2), anyone?).
>
>However, I still haven't seen any strong arguments for need of this "metas"
>stuff _or_ the need to export mode/ownership as files, both for regular
>files and for directories. Aside of "we can do that" [if we solve the
>locking issues] and "xattrs are atrocious" [yes, they are; it doesn't make
>alternative mechanism any better] there was nothing that even pretended to
>be a technical reason.
>
>
Closure is very technical as a reason. It seems to be above your head
though. I can say more about it, but not before bed....
>Note that we also have fun issues with device nodes (Linus' "show partitions"
>vs. "show metadata from hosting filesystem"), which makes it even more dubious.
>We also have symlinks to deal with (do they have attributes? where should
>that be exported?).
>
>Reserved names have one more problem: to be useful, they'd have to be
>hardcoded into applications. And that will create hell with use of
>such applications on existing filesystems. Again, no feasible scheme
>to deal with that in userland code had been proposed so far, AFAICS.
>
>
How is this different from adding any new feature to any program
(library, kernel, fs, daemon) with competitors, that other programs
interact with? If you can't cope with change, don't user reiser4.....
reiser4 still supports stat(),....
>Locking: see above - links to regular files would create directories seen
>in many places.
>
No, it would only be seen from one parent, unless Smith's solution is used.
> With all related issues...
>
>
>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 7:46 ` Hans Reiser
@ 2004-09-10 8:18 ` viro
0 siblings, 0 replies; 46+ messages in thread
From: viro @ 2004-09-10 8:18 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
On Fri, Sep 10, 2004 at 12:46:23AM -0700, Hans Reiser wrote:
> >file-directory duality, and persons who want to link to the directory
> >aspect must use symlinks (best short term answer), or 2) ask Alexander
> >Smith to help us with applying his cycle detection algorithm and gain
> >the benefit of being able to hard link to directories (if it works well,
> >best long term answer).
> ></quote>
> >
> >... which doesn't address the problem at all. The question is what to do
> >with seeing directory "aspect..." in more than one place when we have many
> >links to file in question.
> >
> You don't allow people to see the directory aspect in more than one
> place.....
And which place would that be? Concrete example: we have 4 links to the
same inode in /bin - /bin/gzip, /bin/gunzip, /bin/zcat and /bin/uncompress.
What should happen upon attempts to look at the metadata of /bin/gzip and
/bin/gunzip simultaneously from completely unrelated processes? Where
can these guys be found and in case if you say "whoever looks first wins,
another guy gets -EBUSY or some other error" keep in mind that user-triggerable
DoS tend to make sysadmins quite unhappy.
> >So much for (1). And (2) is not feasible with
> >on-disk fs both due to memory, CPU and IO costs _and_ due to exclusion from
> >hell you'll need to make it safe.
> >
> >
> Your statement regarding 2) is unsupported by technical argument and I
> think wrong as well.
Uhh... Hans, think for a second - any algorithm would have to be able to
tell if adding an edge to graph would create a loop. Consider the following
graph: take two full binary trees of depth N, order their leaves, revert the
edges in one of them and for each leaf of the first tree add an edge leading
to corresponding leaf of the second one. (IOW, for N=2 you'll get 14 nodes
with the following edges: A->A0, A->A1, A0->A00, A0->A01, A1->A10, A1->A11,
A00->B00, A01->B01, A10->B10, A11->B11, B00->B0, B01->B0, B10->B1, B11->B1,
B0->B, B1->B). Now, give that tree to your algorithm and start asking if
adding an edge between given two nodes would add a loop. You'll get
exponential time complexity. Moreover, the number of nodes you would have
to examine is also exponential.
Note that guy specifically mentioned that his filesystem had been in-core
one. With disk-based fs you'll either have to keep the entire graph
in-core *or* you will have to walk the damn thing pulling it from disk.
And you need an exclusion against graph modifications while you are looking
through it. Have fun...
> >Re: ambiguity - lots and lots of handwaving on both sides. FWIW, I agree
> >with Hans in one (and only one) respect here - openat() as a primary API
> >(and not a convenient libc function) is an atrocity. Simply because it
> >doesn't address operations beyond open (unlinkat(2), anyone?).
> >
> >However, I still haven't seen any strong arguments for need of this "metas"
> >stuff _or_ the need to export mode/ownership as files, both for regular
> >files and for directories. Aside of "we can do that" [if we solve the
> >locking issues] and "xattrs are atrocious" [yes, they are; it doesn't make
> >alternative mechanism any better] there was nothing that even pretended to
> >be a technical reason.
> >
> >
> Closure is very technical as a reason. It seems to be above your head
> though. I can say more about it, but not before bed....
The word "closure" has more than enough meanings, so I am afraid that
unless you care to specify what exactly you are talking about it will
remain above my head - I am not a telepath.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 5:04 ` Hans Reiser
2004-09-10 5:53 ` viro
@ 2004-09-10 9:20 ` Alan Cox
2004-09-10 17:48 ` Hans Reiser
2004-09-10 13:08 ` Horst von Brand
2 siblings, 1 reply; 46+ messages in thread
From: Alan Cox @ 2004-09-10 9:20 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel Mailing List
On Gwe, 2004-09-10 at 06:04, Hans Reiser wrote:
> > Just one of many applications. Watch Joe-user save their word
> > processing file sometime, they'll use spaces, quotes, etc.
> With great unhappiness they will.
Its only problematic for the command line users. The GUI doesn't have
some mysterious notion of meta-characters, it provides out of band
information on boundaries.
> This is why I just want to be left alone to tinker with reiser4. It is
> faster than other filesystems. People should assume I know what I am
> doing, and leave me to tinker in my little fs. 5 years later others will
> follow, or not, I don't care.
See I don't care if you tinker with reiser4. I don't care if it turns
out to be a crap fs or a great fs. If its a great fs and scales and
unlike reiser3 can recover well from disk errors then one year I might
even use it.
I do care if you ask me to suffer core API changes for your research,
that in your economics world is an externality. Its a large negative
externality on the part of the userbase so the userbase objects. It
doesn't take a PhD in economics to understand this.
Alan
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 9:20 ` Alan Cox
@ 2004-09-10 17:48 ` Hans Reiser
2004-09-10 17:07 ` Alan Cox
0 siblings, 1 reply; 46+ messages in thread
From: Hans Reiser @ 2004-09-10 17:48 UTC (permalink / raw)
To: Alan Cox
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel Mailing List
Alan Cox wrote:
>On Gwe, 2004-09-10 at 06:04, Hans Reiser wrote:
>
>
>>>Just one of many applications. Watch Joe-user save their word
>>>processing file sometime, they'll use spaces, quotes, etc.
>>>
>>>
>>With great unhappiness they will.
>>
>>
>
>Its only problematic for the command line users. The GUI doesn't have
>some mysterious notion of meta-characters, it provides out of band
>information on boundaries.
>
>
Forgive me, what is out of band information on boundaries?
Most people I know don't use the GUI for executing commands, perhaps
this is because the existing guis are not good enough yet.
>
>
>>This is why I just want to be left alone to tinker with reiser4. It is
>>faster than other filesystems. People should assume I know what I am
>>doing, and leave me to tinker in my little fs. 5 years later others will
>>follow, or not, I don't care.
>>
>>
>
>See I don't care if you tinker with reiser4. I don't care if it turns
>out to be a crap fs or a great fs. If its a great fs and scales and
>unlike reiser3 can recover well from disk errors then one year I might
>even use it.
>
>
Is there a technical basis for your claim that we have trouble with disk
errors?
Do you mean badblocks support or what?
>I do care if you ask me to suffer core API changes for your research,
>that in your economics world is an externality. Its a large negative
>externality on the part of the userbase so the userbase objects. It
>doesn't take a PhD in economics to understand this.
>
>Alan
>
>
>
>
>
I think it would be reasonable for people to say that our approach
currently has bugs, we should turn metafiles off until we make the bugs
go away.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 17:48 ` Hans Reiser
@ 2004-09-10 17:07 ` Alan Cox
0 siblings, 0 replies; 46+ messages in thread
From: Alan Cox @ 2004-09-10 17:07 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel Mailing List
On Gwe, 2004-09-10 at 18:48, Hans Reiser wrote:
> Is there a technical basis for your claim that we have trouble with disk
> errors?
>
> Do you mean badblocks support or what?
I mean probability of gettng your data back after a disk loses data. And
the technical basis for my claims is twofold - painful experience is
one, and shooting random blocks of zeros onto a disk and run fsck tools
is another.
> I think it would be reasonable for people to say that our approach
> currently has bugs, we should turn metafiles off until we make the bugs
> go away.
Well reiserfs4 is a lot more than metafiles and new vfs layer concepts.
Clearly those parts of the the fs that don't require core fs changes
belong in the kernel as soon as everyone is happy they are clean enough
and look correct.
Metafiles and openat() are an argument we can all have later.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 5:04 ` Hans Reiser
2004-09-10 5:53 ` viro
2004-09-10 9:20 ` Alan Cox
@ 2004-09-10 13:08 ` Horst von Brand
2 siblings, 0 replies; 46+ messages in thread
From: Horst von Brand @ 2004-09-10 13:08 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
Hans Reiser <reiser@namesys.com> said:
> Paul Jakma wrote:
> > On Thu, 9 Sep 2004, Hans Reiser wrote:
> >> It is not part of it at one level, but in the shell it is part of it.
> > Just one of many applications. Watch Joe-user save their word
> > processing file sometime, they'll use spaces, quotes, etc.
> With great unhappiness they will.
Given the right GUI, they won't even notice.
> >> Have you looked at the political process at all? Or by lots of
> >> people, do you mean a sizable minority?
> > Kernel development does
> did you mean to have a "not" here?
> > require deep understanding by the majority of computer users. Only
> > kernel developers need deep understanding. ;)
> What makes you think kernel developers have a deep understanding of the
> value of connectivity in the OS?
Enlighten us. Never heard of "conectivity in the OS" before.
> They don't. The average kernel
> developer is not particularly bright.
Right.
> Just ask Ted why htrees are slower
> than reiser4, or ext2 tail combining is slower, and, well, he has no
> clue.
Great PR move, again: Go on publicly insulting the people who you are
trying to convince.
> He is happy to explain how architects don't do real work and
> should not attend the Linux Kernel Summit, and then when reiser4 blows
> htrees away he undoubtedly still thinks I just take the credit away from
> the programmers who do the real work. They did real work, and they are
> the best in the field, but architecture also matters --- quite a lot
> actually.
Right you are about architecture.
[...]
> This is why I just want to be left alone to tinker with reiser4. It is
> faster than other filesystems. People should assume I know what I am
> doing, and leave me to tinker in my little fs. 5 years later others will
> follow, or not, I don't care.
Great idea.
> > The real question though is: Have you given Al Viro technical answers
> > to his technical questions?
> Yes, I did.
Haven't seen them.
> Got no response. Would you like me to post something nice
> and technical to this thread?;-)
That is what this list is supposed to be about: Technical discussion of the
Linux kernel development.
> I can send a summary of my design, and
> the answers I sent to Viro and Linus.
Please do. Together with the questions, so we can see the whole picture.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 0:57 ` Hans Reiser
2004-09-10 1:15 ` Paul Jakma
@ 2004-09-10 3:22 ` Horst von Brand
1 sibling, 0 replies; 46+ messages in thread
From: Horst von Brand @ 2004-09-10 3:22 UTC (permalink / raw)
To: Hans Reiser
Cc: Paul Jakma, Theodore Ts'o, Robin Rosenberg, William Stearns,
Linux Kernel
Hans Reiser <reiser@namesys.com> said:
> Paul Jakma wrote:
> > On Thu, 9 Sep 2004, Hans Reiser wrote:
[...]
> >> Putting \ into filenames makes windows compatibility less trivial.
> > Err, I think Ted used \ as an example of how to escape |. It is not
> > part of the filename.
> It is not part of it at one level, but in the shell it is part of it.
What are you talking about?
> >> Putting | into filenames seems like asking for trouble with shells.
> > I think that was Ted's precise reason for arguing that | be used. Did
> > you even read his rationale? :)
> That trouble is desirable?
He didn't say that at all. He said that '|' in filenames is currently
troublesome, so nobody will do it. Besides, '|' is dangerous in some
contexts, so it will probably already be filtered out where it might do
damage without any further work. This is important, you can't expect
everybody rewrite all their applications/web sites just because somebody
might be fooling around with Reiser4 to check it out.
> Yes, I can understand why he might not want
> things to work well.;-)
It is very clear that you don't even try to understand criticism.
> >> If you think \| is user friendly, oh god, people like you are the
> >> reason why Unix is hated by many.
It isn't. Ted's point is that the alternatives are much worse. Perhaps
using "meta" or something like that is friendlier at first sight, but if
your box is throroughly 0wn3d as a result, I'm sure your impression of
friendliness will radically change.
> > I think he was arguing | (not \|) is the least worst seperator to use.
Exactly.
> >> Rather few people understand closure though, so I don't expect to do
> >> well in the politics of this.
Sorry for you, but either you convince the head kernel hackers (including
Ted, BTW) that you are right. And they are very hard to convince, only hope
is to present clear, clean solutions to the problems they raise. Nobody has
done so in this flamewar, AFAICS. Politics has very little to do with this.
> >> It is a bit like being for free trade,
> >> most people will never understand why it is so important because
> >> their mental gifts are in other matters,
Here you aren't talking to the counterpart of Joe Sixpack, you are trying
to convince the Economics Department of an ivy-league university that your
ideas on economics are right and they don't know what they are talking
about. Possible, but I'd call it somewhat unlikely.
> > Lots of people understand why free-trade is important. It's taught in
> > introductory economics/business classes in secondary school.
> Have you looked at the political process at all? Or by lots of people,
> do you mean a sizable minority?
Again, no political process in sight.
Please stop the handwawing, and address the core issues: Locking, POSIX
compatibility (or convince people that POSIX is wrong), costs of
implementing this (no, not just kernel implementation; also new
applications, application changes required, user/sysadmin retraining, etc).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-09 19:15 ` Hans Reiser
2004-09-09 20:45 ` Paul Jakma
@ 2004-09-12 20:43 ` Davide Inglima
1 sibling, 0 replies; 46+ messages in thread
From: Davide Inglima @ 2004-09-12 20:43 UTC (permalink / raw)
To: Hans Reiser, linux-kernel
On Thu, 09 Sep 2004 12:15:02 -0700, Hans Reiser <reiser@namesys.com> wrote:
> Putting \ into filenames makes windows compatibility less trivial.
> Putting | into filenames seems like asking for trouble with shells.
> Asking users to keep track of multiple levels of escapes imposed by
> shells and such is hard on them.
> If you think \| is user friendly, oh god, people like you are the reason
> why Unix is hated by many.
> Having to explain filename/metas/owner or filename/.../owner or
> filename/..metas/owner (I don't deeply care what string is used in place
> of "metas") is hard enough.
[Sorry if the tone of this e-mail is particularly heated. I used to
use reiserfs and I am really looking towards the insertion of the
final version of reiser4 in the linux kernel, but I wish to publish my
2 cents as user (not as kernel developer). TIA for your attention and
patience in advance...]
The idea of using "metas" (instead of ".metas" and "..metas") however
is ATROCIOUS, as it would mean to have a fine "metas" entry popping up
in every dir, be undeletable, and having some random user pissed at
his random ${OS} because "it puts stuff that does not belong in the
system"...
The main idea about metadata is that you should be able to use
metadata only if you care. And if you use something, THEN you need to
be bugged by its presence but in a way that does not bug everyone's
else... 99% of people out there only care to use metadatas only via
those kind of applications that _really_ support it, like Mp3 players,
Torrentlike apps and CVS-like programs (if they do and really care to
have their metadatas consistent with the reality, that is [1]).
It has no sense for a human being to go and manage thousands of
metadata directories by hand, hence having "metas" right there in the
filesystem is not calling for user-friendlyness... it is only
desperately calling for some n00b# to dd inside it "just for fun" or
"just to make it go away". Putting in the spotlight a potentially
unreliable OR fragile source of informations is only asking for
trouble and is also harrassing for the end-user that couldn't care
less about that "metas" stuff. (what is this metas stuff that is
between my mariah999.jpg and morena001.jpg in my pr0n/ folder? [2])
In the end, using a UNIX-flavoured system matters because things are
shaped to help sysadmin's jobs, and sysadmins are asked for their task
to Read The Finely-written (?) Manuals before inserting the root
password at the login prompts.
The end-users are to be protected from themselves until they are
really ready to read the documentation.
In conclusion: I don't know WAFL, but I won't make Clearcase example a
too forward example... Clearcase naming is useful only inside a
Clearcase-enabled environment and using Clearcase-enabled tools... I
don't think that people at IBM are going to flame me or handle me a
DMCA takedown notice if I put on my filesystem filenames that could
possibly conflict with their system. Instead Reiserfs4 is going to ask
me to sacrifice a viable word for my filenames (no, I don't call my
filenames .something), and to create a workaround for my scripts [3]
while an alternative like .metas or a ..metas would make even more
sense and be more streamlined with Linux/UNIX customs.
Just my 2 cents as random n00b.
Ciao :)
--
Davide Inglima
[1] http://www.well.com/~doctorow/metacrap.htm
[2] whoops...
[3] ls -1 | wc -l
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-09 9:03 ` silent semantic changes in reiser4 (brief attempt to document the idea ofwhat " Theodore Ts'o
` (2 preceding siblings ...)
2004-09-09 19:15 ` Hans Reiser
@ 2004-09-10 9:42 ` Helge Hafting
2004-09-10 17:42 ` Horst von Brand
[not found] ` <20040910201738.GB8698@eskimo.com>
3 siblings, 2 replies; 46+ messages in thread
From: Helge Hafting @ 2004-09-10 9:42 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Robin Rosenberg, William Stearns, Linux Kernel
Theodore Ts'o wrote:
>On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
>
>
>>Maybe file/./attribute then. /. on a file is currently meaningless. That does
>>not avoid the unpleasant fact that has been brought up by others (only to be
>>ignored), that the directory syntax does not allow metadata on directories.
>>
>>
>
>*Not* that I am endorsing the idea of being able to access metadata
>via a standard pathname --- I continue to believe that named streams
>are a bad idea that will be an attractive nuisance to application
>developers, and if we must do them, then Solaris's openat(2) API is
>the best way to proceed --- HOWEVER, if people are insistent on being
>able to do this via standard pathnames, and not introducing a new
>system call, I would suggest /|/ as the separator as the third least
>worst option. Why?
>
>
What's wrong with using / as the separator? It is already
used to separate components of pathnames. Named streams
are very much like files in a subdirectory.
This scheme makes for very little change to existing tools,
users may then do a "gimp somefile/icon.jpg" for example.
Or "ls somefile/*" to see all the named streams/forks.
Helge Hafting
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
2004-09-10 9:42 ` Helge Hafting
@ 2004-09-10 17:42 ` Horst von Brand
[not found] ` <20040910201738.GB8698@eskimo.com>
1 sibling, 0 replies; 46+ messages in thread
From: Horst von Brand @ 2004-09-10 17:42 UTC (permalink / raw)
To: Helge Hafting
Cc: Theodore Ts'o, Robin Rosenberg, William Stearns, Linux Kernel
Helge Hafting <helge.hafting@hist.no> said:
> Theodore Ts'o wrote:
> >On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
> >>Maybe file/./attribute then. /. on a file is currently
> >>meaningless. That does not avoid the unpleasant fact that has been
> >>brought up by others (only to be ignored), that the directory syntax
> >>does not allow metadata on directories.
> >*Not* that I am endorsing the idea of being able to access metadata
> >via a standard pathname --- I continue to believe that named streams
> >are a bad idea that will be an attractive nuisance to application
> >developers, and if we must do them, then Solaris's openat(2) API is
> >the best way to proceed --- HOWEVER, if people are insistent on being
> >able to do this via standard pathnames, and not introducing a new
> >system call, I would suggest /|/ as the separator as the third least
> >worst option. Why?
> What's wrong with using / as the separator? It is already
> used to separate components of pathnames. Named streams
> are very much like files in a subdirectory.
/ is separator for directories, POSIX mandates its exact use. No, POSIX
isn't broken here, and even if it was, you have to remain compatible.
> This scheme makes for very little change to existing tools,
... while breaking fundamental assumptions by all programs in a major way,
and no sane solution for legacy applications in sight, with unknown
(probably huge) correctness and security implications...
> users may then do a "gimp somefile/icon.jpg" for example.
> Or "ls somefile/*" to see all the named streams/forks.
Please don't rehash this one. It is fundamentally broken.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 46+ messages in thread[parent not found: <20040910201738.GB8698@eskimo.com>]
* Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why
[not found] ` <20040910201738.GB8698@eskimo.com>
@ 2004-09-14 8:39 ` Helge Hafting
0 siblings, 0 replies; 46+ messages in thread
From: Helge Hafting @ 2004-09-14 8:39 UTC (permalink / raw)
To: Elladan; +Cc: linux-kernel
Elladan wrote:
>
>>What's wrong with using / as the separator? It is already
>>used to separate components of pathnames. Named streams
>>are very much like files in a subdirectory.
>>
>>This scheme makes for very little change to existing tools,
>>users may then do a "gimp somefile/icon.jpg" for example.
>>Or "ls somefile/*" to see all the named streams/forks.
>>
>>
>
>Directories may have metadata as well.
>
>
They can. That doesn't stand in the way of using "/" to separate
the named stream's name from the file (or directory) that
have the attribute. "Directories may have metadata" pops
up now and then, and the solution is so blindlingly obvious
that nobody sees it.
A file-as-dir can be implemented as a rather normal directory
attached to the file's name. The stuff inside may
be interpreted as "attributes" or as something more file-like,
such as the often mentioned thumbnails.
What about a directory then? It _is_ a directory, so it
support named streams already. They are usually called "files". :-)
So, if you really want a thumb for your directory, just store a
thumb.jpg in it.
Helge Hafting
^ permalink raw reply [flat|nested] 46+ messages in thread