reiser4 crashes
Hello, my server crashed few times latetly, and the only strange thing i found in logs, are reiser4 entries just before every crash: #1 crash: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:15:31 werewolf kernel: reiser4[pure-ftpd-mysql(18809)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:15:31 werewolf kernel: reiser4[pure-ftpd-mysql(18809)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:15:31 werewolf kernel: reiser4[pure-ftpd-mysql(18809)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:26:48 werewolf kernel: reiser4[pure-ftpd-mysql(18685)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:26:48 werewolf kernel: reiser4[pure-ftpd-mysql(18685)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:26:48 werewolf kernel: reiser4[pure-ftpd-mysql(18685)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:33:16 werewolf kernel: reiser4[pure-ftpd-mysql(18548)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:33:16 werewolf kernel: reiser4[pure-ftpd-mysql(18548)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:33:16 werewolf kernel: reiser4[pure-ftpd-mysql(18548)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: #2 crash: Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(31716)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 13:55:42 werewolf kernel: WARNING: Wrong level found in node: 1 != 227 Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(31716)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: Sep 28 13:55:42 werewolf kernel: WARNING: Partial conversion of 4774068: 0 of 1: -5 Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(31716)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: Sep 28 13:55:42 werewolf kernel: WARNING: Failed to convert in release_unix_file (4774068) Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(1826)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 13:55:42 werewolf kernel: WARNING: Wrong level found in node: 1 != 227 Sep 28 13:55:42 werewolf kernel: reiser4[pure-ftpd-mysql(1826)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: Sep 28 13:55:42 werewolf kernel: WARNING: failure: -5 Sep 28 13:56:04 werewolf kernel: reiser4[pure-ftpd-mysql(31745)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 13:56:04 werewolf kernel: WARNING: Wrong level found in node: 1 != 227 Sep 28 13:56:04 werewolf kernel: reiser4[pure-ftpd-mysql(31745)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: Sep 28 13:56:04 werewolf kernel: WARNING: failure: -5 Sep 28 13:56:04 werewolf kernel: reiser4[pure-ftpd-mysql(31745)]: extent2tail
Full of surprises - A reiser4 story from userland
Hello all, 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. 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 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 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: This fsck thing had LIED to me; it was not read-only. It may have checked the fs read-only but it must have treacherously flipped some error bit somewhere on disk because now even 2.6.13 reiser4 refused to boot the partition properly: Warning, mounting filesystem with fatal errors, forcing read-only mount (followed by the error from above) 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. At this
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...
reiserFS error
Hi I have a Raid 5 format in reiserfs with kernel 2.6.13 Ilost 2hard diskof raid for the controller I obtained to force 1 of hard disk it filesystemdont mounted then Istarting reiserfsck with the option -- rebuild-tree finished error-free but in the hour to mount they filesystem it appears the error "Segmentation fault" [ cut here ]kernel BUG at fs/reiserfs/journal.c:3149!invalid operand: [#1]SMP Modules linked in: edd joydev sg st sr_mod ide_cd cdrom nvram ipv6 raw i2c_piix4 ohci_hcd i2c_core ibmasm sworks_agp agpgart evdev tg3 usbcore e100 mii reiserfs ext3 jbd ips sd_mod scsi_modCPU: 1EIP: 0060:[f8c48f72] Not tainted VLIEFLAGS: 00010246 (2.6.13) EIP is at journal_mark_dirty+0x1e2/0x260 [reiserfs]eax: ebx: f5ae0600 ecx: f5a74bdc edx: f510fe60esi: f5ae0600 edi: f5a74bdc ebp: f912f000 esp: f510fdecds: 007b es: 007b ss: 0068Process mount (pid: 11758, threadinfo=f510e000 task=f4481540)Stack: f5e2fab4 f510fe4c f8c5086e f510fe60 f510e000 f5ae0600 f8c48ce5 f510fe60 f5ae0600 f5e2fab4 f510fe4c f510fe60 f8c39095 f8c2ca50 f510fe4c f510fe5c f5cc3380 f4078000 Call Trace:[f8c48ce5] journal_begin+0x75/0x120 [reiserfs][f8c39095] reiserfs_fill_super+0x665/0x760 [reiserfs][f8c2ca50] reiserfs_init_locked_inode+0x0/0x10 [reiserfs][c019779e] disk_name+0x5e/0xc0[c0164ce2] get_sb_bdev+0xb2/0x120[f8c39b79] get_super_block+0x19/0x1e [reiserfs][f8c38a30] reiserfs_fill_super+0x0/0x760 [reiserfs][c0164f8a] do_kern_mount+0x9a/0x180[c017b80b] do_new_mount+0x6b/0xc0[c017bf03] do_mount+0x1b3/0x1f0[c017bc52] exact_copy_from_user+0x32/0x70[c017bce9] copy_mount_options+0x59/0xc0[c017c2d9] sys_mount+0x79/0xc0[c0102f6f] sysenter_past_esp+0x54/0x75Code: 14 89 5d 04 31 d2 83 c4 2c 89 d0 5b 5e 5f 5d c3 89 5d 08 eb ec 8d 74 26 00 83 c0 12 89 42 0c 83 45 2c 12 8b 42 08 e9 50 ff ff ff 0f 0b 4d 0c 9d 0c c5 f8 e9 3e fe ff ff 8b 45 30 ba 08 4a c5 f8 Badness in do_exit at kernel/exit.c:787[c01209d6] do_exit+0x3b6/0x3d0[c01042a1] die+0x171/0x180[c01045c0] do_invalid_op+0x0/0xa0[c0104653] do_invalid_op+0x93/0xa0[c01192b7] __wake_up_common+0x37/0x70[f8c48f72] journal_mark_dirty+0x1e2/0x260 [reiserfs][c0119328] __wake_up+0x38/0x50[c011e253] release_console_sem+0xb3/0xc0[c011e068] vprintk+0x198/0x250[f8c2cb3a] reiserfs_read_locked_inode+0xda/0x150 [reiserfs][c0103adf] error_code+0x4f/0x54[f8c48f72] journal_mark_dirty+0x1e2/0x260 [reiserfs][f8c48ce5] journal_begin+0x75/0x120 [reiserfs][f8c39095] reiserfs_fill_super+0x665/0x760 [reiserfs][f8c2ca50] reiserfs_init_locked_inode+0x0/0x10 [reiserfs][c019779e] disk_name+0x5e/0xc0[c0164ce2] get_sb_bdev+0xb2/0x120[f8c39b79] get_super_block+0x19/0x1e [reiserfs][f8c38a30] reiserfs_fill_super+0x0/0x760 [reiserfs][c0164f8a] do_kern_mount+0x9a/0x180[c017b80b] do_new_mount+0x6b/0xc0[c017bf03] do_mount+0x1b3/0x1f0[c017bc52] exact_copy_from_user+0x32/0x70[c017bce9] copy_mount_options+0x59/0xc0[c017c2d9] sys_mount+0x79/0xc0[c0102f6f] sysenter_past_esp+0x54/0x75 what I make?
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: reiser4 crashes
now it is crashing even more often, i will paste more logs, as it seems to changed a little: Sep 28 19:28:52 werewolf kernel: reiser4[pure-ftpd-mysql(7092)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: Sep 28 19:28:52 werewolf kernel: WARNING: Wrong level found in node: 1 != 111 Sep 28 19:28:52 werewolf kernel: reiser4[pure-ftpd-mysql(7092)]: make_space (fs/reiser4/carry_ops.c:497)[nikita-1065]: Sep 28 19:28:52 werewolf kernel: WARNING: Error accessing right neighbor: -5 Sep 28 19:28:52 werewolf kernel: Unable to handle kernel NULL pointer dereference at virtual address 0078 Sep 28 19:28:52 werewolf kernel: printing eip: Sep 28 19:28:52 werewolf kernel: c01b02bd Sep 28 19:28:52 werewolf kernel: *pde = Sep 28 19:28:52 werewolf kernel: Oops: [#1] Sep 28 19:28:52 werewolf kernel: Modules linked in: Sep 28 19:28:52 werewolf kernel: CPU:0 Sep 28 19:28:52 werewolf kernel: EIP:0060:[carry_on_level+169/188] Not tainted VLI Sep 28 19:28:52 werewolf kernel: EFLAGS: 00010246 (2.6.12.3juice-1) Sep 28 19:28:52 werewolf kernel: EIP is at carry_on_level+0xa9/0xbc Sep 28 19:28:52 werewolf kernel: eax: d5d53bbc ebx: d5d53c70 ecx: e2f9e180 edx: Sep 28 19:28:52 werewolf kernel: esi: edi: d5d53c74 ebp: d5d53c78 esp: d5d53bb0 Sep 28 19:28:52 werewolf kernel: ds: 007b es: 007b ss: 0068 Sep 28 19:28:52 werewolf kernel: Process pure-ftpd-mysql (pid: 7092, threadinfo=d5d52000 task=eb970a80) Sep 28 19:28:52 werewolf kernel: Stack: e2f9e180 d5d53bbc d5d53bf4 d5d53c74 d5d53bf4 d5d53c74 d5d53bf4 Sep 28 19:28:52 werewolf kernel:d5d53c20 c01b00ea d5d53c74 d5d53bf4 d5d53d28 d5d53c88 0002 Sep 28 19:28:52 werewolf kernel:0001 e9c89dc8 e9c89e48 e9a0543c e9a054a4 e9a05400 0003 Sep 28 19:28:52 werewolf kernel: Call Trace: Sep 28 19:28:52 werewolf kernel: [carry+147/445] carry+0x93/0x1bd Sep 28 19:28:52 werewolf kernel: [insert_with_carry_by_coord+184/242] insert_with_carry_by_coord+0xb8/0xf2 Sep 28 19:28:52 werewolf kernel: [insert_by_coord+173/287] insert_by_coord+0xad/0x11f Sep 28 19:28:52 werewolf kernel: [insert_new_sd+260/563] insert_new_sd+0x104/0x233 Sep 28 19:28:52 werewolf kernel: [write_sd_by_inode_common+41/182] write_sd_by_inode_common+0x29/0xb6 Sep 28 19:28:52 werewolf kernel: [create_common+36/63] create_common+0x24/0x3f Sep 28 19:28:52 werewolf kernel: [create_child_common+679/1763] create_child_common+0x2a7/0x6e3 Sep 28 19:28:52 werewolf kernel: [invoke_create_method+152/248] invoke_create_method+0x98/0xf8 Sep 28 19:28:52 werewolf kernel: [reiser4_create+72/78] reiser4_create+0x48/0x4e Sep 28 19:28:52 werewolf kernel: [vfs_create+189/233] vfs_create+0xbd/0xe9 Sep 28 19:28:52 werewolf kernel: [open_namei+1310/1476] open_namei+0x51e/0x5c4 Sep 28 19:28:52 werewolf kernel: [filp_open+59/97] filp_open+0x3b/0x61 Sep 28 19:28:52 werewolf kernel: [get_unused_fd+78/174] get_unused_fd+0x4e/0xae Sep 28 19:28:52 werewolf kernel: [sys_open+64/110] sys_open+0x40/0x6e Sep 28 19:28:52 werewolf kernel: [syscall_call+7/11] syscall_call+0x7/0xb Sep 28 19:28:52 werewolf kernel: Code: 39 e8 74 30 89 cb 89 14 24 e8 6e 03 00 00 89 c1 66 83 b8 d2 00 00 00 00 75 db 8b 90 80 00 00 00 8d 44 24 0c 89 44 24 04 89 0c 24 ff 52 78 89 c6 85 c0 74 c1 89 f0 83 c4 14 5b 5e 5f 5d c3 55 57 i have crash every 1 hour, and i already lost some databases and other random files can you please help me? is there any undelete tool for reiser4 ? (dont think its possible, but i will ask anyways) Hello, my server crashed few times latetly, and the only strange thing i found in logs, are reiser4 entries just before every crash: #1 crash: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:06 werewolf kernel: reiser4[pure-ftpd-mysql(18871)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(15867)]: cut_tree_object (fs/reiser4/tree.c:1723)[nikita-2861]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: extent2tail (fs/reiser4/plugin/file/tail_conversion.c:666)[nikita-2282]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18812)]: release_unix_file (fs/reiser4/plugin/file/file.c:2297)[nikita-3233]: kern.log:Sep 27 21:09:08 werewolf kernel: reiser4[pure-ftpd-mysql(18883)]: parse_node40 (fs/reiser4/plugin/node/node40.c:746)[nikita-494]: kern.log:Sep 27 21:09:08
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
VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the Worm/Mydoom.M virus in your email to the following recipient: - [EMAIL PROTECTED] Delivery of the email was stopped! Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the SMTP envelope originator and headers from your email: From reiserfs-list@namesys.com - BEGIN HEADERS - Received: from gate.gkd-el.de (gate.gkd-el.de [192.168.13.81]) by as.gkd-el.de (Postfix) with ESMTP id 1813E14A56A for [EMAIL PROTECTED]; Wed, 28 Sep 2005 21:03:11 +0200 (CEST) Received: by gate.gkd-el.de (Postfix, from userid 65534) id E96CC7AF4F; Wed, 28 Sep 2005 21:03:10 +0200 (CEST) Received: from wombat.core.gelsen-net.de (wombat.core.gelsen-net.de [217.70.175.40]) by gate.gkd-el.de (Postfix) with ESMTP id 832897AF4C for [EMAIL PROTECTED]; Wed, 28 Sep 2005 21:03:09 +0200 (CEST) Received: from namesys.com (muedsl-82-207-225-127.citykom.de [82.207.225.127]) by wombat.core.gelsen-net.de (8.9.1b+Sun/8.9.1) with ESMTP id VAA00469 for [EMAIL PROTECTED]; Wed, 28 Sep 2005 21:03:12 +0200 (MET DST) From: reiserfs-list@namesys.com Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mail System Error - Returned Mail Date: Wed, 28 Sep 2005 21:02:44 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0009_45AC4C85.5D16C588 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gate.gkd-el.de X-Spam-Level: *** X-Spam-Status: No, score=3.9 required=5.0 tests=BAYES_50,FORGED_MUA_OUTLOOK, NO_REAL_NAME autolearn=no version=3.0.4 -- END HEADERS --
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.
Re: reiserFS error
On 9/28/05, Augusto [EMAIL PROTECTED] wrote: I have a Raid 5 format in reiserfs with kernel 2.6.13 I lost 2 hard disk of raid for the controller I obtained to force 1 of hard disk it filesystem Raid 5 only stores one backup of data with parity, upon the loss of two disks, valueble data (e.g. metadata?) may be lost, and this is not recoverable. In the future, if there is a high chance of losing two disks at the same time, use RAID 6 (I think - it's the one that stores double parity). For now, try and recover data from one disk... maybe SpinRite (grc.com,$50) will do the trick, or a professional data recovery service, then rebuild the tree in RAID. -- ~Mike - Just my two cents - No man is an island, and no man is unable.
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
vs, can you port to 2.6.13 and put the port on our website as part of analyzing the latest patches added to the -mm series and their impact on reiser4 performance
;-) Thanks, Hans Islam Amer 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. 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.
Abolish everything you are indebted for not even paying an other cent
Do away with all you owe not even sending another dollar. Eliminate the embarrassing collection contacts. Bring to an end to the sending of payments! Wild as it may seem the majority lending establishments not following the banking laws here in the US. Mind-boggling but accurate! Visit us for thorough fine points in relation to our approach at 0.00 payment or responsibility. You have not anything to loose and lots to secure. http://uk.geocities.com/ferney_herndon/?2=2j.Get rid of all that you are indebted for not even mailing an other dollar Complete knowledge or to bring to an end obtaining or to view postal But the villagers had now decided that the boy was their enemy, and no sooner had he touched the ground than a shower of stones and sticks rained about him. Not one reached his body, however, for the Garment of Repulsion stopped their flight and returned them to rattle with more or less force against those who had thrown them--like regular boomerangs, thought Rob To receive their own blows in this fashion seemed so like magic to the simple folk that with roars of fear and pain they ran away in all directions
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.
