reiserfsprogs 3.6.5-pre2 release.

reiserfsprogs 3.6.5-pre2 release.

[Vitaly Fertman]

Hi all!

this new pre-release includes:

- a critical bug on pass0 of rebuild-tree with overflowing while checking 
unformatted item offsets was fixed.
- a bug in relocation of shared object id - entry key sometimes does not 
get updated correctly with the new key - was fixed.
- a bug in bitops operations for be mashins was fixed. 
- a bug with the superblock overwriting during replaying was fixed.

- while openning the journal check that journal parameters in the superblock 
and in the journal header mathches; advice to run rebuild-sb if not. While 
rebuilding the superblock, do the same check and ask the user if he wants to 
rebuild the journal header or continue w/out the journal or he wants to change 
the start of the partition before using reiserfsck.
- check that all not valid bits of the bitmap are set to 1, set it correctly. 

- fix-fixable does not relocate shared object ids anymore, as it is too complex 
for fix-fixable and only rebuild-tree does.

- reiserfsck -a (started at boot) replays journal, checks error flags in 
the superblock, bitmaps, fs size, 2 levels of internal tree and switches 
to fixble mode if any problem is detected. For root fs fixable cannot be 
performed (as fs is mounted) and just --check will be done.

- Journal replay was improved a) check blocks if they could be journable 
before replaying; b) replay only transactions which has trans_id == last 
replayed transaction trans_id + 1.

- warning messages were improved.

-- 

Thanks,
Vitaly Fertman

Re: reiserfsprogs 3.6.5-pre2 release.

[Vitaly Fertman]

On Tuesday 25 February 2003 16:50, Vitaly Fertman wrote:
> Hi all!
>
> - a critical bug on pass0 of rebuild-tree with overflowing while checking
> unformatted item offsets was fixed.
>
> - reiserfsck -a (started at boot) replays journal, checks error flags in
> the superblock, bitmaps, fs size, 2 levels of internal tree and switches
> to fixble mode if any problem is detected. For root fs fixable cannot be
> performed (as fs is mounted) and just --check will be done.

As the pre release has one critical bug fixed and we would like to make it
a new release as soon as possible, any test of how rebuild-tree works on
filesystems with big files is appreciated.

Also, it would be interesting to know how much time does reiserfsck -a take
on big arrays. So if you have a such, try it also please. I mean, on consistent
filsystems, otherwise reiserfsck will switch to the fix-fixable mode.

-- 

Thanks,
Vitaly Fertman

RE: reiserfsprogs 3.6.5-pre2 release.

[berthiaume_wayne]

	Vitaly, how does "check-followed-by-fixable" in 3.6.3 compare to
"-a" at boot in 3.6.5? 
Regards,
Wayne.

-----Original Message-----
From: Vitaly Fertman [mailto:vitaly@namesys.com]
Sent: Tuesday, February 25, 2003 8:50 AM
To: reiserfs-list@namesys.com
Subject: reiserfsprogs 3.6.5-pre2 release.



Hi all!

this new pre-release includes:

- a critical bug on pass0 of rebuild-tree with overflowing while checking 
unformatted item offsets was fixed.
- a bug in relocation of shared object id - entry key sometimes does not 
get updated correctly with the new key - was fixed.
- a bug in bitops operations for be mashins was fixed. 
- a bug with the superblock overwriting during replaying was fixed.

- while openning the journal check that journal parameters in the superblock

and in the journal header mathches; advice to run rebuild-sb if not. While 
rebuilding the superblock, do the same check and ask the user if he wants to

rebuild the journal header or continue w/out the journal or he wants to
change 
the start of the partition before using reiserfsck.
- check that all not valid bits of the bitmap are set to 1, set it
correctly. 

- fix-fixable does not relocate shared object ids anymore, as it is too
complex 
for fix-fixable and only rebuild-tree does.

- reiserfsck -a (started at boot) replays journal, checks error flags in 
the superblock, bitmaps, fs size, 2 levels of internal tree and switches 
to fixble mode if any problem is detected. For root fs fixable cannot be 
performed (as fs is mounted) and just --check will be done.

- Journal replay was improved a) check blocks if they could be journable 
before replaying; b) replay only transactions which has trans_id == last 
replayed transaction trans_id + 1.

- warning messages were improved.

-- 

Thanks,
Vitaly Fertman

Re: reiserfsprogs 3.6.5-pre2 release.

[Vitaly Fertman]

On Tuesday 25 February 2003 19:25, berthiaume_wayne@emc.com wrote:
> Vitaly, how does "check-followed-by-fixable" in 3.6.3 compare to
> "-a" at boot in 3.6.5?

First, 3.6.3 is quite old version and many bugs were fixed since then,
you should update it.

When you run reiserfsck-3.6.5-pre2 -a, it does a few light-weight checks
- check some fields in the super block, replay the journal, bitmap, if 
the last block of the fs is readable, and just 2 upper levels of internal 
tree are checked. It is supposed to take not more then a few seconds.

reiserfsck in check mode goes through the whole internal tree, not just 
2 levels, checking nodes structure and links between them, and then (if 
there is no fatal corruptions) does semantic check - goes through the 
whole tree of directories checking them and checking all files. 
This takes more time.

-- 

Thanks,
Vitaly Fertman

Re: reiserfsprogs 3.6.5-pre2 release.

[Philippe Gramoullé]

Hi Vitaly,

here is an output of reiserfsck -a on a ~550 Gb Raid5 array filled about 60%.

# df /dev/sdb1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1            572418604 335826568 236592036  59% /prod


#  reiserfsck -V

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.6.5-pre2


# time reiserfsck -a /dev/sdb1
Reiserfs super block in block 16 on 0x811 of format 3.6 with standard journal
Blocks (total/free): 143109020/59148009 by 4096 bytes
Filesystem is cleanly umounted
Replaying journal..
0 transactions replayed
Checking internal tree..finished                  

real    0m47.890s
user    0m6.668s
sys     0m0.732s

Hope that helps.

Thanks,

Philippe


On Tue, 25 Feb 2003 17:12:45 +0300
Vitaly Fertman <vitaly@namesys.com> wrote:


  |  Also, it would be interesting to know how much time does reiserfsck -a take
  |   on big arrays. So if you have a such, try it also please. I mean, on consistent
  |   filsystems, otherwise reiserfsck will switch to the fix-fixable mode.

-- 

Philippe Gramoullé
philippe.gramoulle@mmania.com
Lycos Europe - NOC France

Re: reiserfsprogs 3.6.5-pre2 release.

[Oleg Drokin]

Hello!

On Wed, Feb 26, 2003 at 01:54:48AM +0100, Philippe Gramoull? wrote:
> # time reiserfsck -a /dev/sdb1
> Reiserfs super block in block 16 on 0x811 of format 3.6 with standard journal
> Blocks (total/free): 143109020/59148009 by 4096 bytes
> Filesystem is cleanly umounted
> Replaying journal..
> 0 transactions replayed
> Checking internal tree..finished                  
> real    0m47.890s
> user    0m6.668s
> sys     0m0.732s

Thanks for trying.
48 seconds is much longer than we expected such test should take.
Was the system loaded at the time of test?

Bye,
    Oleg

Re: reiserfsprogs 3.6.5-pre2 release.

[Philippe Gramoullé]

Hi,

On Wed, 26 Feb 2003 10:29:34 +0300
Oleg Drokin <green@namesys.com> wrote:


  |  Hello!
  |  
  |  On Wed, Feb 26, 2003 at 01:54:48AM +0100, Philippe Gramoull? wrote:
  |  > # time reiserfsck -a /dev/sdb1
  |  > Reiserfs super block in block 16 on 0x811 of format 3.6 with standard journal
  |  > Blocks (total/free): 143109020/59148009 by 4096 bytes
  |  > Filesystem is cleanly umounted
  |  > Replaying journal..
  |  > 0 transactions replayed
  |  > Checking internal tree..finished                  
  |  > real    0m47.890s
  |  > user    0m6.668s
  |  > sys     0m0.732s
  |  
  |  Thanks for trying.
  |  48 seconds is much longer than we expected such test should take.
  |  Was the system loaded at the time of test?

The system was idle, doing absolutely nothing.

Thanks,

Philippe

Re: reiserfsprogs 3.6.5-pre2 release.

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Wed, Feb 26, 2003 at 01:54:48AM +0100, Philippe Gramoull? wrote:
>  
>
>># time reiserfsck -a /dev/sdb1
>>Reiserfs super block in block 16 on 0x811 of format 3.6 with standard journal
>>Blocks (total/free): 143109020/59148009 by 4096 bytes
>>Filesystem is cleanly umounted
>>Replaying journal..
>>0 transactions replayed
>>Checking internal tree..finished                  
>>real    0m47.890s
>>user    0m6.668s
>>sys     0m0.732s
>>    
>>
>
>Thanks for trying.
>48 seconds is much longer than we expected such test should take.
>Was the system loaded at the time of test?
>
>Bye,
>    Oleg
>
>
>  
>
Yes, 48 seconds is too long to be acceptable.

-- 
Hans

Re: reiserfsprogs 3.6.5-pre2 release.

[Anders Widman]

>>># time reiserfsck -a /dev/sdb1
>>>Reiserfs super block in block 16 on 0x811 of format 3.6 with standard journal
>>>Blocks (total/free): 143109020/59148009 by 4096 bytes
>>>Filesystem is cleanly umounted
>>>Replaying journal..
>>>0 transactions replayed
>>>Checking internal tree..finished                  
>>>real    0m47.890s
>>>user    0m6.668s
>>>sys     0m0.732s
>>>    
>>>
>>
>>Thanks for trying.
>>48 seconds is much longer than we expected such test should take.
>>Was the system loaded at the time of test?
>>
> Yes, 48 seconds is too long to be acceptable.

Would it be possible to lower the time it takes to mount a filesystem?
Currently it takes about 48s to mount my fs:

  time mount /dev/Server/FTPRoot /glftpd/site -o noatime

  real    0m48.906s
  user    0m0.000s
  sys     0m0.090s

  Filesystem            Size  Used Avail Use% Mounted on
  /dev/Server/FTPRoot   744G  723G   21G  98% /glftpd/site


~ Anders

Re: reiserfsprogs 3.6.5-pre2 release.

[Oleg Drokin]

Hello!

On Wed, Feb 26, 2003 at 01:14:25PM +0100, Anders Widman wrote:
> >>># time reiserfsck -a /dev/sdb1
> >>>Reiserfs super block in block 16 on 0x811 of format 3.6 with standard journal
> >>>Blocks (total/free): 143109020/59148009 by 4096 bytes
> >>>Filesystem is cleanly umounted
> >>>Replaying journal..
> >>>0 transactions replayed
> >>>Checking internal tree..finished                  
> >>>real    0m47.890s
> >>>user    0m6.668s
> >>>sys     0m0.732s
> >>Thanks for trying.
> >>48 seconds is much longer than we expected such test should take.
> >>Was the system loaded at the time of test?
> > Yes, 48 seconds is too long to be acceptable.
> Would it be possible to lower the time it takes to mount a filesystem?
> Currently it takes about 48s to mount my fs:

Unfortunatelly there is no easy way.
Seems that most of the time is spent reading bitmaps (one bitmap after each 128M of data),
and reiserfs reads in all the bitmaps at once during mount.

Bye,
    Oleg

Re: reiserfsprogs 3.6.5-pre2 release.

[Anders Widman]

>> Would it be possible to lower the time it takes to mount a filesystem?
>> Currently it takes about 48s to mount my fs:

> Unfortunatelly there is no easy way.
> Seems that most of the time is spent reading bitmaps (one bitmap after each 128M of data),
> and reiserfs reads in all the bitmaps at once during mount.

I  only  posted  this  because it is discussed how to lower the bootup
time. The fsck might take a few seconds when optimised, but the actual
mount of the FS takes much longer.

How  big  is  each  block  of bitmaps that is being read during mount?
Would  it  be  possible  to make the reads more efficient? I mean, now
there  would  be 6400 reads on a 800GB FS. From the sound of the disks
it does not seem as they work at 100% during mount?

(Actually,  in  my system it is not a problem is the boot takes 5 min,
but I can imagine many that do not like that)

~Anders

Re: reiserfsprogs 3.6.5-pre2 release.

[Oleg Drokin]

Hello!

On Wed, Feb 26, 2003 at 01:34:22PM +0100, Anders Widman wrote:
> >> Would it be possible to lower the time it takes to mount a filesystem?
> >> Currently it takes about 48s to mount my fs:
> > Unfortunatelly there is no easy way.
> > Seems that most of the time is spent reading bitmaps (one bitmap after each 128M of data),
> > and reiserfs reads in all the bitmaps at once during mount.
> I  only  posted  this  because it is discussed how to lower the bootup
> time. The fsck might take a few seconds when optimised, but the actual
> mount of the FS takes much longer.

But this is not good reason to make it even longer, what do you think?
(and blockdev cache is flushed on last device close, so mount won't get
these bitmap blocks from cache).

> How  big  is  each  block  of bitmaps that is being read during mount?

it's of blocksize size (4k for now).

> Would  it  be  possible  to make the reads more efficient? I mean, now

You still need to seek to every of them.
(Other possibility is to read bitmap blocks on 1st access, but this is not very
easy task, I'd say).

> there  would  be 6400 reads on a 800GB FS. From the sound of the disks
> it does not seem as they work at 100% during mount?

Hm. Disk cannot do anything while it is seeking. Also since the seeks are
in one direction, you won't hear any unusual noises, I believe.

Bye,
    Oleg

RE: reiserfsprogs 3.6.5-pre2 release.

[berthiaume_wayne]

	Philippe, how many files were on the partition?
Regards,
Wayne.

-----Original Message-----
From: Philippe Gramoullé [mailto:philippe.gramoulle@mmania.com]
Sent: Tuesday, February 25, 2003 7:55 PM
To: reiserfs-list@namesys.com
Subject: Re: reiserfsprogs 3.6.5-pre2 release.



Hi Vitaly,

here is an output of reiserfsck -a on a ~550 Gb Raid5 array filled about
60%.

# df /dev/sdb1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1            572418604 335826568 236592036  59% /prod


#  reiserfsck -V

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.6.5-pre2


# time reiserfsck -a /dev/sdb1
Reiserfs super block in block 16 on 0x811 of format 3.6 with standard
journal
Blocks (total/free): 143109020/59148009 by 4096 bytes
Filesystem is cleanly umounted
Replaying journal..
0 transactions replayed
Checking internal tree..finished                  

real    0m47.890s
user    0m6.668s
sys     0m0.732s

Hope that helps.

Thanks,

Philippe


On Tue, 25 Feb 2003 17:12:45 +0300
Vitaly Fertman <vitaly@namesys.com> wrote:


  |  Also, it would be interesting to know how much time does reiserfsck -a
take
  |   on big arrays. So if you have a such, try it also please. I mean, on
consistent
  |   filsystems, otherwise reiserfsck will switch to the fix-fixable mode.

-- 

Philippe Gramoullé
philippe.gramoulle@mmania.com
Lycos Europe - NOC France

Re: reiserfsprogs 3.6.5-pre2 release.

[Vitaly Fertman]

On Wednesday 26 February 2003 18:12, berthiaume_wayne@emc.com wrote:
> Philippe, how many files were on the partition?
> Regards,
> Wayne.

Hi,

tests shown that almost all the time was spent on reading bitmap blocks.
And the same reading is done at mount time actually.

-- 

Thanks,
Vitaly Fertman

> Hi Vitaly,
>
> here is an output of reiserfsck -a on a ~550 Gb Raid5 array filled about
> 60%.
>
> # df /dev/sdb1
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/sdb1            572418604 335826568 236592036  59% /prod
>
>
> #  reiserfsck -V
>
> <-------------reiserfsck, 2002------------->
> reiserfsprogs 3.6.5-pre2
>
>
> # time reiserfsck -a /dev/sdb1
> Reiserfs super block in block 16 on 0x811 of format 3.6 with standard
> journal
> Blocks (total/free): 143109020/59148009 by 4096 bytes
> Filesystem is cleanly umounted
> Replaying journal..
> 0 transactions replayed
> Checking internal tree..finished
>
> real    0m47.890s
> user    0m6.668s
> sys     0m0.732s
>
> Hope that helps.
>
> Thanks,
>
> Philippe
>

Re: reiserfsprogs 3.6.5-pre2 release.

[Hans Reiser]

Vitaly Fertman wrote:

>Hi,
>
>tests shown that almost all the time was spent on reading bitmap blocks.
>And the same reading is done at mount time actually.
>
>  
>
Hmmm, I wonder if it is really making all the drives work actively when 
reading those bitmaps, or if instead something needing optimizing is 
happening?

If it is the bitmap blocks that are taking the 48 seconds, then your 
recent changes are acceptable.

-- 
Hans

Re: reiserfsprogs 3.6.5-pre2 release.

[Andreas Dilger]

On Feb 26, 2003  19:14 +0300, Vitaly Fertman wrote:
> tests shown that almost all the time was spent on reading bitmap blocks.
> And the same reading is done at mount time actually.

It would be interesting to see if reiserfsck immediately followed by mount
(which is the normal boot behaviour) takes any longer than just the mount.
If not, then the added checks in reiserfsck are good and don't hurt anything,
since you have to read the bitmap blocks from disk anyways.

Oleg posted that the block device cache is flushed upon last close, but I
don't think that is totally true.  It _was_ true for a short while, but
it was rather annoying and I think Al Viro fixed that so that the block
device cache was "lazily" dropped, so you would keep it if you re-opened
the device shortly after closing it.

I suppose the other way to test it would be to run 2 "reiserfsck -a"
in a row.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: reiserfsprogs 3.6.5-pre2 release.

[Philippe Gramoullé]

Hi,

Well, the first reiserfsck run (with mount/umount done before) took
48sec/49sec , subsequent runs took about 45sec/46sec.

Thanks,

Philippe

On Wed, 26 Feb 2003 12:21:44 -0700
Andreas Dilger <adilger@clusterfs.com> wrote:


  |  I suppose the other way to test it would be to run 2 "reiserfsck -a"
  |   in a row.

-- 

Philippe Gramoullé
philippe.gramoulle@mmania.com
Lycos Europe - NOC France

Re: reiserfsprogs 3.6.5-pre2 release.

[Anders Widman]

> Hi,
> tests shown that almost all the time was spent on reading bitmap blocks.
> And the same reading is done at mount time actually.

  The   time  it  takes  to fsck a volume is probably only annoying on
  large arrays of disks running LVM or spanned disk setup. Would it be
  possible to read bitmaps from all physical drives at the same time?

  ~ Anders

Re: reiserfsprogs 3.6.5-pre2 release.

[Oleg Drokin]

Hello!

On Wed, Feb 26, 2003 at 12:21:44PM -0700, Andreas Dilger wrote:

> > tests shown that almost all the time was spent on reading bitmap blocks.
> > And the same reading is done at mount time actually.
> It would be interesting to see if reiserfsck immediately followed by mount
> (which is the normal boot behaviour) takes any longer than just the mount.

Two subsequent fsck -a takes twice the time. Almost (+- 2 secs of 48)

> Oleg posted that the block device cache is flushed upon last close, but I
> don't think that is totally true.  It _was_ true for a short while, but

It is. You can trivially verify that.

> it was rather annoying and I think Al Viro fixed that so that the block
> device cache was "lazily" dropped, so you would keep it if you re-opened
> the device shortly after closing it.

No, I do not think so. Invalidate inode pages (or whatever) is called on
last device close. Anyway think of two fscks on two filesystems, then mounting.

Though last time I played with stock SuSE kernels (not so long ago), they had
this behavior turned off and cache survived device close.

> I suppose the other way to test it would be to run 2 "reiserfsck -a"
> in a row.

Yes, Philippe did this for us already.

Bye,
    Oleg

Re: reiserfsprogs 3.6.5-pre2 release.

[Oleg Drokin]

Hello!

On Thu, Feb 27, 2003 at 12:49:22AM +0100, Anders Widman wrote:
> > tests shown that almost all the time was spent on reading bitmap blocks.
> > And the same reading is done at mount time actually.
>   The   time  it  takes  to fsck a volume is probably only annoying on
>   large arrays of disks running LVM or spanned disk setup. Would it be
>   possible to read bitmaps from all physical drives at the same time?

Certain non-trivial amount of work is need to be put into "parallel" fsck then.

I have idea of a "hack" that might work, though ;)
fsck -a may not close the device until it gets mounted (or some timeout passed).
Then mounting will get bitmaps out of the cache or at least I hope so.
Need to do some experiments.

Bye,
    Oleg

Re: reiserfsprogs 3.6.5-pre2 release.

[Zygo Blaxell]

In article <200302251650.22469.vitaly@namesys.com>,
Vitaly Fertman  <vitaly@namesys.com> wrote:
>this new pre-release includes:
>- reiserfsck -a (started at boot) replays journal, checks error flags in 
>the superblock, bitmaps, fs size, 2 levels of internal tree and switches 
>to fixble mode if any problem is detected. For root fs fixable cannot be 
>performed (as fs is mounted) and just --check will be done.

I get:

	Checking all file systems...                                                    
	fsck 1.27 (8-Mar-2002)                                                          
	Reiserfs super block in block 16 on 0x902 of format 3.6 with standard journal   
	Blocks (total/free): 32848/22393 by 4096 bytes                                  
	Filesystem is cleanly umounted                                                  
											
	flush_buffers: device is not specifed                                           
	Warning... fsck.reiserfs for device /dev/md2 exited with signal 6.              
	Reiserfs super block in block 16 on 0x900 of format 3.6 with standard journal   
	Blocks (total/free): 37446896/1277098 by 4096 bytes                             
	Filesystem is cleanly umounted                                                  
											
	flush_buffers: device is not specifed                                           
	Warning... fsck.reiserfs for device /dev/md0 exited with signal 6.              
											
	fsck failed.  Please repair manually.                                           
											
	CONTROL-D will exit from this shell and continue system startup.                
											
	Give root password for maintenance                                              
	(or type Control-D for normal startup):  

...at which point booting stops.

On another machine I get:

	Checking all file systems...
	fsck 1.27 (8-Mar-2002)
	Reiserfs super block in block 16 on 0x900 of format 3.6 with standard journal
	Blocks (total/free): 152654320/1162905 by 4096 bytes
	Filesystem is NOT cleanly umounted
	Wrong amount of used blocks. Switching to fix-fixable pass.
	###########
	reiserfsck --fix-fixable started at Tue Mar  4 19:18:18 2003
	###########

	flush_buffers: device is not specifed
	Warning... fsck.reiserfs for device /dev/md0 exited with signal 6.

	fsck failed.  Please repair manually.

	CONTROL-D will exit from this shell and continue system startup.

	Give root password for maintenance
	(or type Control-D for normal startup):

...again, booting stops.  

If I run reiserfsck --rebuild-tree from a shell, it seems to work
normally.

-- 
Zygo Blaxell (Laptop) <zblaxell@feedme.hungrycats.org>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD

Re: reiserfsprogs 3.6.5-pre2 release.

[Dieter Nützel]

Am Mittwoch, 5. März 2003 01:50 schrieb Zygo Blaxell:
> In article <200302251650.22469.vitaly@namesys.com>,
>
> Vitaly Fertman  <vitaly@namesys.com> wrote:
> >this new pre-release includes:
> >- reiserfsck -a (started at boot) replays journal, checks error flags in
> >the superblock, bitmaps, fs size, 2 levels of internal tree and switches
> >to fixble mode if any problem is detected. For root fs fixable cannot be
> >performed (as fs is mounted) and just --check will be done.
>
> I get:
>
> 	Checking all file systems...
> 	fsck 1.27 (8-Mar-2002)
> 	Reiserfs super block in block 16 on 0x902 of format 3.6 with standard
> journal Blocks (total/free): 32848/22393 by 4096 bytes
> 	Filesystem is cleanly umounted
>
> 	flush_buffers: device is not specifed
> 	Warning... fsck.reiserfs for device /dev/md2 exited with signal 6.
> 	Reiserfs super block in block 16 on 0x900 of format 3.6 with standard
> journal Blocks (total/free): 37446896/1277098 by 4096 bytes
> 	Filesystem is cleanly umounted
>
> 	flush_buffers: device is not specifed
> 	Warning... fsck.reiserfs for device /dev/md0 exited with signal 6.
>
> 	fsck failed.  Please repair manually.
>
> 	CONTROL-D will exit from this shell and continue system startup.
>
> 	Give root password for maintenance
> 	(or type Control-D for normal startup):
>
> ...at which point booting stops.

Same here with all my "normal" SCSI disks.
See my former "reiserfsprogs-3.6.5-pre2: volumes do not mount during boot" 
post.

Should I try reiserfsck --rebuild-tree?

Thanks,
	Dieter

-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel at hamburg.de (replace at with @)

Re: reiserfsprogs 3.6.5-pre2 release.

[Vitaly Fertman]

> Same here with all my "normal" SCSI disks.
> See my former "reiserfsprogs-3.6.5-pre2: volumes do not mount during boot"
> post.
>
> Should I try reiserfsck --rebuild-tree?
>
> Thanks,
> 	Dieter

No, you should run reiserfsck --check manually and follow the instructions.

-- 

Thanks,
Vitaly Fertman