Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
IIRC, don't vanilla and -mm have some somewhat substancial internal differences that could require manual changes? I could be wrong though, I've never even looked at the diffs/patches for vanilla vs -mm. That's what I am pointing to. The patches might apply cleanly or have a few FAILED hunks that can be fixed easily by hand. But what do I know about the changes made to the vfs layer etc.. I could break something without knowing it.
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
Islam Amer wrote: IIRC, don't vanilla and -mm have some somewhat substancial internal differences that could require manual changes? I could be wrong though, I've never even looked at the diffs/patches for vanilla vs -mm. That's what I am pointing to. The patches might apply cleanly or have a few FAILED hunks that can be fixed easily by hand. But what do I know about the changes made to the vfs layer etc.. I could break something without knowing it. Maybe I did, but I've had a relatively sane experience with it so far... Yet, Namesys has put out a 2.6.13 patch, so I'll be switching to that next time I have a reason to compile. I'm running two amd64 boxes and one Pentium 2 on Reiser4, and will soon be putting it on a Powerbook.
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
David Masover wrote: Islam Amer wrote: IIRC, don't vanilla and -mm have some somewhat substancial internal differences that could require manual changes? I could be wrong though, I've never even looked at the diffs/patches for vanilla vs -mm. That's what I am pointing to. The patches might apply cleanly or have a few FAILED hunks that can be fixed easily by hand. But what do I know about the changes made to the vfs layer etc.. I could break something without knowing it. Maybe I did, but I've had a relatively sane experience with it so far... Yet, Namesys has put out a 2.6.13 patch, so I'll be switching to that next time I have a reason to compile. I'm running two amd64 boxes and one Pentium 2 on Reiser4, and will soon be putting it on a Powerbook. By this weekend I'll have a Gentoo 2005.1 install running on a Sun Ultra II workstation (dual processor, 64-bit). I'll let you guys know how the 2.6.13 patch goes. --Dan
Re: Full of surprises - A reiser4 story from userland
On Wed, Sep 28, 2005 at 03:40:12PM +0200, Fionn Behrens wrote: Hello all, hi, Now, would someone please tell me where I can find a reiser4 patch that works as stable and surprise-free as your code back then in the old ages of 2004 and that can be applied to 2.6.13? i'd be interested in such patch too, so that i can update the debian package. Please? Or would I have been better off using XFS from the beginning? oh no.. why xfs jumps on my neck every time reiser4 has some problem? regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Full of surprises - A reiser4 story from userland
On Wednesday 28 September 2005 17:40, Fionn Behrens wrote: Hello all, Hello I just wanted to tell along a bit about my recent experiences with reiserfs. I have been using reiser3.[56] without any glitch for more than five years and when I got a new notebook last year, I decided to give reiser4 a try. There even was a handy kernel patch package available in debian! How nice. A few bencharks proved my choice was right. Over the last 12 months I was very happy with it - no sign of a problem and pretty fast operation on 2.6.10 and 11. A few days ago I decided to upgrade to 2.6.13 because I need it for development at work. Having heard about the discussions around reiser4 kernel integration I supposed it should be quite stable now and that it may even have improved some more. I also expected it to be readily available as a kernel patch for everyone to try. There was my first surprise: It was not! I spent quite some time searching around and finally found that seemingly the only way to get reiser4 for the latest kernel were a dozen and a half reiser4* patches from mm. Their proper sequence of application also is up to the technically interested user. Why you request a software to be integrated into Linux while you dont even provide an official patch download for the very kernel version you want it in, is beyond my comprehension. Well, since I needed 2.6.13 and my root partition already was reiser4 I had to take things like they were. I spent another hour applying those patches and getting around some minor problems doing so. Finally, there was my shiny new 2.6.13 with reiser4. But alas, the next surprise was not far away. Trying to suspend my notebook now resulted in some reiser4 kernel processes going postal: PID USER PR SHR S %CPU %MEMTIME+ COMMAND 984 root 25 0 R 25.3 0.0 0:23.62 ktxnmgrd:dm-0:t 3246 root 25 0 R 24.3 0.0 0:23.54 ktxnmgrd:hda4:t 985 root 25 0 R 23.3 0.0 0:23.61 ent:dm-0. 3247 root 25 0 S 23.3 0.0 0:23.60 ent:hda4. The load went up to 8 and my computer became the most expensive heater on the block. Reboot unavoidable. Maybe reiser4 had not improved that much. A short check on the net just popped a few posts about recent reiser4 being a turkey and that someone should put up a warning somewhere (DAMN YES YOU SHOULD) but no solution. I decided to go back to 2.6.11 before any more bad things happen. Third surprise: they had already happened. 2.6.11 refused to boot the root partition, claiming that there were an inconsistency in the FS. the disk format got new parameters and old kernels cannot understand it right. Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42 Sep 28 08:44:20 rtfm kernel: reiser4[mount(840)]: init_inode_static_sd (fs/reiser4/plugin/item/static_stat.c:283)[nikita-631]: Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42 I know the disk is ok and I had not had a crash of any sort (the freaked out kernel from above seemed to shut down properly at least). So I probed this a bit further: trying 2.6.13 reiser4: booting without a warning. trying 2.6.11 again: error, error, no go trying 2.6.13 once more: booting nicely trying 2.6.11 finally: error again. Okay, I'd call this another surprise. I just did not know whether there actually was a problem or not! So I decided to give fsck a shot (on which fsck version? 2.6.11 - I had somewhat lost my belief in recent reiser4 code). I just ran in with --check, because the man page said that this would be read-only. it says: --check the default action checks the consistency and reports, but does not repair any corruption that it finds. This option may be used on a read-only file system mount. it does not mean 100% read-only check. It found this: FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a valid SD plugin set extention: wrong pset member count detected (12). FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a valid stat data. FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: broken item found. FSCK: Node (2196341): the node is broken. Pointed from the node (2196340), item (0), unit (0). The whole subtree is skipped. Of course, as a user, I don't have the slightest idea what this means. The whole subtree is skipped sounded worryingly lossy, however. At the end of the run, fsck told me I had to rerun it with --build-fs. Now that sounded pretty heavy. I still have some real work to do and I already had lost several working hours to this and was not very willing to do so right now. So I decided to take advantage of the now proven fact that REISER4-2.6.13 DOES NOT RECOGNIZE ITS SELF-MADE DAMAGE and give it another go for today (I made a backup the other day anyway), save my work on NFS and let the --build-fs thing run tonight after work. There was my fourth surprise:
Re: Full of surprises - A reiser4 story from userland
On 9/28/05, Vitaly Fertman [EMAIL PROTECTED] wrote: On Wednesday 28 September 2005 17:40, Fionn Behrens wrote: Hello all, Hello I just wanted to tell along a bit about my recent experiences with reiserfs. I have been using reiser3.[56] without any glitch for more than five years and when I got a new notebook last year, I decided to give reiser4 a try. There even was a handy kernel patch package available in debian! How nice. A few bencharks proved my choice was right. Over the last 12 months I was very happy with it - no sign of a problem and pretty fast operation on 2.6.10 and 11. A few days ago I decided to upgrade to 2.6.13 because I need it for development at work. Having heard about the discussions around reiser4 kernel integration I supposed it should be quite stable now and that it may even have improved some more. I also expected it to be readily available as a kernel patch for everyone to try. There was my first surprise: It was not! I spent quite some time searching around and finally found that seemingly the only way to get reiser4 for the latest kernel were a dozen and a half reiser4* patches from mm. Their proper sequence of application also is up to the technically interested user. Why you request a software to be integrated into Linux while you dont even provide an official patch download for the very kernel version you want it in, is beyond my comprehension. Well, since I needed 2.6.13 and my root partition already was reiser4 I had to take things like they were. I spent another hour applying those patches and getting around some minor problems doing so. Finally, there was my shiny new 2.6.13 with reiser4. But alas, the next surprise was not far away. Trying to suspend my notebook now resulted in some reiser4 kernel processes going postal: PID USER PR SHR S %CPU %MEMTIME+ COMMAND 984 root 25 0 R 25.3 0.0 0:23.62 ktxnmgrd:dm-0:t 3246 root 25 0 R 24.3 0.0 0:23.54 ktxnmgrd:hda4:t 985 root 25 0 R 23.3 0.0 0:23.61 ent:dm-0. 3247 root 25 0 S 23.3 0.0 0:23.60 ent:hda4. The load went up to 8 and my computer became the most expensive heater on the block. Reboot unavoidable. Maybe reiser4 had not improved that much. A short check on the net just popped a few posts about recent reiser4 being a turkey and that someone should put up a warning somewhere (DAMN YES YOU SHOULD) but no solution. I decided to go back to 2.6.11 before any more bad things happen. Third surprise: they had already happened. 2.6.11 refused to boot the root partition, claiming that there were an inconsistency in the FS. the disk format got new parameters and old kernels cannot understand it right. Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42 Sep 28 08:44:20 rtfm kernel: reiser4[mount(840)]: init_inode_static_sd (fs/reiser4/plugin/item/static_stat.c:283)[nikita-631]: Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42 I know the disk is ok and I had not had a crash of any sort (the freaked out kernel from above seemed to shut down properly at least). So I probed this a bit further: trying 2.6.13 reiser4: booting without a warning. trying 2.6.11 again: error, error, no go trying 2.6.13 once more: booting nicely trying 2.6.11 finally: error again. Okay, I'd call this another surprise. I just did not know whether there actually was a problem or not! So I decided to give fsck a shot (on which fsck version? 2.6.11 - I had somewhat lost my belief in recent reiser4 code). I just ran in with --check, because the man page said that this would be read-only. it says: --check the default action checks the consistency and reports, but does not repair any corruption that it finds. This option may be used on a read-only file system mount. it does not mean 100% read-only check. It found this: FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a valid SD plugin set extention: wrong pset member count detected (12). FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a valid stat data. FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: broken item found. FSCK: Node (2196341): the node is broken. Pointed from the node (2196340), item (0), unit (0). The whole subtree is skipped. Of course, as a user, I don't have the slightest idea what this means. The whole subtree is skipped sounded worryingly lossy, however. At the end of the run, fsck told me I had to rerun it with --build-fs. Now that sounded pretty heavy. I still have some real work to do and I already had lost several working hours to this and was not very willing to do so right now. So I decided to take advantage of the now proven fact that REISER4-2.6.13 DOES NOT RECOGNIZE ITS SELF-MADE DAMAGE and give it another go for today (I made a
Re: Full of surprises - A reiser4 story from userland
Please? Or would I have been better off using XFS from the beginning? Maybe this wouldn't be such a bad idea - since it would avoid such unfriendly posts to the mailing list. Since YOU WANT help, you should behave like its ment to be not always throughing arround how stupid this and that is. Lately there have been a lot changes suggested by kernel-developers to get reiser4 into the mainline kernel, so that's why it not as stable as it was. Furthermore maybe this is the reason why there's no such patch, have you thought this way round. Maybe only testers should use the current version? Man you get the best Linux-FS out there for free (I bet you did not contribute) and all you do is nerving arround. lg Clemens ps: sorry for flaming, seems my emotions overheated...
Re: Full of surprises - A reiser4 story from userland
On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote: 2.6.11 refused to boot the root partition, claiming that there were an inconsistency in the FS. the disk format got new parameters and old kernels cannot understand it right. Ah, I see. So maybe it would be a good idea if the new fs version would put up a big fat warning to syslog when it detects a partition written by a previous version, telling the user that he is about to break compatibility to his older version (and that the must upgrade userland tools, too!) Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42 Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42 which fsck version? 1.0.4 the man page said that this would be read-only. it says: --check the default action checks the consistency and reports, but does not repair any corruption that it finds. This option may be used on a read-only file system mount. it does not mean 100% read-only check. Okay, you sound a bit like a lawyer, but: you right me wrong. There was my fourth surprise: This fsck thing had LIED to me; it was not read-only. why do you think --build-fs is read-only? Had not gone --build-fs yet. This was still about --check. It may have checked the fs read-only but it must have treacherously flipped some error bit somewhere on disk Warning, mounting filesystem with fatal errors, forcing read-only mount (followed by the error from above) do you see anything relevant in the syslog? That line was in the syslog. So much for --check being just a check. I grabbed a book and lost about two more precious working hours running the --build-fs thing. you need to clarify what reiser4progs version you are running. 1.0.5 fixes the fs to the letest format, which is needed for 2.6.13. 1.0.3 to the 2.6.10's one. 1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to 1.0.5 or would that not do harm anyway? thanks for answering! kind regards, Fionn -- I believe we have been called by history to lead the world. G.W. Bush, 2002-03-01 signature.asc Description: This is a digitally signed message part
Re: Full of surprises - A reiser4 story from userland
On Mi, 2005-09-28 at 16:51 +0200, Clemens Eisserer wrote: Man you get the best Linux-FS out there for free (I bet you did not contribute) and all you do is nerving arround. Sorry if you see it this way. I actually took some time and effort to write up a post that is at least mildly entertaining and tries to offer understandable background on my emotions instead of simply posting an It dont werk! You suck! ten-liner. At least I thought I did. ps: sorry for flaming, seems my emotions overheated... Well, then you should have understood my post better than you pretend. br, Fionn -- There ought to be limits to freedom! *** US presidential candidate Gov. George W. Bush, press conference at the Texas State House, May 21, 1999 signature.asc Description: This is a digitally signed message part
Re: Full of surprises - A reiser4 story from userland
On 2005-09-28 15:40, Fionn Behrens wrote: There was my first surprise: It was not! I spent quite some time searching around and finally found that seemingly the only way to get reiser4 for the latest kernel were a dozen and a half reiser4* patches from mm. Their proper sequence of application also is up to the technically interested user. A quite stable and easy to use patchset including reiser4 is called ArchCK and can be found at: http://iphitus.loudas.com/archck.php I currently use 2.6.13-archck3.1 together with reiser4progs-1.0.5 and that works like charm. -- Ingo Bormuth, voicebox telefax: +49-12125-10226517 '(~o-o~)' GnuPG key 86326EC9 at http://ibormuth.efil.de/contact ---ooO--(.)--Ooo---
Re: Full of surprises - A reiser4 story from userland
On Wednesday 28 September 2005 19:28, Fionn Behrens wrote: On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote: 2.6.11 refused to boot the root partition, claiming that there were an inconsistency in the FS. the disk format got new parameters and old kernels cannot understand it right. Ah, I see. So maybe it would be a good idea if the new fs version would put up a big fat warning to syslog when it detects a partition written by a previous version, telling the user that he is about to break compatibility to his older version (and that the must upgrade userland tools, too!) Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42 Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42 which fsck version? 1.0.4 the man page said that this would be read-only. it says: --check the default action checks the consistency and reports, but does not repair any corruption that it finds. This option may be used on a read-only file system mount. it does not mean 100% read-only check. Okay, you sound a bit like a lawyer, but: you right me wrong. There was my fourth surprise: This fsck thing had LIED to me; it was not read-only. why do you think --build-fs is read-only? Had not gone --build-fs yet. This was still about --check. It may have checked the fs read-only but it must have treacherously flipped some error bit somewhere on disk Warning, mounting filesystem with fatal errors, forcing read-only mount (followed by the error from above) do you see anything relevant in the syslog? That line was in the syslog. ok, the flag that fs contains errors is indeed cleared only with --check with all reiser4progs untill 1.0.5, the later is able to do it with any options. Thus another --check run would clear the flag. However 'the error from above' that is 'WARNING: wrong pset member (11) for 42' is possible with the old kernel only. remember that reiser4progs-1.0.4 supports both formats, in other words having the format updated to the new one, you are able to use new kernel only. If you want to move back to 2.6.10, you have to build-fs with 1.0.3 version or reiser4progs. So much for --check being just a check. I grabbed a book and lost about two more precious working hours running the --build-fs thing. you need to clarify what reiser4progs version you are running. 1.0.5 fixes the fs to the letest format, which is needed for 2.6.13. 1.0.3 to the 2.6.10's one. 1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to 1.0.5 or would that not do harm anyway? 1.0.5 is 1.0.4 + bugfixes. thanks for answering! kind regards, Fionn -- Vitaly
Re: Full of surprises - A reiser4 story from userland
On Mi, 2005-09-28 at 20:40 +0400, Vitaly Fertman wrote: remember that reiser4progs-1.0.4 supports both formats, in other words having the format updated to the new one, you are able to use new kernelonly. If you want to move back to 2.6.10, you have to build-fs with 1.0.3 version or reiser4progs. Do I get this right? I had reiser4progs 1.0.4 and it should already know the new format? If what you say is right then fsck should have not complained about an error in the first place AND I still should not be able to boot with the old kernel any more after --build-fs. But it found an error. And I ran --build-fs with it. And now I am using the old kernel again and it does NOT complain about errors any more. (except for that flag we discussed already). Pardon me, I am confused. best regards, Fionn -- I feel like God wants me to run for President. I can't explain it, but I sense my country is going to need me. *** George W. Bush, 1999 Quoted from the book The Faith of George W. Bush by Steve Mansfield signature.asc Description: This is a digitally signed message part
Re: Full of surprises - A reiser4 story from userland
Fionn Behrens wrote: On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote: 2.6.11 refused to boot the root partition, claiming that there were an inconsistency in the FS. the disk format got new parameters and old kernels cannot understand it right. Ah, I see. So maybe it would be a good idea if the new fs version would put up a big fat warning to syslog when it detects a partition written by a previous version, telling the user that he is about to break compatibility to his older version (and that the must upgrade userland tools, too!) Yes, it would be nice, and I wish it'd been done that way. I'm hoping it will be once it's in the kernel. I liked how I didn't have to do anything for the upgrade to happen, but I'd probably like it more if this was something you had to do with a userland tool or a specific kernel boot/mount option. 1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to 1.0.5 or would that not do harm anyway? Not sure. I got 2.6.13 to work without much trouble, but I wasn't using the full MM patch, just the reiser4-specific parts.
Re: Full of surprises - A reiser4 story from userland
I apologize that the latest reiser4 with the cleanups requested by Hellwig is more than a bit of a turkey (due to bugs in our cleanups). We just now sent some patches which will improve things, but I don't yet have confidence in the code, and will not until we go for two weeks with no reports of problems. It may also be that the new to -mm write throttling patch is causing us problems, we are still investigating. Hans
Re: Full of surprises - A reiser4 story from userland
Fionn Behrens wrote: On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote: 2.6.11 refused to boot the root partition, claiming that there were an inconsistency in the FS. the disk format got new parameters and old kernels cannot understand it right. Ah, I see. So maybe it would be a good idea if the new fs version would put up a big fat warning to syslog when it detects a partition written by a previous version, telling the user that he is about to break compatibility to his older version (and that the must upgrade userland tools, too!) Good idea. Vitaly, please fix it. Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42 Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42 which fsck version? 1.0.4 the man page said that this would be read-only. it says: --check the default action checks the consistency and reports, but does not repair any corruption that it finds. This option may be used on a read-only file system mount. it does not mean 100% read-only check. Okay, you sound a bit like a lawyer, but: you right me wrong. Vitaly, fix the docs. There was my fourth surprise: This fsck thing had LIED to me; it was not read-only. why do you think --build-fs is read-only? Had not gone --build-fs yet. This was still about --check. It may have checked the fs read-only but it must have treacherously flipped some error bit somewhere on disk Warning, mounting filesystem with fatal errors, forcing read-only mount (followed by the error from above) do you see anything relevant in the syslog? That line was in the syslog. So much for --check being just a check. I grabbed a book and lost about two more precious working hours running the --build-fs thing. you need to clarify what reiser4progs version you are running. 1.0.5 fixes the fs to the letest format, which is needed for 2.6.13. 1.0.3 to the 2.6.10's one. 1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to 1.0.5 or would that not do harm anyway? thanks for answering! kind regards, Fionn
Re: Full of surprises - A reiser4 story from userland
Fionn Behrens wrote: Because of my good experiences with ReiserFS in the past I had high expectations. As you correctly and rightfully stated, reiser4 is development code and that probably means I should not rely on anything. Well, it had gone stable, sorry we let it destable. Hans
Re: Full of surprises - A reiser4 story from userland
Sorry about the full quotes, I just hit reply all in gmail and type in my email. I thought this was how the mailing list knows which thread to attatch my email to. Pardon my ignorance. Yes reiser4 was very solid but now it became a little shaky. little off topic: BTW, Previously I had amazing performance with anticipatory IO-scheduler ( even more so with genetic anticipatory ) any comments on this io-scheduler business, as it stirred up some commotion before. Is the performance boost an illusion or is it not.
iosched (was Re: Full of surprises - A reiser4 story from userland)
On Wed, 28 Sep 2005 22:13:52 +0300, Islam Amer said: BTW, Previously I had amazing performance with anticipatory IO-scheduler ( even more so with genetic anticipatory ) any comments on this io-scheduler business, as it stirred up some commotion before. Is the performance boost an illusion or is it not. The performance boost for any of the provided iosched schemes can be positive, negative, imaginary, or complex(*), depending on the actual workload of the system, and what reference patterns it generates. There's 4 in-tree schedulers precisely because each of them has a clear-cut advantage for some statistic (be it throughput, or latency, or CPU overhead, or whatever) for some identified workload type. (*) I suspect that (benchmarks being benchmarks) the chance that the boost be totally real, with no imaginary component, is very slim. And everybody knows that most benchmark results are complex to interpret.. :) pgpYlwcNDClWq.pgp Description: PGP signature
Re: Full of surprises - A reiser4 story from userland
On Wednesday 28 September 2005 21:57, Fionn Behrens wrote: On Mi, 2005-09-28 at 20:40 +0400, Vitaly Fertman wrote: remember that reiser4progs-1.0.4 supports both formats, in other words having the format updated to the new one, you are able to use new kernelonly. If you want to move back to 2.6.10, you have to build-fs with 1.0.3 version or reiser4progs. Do I get this right? I had reiser4progs 1.0.4 and it should already know the new format? If what you say is right then fsck should have not complained about an error in the first place AND I still should not be able to boot with the old kernel any more after --build-fs. But it found an error. And I ran --build-fs with it. And now I am using the old kernel again and it does NOT complain about errors any more. (except for that flag we discussed already). Pardon me, I am confused. hm, before writing that I had checked 1.0.4 progs and thought there was another older fsck you could run that time, but I have just double checked it and have found that 1.0.4 version I looked into was changed a bit. You are right, 1.0.4 works with the old format. and if you run it again with --check, you get rid of the ERROR flag in the super block. -- Vitaly
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
The performance boost for any of the provided iosched schemes can be positive, negative, imaginary, or complex(*), depending on the actual workload of the system, and what reference patterns it generates. I assumed published benchmarks are conducted under strictly controlled conditions. (*) I suspect that (benchmarks being benchmarks) the chance that the boost be totally real, with no imaginary component, is very slim. And everybody knows that most benchmark results are complex to interpret.. :) Then this scheduler is doing a very good job at creating an illusion of enhanced performance. Thanks for the reply :)
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
On 9/28/05, Hans Reiser [EMAIL PROTECTED] wrote: Check out the latest cfq in the latest kernel, it is much better than the others for most applications. Anticipatory used to be the best, but cfq-3 is better now. Yes I always had my eyes on the applicable parts of -ck patchset becasue they showed good promise ( upto my limited understading ). I just needed an educated opinion. Thanks. And I had to drop using the genetic-as because it oopsed with reiserfs in some kernels. Problem is lots of experimental patches in -mm series hurt throughput and performance and reiser4 users have to suffer. Otherwise we have to go through the slightly non-trivial procedure of patching the vanilla kernel.
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
Islam Amer wrote: The performance boost for any of the provided iosched schemes can be positive, negative, imaginary, or complex(*), depending on the actual workload of the system, and what reference patterns it generates. I assumed published benchmarks are conducted under strictly controlled conditions. The thing to do with benchmarks is to ask your friends and mailing lists if the benchmarks seem accurate to them based on their usage experience. The latest reiser4 has performance problems due to bugs added, but prior to it there seemed to be agreement on our mailing list that experiences matched our benchmarks. Am I right? Hans
iosched (was Re: Full of surprises - A reiser4 story from userland)
On 9/28/05, Hans Reiser [EMAIL PROTECTED] wrote: Check out the latest cfq in the latest kernel, it is much better than the others for most applications. Anticipatory used to be the best, but cfq-3 is better now. When you say the best is that a general conclusion for both single disks and RAID?
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
On Wed, 2005-09-28 at 17:33 -0400, studdugie wrote: On 9/28/05, Hans Reiser [EMAIL PROTECTED] wrote: Check out the latest cfq in the latest kernel, it is much better than the others for most applications. Anticipatory used to be the best, but cfq-3 is better now. When you say the best is that a general conclusion for both single disks and RAID? I find (but no hard data to provide) that no-op or deadline seems to work best when working with an intelligent RAID controller. Just push the queue to the controller and it'll sort out the best way to get things. -- Jonathan Briggs [EMAIL PROTECTED] eSoft, Inc. signature.asc Description: This is a digitally signed message part
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
Islam Amer wrote: Problem is lots of experimental patches in -mm series hurt throughput and performance and reiser4 users have to suffer. Otherwise we have to go through the slightly non-trivial procedure of patching the vanilla kernel. Non-trivial? How's this: for i in `egrep '^reiser4' ../broken-out/series`; do patch -p1 ../broken-out/$1; done That won't always work, but it's certainly trivial. Places it won't work: patch names with spaces (won't happen), commented patches (just generates weird errors), and a couple of kernels also need the attached patch. I don't remember which ones, but you get a compiler error unless you've got it right. It'll also fail (obviously) if anything's changed since I last checked.
Re: iosched (was Re: Full of surprises - A reiser4 story from userland)
On 9/28/05, David Masover [EMAIL PROTECTED] wrote: Islam Amer wrote: Problem is lots of experimental patches in -mm series hurt throughput and performance and reiser4 users have to suffer. Otherwise we have to go through the slightly non-trivial procedure of patching the vanilla kernel. Non-trivial? How's this: I'm not sure, but I do believe he was referring to official vanilla patch submission... although I could be wrong. IIRC, don't vanilla and -mm have some somewhat substancial internal differences that could require manual changes? I could be wrong though, I've never even looked at the diffs/patches for vanilla vs -mm. -- ~Mike - Just my two cents - No man is an island, and no man is unable.
