bug report

bug report

[Stephan Reichel]

proxy:/home/reichel# reiserfsck --check -l /home/reichel/rfsck.log /dev/hdb6

<-------------reiserfsck, 2002------------->
reiserfsprogs 3.x.1b

Will read-only check consistency of the filesystem on /dev/hdb6
Will put log info to '/home/reichel/rfsck.log'

Do you want to run this program?[N/Yes] (note need to type Yes):Yes
###########
reiserfsck --check started at Sat Nov 22 21:38:48 2003
###########
Filesystem seems mounted read-only. Skipping journal replay..
Checking S+tree../  3 (of   3)/115 (of 122)/ 32 (of 170)bit 1067128968,
bitsize 8154586
reiserfsck: bitmap.c:160: reiserfs_bitmap_test_bit: Assertion `bit_number <
bm->bm_bit_size' failed.
Aborted
proxy:/home/reichel#


(I run reiserfsck because I got some errors "file '...' exists but can not
stat-ed")


Thanks in advance

Stephan Reichel
Barteldesplatz 1
D-01309 Dresden
+49 (0351) 3400111
Stephan.Reichel@1net4you.de

reiser4 test

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a new notebook, which I back up every day because it's a 
notebook.  Recently I converted all of its partitions except /boot (to 
support grub) to Reiser4 (from 3.6).  (Converted through some heroic 
maneuvering while booting with init=/bin/bash, not by writing a 
conversion utility.)

I figure I can either suffer in silence or share my experiences.

So far, performance seems very good, and finally my problem of disk 
access is solved -- it spins down!  For 10 or 15 minutes at a time!  
Space efficiency also looks much better.  I don't know if anyone on this 
list uses Gentoo, but the directory /usr/portage typically has 60 or 70 
megabytes of mostly byte to kilobyte sized files, within two layers of 
fairly large (100 +) directories of directories.  Being prudent, I put 
it on its own half-gig partition.  With v3, it uses around 120 megs.  
With v4, 60 or 70.

Other nice things -- speed is definitely better, but it usually doesn't 
matter.  I don't see a noticeable difference with desktop apps, but most 
of the time, they are a certain size and take a certain amount of time 
to open, and after that, there's very little disk access (or even CPU 
usage -- they mostly wait for input).  I can't test much else -- music 
would not be noticeable except while ripping, and I haven't tried 
gaming.  The places that I see performance improvements are places like 
tar, rsync (that /usr/portage dir gets rsynced every day), and program 
installation (which involves automatic fetching, unpacking, compiling, 
and installing of source tarballs).  I haven't really been able to 
measure CPU usage, as I haven't actually run benchmarks -- these are 
just impressions.

Every now and then I have a crash.  It happens gradually, as it's 
locallized to the filesystem -- I can keep working in any program that 
does not access the filesystem (so you can imagine how long that 
lasts).  Once a program touches the filesystem after this "crash", it 
stops responding, so I get the _effect_ of the entire system locking up 
in about 15 or 20 seconds.  I'm not complaining -- this machine came 
with WinXP home!

Interesting looking lines in the logs (not all of them new since Reiser4):

Nov 22 18:29:10 [kernel] WARNING: Flushing like mad: 65536
Nov 22 22:46:14 [kernel] spurious 8259A interrupt: IRQ7.
Nov 22 22:50:49 [kernel] reiser4[ktxnmgrd:run(11)]: commit_current_atom 
(fs/reiser4/txnmgr.c:1184)[nikita-3176]:

(Note that these lines are not one after another -- they are fairly 
scattered.)

After these crashes, typical results are -- nothing.  I don't notice 
anything different in dmesg -- just "loading reiser4 bitmap......done 
(124 jiffies)" (the number of jiffies changes).  If I'm supposed to see 
something else, this is a bug in implementation.  If I'm not, it's a bug 
in design -- I should know when things were not unmounted cleanly.  I 
haven't seen any corruption either directly or indirectly (through the 
reaction of individual programs) -- seems like just whatever made it to 
disk, made it, and whatever didn't, didn't -- so the atomicity seems to 
work.

I've been running like this for 2 or 3 days now.  I can't reproduce the 
crash with any specific activity, just seems to happen about once a day 
(or as reliable as win2k if you don't game).  It's also been happening 
most often when I'm gone, having left long-ish builds running.  Not 
often enough to be inconvenient, just often enough to give me a little 
adrenaline rush every time I log on.

I'd welcome any patches, and I'm willing to run tests.  I can't really 
hack it now -- maybe next summer.

Looking forward to a stable version -- this technology belongs on my 
servers!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBP8BNYQisZLIF6uqOAQKSrg//fQx+Fr6F/zaUOyranWtm+Y/idMd1j/m3
YBUeUMSlVvO+kMnGC/urUrWLx0LcYubxBrkaZ/+XTRMfa/DG2ghX44+rJG0+cepN
ulQ+eSGUlO9lvO55sB6aLgFrQmfvbmFpBGRWyOG5L88tZe9TdbSXYJ/vMoZLPQcZ
OR2tr/QInja1eJbYfKX//6CsPmUQxT1WHGeS1hWWB33Xmw+wtPOovsDJ3Cd1j+ib
akzvinihKFTo/nTpUXzAmKqckZa35jdHnZc4fuWlE+RdrCwOqtFSnfep2iTQfNFH
dmDWre9FwetmRacGJmKN2ITF648gBjdyzqM4zyrEuxFgQpXAcF3QnOXxXmcInhdm
OCgYYiNQd6fTT1wo1TS5k7OvSFMu2xenwBiXL9uOAvdWPzfvGyKFksH+For0Fqot
nYPCOhsPUVwuEfho/FC578EnWz16jF36It4JDKdO5EGu8KPUsGebPTurA2fBP8fF
wXsHPeR4NRoadfcNFu0UDzawYFuyPZ41Y3frxaq2lpSr8DmvqLSzbz7a2rCs25Ww
hWGTGhz8VZfMWJJtdPoC65flZInR8TJ1sm+Y2fbOh2AbEfAnUfGN3pGVdBNhsI2F
CJBEZdqA2NXZ0h8LsrME58hGZiQ2zllllsrsuvjZ8LLZQJzc8bgA3yUjBAbonrIK
4bypQAKNxps=
=eEjY
-----END PGP SIGNATURE-----

Re: bug report

[Vitaly Fertman]

Hello, 

On Sunday 23 November 2003 05:09, Stephan Reichel wrote:
> proxy:/home/reichel# reiserfsck --check -l /home/reichel/rfsck.log
> /dev/hdb6
>
> <-------------reiserfsck, 2002------------->
> reiserfsprogs 3.x.1b
>
> Will read-only check consistency of the filesystem on /dev/hdb6
> Will put log info to '/home/reichel/rfsck.log'
>
> Do you want to run this program?[N/Yes] (note need to type Yes):Yes
> ###########
> reiserfsck --check started at Sat Nov 22 21:38:48 2003
> ###########
> Filesystem seems mounted read-only. Skipping journal replay..
> Checking S+tree../  3 (of   3)/115 (of 122)/ 32 (of 170)bit 1067128968,
> bitsize 8154586
> reiserfsck: bitmap.c:160: reiserfs_bitmap_test_bit: Assertion `bit_number <
> bm->bm_bit_size' failed.
> Aborted
> proxy:/home/reichel#
>
>
> (I run reiserfsck because I got some errors "file '...' exists but can not
> stat-ed")

You are using a quite old riserfsprogs version, please update it to the 
latest one from our ftp site -- 
ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.11.tar.gz

-- 
Thanks,
Vitaly Fertman

Re: bug report

[Redeeman]

i recommend always getting the newest reiserutils

On Sun, 2003-11-23 at 03:09, Stephan Reichel wrote:
> proxy:/home/reichel# reiserfsck --check -l /home/reichel/rfsck.log /dev/hdb6
> 
> <-------------reiserfsck, 2002------------->
> reiserfsprogs 3.x.1b
> 
> Will read-only check consistency of the filesystem on /dev/hdb6
> Will put log info to '/home/reichel/rfsck.log'
> 
> Do you want to run this program?[N/Yes] (note need to type Yes):Yes
> ###########
> reiserfsck --check started at Sat Nov 22 21:38:48 2003
> ###########
> Filesystem seems mounted read-only. Skipping journal replay..
> Checking S+tree../  3 (of   3)/115 (of 122)/ 32 (of 170)bit 1067128968,
> bitsize 8154586
> reiserfsck: bitmap.c:160: reiserfs_bitmap_test_bit: Assertion `bit_number <
> bm->bm_bit_size' failed.
> Aborted
> proxy:/home/reichel#
> 
> 
> (I run reiserfsck because I got some errors "file '...' exists but can not
> stat-ed")
> 
> 
> Thanks in advance
> 
> Stephan Reichel
> Barteldesplatz 1
> D-01309 Dresden
> +49 (0351) 3400111
> Stephan.Reichel@1net4you.de
-- 
Regards, Redeeman
()  ascii ribbon campaign - against html e-mail 
/\                        - against microsoft attachments

bug report

[Stephan Reichel]

[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

Hello,
thanks to Vitaly for the hint.
And this is the next result:
-----------

proxy:/home/reichel# reiserfsck --rebuild-tree -l /home/reichel/rfsck.log
/dev/hdb6
reiserfsck 3.6.11 (2003 www.namesys.com)

*************************************************************
** Do not  run  the  program  with  --rebuild-tree  unless **
** something is broken and MAKE A BACKUP  before using it. **
** If you have bad sectors on a drive  it is usually a bad **
** idea to continue using it. Then you probably should get **
** a working hard drive, copy the file system from the bad **
** drive  to the good one -- dd_rescue is  a good tool for **
** that -- and only then run this program.                 **
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will rebuild the filesystem (/dev/hdb6) tree
Will put log info to '/home/reichel/rfsck.log'

Do you want to run this program?[N/Yes] (note need to type Yes if you
do):Yes

******************************************************
* Warning: The dma on your hard drive is turned off. *
* This may really slow down the fsck process.        *
******************************************************
Replaying journal..
0 transactions replayed
###########
reiserfsck --rebuild-tree started at Mon Nov 24 21:18:21 2003
###########

Pass 0:
Loading on-disk bitmap .. ok, 3472752 blocks marked used
Skipping 8459 blocks (super block, journal, bitmaps) 3464293 blocks will be
read
0%....20%....40%....60%....80%....100%                         left 0, 560
/sec
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 3464293
                Leaves among those 57850
                        - leaves all contents of which could not be saved
and deleted 1
                Objectids found 371712

Pass 1 (will try to insert 57849 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....100%                         left 0, 191
/sec
Flushing..finished
        57849 leaves read
                57428 inserted
                        - pointers in indirect items pointing to metadata 10
(zeroed)
                421 not inserted
        non-unique pointers in indirect items (zeroed) 59

Pass 2:
0%....20%....40%....60%....80%....100%                          left 0, 13
/sec
Flushing..finished
        Leaves inserted item by item 421
Pass 3 (semantic):
/old_var/spool/wwwoffle/prevout6/OrQokTtODwNeuEEihdvrfHQlbalance.c 1019
leaf_delete_items_entirely
leaf_delete_items_entirely: bad leaf 55340: level=1, nr_items=22,
free_space=65484 rdkey
Aborted

---------

See also attached log file.

Thanks,
Stephan Reichel

Re: bug report

[Carl-Daniel Hailfinger]

Stephan Reichel wrote:
> See also attached log file.

You forgot to attach it.


Carl-Daniel

Re: bug report

[Vitaly Fertman]

Hello, 

On Tuesday 25 November 2003 03:44, Stephan Reichel wrote:
> Hello,
> thanks to Vitaly for the hint.
> And this is the next result:
> -----------
>
> proxy:/home/reichel# reiserfsck --rebuild-tree -l /home/reichel/rfsck.log
> /dev/hdb6
> reiserfsck 3.6.11 (2003 www.namesys.com)
...
> Pass 3 (semantic):
> /old_var/spool/wwwoffle/prevout6/OrQokTtODwNeuEEihdvrfHQlbalance.c 1019
> leaf_delete_items_entirely
> leaf_delete_items_entirely: bad leaf 55340: level=1, nr_items=22,
> free_space=65484 rdkey
> Aborted

Hm, this is strange. 
Did you build the reiserfsprogs on the same mashine where you run it?
Would you run
    debugreiserfs -p /dev/hdb6 | bzip2 -c > hdb6.bz2
and provide it for downloading -- I will debug reiserfsck localy on your fs 
metadata if there is some bug. Although it may be some hardware problem
also -- with hdb or with the memory. 

-- 
Thanks,
Vitaly Fertman