Re: silent semantic changes in reiser4 (brief attempt to documentthe idea ofwhat reiser4 wants to do with metafiles and why
From: Hans Reiser
Date: Fri Sep 10 2004 - 02:49:35 EST
Well I didn't get this response, so whether or not you sent it, it was
not a lie. Drink less coffee.
viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxx>
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...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/