Re: I request inclusion of reiser4 in the mainline kernel
The longer I read discussions about the inclusion of reiser4 into the kernel the more I think the whole discussion has to do with personal oppinions, not with technical problems or limitations that should be adressed. Anybody who is a ext3 fan seems to find his own reasons why reaiser4 should stay away - thats real competition - could be fud-people payed by redhat how seem to force anybody to use ext3 (thanks for fc4 bullshit) ;-) I have heard so many reasons why reiser4 should not be in kernel, however nobody seems to think about why it should be included. Its the only really activly developed linux vs with features most (all) other fs lack and it has a great ability for improvements through plugins. just makes me sad, lg Clemens
Re: I request inclusion of reiser4 in the mainline kernel
Clemens Eisserer schrieb: The longer I read discussions about the inclusion of reiser4 into the kernel the more I think the whole discussion has to do with personal oppinions, not with technical problems or limitations that should be adressed. Anybody who is a ext3 fan seems to find his own reasons why reaiser4 should stay away - thats real competition - could be fud-people payed by redhat how seem to force anybody to use ext3 (thanks for fc4 bullshit) ;-) I have heard so many reasons why reiser4 should not be in kernel, however nobody seems to think about why it should be included. Its the only really activly developed linux vs with features most (all) other fs lack and it has a great ability for improvements through plugins. compression plugin would save me (not only me I believe) lots of time and a couple of disks... and the only other Linux fs with write mode that has compression is patched ext2 (which is also not included in the kernel, and has some problems) - well, there is also jffs2 with limits of 4 GB partition, so not really useful for storing bigger amounts of data. I actually even considered using NTFS on Linux servers, with some commercial product providing NTFS with all features (write, compression etc.) - crazy, isn't it? -- Tomek http://wpkg.org Software deployment and upgrades with Samba
Re: I request inclusion of reiser4 in the mainline kernel
Tomasz Chmielewski wrote: and the only other Linux fs with write mode that has compression is patched ext2 (which is also not included in the kernel, and has some problems) - well, there is also jffs2 with limits of 4 GB partition, so not really useful for storing bigger amounts of data. Well, don't include JFFS2 here :-) Although it supports compression it is useless with disks, and not only because of the 4GB limit. :-) -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia.
Re: I request inclusion of reiser4 in the mainline kernel
Artem B. Bityutskiy schrieb: Tomasz Chmielewski wrote: and the only other Linux fs with write mode that has compression is patched ext2 (which is also not included in the kernel, and has some problems) - well, there is also jffs2 with limits of 4 GB partition, so not really useful for storing bigger amounts of data. Well, don't include JFFS2 here :-) Although it supports compression it is useless with disks, and not only because of the 4GB limit. :-) baah, if I didn't mention it, someone would just flame me with words jffs2 supports compression seamlessly, you .! :) and, as any other filesystem, can be used with disks or even kept in RAM, it's just an image, right? but what fun is it to have fifty 4 GB partitions? :) -- Tomek http://wpkg.org Software deployment and upgrades with Samba
Re: I request inclusion of reiser4 in the mainline kernel
On Sunday 18 September 2005 03:34, Chris White wrote: CC-List trimmed On Saturday 17 September 2005 20:15, Denis Vlasenko wrote: At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more time to optimize code size, but: reiser42557872 bytes xfs3306782 bytes And modules sizes: reiser4.ko442012 bytes xfs.ko494337 bytes All this is fine and dandy, but saying My code is better than yours!! still doesn't solve the issue this thread hopes to achieve, that being I'd like to get reiser4 into the kernel. There seems to be a lot of (historical?) tension present here, but all that seems to be doing is making things worse. PLEASE keep this thing a tad on par. Keeping this up is hurting everyone more than helping. I wish I could say something as simple as let's just be friends, but that's saying a lot. I can say this though: this is open source, and that means that our source is open, and we should be too. I am trying to say that I think that Hans is being treated a bit unfairly. His fs is new and has fairly complex on-disk structure and complex journalling machinery, yet his source and object code is smaller than xfs which already is accepted. This is no easy feat I guess. Maybe xfs shouldn't be accepted too, this may be an answer. Let's look at the code. Hans' code is not _that_ awful. Yet people (not all of them, but some) do not point to specific things which they want to be fixed/improved. I see blanket arguments like your code is hard to read. Well. Maybe spend a minute on what exactly is hard to read, or do we require Hans to be able to read minds from the distance? This is it. I do not say accept reiser4 NOW, I am saying give Hans good code review. -- vda
Re: I request inclusion of reiser4 in the mainline kernel
On Sat, Sep 17, 2005 at 01:56:14PM +0300, Denis Vlasenko wrote: At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more time to optimize code size, but: reiser42557872 bytes xfs3306782 bytes and romfs is smaller than ext2, damn. Should we remove all filesystems but romfs now? and yeah, if you didn't get the hint compare the feature sets.
Re: I request inclusion of reiser4 in the mainline kernel
On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote: This is it. I do not say accept reiser4 NOW, I am saying give Hans good code review. After he did his basic homework. Note that reviewing hans code is probably at the very end of everyones todo list because every critizm of his code starts a huge flamewar where hans tries to attack everyone not on his party line personally. I've said I'm gonna do a proper review after he has done the basic homework, which he seems to have half-done now at least. Right now he hasn't finished that and there's much more exciting filesystems like ocfs2 around that are much easier to read and actually have developers that you can have a reasonable conversation with. (and that unlike hans actually try to improve core code where it makes sense for them)
Re: I request inclusion of reiser4 in the mainline kernel
I threw in your new codedrop into a compilation and the byte-order mess is _still_ now sorted out. Please kill the d* as struct type crap and just use __le types directly. Also lots of memset with byte count of 0 warnings from sparse.
Re: I request inclusion of reiser4 in the mainline kernel
On Sunday 18 September 2005 12:26, Christoph Hellwig wrote: On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote: This is it. I do not say accept reiser4 NOW, I am saying give Hans good code review. After he did his basic homework. Note that reviewing hans code is probably at the very end of everyones todo list because every critizm of his code starts a huge flamewar where hans tries to attack everyone not on his party line personally. I've said I'm gonna do a proper review after he has done the basic homework, which he seems to have half-done now at least. Right now he hasn't finished that and there's much more exciting filesystems like ocfs2 around [...] Now _what_ good does that sentence do us? I've been following this this since the primary reiser filesystem was number 3, and the kernel everybody was using was 2.4.10. You've probably been following this list for far longer, but is that really an excuse for rudeness? reiser4 has many, many extremely interesting features. I'm sure anybody is more than willing to go into detail with them, but saying that ocfs2 is much more exiting is just plain bashing, and it's not fair to Hans, to Namesys, or to every one of us who can't wait for reiser4 in mainline. Could you please keep your personal idea of which filesystem is more interesting to yourself? It doesn't help anybody accomplish anything. -- Regards, Christian Iversen (not affiliated with namesys..)
Re: I request inclusion of reiser4 in the mainline kernel
On Sunday 18 September 2005 15:06, Christian Iversen wrote: On Sunday 18 September 2005 12:26, Christoph Hellwig wrote: On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote: This is it. I do not say accept reiser4 NOW, I am saying give Hans good code review. After he did his basic homework. Note that reviewing hans code is probably at the very end of everyones todo list because every critizm of his code starts a huge flamewar where hans tries to attack everyone not on his party line personally. I've said I'm gonna do a proper review after he has done the basic homework, which he seems to have half-done now at least. Right now he hasn't finished that and there's much more exciting filesystems like ocfs2 around [...] Now _what_ good does that sentence do us? I've been following this this since the primary reiser filesystem was number 3, and the kernel everybody was using was 2.4.10. You've probably been following this list for far longer, but is that really an excuse for rudeness? reiser4 has many, many extremely interesting features. I'm sure anybody is more than willing to go into detail with them, but saying that ocfs2 is much more exiting is just plain bashing, and it's not fair to Hans, to Namesys, or to every one of us who can't wait for reiser4 in mainline. every one of us who can't wait do not count, because they do nothing. If you want reiser4 included into mainline, do something. Like download a patch and try to use it. Last time I tried, it didn't work. Kernel locked up. Namesys was quick with fix for the lockup, but then ls . failed to work. I sent all the data (kernel version, fs image, etc) to Namesys but after several email iterations it died out with no resolution. I will try again sometime. Maybe it got better. Could you please keep your personal idea of which filesystem is more interesting to yourself? It doesn't help anybody accomplish anything. Your reply wasn't polite/useful either. -- vda
RE: Tremendous Report
Dear LifeInsured: You will be unexpectedly happy about how much you willSve on TermLifeInsurance. This offer is for you and your friends. It is time to take advatage of this wonderful oppurtunity. All we ask is that you visit our Website and complete the short, short form. Enter Here Sincerely, Eric Jones National InsuranceRep Turn off notiiificationsheeere.
Re: I request inclusion of reiser4 in the mainline kernel
Christoph Hellwig wrote: On Sat, Sep 17, 2005 at 01:56:14PM +0300, Denis Vlasenko wrote: At least reiser4 is smaller. IIRC xfs is older than reiser4 and had more time to optimize code size, but: reiser42557872 bytes xfs3306782 bytes and romfs is smaller than ext2, damn. Should we remove all filesystems but romfs now? and yeah, if you didn't get the hint compare the feature sets. XFS does have a nice feature set, sure. So does Reiser4. XFS can freeze the filesystem, take a live snapshot, and do some other, similar tricks. Reiser4 can show file metadata as files themselves, compress on-the-fly (last I checked, the compression code is in there, just not being used), and pack small files incredibly well. XFS has xattrs. Reiser has metas, and will eventually provide an xattr interface to them. You may not value Reiser's feature set, but that doesn't make it less complex. Romfs is actually simpler than ext2, and its whole feature seems to be having a tiny implementation.
Re: I request inclusion of reiser4 in the mainline kernel
Denis Vlasenko wrote: If you want reiser4 included into mainline, do something. Like download a patch and try to use it. Alright... Last time I tried, it didn't work. Kernel locked up. Namesys was quick with fix for the lockup, but then ls . failed to work. I sent all the data (kernel version, fs image, etc) to Namesys but after several email iterations it died out with no resolution. When was last time? I will try again sometime. Maybe it got better. I have three boxes running Reiser4 for everything except /boot, and no problems yet, except an occasional missing feature, like a repacker/resizer. One's a Pentium 3, the other two are amd64s. I've had a total of one crash each on the amd64s, and one of those was while playing a game, and could easily have been the nvidia drivers. I can't reproduce the other one, and the box has been fine since -- and both amd64s are overclocked by 600 mhz, so I have a sneaking suspicion that it might have been hardware. No crashes yet on the Pentium 3, which isn't overclocked at all. No lost data yet either, in fact, I recovered from an essential 'rm -rf' of a Reiser4 partition, so I could even say Reiser4 (or rather, fsck.reiser4) has *found* data for me. For a long time, it's been painfully obvious that the reasons Reiser4 isn't in the kernel all have to do with things like coding style and politics. At this point, if I tried to do anything more than be an active user, I'd be so far out of my depth I'd need a life jacket.
Payuz.com Join Early!
http://www.payuz.com Join this brand new doubler! Join early and get paid! Payouts daily! http://www.payuz.com
Re: I request inclusion of reiser4 in the mainline kernel
On Sun, 18 Sep 2005 13:22:27 EDT, michael chang said: Give Hans a chance; and please try to understand, even if he's hard to work with. Discriminate him because he's not a developer you can talk with, and I believe that's like discriminating a guy in a wheelchair because he can't run with you when you jog in the morning. There's nothing wrong with discriminating against the guy in the wheelchair under some circumstances - for instance, when your track team needs a new high jumper. Similarly, when the goal is to build a set of developers that can actually get work accomplished, poor interpersonal communication skills can be a major problem. If the problem is that Hans and the rest of the kernel developers don't get along, perhaps the most expedient thing would be for Hans to step out of the way and have somebody else from Namesys (or elsewhere even) act as the interface. pgp90wjQAcsxl.pgp Description: PGP signature
Re: I request inclusion of reiser4 in the mainline kernel
michael chang [EMAIL PROTECTED] wrote: On 9/18/05, Christoph Hellwig [EMAIL PROTECTED] wrote: On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote: This is it. I do not say accept reiser4 NOW, I am saying give Hans good code review. After he did his basic homework. Note that reviewing hans code is probably at the very end of everyones todo list because every critizm of his code starts a huge flamewar where hans tries to attack everyone not on his party line personally. I've said I'm gonna do a proper review after he has done the basic homework, which he seems to have half-done now at least. Right now he hasn't finished Explain to us all what is this basic homework of which you speak. The required cleanups have been posted (in outline at least), several times, by unrelated people. that and there's much more exciting filesystems like ocfs2 around that This is exciting to... whom? To Cristoph, obviously. You should thank him for doing the (hard, boring, thankless) work of reviewing code for free. Even if it isn't yours. As he is doing it as community service, I wouldn't dare blame him for picking whatever he likes most, for whatever reasons. The only thing that appears remotely interesting about it is that it's made by Oracle and apparently is supposed to be geared toward parallel server whatsits. This might be helpful to corporations, but seems senseless toward many consumers. Cristoph finds it interesting, that should be enough for everybody not paying him for doing the work. (I'm assuming there's still at least one consumer left who still uses Linux.) Count me in. That doesn't mean I agree with ReiserFS' goals... are much easier to read and actually have developers that you can have a reasonable conversation with. (and that unlike hans actually try to Is that Hans' fault, or the fault of your lot? Why can't we all just get along? Hans is one person, and he has managed to alienate a most of the LKML bunch. Sure, there are very abrasive people here, but there are plenty that are extremely helpful to newbies that /really/ want to learn how to do things right. Give Hans a chance; and please try to understand, even if he's hard to work with. Discriminate him because he's not a developer you can talk with, and I believe that's like discriminating a guy in a wheelchair because he can't run with you when you jog in the morning. Please consider that most people here are volunteers, they owe nobody nothing. Quite the contrary: if somebody wants to unload their code (and its future maintenance) on the kernel crew, they are in /great/ debt if it gets accepted. improve core code where it makes sense for them) Not everyone has the same common sense that you do. Explain, fully, with reasoning, and reproducable back-up statistics on common hardware, what code is wrong, and what must be written instead. We'd like to be efficient, and it's not being efficient to play a guessing game with us. If you don't have the time to review, then please hold off on replying until you have a through review of at least part of the code. Can't do. It is mostly an artistic sense of taste. Unless you object fully to one particular, fixable thing that isn't the core of Reiser4, it'd be nice for you to wait on replying -- vagueness is not helpful to development in any way. Are we supposed to be the million monkeys randomly typing on a million typewriters waiting for someone to give you code that you like, one in a million years? You are the ones that want to benefit from having your code in the kernel. You evaluate if the (standard!) cycle of Code, propose, get rejected, fix, repropose, ... until finally accepted works for you or just isn't worth the bother. Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS or ext2 or ext3 had never gotten into the kernel. How would their development be now as opposed to how we see it, when they have gotten into the kernel? I don't see anything wrong with the idea of letting what seems a mostly mature FS into the kernel; that is how most bugs are found in the first place. Of course, there is nothing wrong with putting huge warnings on the FS; I'd recommend them, considering that some people are having funky problems with the patch. Just unloading some untested code on unsuspecting, innocent users is not very nice, is it? I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2. Indeed, H.264 crashes some computers, similar to Reiser4 might crash some machines, but this is merely because Reiser4 explores new concepts, meaning it may require hardyier hardware than ext2/3, as H.264 requries hardier hardware than Mpeg-2. Either one crashing the machine is unacceptable (in principle at least). A filesystem is so central to everything is a file that filesystem problems are doubly unacceptable. There are lots of reports of ReiserFS 3
ent:sdXnn going to D state with latest reiser4 patch
Hello, Doing some tests with latest reiser4 patches from 2.6.14-mm1, I noticed that the load of the machine never goes under 2. It comes from two processes related to reiser4 and going to D state immediately after the filesystems are mounted. As there are two reiser4 partitions, I get two such processes, and the load is always higher than 2. These processes appear as ent:sdb7 and ent:sdb11 (correspnding fs are on sdb7 and sdb11) and same with square brackets sometimes. I can reproduce this with 2.6.14-rc1-git4 and 2.6.13.2, with the latest patch. I do not have this problem with previous reiser4 patch (2.6.13-mm3 + latest reiser4-only.1.patch from ftp.namesys.com. I guess people doing simple tests of this patch will see this behaviour, and I am surprised nobody seems to have posted about this on the list. Best regards, -- Damien Wyart
Re: I request inclusion of reiser4 in the mainline kernel
Horst von Brand wrote: There are lots of reports of ReiserFS 3 filesystems completely destroyed by minor hardware flakiness. Honestly, this is one of the things I like about Linux. If I have memory errors, Windows will just keep running, occasionally something will crash, you restart it, never suspecting just how corrupt things are getting under the hood. On Linux, I generally get kernel panics pretty quickly, so I run memtest86 and replace the RAM. If my hardware is flaky, I consider it my job to replace it, not the job of all my software to magically compensate for it. If I lose data, oh well, I have backups. If I didn't, I was asking for trouble anyway.
Re: I request inclusion of reiser4 in the mainline kernel
For what it's worth sometimes people get emotional and frustrated and sometimes people can be difficult at thimes to work with. But - for what it's worth - I think people should ignore some of that as human nature and look at the big picture. And the big picture is Hans has make a huge contribution with Reiser 3 and eventually Reiser 4 is going to be something that will greatly enhance the kernel and advance Linux the way Reiser 3 has done. Wasn't Resiser 3 the first journalling file system for Linux that actually worked? So - I say - if it doesn't break anything else - why not throw it into the mail kernel? It will get there eventually and if it's there sooner them more people will be out there trying to break it and it will develop faster. I don't know personally how stable it is - but from what I understand it is winning the speed tests and that will shave some time off of everything the rest of us do. And even if it is somewhat broken - in a few months it will all be fixed. And Hans is apparently ready to take abuse if it's broken. So I say - lets do it already. My 2 centz
Re: I request inclusion of reiser4 in the mainline kernel
On Sul, 2005-09-18 at 13:22 -0400, michael chang wrote: This is exciting to... whom? The only thing that appears remotely interesting about it is that it's made by Oracle and apparently is supposed to be geared toward parallel server whatsits. Which no current included fs supports. And parallel file systems btw get exciting for everyone once you have virtualisation. Is that Hans' fault, or the fault of your lot? Why can't we all just get along? Insufficient drugs ;) ? work with. Discriminate him because he's not a developer you can talk with, and I believe that's like discriminating a guy in a wheelchair because he can't run with you when you jog in the morning. Hans can learn to work with people, most folks in wheelchairs cannot take lessons and walk. Many of them have tried months of physiotherapy. to learn to walk again. I think your comparison is insulting to a lot of the disabled. Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS or ext2 or ext3 had never gotten into the kernel. How would their Linus refused ext3 initially. It went in because it had a userbase, vendors shipping it and reliable clean code. Saying no a lot is really rather important to keeping the kernel maintainable. I regularly meet cases we should have said no a lot louder 8) I'm willing to go compare Reiser4 to ext2/3 as like H.264 to Mpeg-2. Indeed, H.264 crashes some computers, similar to Reiser4 might crash some machines, but this is merely because Reiser4 explores new It doesn't matter if reiser4 causes crashes. It matters that people can fix them, that they are actively fixed and the code is maintainable. It will have bugs, all complex code has bugs. Hans team have demonstrated the ability to fix some of those bugs fast, but we also all remember what happened with reiser3 later on despite early fast fixing. One big reason we jump up and down so much about the coding style is that its the one thing that ensures someone else can maintain and fix code that the author has abandoned, doesn't have time to fix or that needs access to specific hardware the authors may not have. Alan
Re: ent:sdXnn going to D state with latest reiser4 patch
Le 18.09.2005 22:29, Damien Wyart a écrit : Hello, Doing some tests with latest reiser4 patches from 2.6.14-mm1, I noticed that the load of the machine never goes under 2. It comes from two processes related to reiser4 and going to D state immediately after the filesystems are mounted. As there are two reiser4 partitions, I get two such processes, and the load is always higher than 2. These processes appear as ent:sdb7 and ent:sdb11 (correspnding fs are on sdb7 and sdb11) and same with square brackets sometimes. I can reproduce this with 2.6.14-rc1-git4 and 2.6.13.2, with the latest patch. I do not have this problem with previous reiser4 patch (2.6.13-mm3 + latest reiser4-only.1.patch from ftp.namesys.com. I guess people doing simple tests of this patch will see this behaviour, and I am surprised nobody seems to have posted about this on the list. Hello Damien, I didn't notice an extra load here (Linux version 2.6.14-rc1-mm2 ([EMAIL PROTECTED]) (gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)) #130 Sat Sep 17 10:26:06 CEST 2005). But, I can confirm that ent:hda8 is always in D state. [notice the *mm2* ? I'm using http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.14-rc1-mm1.5.gz which is kinda rc1-mm1 without big input/sysfs changes] Furthermore reiser4 prevents the box from suspending to disk. Found in log while suspending : Restarting tasks...6 Strange, ent:hda8. not stopped ~~ laurent signature.asc Description: OpenPGP digital signature
Re: I request inclusion of reiser4 in the mainline kernel
David Masover wrote: Horst von Brand wrote: There are lots of reports of ReiserFS 3 filesystems completely destroyed by minor hardware flakiness. Honestly, this is one of the things I like about Linux. If I have memory errors, Windows will just keep running, occasionally something will crash, you restart it, never suspecting just how corrupt things are getting under the hood. On Linux, I generally get kernel panics pretty quickly, so I run memtest86 and replace the RAM. If my hardware is flaky, I consider it my job to replace it, not the job of all my software to magically compensate for it. If I lose data, oh well, I have backups. If I didn't, I was asking for trouble anyway. I'm of the same opinion. If I have hardware that has a problem, and causes downtime, it gets replaced or repaired. I don't switch to a different piece of software to compensate for broken hardware. With that said, I have seen ReiserFS expose hardware that had problems. Hardware was repaired, and ReiserFS rides again. --Dan
reiser4()
Hi, Is the reiser4() system call already implemented? Is there any sample code to see its usage? I'd really like to try it and perhaps help with debugging. Ivan
Re: I request inclusion of reiser4 in the mainline kernel
Denis Vlasenko wrote: On Friday 16 September 2005 20:05, Hans Reiser wrote: All objections have now been addressed so far as I can discern. Random observation: You can declare functions even if you never use them. Thus here you can avoid using #if/#endif: #if defined(REISER4_DEBUG) || defined(REISER4_DEBUG_MODIFY) || defined(REISER4_DEBUG_OUTPUT) int znode_is_loaded(const znode * node /* znode to query */ ); #endif -- vda thanks. zam, please address this.
reiser4 mount options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello People, Despite the fact said that reiser4 is not stable so isn't included in mainline kernel, I trusted Hans Reiser's statement that they've not been able to crash the fs in the labs. I just migrated my laptop from plain partitions with ext3 to Reiser4 on LVM. Till now, I'm pretty happy with the performance. 2.2 gigs of files in ext3 show 1.9 gigs in Reiser4. Thanks to all your work. Disk access is almost doubled. I haven't measured it, I just feel it. Thanks to all of you. Some questions, What mount options should one use for laptops ? (Right now I'm using defaults) When can we have the reiser4 version of filesystem resize utility ? Regards, rrs - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC Stealing logic from one person is plagiarism, stealing from many is research. Necessity is the mother of invention. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDLgKD4Rhi6gTxMLwRAiYJAJ4yFlOCFC3K3vJaafIgSqASW0T/dgCggts4 TGWhaSnYT99Hfigts8au5MY= =mxiM -END PGP SIGNATURE-
Re: I request inclusion of reiser4 in the mainline kernel
I'm of the same opinion. If I have hardware that has a problem, and causes downtime, it gets replaced or repaired. I don't switch to a different piece of software to compensate for broken hardware. With that said, I have seen ReiserFS expose hardware that had problems. Hardware was repaired, and ReiserFS rides again. This summer : Coming back from vacation, looking at the logs, I saw that the cupboard router-server had kernel-panicked almost daily and rebooted itself automatically. I also had a lot of corrupted BitTorrent downloads. I could have blamed reiserfs, or bittorrent. But instead, I opened the case and found the CPU was overheating due to the fan being clogged by an unbelievable amount of accumulated dust and crap. reiserfs was still happy, I ran a fsck just to be sure, no errors. fhew. I wonder how it's possible. Given the state of the CPU fan, everything should have been wiped out. I have an all-reiser4 laptop (except /boot) and it's great. No problems whatsoever, it flies. Pentium-M kicks ass. My jukebox PC is half reiser3 and (since a few months) half reiser4, running fine, on the cheapest possible motherboard, and the no-name RAM, with an underclocked Duron. The hardware is so bad I had to underclock the PC133 to PC100. It has never crashed in 4 years, or got any data corruption. Crap hardware is actually sometimes pretty good if you underclock it (just have to get lucky). With windows, it used to bluescreen just by plugging a cable in the ethernet port. My server is all reiser3 too. I could have used other filesystems but reiserfs Just Works. No horror stories to tell, sorry. I like reiserfs. I don't care it there were very old versions that crashed. I don't care about Linux 2.0 or 1 either. Or Netscape 2. That's the past now.
Re: I request inclusion of reiser4 in the mainline kernel
I have a bug report for the first time about reiser4 in 2.6.14-rc1-mm1 with 4k stacks, preempt and smp. It is the first time I face a bug after using reiser4 for about a year. Well I had to with 4k stacks right ? firefox has triggerred the bug twice and I had to fsck the filesystem with --fix --build-fs which fixed the error. After fixing it any attempt to access the drive resulted in a 'Bus error' message. A sync and reboot using the sysreq mechanism returned me to a working system. Sorry if this is not the place to report the bug, or if doesn't get attatched to the reiser4 thread, I am new to LKML. Thanks in advance. [ cut here ] kernel BUG at bad filename:59883! invalid operand: [#1] PREEMPT SMP last sysfs file: /class/sound/seq/dev Modules linked in: snd_seq_instr snd_seq_midi_emul snd_seq_midi snd_seq_midi_event snd_seq firmware_class nls_utf8 nls_cp864 vfat fat nls_base af_packet joydev tsdev ohci_hcd ehci_hcd yealink usbhid mousedev nvidia snd_pcm_oss snd_mixer_oss video via_rhine uhci_hcd usbcore tpm_nsc tpm_infineon tpm_atmel tpm thermal speedstep_lib snd_cmipci gameport snd_pcm snd_page_alloc snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore shpchp pci_hotplug rtc processor loop intel_agp agpgart i2c_i801 i2c_core fan cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave cpufreq_ondemand cpufreq_conservative container button battery CPU:0 EIP:0060:[c01d56fb]Tainted: P VLI EFLAGS: 00010297 (2.6.14-rc1-mm1) EIP is at sub_from_ctx_grabbed+0x2b/0x30 eax: ebx: ecx: 0001 edx: esi: d24deec0 edi: df69e800 ebp: d50fc9e0 esp: cea25d8c ds: 007b es: 007b ss: 0068 Process firefox-bin (pid: 10393, threadinfo=cea25000 task=de659050) Stack: 0001 c01d63c0 d24deec0 0001 de202680 d50fc9e0 d50fc9e0 ce6cb8d4 c01d8594 d50fc9e0 0001 de202680 d50fc9e0 de2026b4 c01d85e7 de202680 d50fc9e0 de202680 c01d861e de202680 Call Trace: [c01d63c0] grabbed2flush_reserved_nolock+0x30/0x70 [c01d8594] do_jnode_make_dirty+0xf4/0x120 [c01d85e7] jnode_make_dirty_locked+0x27/0x40 [c01d861e] znode_make_dirty+0x1e/0x90 [c01ef1b5] update_sd_at+0xc5/0x1f0 [c01ef32d] update_sd+0x4d/0x70 [c01ee5fb] write_sd_by_inode_common+0x8b/0x90 [c01e37c8] reiser4_dirty_inode+0x18/0x70 [c0180883] __mark_inode_dirty+0xb3/0x190 [c01784c4] update_atime+0x54/0x80 [c01f1aee] read_unix_file+0x35e/0x3c0 [c015d316] vfs_read+0xa6/0x140 [c015d64d] sys_read+0x3d/0x70 [c0102d7b] sysenter_past_esp+0x54/0x79 Code: 56 53 8b 74 24 0c 8b 5c 24 14 8b 4c 24 10 8b 56 78 8b 46 74 39 da 76 0d 29 c8 19 da 89 46 74 89 56 78 5b 5e c3 72 04 39 c8 73 ed 0f 0b eb e9 90 8b 4c 24 04 8b 41 74 8b 51 78 03 44 24 08 13 54 6note: firefox-bin[10393] exited with preempt_count 3 Please request any extra info you need. Thanks and keep up the good work.
Re: I request inclusion of reiser4 in the mainline kernel
PFC wrote: I'm of the same opinion. If I have hardware that has a problem, and causes downtime, it gets replaced or repaired. I don't switch to a different piece of software to compensate for broken hardware. With that said, I have seen ReiserFS expose hardware that had problems. Hardware was repaired, and ReiserFS rides again. Agreed - if the hardware has problem and anything is readable I'm happy. When I was sysadmin at EFF we got a bunch of IBM Deathstar drives - and for those who experiences this - every one of them fails. But they usually fail slowly. What amazed me was I would stat to see seek errors - sector not found and I would copy off everything I could onto a new drive before I lost anything. And - I thought it was amazing that I usually managed to get all the important stuff. So - I give reiser credit for being somewhat resiliant. here's the way I see it. This isn't like Hans Reiser is some unknown guy who has some wild idea that we all don't know. ReiserFS is a majoy player in the Linux world and many people like it the best. Several distros use Reiser as their default install. So to me this gives him more than average standing and the way I see it - there has to be a good reason to NOT merge it rather than a reason TO merge it. So - is Reiser4 going to break anything? If not - what is the reason to not do it? -- Marc Perkel - [EMAIL PROTECTED] Spam Filter: http://www.junkemailfilter.com My Blog: http://marc.perkel.com
Re: I request inclusion of reiser4 in the mainline kernel
PFC wrote: I'm of the same opinion. If I have hardware that has a problem, and causes downtime, it gets replaced or repaired. I don't switch to a different piece of software to compensate for broken hardware. With that said, I have seen ReiserFS expose hardware that had problems. Hardware was repaired, and ReiserFS rides again. Agreed - if the hardware has problem and anything is readable I'm happy. When I was sysadmin at EFF we got a bunch of IBM Deathstar drives - and for those who experiences this - every one of them fails. But they usually fail slowly. What amazed me was I would stat to see seek errors - sector not found and I would copy off everything I could onto a new drive before I lost anything. And - I thought it was amazing that I usually managed to get all the important stuff. So - I give reiser credit for being somewhat resiliant. here's the way I see it. This isn't like Hans Reiser is some unknown guy who has some wild idea that we all don't know. ReiserFS is a majoy player in the Linux world and many people like it the best. Several distros use Reiser as their default install. So to me this gives him more than average standing and the way I see it - there has to be a good reason to NOT merge it rather than a reason TO merge it. So - is Reiser4 going to break anything? If not - what is the reason to not do it? -- Marc Perkel - [EMAIL PROTECTED] Spam Filter: http://www.junkemailfilter.com My Blog: http://marc.perkel.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I request inclusion of reiser4 in the mainline kernel
Denis Vlasenko wrote: And yet thousands and thousands of people, businesses, etc, say that the Linux kernel code is miles above all the commercial software out there. Not the commercial software I have worked with. IBM code, government procured code, both are much more readable code than Linux Kernel standards. I am sure there is no shortage of bad IBM code and bad government code, but my personal experiences were that it was much better commented. Your statement sounds like something you want to believe. That all said, the kernel code is getting better. if the rest of the kernel was as well commented as akpm's code I would not be complaining at all.
Re: I request inclusion of reiser4 in the mainline kernel
Alan Cox wrote: It doesn't matter if reiser4 causes crashes. It matters that people can fix them, that they are actively fixed and the code is maintainable. It will have bugs, all complex code has bugs. Hans team have demonstrated the ability to fix some of those bugs fast, but we also all remember what happened with reiser3 later on despite early fast fixing. What was that? One big reason we jump up and down so much about the coding style is that its the one thing that ensures someone else can maintain and fix code that the author has abandoned, doesn't have time to fix or that needs access to specific hardware the authors may not have. So why is the code in the kernel so hard to read then? Linux kernel code is getting better, and Andrew Morton's code is especially good, but for the most part it's unnecessarily hard to read. Look at the elevator code for instance. Ugh. I differ in one major aspect from some. That is, the only coding style requirement I have of those who work for me is that it must be easy to read. That is because at every company I can remember where someone was gungho about advocating that code be written in a specific defined style, that someone was always the one with the least readable code. I have a simple punishment for those who violate my requirement: I go through the code line by line with them, which they always hate for some reason, and help them comment and clarify it. 1-2 sessions of this, and they usually change how they code so that they don't have to go through it again with me. Asking for readable code is not that different from asking for readable novels: if you try to define what is required rather than teaching instance by instance, you can only get in the way of the artist rather than instructing. That is why I just say make it easy to read and I don't care how you do that so long as it works.
Re: I request inclusion of reiser4 in the mainline kernel
Lennart Sorensen wrote: Neither was ready for use when they were included in the kernel and should probably have had big warning signs in the kernel config for them. They did have warning signs: they were labeled experimental as is reiser4. At some point developers and their limited size mailing list simply cannot make things crash, and then it needs to go in to the main kernel labeled experimental. Of course, the reiser4 code is not as stable as it was before the changes Christoph asked for. Hans
Re: I request inclusion of reiser4 in the mainline kernel
Christian Iversen wrote: On Sunday 18 September 2005 12:26, Christoph Hellwig wrote: On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote: This is it. I do not say accept reiser4 NOW, I am saying give Hans good code review. After he did his basic homework. Note that reviewing hans code is probably at the very end of everyones todo list because every critizm of his code starts a huge flamewar where hans tries to attack everyone not on his party line personally. I've said I'm gonna do a proper review after he has done the basic homework, which he seems to have half-done now at least. Right now he hasn't finished that and there's much more exciting filesystems like ocfs2 around [...] Now _what_ good does that sentence do us? I've been following this this since the primary reiser filesystem was number 3, and the kernel everybody was using was 2.4.10. You've probably been following this list for far longer, but is that really an excuse for rudeness? reiser4 has many, many extremely interesting features. I'm sure anybody is more than willing to go into detail with them, but saying that ocfs2 is much more exiting is just plain bashing, and it's not fair to Hans, to Namesys, or to every one of us who can't wait for reiser4 in mainline. Could you please keep your personal idea of which filesystem is more interesting to yourself? It doesn't help anybody accomplish anything. Hellwig, people who write slow file systems should not lecture their measurably superiors on how to code. Oh, and I should mention that other people besides me have measured reiser4, and concluded it is twice the speed of the other Linux filesystems, so don't go claiming it is just my benchmarks. What you are doing is keeping me from doing a real code review myself by keeping my guys so busy that they don't have time to review the fixmes I inserted and would insert more of if I thought they had time for them. If you were as well suited to doing code reviews as I am, you would have written a faster file system yourself. Anybody can find things to fix in someone else's code, and it can go on for years if they want it to. I could get what you do from hiring a college junior, and if it was a good university I'd probably learn more from that junior in college than from you. We are doing work, and you are getting in the way. Nobody who wants reiser4 views your contributions as the least bit positive. I fear you will delay us until ext3 can catch up. What you are is someone who substitutes social connections for technical ability. You measurably can't code as well as we can, so once it conforms to VFS interface requirements, please go away.
Re: I request inclusion of reiser4 in the mainline kernel
On Sunday 18 September 2005 21:25, David Masover wrote: Denis Vlasenko wrote: If you want reiser4 included into mainline, do something. Like download a patch and try to use it. Alright... Last time I tried, it didn't work. Kernel locked up. Namesys was quick with fix for the lockup, but then ls . failed to work. I sent all the data (kernel version, fs image, etc) to Namesys but after several email iterations it died out with no resolution. When was last time? A month or two ago. -- vda
Re: I request inclusion of reiser4 in the mainline kernel
Horst von Brand wrote: that and there's much more exciting filesystems like ocfs2 around that This is exciting to... whom? To Cristoph, obviously. You should thank him for doing the (hard, boring, thankless) work of reviewing code for free. Even if it isn't yours. As he is doing it as community service, I wouldn't dare blame him for picking whatever he likes most, for whatever reasons. Well maybe he should just go away then and save his and our time. Reiser4 works just fine without Christoph. Users are happy with it. None of them have asked for his help. I don't consider Christoph to be qualified to work on our filesystem. I would not hire him if he applied --- he is not capable of innovative work. Reiser4 is far from perfect, but it is ready for more users. Is that Hans' fault, or the fault of your lot? Why can't we all just get along? Hans is one person, and he has managed to alienate a most of the LKML bunch. Sure, there are very abrasive people here, but there are plenty that are extremely helpful to newbies that /really/ want to learn how to do things right. Yes, but the helpful ones have nothing to do with VFS. Linux has lost filesystem developers because of the VFS team, developers who I can tell you were very very gifted DARPA researchers who decided to work on BSD because they had too much dignity to develop a filesystem for Linux. I assure you that no one on the VFS team is as bright or capable as one of the fellows I know of that they abused away. If you don't have the time to review, then please hold off on replying until you have a through review of at least part of the code. Can't do. It is mostly an artistic sense of taste. Yes, which is why people who have not written a serious filesystem should not instruct those who have written the measurably fastest one. Also, let's say that Reiser4 doesn't get into the kernel, as maybe XFS or ext2 or ext3 had never gotten into the kernel. How would their development be now as opposed to how we see it, when they have gotten into the kernel? I don't see anything wrong with the idea of letting what seems a mostly mature FS into the kernel; that is how most bugs are found in the first place. Of course, there is nothing wrong with putting huge warnings on the FS; I'd recommend them, considering that some people are having funky problems with the patch. Just unloading some untested code on unsuspecting, innocent users is not very nice, is it? Christoph is not testing. We have tested, our mailing list has tested. There are lots of reports of ReiserFS 3 filesystems completely destroyed by minor hardware flakiness. And that has /never/ been fixed, as the developers just went off to do the next cool thing. That history weighs against ReiserFS, heavily. We are supposed to write a filesystem so that overheating CPUs do not make it crash? Prejudice is a very simple phenomenom. When either ext3 or ReiserFS V3 crash it is almost always due to bad hardware. Prejudice is the process of remembering that one filesystem crashed due to bad hardware and not remembering that the other one crashed. It is remarkably simple how it works: people who use Reiser4 want it in, people who use ext3 and don't want to have a choice of something else don't want it in. That was true of V3, and it is true of V4. My point of course is that those who have used V4 know more about it than those who haven't.. I think Alan Cox is the only poster who has no intention of using Reiser4 but said at one point that he thinks it should go in. V3 is obsoleted by V4 in every way. V3 is old code that should be marked as deprecated as soon as V4 has passed mass testing. V4 is far superior in its coding style also. Having V3 in and V4 out is at this point just stupid. This whole thing reminds me of an IBMer who told me that he thought that IBM lost to MS because they called OS/2 by a name other than DOS. The sad thing is he was probably right. V4, as it is today, is as much superior to V3 as OS/2 was to DOS. Any distro or user who would stay with V3 for new installs once we have passed mass testing is nuts. We need the mass testing. Hans
Namesys web page, possible update?
The following line of text appears on the main page at http://www.namesys.com: V3 of reiserfs is used as the default filesystem for SuSE, Lindows, FTOSX, Libranet, Gentoo, Xandros and Yoper. I believe Slackware has defaulted to V3 for some time now. EXT3 and 2 are still options as well, but the default selection for filesystem type is ReiserFS when you go through the setup process. Just hoping to give you guys another (very mature) distro to add to the list. --Dan
Burst HYIP Referral Commision 10%
http://bursthyip.com/?ref=steverob3389 Burst HYIP The safest HYIP you can have. Payouts made daily! Referral Contest with over $4000 in prize money! 10% Referral Commision Make your money back! 8-10% Profit a day! Join now! http://bursthyip.com/?ref=steverob3389
Re: I request inclusion of reiser4 in the mainline kernel
On Sun, 18 Sep 2005 22:16:11 PDT, Hans Reiser said: Hellwig, people who write slow file systems should not lecture their measurably superiors on how to code. Oh, and I should mention that other people besides me have measured reiser4, and concluded it is twice the speed of the other Linux filesystems, so don't go claiming it is just my benchmarks. What you are doing is keeping me from doing a real code review myself by keeping my guys so busy that they don't have time to review the fixmes I inserted and would insert more of if I thought they had time for them. Hans, unfortunately the most obvious reading of the above is Reiser4 is so damned fast because it doesn't bother doing sanity-checking. If there's still more fixmes to be inserted that *you* know of, and there are so many that there's no time to fix them, why is this being submitted for inclusion? On Sun, 18 Sep 2005 22:09:08 PDT, Hans Reiser said: Of course, the reiser4 code is not as stable as it was before the changes Christoph asked for. This sort of claim requires proof - can you point at *specific* things that were less stable after you fixed the code, including explaining why they're less stable? pgpSbMPr0RKqd.pgp Description: PGP signature
