* Re: Reiserfs3 is crashing - where/whom to report? [not found] <49750FC1.23700.2C929@JaFojtik.seznam.cz> @ 2009-01-20 0:20 ` Edward Shishkin 2009-01-20 4:49 ` Jeff Mahoney [not found] ` <49759410.20384.D37CA@JaFojtik.seznam.cz> 0 siblings, 2 replies; 14+ messages in thread From: Edward Shishkin @ 2009-01-20 0:20 UTC (permalink / raw) To: Jaroslav Fojtik, Reiserfs mailing list; +Cc: Jeff Mahoney Hello Jaroslav, would you please check your partition with fsck, and, please, upgrade the kernel, if possible. Jeff, it seems to be BUG_ONs in the old on-demand bitmap loading code? Edward. Jaroslav Fojtik wrote: > Dears, > > please help me how to avoid this bug. It occurs on kernel 2.6.21.5 > on HDD with size 640GB and sector size 1kB. > > When sector size is set to 512B the drive cannot be mounted and a driver writes > invalid float exception. > > 2kB block size seems to work OK - but a bug is still present here until gets fixed. > > > Jan 18 20:32:30 F&T kernel: ------------[ cut here ]------------ > Jan 18 20:32:30 F&T kernel: Kernel BUG at b01b35e3 [verbose debug info unavailable] > Jan 18 20:32:30 F&T kernel: invalid opcode: 0000 [#1] > Jan 18 20:32:30 F&T kernel: SMP > Jan 18 20:32:30 F&T kernel: Modules linked in: ntfs sis900 ipv6 it87 hwmon_vid i2c_isa > i2c_core tulip bitrev atl1 crc32 mii agpgart lp parport_pc parport > Jan 18 20:32:30 F&T kernel: CPU: 1 > Jan 18 20:32:30 F&T kernel: EIP: 0060:[<b01b35e3>] Not tainted VLI > Jan 18 20:32:30 F&T kernel: EFLAGS: 00010246 (2.6.21.5 #11) > Jan 18 20:32:30 F&T kernel: EIP is at reiserfs_read_bitmap_block+0x153/0x160 > Jan 18 20:32:30 F&T kernel: eax: 00000000 ebx: f0864858 ecx: babda000 edx: babd9ffc > Jan 18 20:32:30 F&T kernel: esi: 00000000 edi: ba59e13c ebp: 00002a16 esp: e7f23bf4 > Jan 18 20:32:30 F&T kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Jan 18 20:32:30 F&T kernel: Process mc (pid: 1530, ti=e7f22000 task=e8185030 > task.ti=e7f22000) > Jan 18 20:32:30 F&T kernel: Stack: bc4c0818 00000000 b1157b20 00000001 f085a000 00000060 > 00002a16 e7f23cf4 > Jan 18 20:32:30 F&T kernel: 00001ffc b01b3aa1 00000000 0000000f 00000003 00002a16 > e7f23ecc eef22000 > Jan 18 20:32:30 F&T kernel: f0864858 00000000 013d8000 00000001 00002a16 00000015 > 00001ffc b01b44b8 > Jan 18 20:32:30 F&T kernel: Call Trace: > Jan 18 20:32:30 F&T kernel: [<b01b3aa1>] scan_bitmap_block+0x51/0x2d0 > Jan 18 20:32:30 F&T kernel: [<b01b44b8>] reiserfs_allocate_blocknrs+0x798/0x12a0 > Jan 18 20:32:30 F&T kernel: [<b01c24be>] reiserfs_file_write+0x99e/0x1e40 > Jan 18 20:32:30 F&T kernel: [<b013c5da>] clocksource_get_next+0x3a/0x40 > Jan 18 20:32:30 F&T kernel: [<b014f047>] do_generic_mapping_read+0x687/0x8c0 > Jan 18 20:32:30 F&T kernel: [<b0136a30>] autoremove_wake_function+0x0/0x40 > Jan 18 20:32:30 F&T kernel: [<b0297dba>] tty_write+0x22a/0x2e0 > Jan 18 20:32:30 F&T kernel: [<b01a5d6d>] dnotify_parent+0x3d/0x120 > Jan 18 20:32:30 F&T kernel: [<b01c1b20>] reiserfs_file_write+0x0/0x1e40 > Jan 18 20:32:30 F&T kernel: [<b0170480>] vfs_write+0xf0/0x1c0 > Jan 18 20:32:30 F&T kernel: [<b0170611>] sys_write+0x41/0x70 > Jan 18 20:32:30 F&T kernel: [<b0102e34>] syscall_call+0x7/0xb > Jan 18 20:32:30 F&T kernel: ======================= > Jan 18 20:32:30 F&T kernel: Code: c7 44 24 08 a0 e0 3e b0 c7 44 24 04 cc 51 43 b0 e8 63 > 81 01 00 eb 8e 0f 0b eb fe 8b 02 8b 40 0c 83 c0 01 8d 1c 28 e9 e7 fe ff ff <0f> 0b eb fe > 0f 0b eb fe 90 8d 74 26 00 55 89 cd 57 56 53 83 ec > Jan 18 20:32:30 F&T kernel: EIP: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160 > SS:ESP 0068:e7f23bf4 > Jan 18 20:32:30 F&T kernel: BUG: at kernel/exit.c:861 do_exit() > Jan 18 20:32:30 F&T kernel: [<b01226c7>] do_exit+0x667/0x850 > Jan 18 20:32:30 F&T kernel: [<b01048c7>] die+0x237/0x240 > Jan 18 20:32:30 F&T kernel: [<b0104ed0>] do_invalid_op+0x0/0xb0 > Jan 18 20:32:30 F&T kernel: [<b0104f72>] do_invalid_op+0xa2/0xb0 > Jan 18 20:32:30 F&T kernel: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160 > Jan 18 20:32:30 F&T kernel: [<b01951a2>] __find_get_block_slow+0x82/0x100 > Jan 18 20:32:30 F&T kernel: [<b03e5502>] io_schedule+0x22/0x30 > Jan 18 20:32:30 F&T kernel: [<b0195385>] sync_buffer+0x35/0x40 > Jan 18 20:32:30 F&T kernel: [<b03e5cd8>] __wait_on_bit+0x88/0xe0 > Jan 18 20:32:30 F&T kernel: [<b0195350>] sync_buffer+0x0/0x40 > Jan 18 20:32:30 F&T kernel: [<b0195350>] sync_buffer+0x0/0x40 > Jan 18 20:32:30 F&T kernel: [<b03e5dd8>] out_of_line_wait_on_bit+0xa8/0xc0 > Jan 18 20:32:30 F&T kernel: [<b03e706c>] error_code+0x7c/0x84 > Jan 18 20:32:30 F&T kernel: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160 > Jan 18 20:32:30 F&T kernel: [<b01b3aa1>] scan_bitmap_block+0x51/0x2d0 > Jan 18 20:32:30 F&T kernel: [<b01b44b8>] reiserfs_allocate_blocknrs+0x798/0x12a0 > Jan 18 20:32:30 F&T kernel: [<b01c24be>] reiserfs_file_write+0x99e/0x1e40 > Jan 18 20:32:30 F&T kernel: [<b013c5da>] clocksource_get_next+0x3a/0x40 > Jan 18 20:32:30 F&T kernel: [<b014f047>] do_generic_mapping_read+0x687/0x8c0 > Jan 18 20:32:30 F&T kernel: [<b0136a30>] autoremove_wake_function+0x0/0x40 > Jan 18 20:32:30 F&T kernel: [<b0297dba>] tty_write+0x22a/0x2e0 > Jan 18 20:32:30 F&T kernel: [<b01a5d6d>] dnotify_parent+0x3d/0x120 > Jan 18 20:32:30 F&T kernel: [<b01c1b20>] reiserfs_file_write+0x0/0x1e40 > Jan 18 20:32:30 F&T kernel: [<b0170480>] vfs_write+0xf0/0x1c0 > Jan 18 20:32:30 F&T kernel: [<b0170611>] sys_write+0x41/0x70 > Jan 18 20:32:30 F&T kernel: [<b0102e34>] syscall_call+0x7/0xb > Jan 18 20:32:30 F&T kernel: ======================= > Jan 18 20:39:52 F&T kernel: sanitize start > Jan 18 20:39:52 F&T kernel: sanitize end > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Reiserfs3 is crashing - where/whom to report? 2009-01-20 0:20 ` Reiserfs3 is crashing - where/whom to report? Edward Shishkin @ 2009-01-20 4:49 ` Jeff Mahoney 2009-01-20 9:09 ` Re2: " Jaroslav Fojtik [not found] ` <49759410.20384.D37CA@JaFojtik.seznam.cz> 1 sibling, 1 reply; 14+ messages in thread From: Jeff Mahoney @ 2009-01-20 4:49 UTC (permalink / raw) To: Edward Shishkin; +Cc: Jaroslav Fojtik, Reiserfs mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Shishkin wrote: > Hello Jaroslav, > would you please check your partition with fsck, > and, please, upgrade the kernel, if possible. > > Jeff, it seems to be BUG_ONs in the old on-demand > bitmap loading code? Yeah, I'd prefer to see this repeated with a recent kernel before I dig in. - -Jeff > Edward. > > Jaroslav Fojtik wrote: >> Dears, >> >> please help me how to avoid this bug. It occurs on kernel 2.6.21.5 >> on HDD with size 640GB and sector size 1kB. >> >> When sector size is set to 512B the drive cannot be mounted and a driver writes >> invalid float exception. >> >> 2kB block size seems to work OK - but a bug is still present here until gets fixed. >> >> >> Jan 18 20:32:30 F&T kernel: ------------[ cut here ]------------ >> Jan 18 20:32:30 F&T kernel: Kernel BUG at b01b35e3 [verbose debug info unavailable] >> Jan 18 20:32:30 F&T kernel: invalid opcode: 0000 [#1] >> Jan 18 20:32:30 F&T kernel: SMP >> Jan 18 20:32:30 F&T kernel: Modules linked in: ntfs sis900 ipv6 it87 hwmon_vid i2c_isa >> i2c_core tulip bitrev atl1 crc32 mii agpgart lp parport_pc parport >> Jan 18 20:32:30 F&T kernel: CPU: 1 >> Jan 18 20:32:30 F&T kernel: EIP: 0060:[<b01b35e3>] Not tainted VLI >> Jan 18 20:32:30 F&T kernel: EFLAGS: 00010246 (2.6.21.5 #11) >> Jan 18 20:32:30 F&T kernel: EIP is at reiserfs_read_bitmap_block+0x153/0x160 >> Jan 18 20:32:30 F&T kernel: eax: 00000000 ebx: f0864858 ecx: babda000 edx: babd9ffc >> Jan 18 20:32:30 F&T kernel: esi: 00000000 edi: ba59e13c ebp: 00002a16 esp: e7f23bf4 >> Jan 18 20:32:30 F&T kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 >> Jan 18 20:32:30 F&T kernel: Process mc (pid: 1530, ti=e7f22000 task=e8185030 >> task.ti=e7f22000) >> Jan 18 20:32:30 F&T kernel: Stack: bc4c0818 00000000 b1157b20 00000001 f085a000 00000060 >> 00002a16 e7f23cf4 >> Jan 18 20:32:30 F&T kernel: 00001ffc b01b3aa1 00000000 0000000f 00000003 00002a16 >> e7f23ecc eef22000 >> Jan 18 20:32:30 F&T kernel: f0864858 00000000 013d8000 00000001 00002a16 00000015 >> 00001ffc b01b44b8 >> Jan 18 20:32:30 F&T kernel: Call Trace: >> Jan 18 20:32:30 F&T kernel: [<b01b3aa1>] scan_bitmap_block+0x51/0x2d0 >> Jan 18 20:32:30 F&T kernel: [<b01b44b8>] reiserfs_allocate_blocknrs+0x798/0x12a0 >> Jan 18 20:32:30 F&T kernel: [<b01c24be>] reiserfs_file_write+0x99e/0x1e40 >> Jan 18 20:32:30 F&T kernel: [<b013c5da>] clocksource_get_next+0x3a/0x40 >> Jan 18 20:32:30 F&T kernel: [<b014f047>] do_generic_mapping_read+0x687/0x8c0 >> Jan 18 20:32:30 F&T kernel: [<b0136a30>] autoremove_wake_function+0x0/0x40 >> Jan 18 20:32:30 F&T kernel: [<b0297dba>] tty_write+0x22a/0x2e0 >> Jan 18 20:32:30 F&T kernel: [<b01a5d6d>] dnotify_parent+0x3d/0x120 >> Jan 18 20:32:30 F&T kernel: [<b01c1b20>] reiserfs_file_write+0x0/0x1e40 >> Jan 18 20:32:30 F&T kernel: [<b0170480>] vfs_write+0xf0/0x1c0 >> Jan 18 20:32:30 F&T kernel: [<b0170611>] sys_write+0x41/0x70 >> Jan 18 20:32:30 F&T kernel: [<b0102e34>] syscall_call+0x7/0xb >> Jan 18 20:32:30 F&T kernel: ======================= >> Jan 18 20:32:30 F&T kernel: Code: c7 44 24 08 a0 e0 3e b0 c7 44 24 04 cc 51 43 b0 e8 63 >> 81 01 00 eb 8e 0f 0b eb fe 8b 02 8b 40 0c 83 c0 01 8d 1c 28 e9 e7 fe ff ff <0f> 0b eb fe >> 0f 0b eb fe 90 8d 74 26 00 55 89 cd 57 56 53 83 ec >> Jan 18 20:32:30 F&T kernel: EIP: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160 >> SS:ESP 0068:e7f23bf4 >> Jan 18 20:32:30 F&T kernel: BUG: at kernel/exit.c:861 do_exit() >> Jan 18 20:32:30 F&T kernel: [<b01226c7>] do_exit+0x667/0x850 >> Jan 18 20:32:30 F&T kernel: [<b01048c7>] die+0x237/0x240 >> Jan 18 20:32:30 F&T kernel: [<b0104ed0>] do_invalid_op+0x0/0xb0 >> Jan 18 20:32:30 F&T kernel: [<b0104f72>] do_invalid_op+0xa2/0xb0 >> Jan 18 20:32:30 F&T kernel: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160 >> Jan 18 20:32:30 F&T kernel: [<b01951a2>] __find_get_block_slow+0x82/0x100 >> Jan 18 20:32:30 F&T kernel: [<b03e5502>] io_schedule+0x22/0x30 >> Jan 18 20:32:30 F&T kernel: [<b0195385>] sync_buffer+0x35/0x40 >> Jan 18 20:32:30 F&T kernel: [<b03e5cd8>] __wait_on_bit+0x88/0xe0 >> Jan 18 20:32:30 F&T kernel: [<b0195350>] sync_buffer+0x0/0x40 >> Jan 18 20:32:30 F&T kernel: [<b0195350>] sync_buffer+0x0/0x40 >> Jan 18 20:32:30 F&T kernel: [<b03e5dd8>] out_of_line_wait_on_bit+0xa8/0xc0 >> Jan 18 20:32:30 F&T kernel: [<b03e706c>] error_code+0x7c/0x84 >> Jan 18 20:32:30 F&T kernel: [<b01b35e3>] reiserfs_read_bitmap_block+0x153/0x160 >> Jan 18 20:32:30 F&T kernel: [<b01b3aa1>] scan_bitmap_block+0x51/0x2d0 >> Jan 18 20:32:30 F&T kernel: [<b01b44b8>] reiserfs_allocate_blocknrs+0x798/0x12a0 >> Jan 18 20:32:30 F&T kernel: [<b01c24be>] reiserfs_file_write+0x99e/0x1e40 >> Jan 18 20:32:30 F&T kernel: [<b013c5da>] clocksource_get_next+0x3a/0x40 >> Jan 18 20:32:30 F&T kernel: [<b014f047>] do_generic_mapping_read+0x687/0x8c0 >> Jan 18 20:32:30 F&T kernel: [<b0136a30>] autoremove_wake_function+0x0/0x40 >> Jan 18 20:32:30 F&T kernel: [<b0297dba>] tty_write+0x22a/0x2e0 >> Jan 18 20:32:30 F&T kernel: [<b01a5d6d>] dnotify_parent+0x3d/0x120 >> Jan 18 20:32:30 F&T kernel: [<b01c1b20>] reiserfs_file_write+0x0/0x1e40 >> Jan 18 20:32:30 F&T kernel: [<b0170480>] vfs_write+0xf0/0x1c0 >> Jan 18 20:32:30 F&T kernel: [<b0170611>] sys_write+0x41/0x70 >> Jan 18 20:32:30 F&T kernel: [<b0102e34>] syscall_call+0x7/0xb >> Jan 18 20:32:30 F&T kernel: ======================= >> Jan 18 20:39:52 F&T kernel: sanitize start >> Jan 18 20:39:52 F&T kernel: sanitize end >> >> >> > - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl1V+YACgkQLPWxlyuTD7JcVgCeNhmvS/PGcNWDXU9yBOmVRAo4 pzEAn199vrJ+DFse5E2j1xpIl07SDxsM =au8o -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re2: Reiserfs3 is crashing - where/whom to report? 2009-01-20 4:49 ` Jeff Mahoney @ 2009-01-20 9:09 ` Jaroslav Fojtik 0 siblings, 0 replies; 14+ messages in thread From: Jaroslav Fojtik @ 2009-01-20 9:09 UTC (permalink / raw) To: Jeff Mahoney, Reiserfs mailing list Dear Jeff Mahoney, > > Jeff, it seems to be BUG_ONs in the old on-demand > > bitmap loading code? > > Yeah, I'd prefer to see this repeated with a recent kernel before I dig in. Basically I CAN do this for you, if linux-2.6.21.5 is not recent enough. Jara ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <49759410.20384.D37CA@JaFojtik.seznam.cz>]
* Re: Re2: Reiserfs3 is crashing - where/whom to report? [not found] ` <49759410.20384.D37CA@JaFojtik.seznam.cz> @ 2009-01-20 10:45 ` Edward Shishkin 2009-01-20 14:54 ` Jeff Mahoney 0 siblings, 1 reply; 14+ messages in thread From: Edward Shishkin @ 2009-01-20 10:45 UTC (permalink / raw) To: Jaroslav Fojtik; +Cc: Jeff Mahoney, Reiserfs mailing list Jaroslav Fojtik wrote: > Dear Shishkin, > > >> would you please check your partition with fsck, >> and, please, upgrade the kernel, if possible. >> > Yes, I can. Now I have a new format of HDD, so fschk is meaningless. > If it is neccessary, I could reproduce a bug again, change format > (mkreiserfs) and do a hard load until reiserfs crash. Do you want > me to do this? > HDD is still clean and free for experiments. After while, I will > use HDD for regular data storage. > > I am using linux-2.6.21.5 now. I cannot upgrade to >linux-2.6.24.7, > because MadWiFi stops to be compiled. > > Ok, please, have the 2.6.24.7 kernel and reiserfsprogs-3.6.21 to format a partition: http://www.kernel.org/pub/linux/utils/fs/reiserfs/reiserfsprogs-3.6.21.tar.gz Catch all kernel messages and describe steps to reproduce the crash. Thanks, Edward. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re2: Reiserfs3 is crashing - where/whom to report? 2009-01-20 10:45 ` Edward Shishkin @ 2009-01-20 14:54 ` Jeff Mahoney 2009-01-20 17:49 ` Re4: " Jaroslav Fojtik 0 siblings, 1 reply; 14+ messages in thread From: Jeff Mahoney @ 2009-01-20 14:54 UTC (permalink / raw) To: Edward Shishkin; +Cc: Jaroslav Fojtik, Reiserfs mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Shishkin wrote: > Jaroslav Fojtik wrote: >> Dear Shishkin, >> >> >>> would you please check your partition with fsck, >>> and, please, upgrade the kernel, if possible. >>> >> Yes, I can. Now I have a new format of HDD, so fschk is meaningless. >> If it is neccessary, I could reproduce a bug again, change format >> (mkreiserfs) and do a hard load until reiserfs crash. Do you want >> me to do this? >> HDD is still clean and free for experiments. After while, I will >> use HDD for regular data storage. >> >> I am using linux-2.6.21.5 now. I cannot upgrade to >linux-2.6.24.7, >> because MadWiFi stops to be compiled. >> >> > > Ok, please, have the 2.6.24.7 kernel and reiserfsprogs-3.6.21 > to format a partition: > http://www.kernel.org/pub/linux/utils/fs/reiserfs/reiserfsprogs-3.6.21.tar.gz > Catch all kernel messages and describe steps to reproduce the crash. Since reiserfsprogs 3.6.21 doesn't support block sizes < 4k, he'll be unable to. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl15Y0ACgkQLPWxlyuTD7J4NwCeJZIE14DxckwOYs/bmKNZyGcu PGYAniu8tNmqTlGP0DOKG92vR98uqgzy =syVJ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re4: Reiserfs3 is crashing - where/whom to report? 2009-01-20 14:54 ` Jeff Mahoney @ 2009-01-20 17:49 ` Jaroslav Fojtik 2009-01-20 18:19 ` Edward Shishkin 0 siblings, 1 reply; 14+ messages in thread From: Jaroslav Fojtik @ 2009-01-20 17:49 UTC (permalink / raw) To: Jeff Mahoney, Reiserfs mailing list; +Cc: Edward Shishkin Dear Jeff Mahoney, > > Ok, please, have the 2.6.24.7 kernel and reiserfsprogs-3.6.21 > > to format a partition: > > http://www.kernel.org/pub/linux/utils/fs/reiserfs/reiserfsprogs-3.6.21.tar.gz > > Catch all kernel messages and describe steps to reproduce the crash. > > Since reiserfsprogs 3.6.21 doesn't support block sizes < 4k, he'll be > unable to. I would like to ask you - I have made windiff 3.6.19 and 3.6.21 and I have noted several changes. I can comment this piece of code if you really want to catch and fix a problem found: } else if (blocksize < 4096) { reiserfs_warning (stderr, "Block sizes smaller than 4k " "are not supported.\n"); return 0; } I do not know why these block sizes has been disabled - stability? speed? Overflowing block count? Anyway, nothing warned me when I have installed Slackware and build and mount riserfs disk of this kind. Jara ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re4: Reiserfs3 is crashing - where/whom to report? 2009-01-20 17:49 ` Re4: " Jaroslav Fojtik @ 2009-01-20 18:19 ` Edward Shishkin 2009-01-20 18:49 ` Re6: " Jaroslav Fojtik 0 siblings, 1 reply; 14+ messages in thread From: Edward Shishkin @ 2009-01-20 18:19 UTC (permalink / raw) To: Jaroslav Fojtik; +Cc: Jeff Mahoney, Reiserfs mailing list Jaroslav Fojtik wrote: > Dear Jeff Mahoney, > > >>> Ok, please, have the 2.6.24.7 kernel and reiserfsprogs-3.6.21 >>> to format a partition: >>> http://www.kernel.org/pub/linux/utils/fs/reiserfs/reiserfsprogs-3.6.21.tar.gz >>> Catch all kernel messages and describe steps to reproduce the crash. >>> >> Since reiserfsprogs 3.6.21 doesn't support block sizes < 4k, he'll be >> unable to. >> > > I would like to ask you - I have made windiff 3.6.19 and 3.6.21 and I have noted > several changes. > > I can comment this piece of code if you really want to catch and fix > a problem found: > } else if (blocksize < 4096) { > reiserfs_warning (stderr, "Block sizes smaller than 4k " > "are not supported.\n"); > return 0; > } > > I do not know why these block sizes has been disabled - stability? speed? > Overflowing block count? > http://bugzilla.kernel.org/show_bug.cgi?id=9108 Reiserfs has never worked properly with small blocksizes, and it was unpleasant surprise when I saw that it is enabled again in reiserfsprogs-3.6.19. IMHO there is no chances to make reiserfs work with 512K blocks. Other cases should be carefully debugged. Put in longterm todo. Edward. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re6: Reiserfs3 is crashing - where/whom to report? 2009-01-20 18:19 ` Edward Shishkin @ 2009-01-20 18:49 ` Jaroslav Fojtik 2009-01-20 18:54 ` Edward Shishkin 0 siblings, 1 reply; 14+ messages in thread From: Jaroslav Fojtik @ 2009-01-20 18:49 UTC (permalink / raw) To: Edward Shishkin, Jeff Mahoney, Reiserfs mailing list Dear Edward, > > I do not know why these block sizes has been disabled - stability? speed? > > Overflowing block count? > > > http://bugzilla.kernel.org/show_bug.cgi?id=9108 > > Reiserfs has never worked properly with small blocksizes, and it was > unpleasant surprise when I saw that it is enabled again in > reiserfsprogs-3.6.19. > IMHO there is no chances to make reiserfs work with 512K blocks. Never mind. > Other cases should be carefully debugged. Put in longterm todo. OK. And make it sense for you to make a test on my HDD with blocksize 1024 and report you a problem? At least one known crash could be avoided. Jara ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re6: Reiserfs3 is crashing - where/whom to report? 2009-01-20 18:49 ` Re6: " Jaroslav Fojtik @ 2009-01-20 18:54 ` Edward Shishkin 2009-01-20 21:20 ` Re8: " Jaroslav Fojtik 0 siblings, 1 reply; 14+ messages in thread From: Edward Shishkin @ 2009-01-20 18:54 UTC (permalink / raw) To: Jaroslav Fojtik; +Cc: Jeff Mahoney, Reiserfs mailing list Jaroslav Fojtik wrote: > Dear Edward, > > >>> I do not know why these block sizes has been disabled - stability? speed? >>> Overflowing block count? >>> >>> >> http://bugzilla.kernel.org/show_bug.cgi?id=9108 >> >> Reiserfs has never worked properly with small blocksizes, and it was >> unpleasant surprise when I saw that it is enabled again in >> reiserfsprogs-3.6.19. >> > > >> IMHO there is no chances to make reiserfs work with 512K blocks. >> > Never mind. > > >> Other cases should be carefully debugged. Put in longterm todo. >> > OK. > > And make it sense for you to make a test on my HDD with blocksize 1024 > "HDD with blocksize" is a poor phrase. HDD has a property "sector size". Blocksize is a property of filesystem. > and report you a problem? At least one known crash could be avoided. > No, it doesn't, if you mean to reproduce a crash with reiserfs formatted by "mkreiserfs -b 1024": I know how to reproduce it. Thanks. Edward. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re8: Reiserfs3 is crashing - where/whom to report? 2009-01-20 18:54 ` Edward Shishkin @ 2009-01-20 21:20 ` Jaroslav Fojtik 2009-01-20 23:07 ` Jeff Mahoney 0 siblings, 1 reply; 14+ messages in thread From: Jaroslav Fojtik @ 2009-01-20 21:20 UTC (permalink / raw) To: Edward Shishkin, Jeff Mahoney, Reiserfs mailing list Dear Edward, > "HDD with blocksize" is a poor phrase. HDD has a property "sector size". > Blocksize is a property of filesystem. Sorry. I mean HDD with filesystem with blocksize. > No, it doesn't, if you mean to reproduce a crash with reiserfs > formatted by "mkreiserfs -b 1024": I know how to reproduce it. Now it is clean. It was a very stupid thing to allow unstable stuff in reiserfs in public without any warning and pretend that everything is OK. Jara ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re8: Reiserfs3 is crashing - where/whom to report? 2009-01-20 21:20 ` Re8: " Jaroslav Fojtik @ 2009-01-20 23:07 ` Jeff Mahoney 2009-01-21 19:34 ` Re10: " Jaroslav Fojtik 0 siblings, 1 reply; 14+ messages in thread From: Jeff Mahoney @ 2009-01-20 23:07 UTC (permalink / raw) To: Jaroslav Fojtik; +Cc: Edward Shishkin, Reiserfs mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jaroslav Fojtik wrote: > Dear Edward, > >> "HDD with blocksize" is a poor phrase. HDD has a property "sector size". >> Blocksize is a property of filesystem. > Sorry. I mean HDD with filesystem with blocksize. > > >> No, it doesn't, if you mean to reproduce a crash with reiserfs >> formatted by "mkreiserfs -b 1024": I know how to reproduce it. > Now it is clean. > > It was a very stupid thing to allow unstable stuff in reiserfs in public > without any warning and pretend that everything is OK. Why would you want a file system with a different block size anyway? 4k is nearly universal as a block size, and it also happens to match the page size on most linux systems. Going down just slows your system down. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl2WSIACgkQLPWxlyuTD7LYpwCfbNAOFJIuv6o8Ne+EVINatarG 110An28wbBerkf4OFLTQPm73qIIIpsZY =EP2n -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re10: Reiserfs3 is crashing - where/whom to report? 2009-01-20 23:07 ` Jeff Mahoney @ 2009-01-21 19:34 ` Jaroslav Fojtik 2009-01-21 19:25 ` Jeff Mahoney 0 siblings, 1 reply; 14+ messages in thread From: Jaroslav Fojtik @ 2009-01-21 19:34 UTC (permalink / raw) To: Jeff Mahoney, Edward Shishkin, Reiserfs mailing list [-- Attachment #1: Mail message body --] [-- Type: text/plain, Size: 648 bytes --] Dear Jeff, > Why would you want a file system with a different block size anyway? 4k > is nearly universal as a block size, and it also happens to match the > page size on most linux systems. Going down just slows your system down. It is over, because it does not work. Do not worry. Please have a look at attached image. It shows how many wasted space is generated by larger block sizes on 32GB hard drive with around 20GB data. So I assume 7GB of wasted space for my HDD. I am planning reiserfs just because startup time. Ext2 with 20GB needs sometimes more than one hour to be checked up. I am afraid of 32 hours running ext2fsck. Jara [-- Attachment #2: Free_blk_space.jpg --] [-- Type: Image/JPEG, Size: 46243 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re10: Reiserfs3 is crashing - where/whom to report? 2009-01-21 19:34 ` Re10: " Jaroslav Fojtik @ 2009-01-21 19:25 ` Jeff Mahoney 2009-01-27 21:30 ` Re12: " Jaroslav Fojtik 0 siblings, 1 reply; 14+ messages in thread From: Jeff Mahoney @ 2009-01-21 19:25 UTC (permalink / raw) To: Jaroslav Fojtik; +Cc: Edward Shishkin, Reiserfs mailing list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jaroslav Fojtik wrote: > Dear Jeff, > >> Why would you want a file system with a different block size anyway? 4k >> is nearly universal as a block size, and it also happens to match the >> page size on most linux systems. Going down just slows your system down. > It is over, because it does not work. Do not worry. > > Please have a look at attached image. It shows how many wasted space is > generated by larger block sizes on 32GB hard drive with around 20GB data. > So I assume 7GB of wasted space for my HDD. > > I am planning reiserfs just because startup time. Ext2 with 20GB needs > sometimes more than one hour to be checked up. I am afraid of 32 hours > running ext2fsck. Well then I have good news for you. That graph is for fat32, which is really really dumb in the way it does allocations. Reiserfs does "tail packing," which allows us to pack data in with metadata, eliminating most of the waste that you're afraid of. In fact, by choosing a smaller block size, you actually waste *more* space since more metadata is needed to describe it, and each of those metadata blocks needs a portion of it for headers, etc. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl3dqQACgkQLPWxlyuTD7KOdwCgoPs3UxgdETHZ5p4D/czIqV1I Jr4AoIA6QFySoLr5OaRsHawTbTD4GDzd =HRr2 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re12: Reiserfs3 is crashing - where/whom to report? 2009-01-21 19:25 ` Jeff Mahoney @ 2009-01-27 21:30 ` Jaroslav Fojtik 0 siblings, 0 replies; 14+ messages in thread From: Jaroslav Fojtik @ 2009-01-27 21:30 UTC (permalink / raw) To: Jeff Mahoney, Edward Shishkin, Reiserfs mailing list Dear Jeff, > Well then I have good news for you. That graph is for fat32, which is > really really dumb in the way it does allocations. Reiserfs does "tail > packing," which allows us to pack data in with metadata, eliminating > most of the waste that you're afraid of. In fact, by choosing a smaller > block size, you actually waste *more* space since more metadata is > needed to describe it, and each of those metadata blocks needs a portion > of it for headers, etc. Thank you very much for your promising info. I have tested full reiserfs file check and 640GB has been checked in 20mins and this check is not necessary. It is a good job in comparison with ext2 where 20GB check spends 2 hours. But I still believe that there must be some dependency between allocation units and wasted space. I guess that one allocation unit could accommodate one short file but looking here: http://homes.cerias.purdue.edu/~florian/reiser/reiserfs.php it does not neccesary to be a case. thanks for explanation Jara > > - -Jeff > > - -- > Jeff Mahoney > SUSE Labs > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iEYEARECAAYFAkl3dqQACgkQLPWxlyuTD7KOdwCgoPs3UxgdETHZ5p4D/czIqV1I > Jr4AoIA6QFySoLr5OaRsHawTbTD4GDzd > =HRr2 > -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-01-27 21:30 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <49750FC1.23700.2C929@JaFojtik.seznam.cz>
2009-01-20 0:20 ` Reiserfs3 is crashing - where/whom to report? Edward Shishkin
2009-01-20 4:49 ` Jeff Mahoney
2009-01-20 9:09 ` Re2: " Jaroslav Fojtik
[not found] ` <49759410.20384.D37CA@JaFojtik.seznam.cz>
2009-01-20 10:45 ` Edward Shishkin
2009-01-20 14:54 ` Jeff Mahoney
2009-01-20 17:49 ` Re4: " Jaroslav Fojtik
2009-01-20 18:19 ` Edward Shishkin
2009-01-20 18:49 ` Re6: " Jaroslav Fojtik
2009-01-20 18:54 ` Edward Shishkin
2009-01-20 21:20 ` Re8: " Jaroslav Fojtik
2009-01-20 23:07 ` Jeff Mahoney
2009-01-21 19:34 ` Re10: " Jaroslav Fojtik
2009-01-21 19:25 ` Jeff Mahoney
2009-01-27 21:30 ` Re12: " Jaroslav Fojtik
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.