Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 103077 - Docs say Reiser4 doesn't work on amd64. It does.
Summary: Docs say Reiser4 doesn't work on amd64. It does.
Status: VERIFIED WONTFIX
Alias: None
Product: [OLD] Docs-user
Classification: Unclassified
Component: Gentoo Linux x86 Installation Guide (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: AMD64 Project
URL: http://www.gentoo.org/proj/en/base/am...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-19 11:40 UTC by David Masover
Modified: 2005-08-20 18:47 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
gentoo/xml/htdocs/proj/en/base/amd64/technotes/install-software.xml.patch (patch,689 bytes, patch)
2005-08-20 14:57 UTC, Jan Kundrát (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Masover 2005-08-19 11:40:52 UTC
Reiser4 has been working on amd64 for awhile now, and is probably actually
stable already.  What it doesn't work on is 4k stacks.

Although, of course, it's fair that you don't support it yet, but it's not fair
that you claim it "doesn't work".  I'm writing this from an amd64/reiser4 Gentoo
box.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Xavier Neys (RETIRED) gentoo-dev 2005-08-19 11:52:32 UTC
(In reply to comment #0)
> What it doesn't work on is 4k stacks.
So it does not work, right?

> Although, of course, it's fair that you don't support it yet, but it's not fair
> that you claim it "doesn't work".  I'm writing this from an amd64/reiser4 Gentoo
> box.

And for every guy who claims he's never had any trouble with reiser*, you'll
find another one who lost some data to it and who will stay as far away from it
as possible.

Anyway, the AMD64 technotes are suprisingly maintained by the AMD64 team.
Comment 2 David Masover 2005-08-19 13:35:39 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > What it doesn't work on is 4k stacks.
> So it does not work, right?

Yes.  If you enable 4K stacks, which are experimental anyway.  If you read the
docs and turn off CONFIG_4K_STACKS, which doesn't seem to exist in my kernel
config anymore anyway (2.6.12.3).

> > Although, of course, it's fair that you don't support it yet, but it's not fair
> > that you claim it "doesn't work".

> 
> And for every guy who claims he's never had any trouble with reiser*, you'll
> find another one who lost some data to it and who will stay as far away from it
> as possible.

So I "claim" to have never had trouble, but others "have" lost data?  You seem a
little prejudiced.  I'd say it's others that "claim" to have lost data, and
probably on an old 2.4 kernel or back when Reiser4 was experimental.

Anyway, the question isn't whether the FS is stable, but whether it works at
all.  People are going to see "DOESN'T WORK ON AMD64" and decide not to even try
to use it when they might have if it was just "WE WON'T HELP YOU IF IT BREAKS".

> Anyway, the AMD64 technotes are suprisingly maintained by the AMD64 team.

Sorry if I submitted this to the wrong place.
Comment 3 SpanKY gentoo-dev 2005-08-19 13:38:03 UTC
(In reply to comment #2)
> Yes.  If you enable 4K stacks, which are experimental anyway.

and reiser4 isnt ?
Comment 4 David Masover 2005-08-19 13:50:08 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Yes.  If you enable 4K stacks, which are experimental anyway.
> 
> and reiser4 isnt ?

Troll.  I should have learned by now, but...

How's that relevant?

This is about the statement in the docs that reiser4 "DOESN'T WORK ON AMD64",
which is simply no longer true.

I'm not even arguing that you claim it's stable, although it is.  It's not in
the kernel because it has "layering violations", which is not a functional bug,
it's a maintainability bug.

Comment 5 Jeremy Huddleston (RETIRED) gentoo-dev 2005-08-20 02:15:58 UTC
ReiserFS4 is not stable, and we're not going to pretend that it is just because
some users and upstream devs want us to.
Comment 6 David Masover 2005-08-20 06:13:52 UTC
(In reply to comment #5)
> ReiserFS4 is not stable, and we're not going to pretend that it is just because
> some users and upstream devs want us to.

I'm not asking you to.  Its stability is not the question.

IT WORKS on amd64.  Whether you think it's stable or not is irrelevant.  What's
relevant is that you say, specifically, that it doesn't work on amd64.  It works
on amd64 as well as it does on x86.  Either say "It's unstable" or "It doesn't
work", not "It doesn't work on amd64".  And if you really want to be fair, say
"The developers claim it's stable, some users (who?) claim it's not, YMMV."
Comment 7 Luis Medinas (RETIRED) gentoo-dev 2005-08-20 07:00:25 UTC
I say that reiser4  is not stable and the users for safety precaution should
know that doesn't work. For somehow isn't available in the stable kernel. I can
change the docs and say that it works but in reality reiser4 isn't stable enough
to write in the docs that reiser4 works.
Comment 8 David Masover 2005-08-20 08:56:10 UTC
(In reply to comment #7)
> I say that reiser4  is not stable

Fine.

> and the users for safety precaution should
> know that doesn't work.

English isn't your  first language, is it?  Maybe you should let a native do the
English docs?

> For somehow isn't available in the stable kernel.

Yeah, for reasons entirely unrelated to its stability.  For reasons of code
maintainability.

> I can
> change the docs and say that it works

Please do.  I'm not asking you to change the docs and say that it's stable or
recommended.  I just want you to remove the amd64-specific warning that it
doesn't work.

> but in reality reiser4 isn't stable enough

But it works.  According to you, it's not stable enough.  That doesn't change
the fact that I'm writing this on my amd64, on Reiser4, on dmraid.  According to
your doc, this SHOULDN'T BE POSSIBLE AT ALL.

> to write in the docs that reiser4 works.

So write "We don't support Reiser4."  Or write "Reiser4 isn't stable yet." 
These are very differet from "It  doesn't work" or "DOESN'T WORK ON AMD64."

Reiser4 boots, it runs, and it runs on amd64, no differently than on any other
arch.  Whether it's stable or works for everyone is an entirely different
matter.  The point is, amd64 people who are willing to try *unstable* things
will see your doc and think "Oh, it won't work at all, no point trying, then." 
If it was just a warning of "It's unstable", then these people might think
"Well, it works, but it's unstable.  Maybe I'll try it and help debug it."  And
that's how it becomes stable.

For the average user, NOTHING CHANGES.  The average user sees "Unstable" and
says "Ooh, scary, I won't try this," -- which is exactly the same as if it said
"Doesn't work."
Comment 9 Olivier Crete (RETIRED) gentoo-dev 2005-08-20 12:23:26 UTC
Working for a file system does NOT mean.. "it works some times".. or "I dont
loose all of my data".. but "It works all the time and will NOT eat my data". If
you want to loose yours, feel free, Gentoo is about choice.. but please dont
waste our time.. The doc is about protecting our users, not making Hans feel
warm inside.
Comment 10 David Masover 2005-08-20 13:10:17 UTC
(In reply to comment #9)
> Working for a file system does NOT mean.. "it works some times".. or "I dont
> loose all of my data".. but "It works all the time and will NOT eat my data".

Fine, then, say "It doesn't work" -- or better, "It's not stable, we think
you'll lose data."

> If
> you want to loose yours, feel free, Gentoo is about choice..

If it's really about choice, then why are you saying something which is at best
misleading (reiser4 "not working" is not amd64-specific) and at worst simply
wrong (reiser4 compiles and runs, and seems stable -- you just don't like that
it hasn't been widely tested yet.)

> but please dont
> waste our time..

Then change the doc.

What is wrong with removing "DOESN'T WORK ON AMD64" and leaving "NOT SUPPORTED
ON ANY ARCH" or even "UNSTABLE; NOT SUPPORTED ON ANY ARCH"  ?
Comment 11 Homer Parker (RETIRED) gentoo-dev 2005-08-20 13:23:05 UTC
(In reply to comment #10)

> What is wrong with removing "DOESN'T WORK ON AMD64" and leaving "NOT SUPPORTED
> ON ANY ARCH" or even "UNSTABLE; NOT SUPPORTED ON ANY ARCH"  ?

Ask the poor user that showed up in #gentoo-amd64 while ago. Reiserfs blew up,
and he ended up with everything in lost+found. Shut it down properly last night,
fired it up this morning, and ended up with that. I don't call that anything
resembling "Working on AMD64". Yes, there are reports of people that are running
it, there are also reports of people winning the lottery. I see both cases as
the same, very lucky.

Comment 12 David Masover 2005-08-20 13:43:15 UTC
(In reply to comment #11)
> (In reply to comment #10)
> 
> > What is wrong with removing "DOESN'T WORK ON AMD64" and leaving "NOT SUPPORTED
> > ON ANY ARCH" or even "UNSTABLE; NOT SUPPORTED ON ANY ARCH"  ?
> 
> Ask the poor user that showed up in #gentoo-amd64 while ago. Reiserfs blew up,
> and he ended up with everything in lost+found.

You are talking about Reiser4, right?  (not Reiserfs3?)

Anyway, was it an amd64-specific issue?  Was he using a recent-enough patch,
considering that Reiser4 used to not work on amd64, many months ago?

If it wasn't an amd64 issue, why are you arguing to leave the WRONG
amd64-specific warning?

Comment 13 Luis Medinas (RETIRED) gentoo-dev 2005-08-20 13:49:06 UTC
David i won't insult you like you did to me but I Will NOT change the docs and
say that reiser4 works. And i'm pretty sure that no other dev will do that for now.

Please let us do our work.
If you want to discuss this please do in forums or mailing lists not in bugs.g.o.
Comment 14 David Masover 2005-08-20 14:07:01 UTC
(In reply to comment #13)
> David i won't insult you like you did to me

Thank you.

Sorry, I shouldn't have insulted you, but I have a low tolerance for people who
don't read the full post.  And it seems you've done it again:

> but I Will NOT change the docs and
> say that reiser4 works.

That's not what I'm asking for.  Go back and read.

Oh, wait, I need to not waste your time (by spending more of my own), so here
you go:

Saying "UNSTABLE; NOT SUPPORTED" is pretty much the same thing as saying
"doesn't work", isn't it?  Can you name one meaningful reason that you'd rather
it say "doesn't work"?  Because I can name one reason it should be labeled
"UNSTABLE" -- some people like to test unstable stuff, but have no patience for
stuff that is known to not even compile, to not even be ready for testing.

It's kind of like the difference between a hard mask and a ~arch mask.  I'm
willing to try stuff that's ~arch, if upstream has declared it stable and I have
a reason for trying it, but I usually don't even bother if it's hard-masked or
is missing a keyword, because usually hard-masked stuff actually doesn't work,
won't compile, crashes after two seconds, etc, and ~arch-masked stuff usually at
least works for some people, in some situations.

Am I wrong?

> If you want to discuss this please do in forums or mailing lists not in bugs.g.o.

Why not?  It's a bug, and a simple one.  It's a factual inaccuracy.  Should I
also be using the forums/lists for errors in spelling, punctuation, or grammar?
 What's to discuss?
Comment 15 Jan Kundrát (RETIRED) gentoo-dev 2005-08-20 14:57:56 UTC
Created attachment 66432 [details, diff]
gentoo/xml/htdocs/proj/en/base/amd64/technotes/install-software.xml.patch

Would something like this accomodate you? (tx dsd for the idea)
Comment 16 Jeremy Huddleston (RETIRED) gentoo-dev 2005-08-20 15:27:54 UTC
> > and the users for safety precaution should
> > know that doesn't work.
> 
> English isn't your  first language, is it?  Maybe you should let a native do the
> English docs?

Uhm, that kind of remark is NOT called for!  Additionally, if the FS is not
stable, then to me that means that it doesn't work.  If I want to save a file,
and instead it corrupts the file descriptors, that doesn't seem like "working"
to me.  It seems like "unstable" or "not working" to me.

If you want to get into the technical meaning of "works", I gurantee that this
command "works":

dd if=/dev/zero of=/dev/hda 
 
> > For somehow isn't available in the stable kernel.
> 
> Yeah, for reasons entirely unrelated to its stability.  For reasons of code
> maintainability.

Yeah ugly code.  badly designed.  badly designed code is more likely to be
buggy, and in this case it certainly IS!
 
The rest of this thread is heading straing to /dev/null.  Don't reopen!
Comment 17 David Masover 2005-08-20 17:17:55 UTC
(In reply to comment #15)
> Created an attachment (id=66432) [edit]
> gentoo/xml/htdocs/proj/en/base/amd64/technotes/install-software.xml.patch
> 
> Would something like this accomodate you? (tx dsd for the idea)

Yes, that works.

I would prefer one of these:

UNSTABLE; NOT SUPPORTED ON ANY ARCH
NOT SUPPORTED ON ANY ARCH

But they all work.

Reopened out of habit, and so you can close it if you're going to.

(In reply to comment #16)
> > > For somehow isn't available in the stable kernel.
> > 
> > Yeah, for reasons entirely unrelated to its stability.  For reasons of code
> > maintainability.
> 
> Yeah ugly code.  badly designed.  badly designed code is more likely to be
> buggy, and in this case it certainly IS!

Have you looked at it?  Have you tried using it?

The reason it's not in the kernel has nothing to do with how nice the design
was, it was a couple of very high-level decisions, like whether certain plugins
belong in the FS proper or in the VFS, so other FSes can use them.  Functionally
irrelevant -- it could still be rock-solid.
Comment 18 Jeremy Huddleston (RETIRED) gentoo-dev 2005-08-20 18:47:09 UTC
> Reopened out of habit, and so you can close it if you're going to.

Ok, I said this was going to /dev/null... so I lied as I am responding, but do
NOT reopen as I will just close it withoug comment in the future.
 
> > Yeah ugly code.  badly designed.  badly designed code is more likely to be
> > buggy, and in this case it certainly IS!
> 
> Have you looked at it?  Have you tried using it?

Looked at it, yes.  Like I said, it's ugly.  Used it, not for anything I don't
want to loose...
 
> The reason it's not in the kernel has nothing to do with how nice the design
> was, it was a couple of very high-level decisions, like whether certain plugins
> belong in the FS proper or in the VFS, so other FSes can use them.  Functionally
> irrelevant -- it could still be rock-solid.

No, actually, that is QUITE relevant.  It does not use good data abstraction or
modularity meaning it would be a hassle to maintain and breaks the very good VFS
abstraction already in place.  This is NOT PRODUCTION CODE!!! And I am not going
to put any kind of stamp on it other that, "If you use this, you'd better make
backups"

Do NOT REOPEN!!!!
Comment 19 Jeremy Huddleston (RETIRED) gentoo-dev 2005-08-20 18:47:46 UTC
If you feel like discussing this further, take it to -dev