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.
(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.
(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.
(In reply to comment #2) > Yes. If you enable 4K stacks, which are experimental anyway. and reiser4 isnt ?
(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.
ReiserFS4 is not stable, and we're not going to pretend that it is just because some users and upstream devs want us to.
(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."
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.
(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."
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.
(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" ?
(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.
(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?
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.
(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?
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)
> > 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!
(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.
> 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!!!!
If you feel like discussing this further, take it to -dev