Hello all,
Thanks to Andrew for helping to test and feed many of the reiserfs
patches into mainline. I've rediffed against the current -mm and linus
trees:
ftp.suse.com/pub/people/mason/patches/reiserfs/2.6.6-rc2
The directory includes a series file to tell you the order to apply the
patches. The same series file should work with -mm kernels as well
right now.
New in this patch set is data=journal support, which fills out the
compatibility list with the 2.4.x reiserfs data logging patches. Other
patches include:
xattrs and acls (Jeff Mahoney)
warning/error messages that include device names (Jeff Mahoney)
quotas
block allocator improvements
metadata readahead for some types of tree searches
data=journal is experimental, but most of the code changes don't kick in
unless you mount with data=journal.
The rest of the patches should be stable.
-chris
Adding additional namespaces is not a trivial thing to do, though it
always seems so minor to the person driven by marketing to quickly hack
something in.
The xattr namespace offers zero functional advantage over the file
namespace. The use of '.' instead of '/' is idiotic, see the very short
paper "The Hideous Name" by Rob Pike ( http://www.cs.bell-labs.com/cm/cs/doc/
) for why mindlessly varying the separators in hierarchical names
throughout an OS is a bad idea.
V4 of ReiserFS accesses all file attributes via the filesystem namespace
(see our mainpage at http://www.namesys.com, there is a section on semantics in
it). In V4, attributes are just files with peculiar qualities, kind of
like the files in /proc have peculiar qualities. V4 adds some
additional functionality to the filesystem namespace to make this more
effective (accessing multiple files in one system call, etc.).
Namespaces are the roads and waterways of an operating system. The cost
of developing an operating system is proportional to how many components
you build into it. Namespaces are part of what determines whether that
cost is linear with the number of components, or something worse.
The expressive power of an operating system is NOT proportional to the
number of components, but instead is proportional to the number of
possible connections between its components. If you fragment the
namespaces of an OS, you reduce each component to effective interactions
with only those components in its reduced size namespace. Designing the
namespaces of an OS so that they possess closure and are unified may
seem like a lot of effort, but it is very cost effective compared to
building many times more other OS components to get the same expressive
power.
In the free software community you have to produce working code to be
paid attention to. We are doing that. Chris is sending his patch in at
this time in part because V4 is about to make his work completely
obsolete. At the time he started to write the patch he was told that
ReiserFS was taking this other approach, and his patch would never be
accepted so he should not write it. DARPA was then convinced to fund us
to do the other approach, and we accepted $600k in funding to (among
other things) extend the filesystem namespace to access security
attributes effectively. I have no desire to change direction at the
last moment before we ship V4 so as to become less elegant. I also view
V3 as stable code that should not be disturbed more than minimally
necessary, and I desire for all new functionality to go into V4 (Chris
was also told that before his patch was written).
Making it possible to unify operating system namespaces was why ReiserFS
was created. I am not in this for the money. Pasting in an additional
namespace beyond what Unix had for short term marketing reasons violates
its soul, and I have no desire to provide support for it as it
complicates one feature at a time over 30 years.
Please, let our competing solution of more unified naming have this
ecological niche it can survive in long enough to see if it is the right
longterm direction for Linux. It is more work to be elegant, and it
will cause application writers some short term pain, but in 30 years you
will not regret trying it.
Please reject the xattr and acl patch for ReiserFS V3, and wait a week
or two for ReiserFS V4 to ship to you instead.
Hans
On Mon, 2004-04-26 at 12:59, Hans Reiser wrote:
> In the free software community you have to produce working code to be
> paid attention to. We are doing that. Chris is sending his patch in at
> this time in part because V4 is about to make his work completely
> obsolete.
We write patches for v3 because that is what our users are using. We
write patches to support xattrs because those are the interfaces that
linux as a whole supports.
v4 didn't factor into these decisions because it was still in extremely
early stages back then (2.4.16 or so).
I welcome v4, it has a lot of improvements over v3 and I very much want
to see v4 (and namesys) succeed.
> I also view
> V3 as stable code that should not be disturbed more than minimally
> necessary, and I desire for all new functionality to go into V4 (Chris
> was also told that before his patch was written).
>
You can't release v4 and then expect all the v3 users to disappear
instantly. Our users have an expectation that the filesystem they
choose for their production systems will be reasonably maintained over
time.
I consider supporting the linux standard interfaces for acls and xattrs
part of being reasonably maintained, and the pending release of v4
doesn't change that.
> Making it possible to unify operating system namespaces was why ReiserFS
> was created. I am not in this for the money. Pasting in an additional
> namespace beyond what Unix had for short term marketing reasons violates
> its soul, and I have no desire to provide support for it as it
> complicates one feature at a time over 30 years.
>
Disliking the xattr interface is a different discussion. We
specifically did not do new and interesting namespace research with the
v3 patches, we supported the existing apis in as plain and non-intrusive
a manner possible.
These patches were not a quick hack, a lot of thought went into making
them usable in existing v3 installations, and they have been around for
quite a while.
-chris
Chris Mason wrote:
>On Mon, 2004-04-26 at 12:59, Hans Reiser wrote:
>
>
>
>
>v4 didn't factor into these decisions because it was still in extremely
>early stages back then (2.4.16 or so).
>
>
It was clearly indicated then that accessing acls was scheduled for V4
not V3.
>
>
>>I also view
>>V3 as stable code that should not be disturbed more than minimally
>>necessary, and I desire for all new functionality to go into V4 (Chris
>>was also told that before his patch was written).
>>
>>
>>
>
>You can't release v4 and then expect all the v3 users to disappear
>instantly. Our users have an expectation that the filesystem they
>choose for their production systems will be reasonably maintained over
>time.
>
>
The ReiserFS maintainer (me, in case you forgot;-) ) decided what
release acls would go into, and you disregarded it and wrote an
implementation that was inconsistent with the one planned.
>I consider supporting the linux standard interfaces for acls and xattrs
>part of being reasonably maintained, and the pending release of v4
>doesn't change that.
>
>
>
>>Making it possible to unify operating system namespaces was why ReiserFS
>>was created. I am not in this for the money. Pasting in an additional
>>namespace beyond what Unix had for short term marketing reasons violates
>>its soul, and I have no desire to provide support for it as it
>>complicates one feature at a time over 30 years.
>>
>>
>>
>Disliking the xattr interface is a different discussion. We
>specifically did not do new and interesting namespace research with the
>v3 patches, we supported the existing apis in as plain and non-intrusive
>a manner possible.
>
>
Reiser4 was specifically created as a rejection of the xattr api at the
time that xattrs were first discussed. It took longer to write it than
xattrs. One of your colleagues wrote the xattr api and you/Jeff did the
ReiserFS portion. ReiserFS did not go down the xattr path, and declared
that it would not do so long at the very beginning. You are continuing
to try to force us down that path, and now you are claiming that because
V4 took longer than hacking V3 that means that xattrs are a pre-existing
api that we are heretically not conforming to. Love it.
>These patches were not a quick hack,
>
Creating reiser4's unified namespaces was more work and took longer, and
fragmented namespaces are ugly, that makes xattrs a quick hack.
ReiserFS is release managed. That means that we schedule when features
get implemented, and stick to those schedules. Persons who disregard
the schedules they were informed of get their release schedule violating
patches disregarded. Stable branches do not get new semantics added to
them just before new major releases with preferred semantics come out.
Please consider contributing to enriching the collection of files that
act as attributes of other files in V4 instead of pulling your oars in
the other direction. If you do, you will be (as usually) a valued
contributor.
Hans
On Mon, 2004-04-26 at 14:15, Hans Reiser wrote:
> Chris Mason wrote:
>
> >On Mon, 2004-04-26 at 12:59, Hans Reiser wrote:
> >
> >v4 didn't factor into these decisions because it was still in extremely
> >early stages back then (2.4.16 or so).
> >
> It was clearly indicated then that accessing acls was scheduled for V4
> not V3.
>
Well, that part we've always disagreed most on is how to support
existing users. SUSE implemented the acls for v3 because we felt they
were an important feature, and didn't want to tell users asking for ACLs
to switch filesystems when it was reasonable to implement in v3.
It seems that you don't want the ACLs in v3 for two major reasons:
1) it's not v4
2) it's based on xattrs
I don't feel this is a good way to support v3, since v4 still means
telling someone to switch just for acls, and not using xattrs means not
using the same API as the rest of the kernel.
I hope v4 does improve the xattr api, and I hope it manages to do so for
more then just reiser4. It is important that application writers are
able to code to a single interface and get coverage across all the major
linux filesystems.
-chris
> the other direction. If you do, you will be (as usually) a valued
> contributor.
>
> Hans
as usual, Hans is the tail attempting to wag the dog.
On Mon, Apr 26, 2004 at 09:59:26AM -0700, Hans Reiser wrote:
> The xattr namespace offers zero functional advantage over the file
> namespace. The use of '.' instead of '/' is idiotic, see the very short
> paper "The Hideous Name" by Rob Pike ( http://www.cs.bell-labs.com/cm/cs/doc/
> ) for why mindlessly varying the separators in hierarchical names
> throughout an OS is a bad idea.
Hans, where have you been the last three years? Hiding under a rock?
If Linux wants to support additional attributes and ACLs they better
have a common API for _all_ filesystems. People have discussed the xattr
issue to death, see the -fsdevel and acl-devel archives. I haven't
seen you input anywhere, so better shut up now.
If you don't want to suport xattrs and acls at all in your filesystem
that's your business, but adding random new APIs is not. If you want
your magic files included send them to -fsdevel, including how to
deal with them at the VFS level and using one set of entry points for
them and xattrs. If not keep on dreaming your pipe dreams and don't
anoy us with your 'research' fantasies.
As for ACLs in v3 that's a decision of the maintainer, currently you're
the formal maintainer, but I don't remember a single patch from you.
Most of the linux 2.6 work has been done by Chris and quite a bit of
work by your employees. Chris is paid for doing a stable and working
reiserfs variant for SuSE so he seems to be qualified for doing that, to..
> Please reject the xattr and acl patch for ReiserFS V3, and wait a week
> or two for ReiserFS V4 to ship to you instead.
>
Wasn't ReiserFS V4 promised months ago ? Are you that sure when it ships, it's
going to be merge into mainline or let alone the -mm tree ?
As a ReiserFS user, I'm fully behind theese new changes. I'd rather stay with
the current fs I have ( with new features slowly trinkling in ) , then switch
to a new untested fs ( ReiserFS V4 ).
Matt H.
On Mon, 26 Apr 2004, Chris Mason wrote:
> I hope v4 does improve the xattr api, and I hope it manages to do so for
> more then just reiser4. It is important that application writers are
> able to code to a single interface and get coverage across all the major
> linux filesystems.
Interesting point, given that SuSE were early adopters of alternative
file systems such as JFS, ReiserFS, and XFS (in lexicographical order
rather than order of appearance). These have always diversified the
semantics offered, not only in adding features that other systems didn't
have, but also in omitting features the other file systems did have -
chattr, for instance, or tail merging that confused boot loaders, for
another.
With respect to Hans's reasoning about name spaces, is there an official
standard that mandates a particular API for the ACL stuff ("POSIX")?
If so, the whole discussion is about getting out of the frying pan and
into the fire. The traditional approach will then be standards compliant
but be out-of-band and outside of the file system name space, the new
approach will be outside of the standards, requiring application
developers to produce a Linux and a POSIX version.
Or am I barking up the wrong tree?
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
* Matthias Andree ([email protected]) wrote:
> With respect to Hans's reasoning about name spaces, is there an official
> standard that mandates a particular API for the ACL stuff ("POSIX")?
POSIX ACL's sit defined in a withdrawn POSIX spec (1003.1e). The API
doesn't specify the fs/vfs level detail (other than supporting, user,
group, other and mask acls), and gives a userspace API for accessing
the ACL info (with simple functions like acl_get_file() which you should
find in libacl and can fit many os level implementations). Not sure it
helps much.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Hey, I was reading that!
Please do *not* go making modifications to Cc: lists. Just do reply-to-all
and be happy, thanks.
Christoph Hellwig wrote:
>On Mon, Apr 26, 2004 at 09:59:26AM -0700, Hans Reiser wrote:
>
>
>>The xattr namespace offers zero functional advantage over the file
>>namespace. The use of '.' instead of '/' is idiotic, see the very short
>>paper "The Hideous Name" by Rob Pike ( http://www.cs.bell-labs.com/cm/cs/doc/
>>) for why mindlessly varying the separators in hierarchical names
>>throughout an OS is a bad idea.
>>
>>
>
>Hans, where have you been the last three years? Hiding under a rock?
>
>
>
>As for ACLs in v3 that's a decision of the maintainer, currently you're
>the formal maintainer, but I don't remember a single patch from you.
>Most of the linux 2.6 work has been done by Chris and quite a bit of
>work by your employees. Chris is paid for doing a stable and working
>reiserfs variant for SuSE so he seems to be qualified for doing that, to..
>
>
Did you notice that V4 blows XFS and ReiserFS V3 away in benchmarks?
That is what I have been doing for 3 years....
See http://www.namesys.com for details.
> Did you notice that V4 blows XFS and ReiserFS V3 away in benchmarks?
> That is what I have been doing for 3 years....
>
> See http://www.namesys.com for details.
see http://www.microsoft.com why Windows is much better than Linux. Yeah, thanks.
still leaving every single non-rhetorical question unanswered of course..
Matthias Andree wrote:
>
>If so, the whole discussion is about getting out of the frying pan and
>into the fire. The traditional approach will then be standards compliant
>but be out-of-band and outside of the file system name space, the new
>approach will be outside of the standards, requiring application
>developers to produce a Linux and a POSIX version.
>
>Or am I barking up the wrong tree?
>
>
>
There is always friction between standards and innovation. One should
comply with standards unless genuinely innovating.
Christoph Hellwig wrote:
>>Did you notice that V4 blows XFS and ReiserFS V3 away in benchmarks?
>>That is what I have been doing for 3 years....
>>
>>See http://www.namesys.com for details.
>>
>>
>
>see http://www.microsoft.com why Windows is much better than Linux. Yeah, thanks.
>
>
Ask the users whether their laptops, etc., seem to go a lot faster with
V4. They seem to be pretty happy with it.
V4 fixed all of V3's serious performance flaws, and totally obsoletes
it. I am very happy with it.
On Mon, Apr 26, 2004 at 11:15:32AM -0700, Hans Reiser wrote:
>The ReiserFS maintainer (me, in case you forgot;-) ) decided what
>release acls would go into, and you disregarded it and wrote an
>implementation that was inconsistent with the one planned.
Surely this can not be such a bad thing.
There's a lot of stuff flying around for the kernel that's not included
for one reason or another, probably because some maintainer doesn't like
it. What do people do? They patch it in by themselves.
If there's demand for something and someone provides it, what's the big
deal? It's still not supported by the maintainer, but it is maintained,
and it complies with standards.
Not that different from using some other scheduler or something than what's
provided in the mainline kernel. It can then be developed and possibly
make it into the mainline. Possibly. If the maintainer wants it.
Besides, Reiser4 was, and maybe is in the grand scheme of things, something
of the future and maybe interim solutions shouldn't be disregarded.
>ReiserFS portion. ReiserFS did not go down the xattr path, and declared
>that it would not do so long at the very beginning. You are continuing
>to try to force us down that path, and now you are claiming that because
I hardly see this as forcing anyone to do anything.
No-one takes away anyone's freedom of choice, in fact, the very idea of
free software has been embodied here.
>V4 took longer than hacking V3 that means that xattrs are a pre-existing
>api that we are heretically not conforming to. Love it.
If xattrs were there first, why wouldn't they be pre-existing?-)
If Reiser4 attributes are better and stand a chance at becoming the new
standard, you should by Bog stand behind them and embrace this competition.
Let SuSE keep their customers happy and have people see that Reiser4
attributes are better.
>patches disregarded. Stable branches do not get new semantics added to
>them just before new major releases with preferred semantics come out.
This is of course only natural. But you allowed this to happen in your
choice of license and that's not a bad thing. Quite the contrary.
>Please consider contributing to enriching the collection of files that
>act as attributes of other files in V4 instead of pulling your oars in
>the other direction. If you do, you will be (as usually) a valued
>contributor.
Amen to that.
--
mjt
On Tue, Apr 27, 2004 at 10:58:26AM -0700, Hans Reiser wrote:
> Ask the users whether their laptops, etc., seem to go a lot faster with
> V4. They seem to be pretty happy with it.
>
> V4 fixed all of V3's serious performance flaws, and totally obsoletes
> it. I am very happy with it.
Hans, that's not what we're discussing in this thread. I don't give a shit
whether filesystem A is fater than filesystem B on task C. Really, how
fast a fs is an implementation details.
I also still think someone who does most work in the last years on a fs
(Chris on reiserfs v3) should be considered maintainer, but that's just my
2cents and I'd rather leave that to you guys.
The important part is xattr/acl/namespace semantics. In Linux those
semantics are at the _VFS_ level, not at the individual filesystem,
in fact if a fs can mess with namespace semantics I'd almost considere
that a bug.
So if you want different xattr/acl semantics after you ignored all the
discussion has been going on the last years start *now* to discuss you
proposal on -fsdevel, and acl-devel, explaining why your semantics are
better and hash out the implementation details to support both
transparently.
Funneling in new semantics through a low level driver is pretty much
always wrong.
Hans Reiser wrote:
> Christoph Hellwig wrote:
>
>>> Did you notice that V4 blows XFS and ReiserFS V3 away in
>>> benchmarks? That is what I have been doing for 3 years....
>>>
>>> See http://www.namesys.com for details.
>>>
>>
>>
>> see http://www.microsoft.com why Windows is much better than Linux. Yeah,
>> thanks.
>>
>>
> Ask the users whether their laptops, etc., seem to go a lot faster with
> V4. They seem to be pretty happy with it.
>
> V4 fixed all of V3's serious performance flaws, and totally obsoletes
> it. I am very happy with it.
For the present thread, this is irrelevant, as the irreverent responses
hinted at:
Regardless of _any_ features or fixes in V4, reiserfs V3 will be used in
production system for years. Minor feature additions to an existing
filesystem make it far easier for kernel engineers and sysadmins to
assess the impact on their systems -- which is typically of less impact
than switching to a new filesystem.
Jeff
On Tue, Apr 27, 2004 at 07:04:39PM +0100, Christoph Hellwig wrote:
> I also still think someone who does most work in the last years on a fs
> (Chris on reiserfs v3) should be considered maintainer, but that's just my
> 2cents and I'd rather leave that to you guys.
I agree and add my 2cents to this statement.
(Euro-cent, so it has a value :)
Chris wrote on 5 Apr: "If there is some technical objection to the
patches I'd really like to discuss it."
Nothing happened since then and
I simply do not consider the $600k payment of DARPA for V4 development
as a technical objection against work on V3 - but hey -
you can always prove me wrong by rejecting Chris patches.
--
ciao -
Stefan
" GNU's Not Unix -- IIS Isn't Secure "
HR> V4 fixed all of V3's serious performance flaws, and totally obsoletes
HR> it. I am very happy with it.
So if you consider it obsolete and not interesting any more, why not
hand the de jure maintainership over to Chris? He has been the de facto
mainatainer for a long time.
I find that Reiserfs V3 has just become mature enough in the last half a
year to actually trust my data to it - maybe even on non-x86. Reiserfs
V4 would take some years to gain this trust so I see a real potential
user base for V3 and refusing further development of it seems unwise.
--
Meelis Roos ([email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| Christoph Hellwig wrote:
|
|>> Did you notice that V4 blows XFS and ReiserFS V3 away in
|>> benchmarks? That is what I have been doing for 3 years....
|>>
|>> See http://www.namesys.com for details.
|>>
|>
|>
|> see http://www.microsoft.com why Windows is much better than Linux. Yeah,
|> thanks.
|>
|>
| Ask the users whether their laptops, etc., seem to go a lot faster with
| V4. They seem to be pretty happy with it.
With the speed, yes. With the stability, no. I use it on my desktop
now, as that's for games, and use xfs on cryptoloop for my laptop. I
hope to replace that with reiser4 and some crypto plugin someday. I'll
follow this up with the specific problems in a bit.
|
| V4 fixed all of V3's serious performance flaws, and totally obsoletes
| it. I am very happy with it.
|
In fact, regarding the whole "innovation" thing, Microsoft and others
have occasionally announced that they were going to create a filesystem
which could act as a database (or the other way around), and generally
introduce some of the features reiser4 has solid by now.
Every time I've seen such a thing announced, it flops later. It becomes
a userland project, or an abandoned project, and definitely nowhere near
as usable. Reiser4, however, seems to already have that kind of
functionality -- it's efficient at storing lots of tiny flat text files,
and searching them randomly.
I haven't run any benchmarks against "real" databases like mysql, but if
we want to talk about what V4 obsoletes, it obsoletes things which
haven't even been developed/released yet (WinFS on Longhorn).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQJJ7angHNmZLgCUhAQIZ+hAAjEI4q47XD+ihgMvXvSo5M7yUMfXZL6vp
Kf306LWaSHEqONsfOZ66X084kezb/1FbG3SrGVkK9TQ2BZ2dCCCa8mHz/eWx6X6j
BiXyBmj7h5UZAVngzbeSFd4LkmWsSVedBb5eKjAj2saHoXbVz/B+efLwaTr5V9+7
ANPL9Qe4qB5O3gNdft1wNu+Zajnuoe5tMGadVyhVKUju8dm43WLOAo23+c5CNBfA
VPheDgLQG84qje6ggwhUEjnpzVKHBKT2jBQ+FG7+MVrK9fiqhWRXLft2ytG6zQfL
VPWiRB5yIYXMItNHm29f1rP/Gx2yITmEGtxMyo/Aq3dD7SWAGik4o/6piQ7OzXCI
+Hfplx4DeVbJ6DeitkeOfJmzOBNMAdE7k2kWs6/Gh7W+TJhp+lYQpYfM/sRPaxRF
T9Wgpq3/kH5GzY+dqkYX/SPU202uSG5X9RAk7oW8Fl55Cmhdrapfp2xkv88Sl6JT
BypmnQFAQl5uBfvtOXzEtz3JLssTATY8JapZyR7KH3+uORsikO1yfb5kuAdBUHvr
Qs+nvHNVg2yQMDA2iB0LXobx/NFY8rMuFj1tmHRVOWgfm9Ky9i2KWfSf/RgtlyjH
gTHLbtCQKpZk/cF1gdkw1fFAath/q2BunSQNdvV6ESy8CYVNTJeYjWqmTktejnS6
NvLjomnwp78=
=cYSQ
-----END PGP SIGNATURE-----