Re: Reiserfs3 is crashing - where/whom to report?

Re: Reiserfs3 is crashing - where/whom to report?

[Edward Shishkin]

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
>
>
>   

Re: Reiserfs3 is crashing - where/whom to report?

[Jeff Mahoney]

-----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-----

Re2: Reiserfs3 is crashing - where/whom to report?

[Jaroslav Fojtik]

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

Re: Re2: Reiserfs3 is crashing - where/whom to report?

[Edward Shishkin]

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.

Re: Re2: Reiserfs3 is crashing - where/whom to report?

[Jeff Mahoney]

-----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-----

Re4: Reiserfs3 is crashing - where/whom to report?

[Jaroslav Fojtik]

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

Re: Re4: Reiserfs3 is crashing - where/whom to report?

[Edward Shishkin]

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.

Re6: Reiserfs3 is crashing - where/whom to report?

[Jaroslav Fojtik]

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

Re: Re6: Reiserfs3 is crashing - where/whom to report?

[Edward Shishkin]

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.

Re8: Reiserfs3 is crashing - where/whom to report?

[Jaroslav Fojtik]

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

Re: Re8: Reiserfs3 is crashing - where/whom to report?

[Jeff Mahoney]

-----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-----

Re: Re10: Reiserfs3 is crashing - where/whom to report?

[Jeff Mahoney]

-----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-----

Re10: Reiserfs3 is crashing - where/whom to report?

[Jaroslav Fojtik]

[-- 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 --]

Re12: Reiserfs3 is crashing - where/whom to report?

[Jaroslav Fojtik]

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-----