Reiserfsck can't fix FS

Reiserfsck can't fix FS

[Thomas Raschbacher]

[-- Attachment #1.1: Type: text/plain, Size: 1117 bytes --]

Hi,

I had to run reiserfsck on my usb hdd because there were some problems.
It told me to rebuild the tree (because I couldn't mount it I coudlnt'
backup things and I didn't have enough space (50GB) spare for a disk
image).

attached my logfiles and (where i remembered to save it the stdout
output)

It alwasy aborts at the same place.

(i did the same for another partition and there after running reiserfsck
--rebuild-tree about 10 times it worked out ok but this one seems to be
a problem ..)

reiserfsck 3.6.19 (2003 www.namesys.com)
Linux version 2.6.12-gentoo-r6 (root@desktop) (gcc version
3.4.3-20050110 (Gentoo 3.4.3.20050110-r2, ssp-3.4.3.20050110-0,
pie-8.7.7)) #1 Thu Jul 21 20:21:20 BST 2005
(i can provide kernel config file if needed)

Please let me know if ther'es anything I can do as there's quite a bit
of data on that drive.

Thanks

-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K
w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++
h-- !r
z- 
------END GEEK CODE BLOCK------

[-- Attachment #1.2: reiser6_rebuild_sb --]
[-- Type: text/plain, Size: 1946 bytes --]

desktop ~ # reiserfsck --rebuild-sb /dev/discs/disc2/part6 
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** 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 check superblock and rebuild it if needed
Will put log info to 'stdout'

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

Did you use resizer(y/n)[n]: 
rebuild-sb: wrong block count occured (12440326), fixed (12440320)
Reiserfs super block in block 16 on 0x816 of format 3.6 with standard journal
Count of blocks on the device: 12440320
Number of bitmaps: 380
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 443668
Root block: 203730
Filesystem is clean
Tree height: 4
Hash function used to sort names: "r5"
Objectid map size 670, max 972
Journal parameters:
        Device [0x0]
        Magic [0x134bceb1]
        Size 8193 blocks (including 1 for journal header) (first block 18)
        Max transaction length 1024 blocks
        Max batch size 900 blocks
        Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x1:
         some corruptions exist.
sb_version: 2
inode generation number: 118358
UUID: 230d7cdd-7a82-41bd-918c-adfe8c5cf509
LABEL: 
Set flags in SB:
        ATTRIBUTES CLEAN
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

[-- Attachment #1.3: reiser6_rebuild_tree1 --]
[-- Type: text/plain, Size: 8711 bytes --]

####### Pass 0 #######
block 447787: The number of items (14) is incorrect, should be (2) - corrected
block 447787: The free space (504) is incorrect, should be (3908) - corrected
pass0: vpf-10100: block 447787, item (0): Unknown item type of StatData size, type set to StatData [35373 35470 0x0 SD (0)]
pass0: vpf-10110: block 447787, item (1): Unknown item type found [35469 35470 0x8401f400000001 ??? (8)] - deleted
block 1135008: The number of items (14605) is incorrect, should be (1) - corrected
block 1135008: The free space (220) is incorrect, should be (3044) - corrected
pass0: vpf-10200: block 1135008, item 0: The item [7550 40344 0x100000075d801 IND (1)] with wrong offset is deleted
block 1849909: The number of items (32837) is incorrect, should be (2) - corrected
block 1849909: The free space (3276) is incorrect, should be (3468) - corrected
pass0: block 1849909, items 0 and 1: Which of these items looks better (the other will be deleted.)?
[63474 18818 0x13c4001 IND (1)]
[63218 2435 0x0 SD (0)]
block 1869431: The number of items (8206) is incorrect, should be (1) - corrected
block 1869431: The free space (32828) is incorrect, should be (4024) - corrected
block 2752513: The number of items (34) is incorrect, should be (1) - corrected
block 2752513: The free space (36) is incorrect, should be (4004) - corrected
pass0: vpf-10100: block 2752513, item (0): Unknown item type of StatData size, type set to StatData [169550 2135647 0x0 SD (0)]
block 3548060: The number of items (7) is incorrect, should be (2) - corrected
block 3548060: The free space (0) is incorrect, should be (2652) - corrected
pass0: vpf-10200: block 3548060, item 0: The item [2148533239 2147715871 0x43201 IND (1)] with wrong offset is deleted
block 4030472: The number of items (105) is incorrect, should be (2) - corrected
block 4030472: The free space (204) is incorrect, should be (3276) - corrected
block 4718594: The number of items (12) is incorrect, should be (6) - corrected
block 4718594: The free space (784) is incorrect, should be (2132) - corrected
pass0: vpf-10210: block 4718594, item 0: The item with wrong offset or length found [18245 18399 0x100000d9 DRCT (2)], len 208 - deleted
pass0: vpf-10540: block 4718594, item 0: Wrong order of items - change the object_id of the key [18245 18272 0x0 SD (0)] to 134236000
pass0: vpf-10170: block 4718594: item 1: Wrong order of items - the item 
	18253 134236000 0x1 DRCT (2), len 1160, location 2892 entry count 65535, fsck need 2, format new fixed to 
	18245 134236000 0x1 DRCT (2), len 1160, location 2892 entry count 65535, fsck need 2, format new
pass0: vpf-10410: block 4718594, item 4: Wrong order of items - change the type of the key [18246 18248 0x0 ??? (15)] to StatData
pass0: vpf-10170: block 4718594: item 3: Wrong order of items - the item 
	542534 18243 0x20000000001 DRCT (2), len 296, location 2552 entry count 65535, fsck need 0, format old fixed to 
	67127110 148295 0x1 DRCT (2), len 296, location 2552 entry count 65535, fsck need 0, format new
pass0: block 4718594, item 4 (lower): Item [18246 18248 0x0 SD (0)] is out of order - deleted
block 6719498: The number of items (12) is incorrect, should be (1) - corrected
block 6719498: The free space (2104) is incorrect, should be (4004) - corrected
pass0: vpf-10550: block 6848587, item 1: Wrong order of items - change the object_id of the key [20049 5132086 0x0 SD (0)] to 20278
pass0: block 6848587, item 2: The directory [20049 20278] has the wrong mode (?---r--rw-), corrected to (d---r--rw-)
verify_directory_item: block 6848587, item 20049 20278 0x1 DIR (3), len 2216, location 132 entry count 27, fsck need 0, format old: All entries were deleted from the directory
block 7766043: The number of items (29) is incorrect, should be (4) - corrected
block 7766043: The free space (0) is incorrect, should be (3636) - corrected
pass0: vpf-10410: block 7766043, item 3: Wrong order of items - change the type of the key [34597 34750 0x100000000 ??? (4)] to StatData
pass0: vpf-10600: block 7766043, item 1: Wrong order of items - change the object_id of the key [34597 1073780669 0x0 SD (0)] to 34749
pass0: block 7766043, item 2: The file [34597 34749] has the wrong mode (?--xr--rw-), corrected to (---xr--rw-)
block 8028166: The number of items (23) is incorrect, should be (1) - corrected
block 8028166: The free space (0) is incorrect, should be (3664) - corrected
block 8028176: The number of items (13) is incorrect, should be (1) - corrected
block 8028176: The free space (32) is incorrect, should be (2464) - corrected
pass0: vpf-10200: block 8028176, item 0: The item [22304 8411058 0xa0132b0111 IND (1)] with wrong offset is deleted
block 8290305: The number of items (17) is incorrect, should be (0) - corrected
block 8290305: The free space (1372) is incorrect, should be (4072) - corrected
block 9724285: The number of items (27) is incorrect, should be (1) - corrected
block 9724285: The free space (116) is incorrect, should be (2272) - corrected
verify_directory_item: block 10059748, item 8630 18237 0x26c880 DIR (3), len 240, location 3856 entry count 9, fsck need 0, format old: All entries were deleted from the directory
pass0: block 10059748, item 1: The directory [8630 18393] has the wrong mode (?rw-rwx-w-), corrected to (drw-rwx-w-)
verify_directory_item: block 10059748, item 8630 18393 0x1 DIR (3), len 232, location 3820 entry count 8, fsck need 0, format old: All entries were deleted from the directory
pass0: block 10059748, item 2: The directory [8630 19269] has the wrong mode (lrwx-w---x), corrected to (drwx-w---x)
verify_directory_item: block 10059748, item 8630 19269 0x1 DIR (3), len 136, location 3872 entry count 5, fsck need 0, format old: All entries were deleted from the directory
pass0: block 10059748, item 3: The directory [8630 19969] has the wrong mode (?---r--r--), corrected to (d---r--r--)
verify_directory_item: block 10059748, item 8630 19969 0x1 DIR (3), len 136, location 3828 entry count 5, fsck need 0, format old: All entries were deleted from the directory
pass0: block 10059748, item 6: The directory [8630 20670] has the wrong mode (lr-xrw-rwx), corrected to (dr-xrw-rwx)
verify_directory_item: block 10059748, item 8630 20670 0x1 DIR (3), len 72, location 3644 entry count 3, fsck need 0, format old: All entries were deleted from the directory
pass0: block 10059748, item 7: The directory [8630 20672] has the wrong mode (c----wxrw-), corrected to (d----wxrw-)
verify_directory_item: block 10059748, item 8630 20672 0x1 DIR (3), len 72, location 3600 entry count 3, fsck need 0, format old: All entries were deleted from the directory
pass0: block 10059748, item 10: The directory [8630 20675] has the wrong mode (?-w----r-x), corrected to (d-w----r-x)
verify_directory_item: block 10059748, item 8630 20675 0x1 DIR (3), len 280, location 2544 entry count 8, fsck need 0, format old: All entries were deleted from the directory
pass0: block 10059748, item 11: The directory [8630 20682] has the wrong mode (?rwxrw----), corrected to (drwxrw----)
verify_directory_item: block 10059748, item 8630 20682 0x1 DIR (3), len 72, location 2708 entry count 3, fsck need 0, format old: All entries were deleted from the directory
pass0: vpf-10110: block 10059748, item (12): Unknown item type found [8630 20697 0x2000001 ??? (15)] - deleted
pass0: vpf-10410: block 10059748, item 14: Wrong order of items - change the type of the key [8630 20726 0x80000 ??? (15)] to StatData
pass0: vpf-10590: block 10059748, item 13: Wrong order of items - change the object_id of the key [8630 134238436 0x1 DIR (3)] to 20708
pass0: block 10059748, item 13: The directory [8630 20708] has the wrong mode (--wxrwx-wx), corrected to (d-wxrwx-wx)
verify_directory_item: block 10059748, item 8630 20708 0x1 DIR (3), len 432, location 2260 entry count 17, fsck need 0, format old: All entries were deleted from the directory
pass0: vpf-10160: block 10059748: item 14: No "." entry found in the first item of a directory
verify_direntry: block 10059748, item 8630 20726 0x809 DIR (3), len 24, location 2624 entry count 1, fsck need 0, format old: Key's offset [8630 20726 0x809 DIR (3)] must match the directory's hash (1) - changed.
pass0: block 10059748, item 8630 20726 0x809 DIR (3), len 48, location 2600 entry count 2, fsck need 0, format old: 1 entries were deleted
block 10160124: The number of items (11) is incorrect, should be (0) - corrected
block 10160124: The free space (60) is incorrect, should be (4072) - corrected
35 directory entries were hashed with not set hash.
24524 directory entries were hashed with "r5" hash.
####### Pass 1 #######

[-- Attachment #1.4: reiser6_rebuild_tree1_2 --]
[-- Type: text/plain, Size: 319 bytes --]

####### Pass 0 #######
block 458759: The number of items (28) is incorrect, should be (1) - corrected
block 458759: The free space (0) is incorrect, should be (3688) - corrected
pass0: vpf-10210: block 458759, item 0: The item with wrong offset or length found [2147516278 32671 0x2310 DRCT (2)], len 360 - deleted

[-- Attachment #1.5: reiser6_rebuild_tree1_2stdout --]
[-- Type: text/plain, Size: 1521 bytes --]

Will rebuild the filesystem (/dev/discs/disc2/part6) tree
Will put log info to 'reiser6_rebuild_tree1_2'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
Reiserfs journal '/dev/discs/disc2/part6' in blocks [18..8211]: 0 transactions replayed
###########
reiserfsck --rebuild-tree started at Wed Oct 12 21:24:34 2005
###########

Pass 0:
Loading on-disk bitmap .. ok, 11996652 blocks marked used
Skipping 8590 blocks (super block, journal, bitmaps) 11988062 blocks will be read
0%.                                                    left 11319960, 7107 /sec
The problem has occurred looks like a hardware problem. If you have
bad blocks, we advise you to get a new hard drive, because once you
get one bad block  that the disk  drive internals  cannot hide from
your sight,the chances of getting more are generally said to become
much higher  (precise statistics are unknown to us), and  this disk
drive is probably not expensive enough  for you to you to risk your
time and  data on it.  If you don't want to follow that follow that
advice then  if you have just a few bad blocks,  try writing to the
bad blocks  and see if the drive remaps  the bad blocks (that means
it takes a block  it has  in reserve  and allocates  it for use for
of that block number).  If it cannot remap the block,  use badblock
option (-B) with  reiserfs utils to handle this block correctly.

bread: Cannot read the block (680320): (Input/output error).

Aborted

[-- Attachment #1.6: reiser6_rebuild_tree1_3 --]
[-- Type: text/plain, Size: 2073 bytes --]

####### Pass 0 #######
block 1135008: The number of items (4877) is incorrect, should be (1) - corrected
block 1135008: The free space (6364) is incorrect, should be (3044) - corrected
pass0: vpf-10200: block 1135008, item 0: The item [7550 40344 0x100100075d801 IND (1)] with wrong offset is deleted
block 4161546: The number of items (8) is incorrect, should be (0) - corrected
block 4161546: The free space (1868) is incorrect, should be (4072) - corrected
pass0: block 7766046, item 2: The directory [34721 34846] has the wrong mode (?-wxr--r-x), corrected to (d-wxr--r-x)
verify_directory_item: block 7766046, item 34721 34846 0x1 DIR (3), len 368, location 3536 entry count 12, fsck need 0, format old: All entries were deleted from the directory
pass0: block 7766046, item 3: The directory [34721 34857] has the wrong mode (?rwx-w---x), corrected to (drwx-w---x)
verify_directory_item: block 7766046, item 34721 34857 0x1 DIR (3), len 112, location 3748 entry count 4, fsck need 0, format old: All entries were deleted from the directory
block 8028161: The number of items (15) is incorrect, should be (0) - corrected
block 8028161: The free space (0) is incorrect, should be (4072) - corrected
block 8028176: The number of items (13) is incorrect, should be (1) - corrected
block 8028176: The free space (32) is incorrect, should be (2464) - corrected
pass0: vpf-10200: block 8028176, item 0: The item [20512 18354 0x402b0011 IND (1)] with wrong offset is deleted
block 8552386: The number of items (1038) is incorrect, should be (1) - corrected
block 8552386: The free space (0) is incorrect, should be (4004) - corrected
block 10059768: The number of items (33291) is incorrect, should be (1) - corrected
block 10059768: The free space (24) is incorrect, should be (3904) - corrected
verify_directory_item: block 10059768, item 9138 9466898 0x809103 DIR (3), len 144, location 3952 entry count 5, fsck need 0, format old: All entries were deleted from the directory
24731 directory entries were hashed with "r5" hash.
####### Pass 1 #######

[-- Attachment #1.7: reiser6_rebuild_tree1_3stdout --]
[-- Type: text/plain, Size: 1439 bytes --]

Will rebuild the filesystem (/dev/discs/disc2/part6) tree
Will put log info to 'reiser6_rebuild_tree1_3'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
Reiserfs journal '/dev/discs/disc2/part6' in blocks [18..8211]: 0 transactions replayed
###########
reiserfsck --rebuild-tree started at Wed Oct 12 21:51:20 2005
###########

Pass 0:
Loading on-disk bitmap .. ok, 11996652 blocks marked used
Skipping 8590 blocks (super block, journal, bitmaps) 11988062 blocks will be read
0%....20%....40%....60%....80%....100%                        left 0, 7110 /sec
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 11988062
                Leaves among those 16444
                        - corrected leaves 2
                        - leaves all contents of which could not be saved and deleted 5
                pointers in indirect items to wrong area 37 (zeroed)
                Objectids found 26029

Pass 1 (will try to insert 16439 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%.                             left 1982, 176 /sec
The problem has occurred looks like a hardware problem (perhaps
memory). Send us the bug report only if the second run dies at
the same place with the same block number.

build_the_tree: Nothing but leaves are expected. Block 10059767 - unknown

Aborted

[-- Attachment #1.8: reiser6_rebuild_tree1_4 --]
[-- Type: text/plain, Size: 5221 bytes --]

####### Pass 0 #######
block 458759: The number of items (28) is incorrect, should be (1) - corrected
block 458759: The free space (0) is incorrect, should be (3688) - corrected
pass0: vpf-10210: block 458759, item 0: The item with wrong offset or length found [268467990 32671 0x5002310 DRCT (2)], len 360 - deleted
block 1135008: The number of items (269) is incorrect, should be (1) - corrected
block 1135008: The free space (220) is incorrect, should be (3044) - corrected
pass0: vpf-10200: block 1135008, item 0: The item [7550 40344 0x1001000757005 IND (1)] with wrong offset is deleted
block 5996551: The number of items (28) is incorrect, should be (1) - corrected
block 5996551: The free space (16) is incorrect, should be (3688) - corrected
pass0: vpf-10110: block 5996551, item (0): Unknown item type found [32693 32702 0x311 ??? (6)] - deleted
block 6246995: The number of items (12) is incorrect, should be (0) - corrected
block 6246995: The free space (256) is incorrect, should be (4072) - corrected
block 6837836: The number of items (4) is incorrect, should be (0) - corrected
block 6837836: The free space (196) is incorrect, should be (4072) - corrected
block 8028161: The number of items (15) is incorrect, should be (0) - corrected
block 8028161: The free space (0) is incorrect, should be (4072) - corrected
block 8028176: The number of items (13) is incorrect, should be (11) - corrected
block 8028176: The free space (32) is incorrect, should be (1684) - corrected
pass0: vpf-10160: block 8028176: item 2: No "." entry found in the first item of a directory
pass0: block 8028176, item 2: The directory [284448 22451] has the wrong mode (?---rw-rw-), corrected to (d---rw-rw-)
verify_directory_item: block 8028176, item 284448 22451 0x800 DIR (3), len 72, location 2396 entry count 3, fsck need 0, format old: All entries were deleted from the directory
pass0: vpf-10450: block 8028176, item 1: Wrong order of items - change the dir_id of the key [284448 22451 0x0 SD (0)] to 22304
pass0: vpf-10410: block 8028176, item 4: Wrong order of items - change the type of the key [67131168 1075058357 0x0 ??? (15)] to StatData
pass0: block 8028176, item 3: The directory [22304 22452] has the wrong mode (brwxrwxrw-), corrected to (drwxrwxrw-)
verify_directory_item: block 8028176, item 22304 22452 0x1 DIR (3), len 136, location 2288 entry count 4, fsck need 0, format old: All entries were deleted from the directory
pass0: vpf-10460: block 8028176, item 3: Wrong order of items - change the dir_id of the key [67131168 1075058357 0x0 SD (0)] to 22304
pass0: vpf-10170: block 8028176: item 4: Wrong order of items - the item 
	22304 22453 0x1 IND (1), len 20, location 2360 entry count 0, fsck need 4, format BAD fixed to 
	22304 1075058357 0x1 IND (1), len 20, location 2360 entry count 0, fsck need 4, format new
pass0: block 8028176, item 4: The file [22304 1075058357] has the wrong mode (brwxr-xrwx), corrected to (-rwxr-xrwx)
pass0: vpf-10440: block 8028176, item 5: Wrong order of items - change the dir_id of the key [21920 22078 0x0 SD (0)] to 22304
pass0: vpf-10520: block 8028176, item 4: Wrong order of items - change the object_id of the key [22304 1075058357 0x1 IND (1)] to 2416072630
pass0: block 8028176, item 6: The file [22304 2416072630] has the wrong mode (?--x------), corrected to (---x------)
pass0: block 8028176, item 6 (upper): Item [22304 2416072630 0x1 IND (1)] is out of order - deleted
pass0: block 8028176, item 5 (upper): Item [22304 2416072630 0x0 SD (0)] is out of order - deleted
pass0: block 8028176, item 4 (upper): Item [22304 1075058357 0x1 IND (1)] is out of order - deleted
pass0: block 8028176, item 3 (upper): Item [22304 1075058357 0x0 SD (0)] is out of order - deleted
pass0: vpf-10170: block 8028176: item 4: Wrong order of items - the item 
	22304 22455 0x80000000001 IND (1), len 8, location 2372 entry count 32768, fsck need 0, format BAD fixed to 
	22304 22455 0x1 IND (1), len 8, location 2372 entry count 32768, fsck need 0, format new
pass0: block 8028176, item 4: The file [22304 22455] has the wrong mode (?rwxr---w-), corrected to (-rwxr---w-)
block 10059768: The number of items (11) is incorrect, should be (1) - corrected
block 10059768: The free space (24) is incorrect, should be (3904) - corrected
verify_directory_item: block 10059768, item 151008178 30268 0xa09003 DIR (3), len 144, location 3952 entry count 5, fsck need 0, format old: All entries were deleted from the directory
block 10160124: The number of items (11) is incorrect, should be (0) - corrected
block 10160124: The free space (60) is incorrect, should be (4072) - corrected
block 10321909: The number of items (22) is incorrect, should be (4) - corrected
block 10321909: The free space (17393) is incorrect, should be (3696) - corrected
pass0: vpf-10110: block 10321909, item (1): Unknown item type found [2 270738 0x1 ??? (15)] - deleted
pass0: block 10321909, item 1 (lower): Item [2 40810 0x0 SD (0)] is out of order - deleted
pass0: vpf-10110: block 10321909, item (1): Unknown item type found [10486272 40810 0x900b01 ??? (15)] - deleted
24746 directory entries were hashed with "r5" hash.
####### Pass 1 #######

[-- Attachment #1.9: reiser6_rebuild_tree1_5 --]
[-- Type: text/plain, Size: 1303 bytes --]

####### Pass 0 #######
block 4161546: The number of items (8) is incorrect, should be (0) - corrected
block 4161546: The free space (1868) is incorrect, should be (4072) - corrected
block 6837836: The number of items (4) is incorrect, should be (0) - corrected
block 6837836: The free space (196) is incorrect, should be (4072) - corrected
block 8028161: The number of items (15) is incorrect, should be (0) - corrected
block 8028161: The free space (0) is incorrect, should be (4072) - corrected
block 8290305: The number of items (17) is incorrect, should be (1) - corrected
block 8290305: The free space (1372) is incorrect, should be (3432) - corrected
pass0: vpf-10200: block 8290305, item 0: The item [298744 5279506 0x90001005 IND (1)] with wrong offset is deleted
block 10059768: The number of items (33291) is incorrect, should be (1) - corrected
block 10059768: The free space (88) is incorrect, should be (3904) - corrected
pass0: vpf-10110: block 10059768, item (0): Unknown item type found [151003622 1111606 0xa08002 ??? (15)] - deleted
block 10160124: The number of items (11) is incorrect, should be (0) - corrected
block 10160124: The free space (60) is incorrect, should be (4072) - corrected
24746 directory entries were hashed with "r5" hash.
####### Pass 1 #######

[-- Attachment #1.10: reiser6_rebuild_tree1_5stdout --]
[-- Type: text/plain, Size: 1323 bytes --]

Will rebuild the filesystem (/dev/discs/disc2/part6) tree
Will put log info to 'reiser6_rebuild_tree1_5'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
Reiserfs journal '/dev/discs/disc2/part6' in blocks [18..8211]: 0 transactions replayed
###########
reiserfsck --rebuild-tree started at Thu Oct 13 17:29:43 2005
###########

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

Pass 1 (will try to insert 16442 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%.                             left 2069, 177 /sec
The problem has occurred looks like a hardware problem (perhaps
memory). Send us the bug report only if the second run dies at
the same place with the same block number.

build_the_tree: Nothing but leaves are expected. Block 10059767 - unknown

Aborted

[-- Attachment #1.11: reiser6_rebuild_tree1_stdout --]
[-- Type: text/plain, Size: 1231 bytes --]

Reiserfs journal '/dev/discs/disc2/part6' in blocks [18..8211]: 0 transactions replayed
###########
reiserfsck --rebuild-tree started at Thu Oct 13 07:07:29 2005
###########

Pass 0:
Loading on-disk bitmap .. ok, 11996652 blocks marked used
Skipping 8590 blocks (super block, journal, bitmaps) 11988062 blocks will be read
0%....20%....40%....60%....80%....100%                        left 0, 6846 /sec
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 11988062
                Leaves among those 16450
                        - corrected leaves 2
                        - leaves all contents of which could not be saved and deleted 8
                pointers in indirect items to wrong area 423 (zeroed)
                Objectids found 26045

Pass 1 (will try to insert 16442 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%.                             left 2128, 178 /sec
The problem has occurred looks like a hardware problem (perhaps
memory). Send us the bug report only if the second run dies at
the same place with the same block number.

build_the_tree: Nothing but leaves are expected. Block 10059767 - unknown

Aborted

[-- Attachment #1.12: reiser6_rebuild_tree1stdout --]
[-- Type: text/plain, Size: 1442 bytes --]

Will rebuild the filesystem (/dev/discs/disc2/part6) tree
Will put log info to '/home/lordvan/reiser6_rebuild_tree1'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal..
Reiserfs journal '/dev/discs/disc2/part6' in blocks [18..8211]: 0 transactions replayed
###########
reiserfsck --rebuild-tree started at Wed Oct 12 19:31:20 2005
###########

Pass 0:
Loading on-disk bitmap .. ok, 11996652 blocks marked used
Skipping 8590 blocks (super block, journal, bitmaps) 11988062 blocks will be read
0%....20%....40%....60%....80%....100%                        left 0, 6554 /sec
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 11988062
                Leaves among those 16410
                        - corrected leaves 14
                        - leaves all contents of which could not be saved and deleted 4
                pointers in indirect items to wrong area 888 (zeroed)
                Objectids found 25965

Pass 1 (will try to insert 16406 leaves):
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%.                             left 1973, 169 /sec
The problem has occurred looks like a hardware problem (perhaps
memory). Send us the bug report only if the second run dies at
the same place with the same block number.

build_the_tree: Nothing but leaves are expected. Block 10059767 - unknown

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Reiserfsck can't fix FS

[Vitaly Fertman]

Hello Thomas!

On Friday 14 October 2005 19:21, Thomas Raschbacher wrote:
> Hi,
> 
> I had to run reiserfsck on my usb hdd because there were some problems.
> It told me to rebuild the tree (because I couldn't mount it I coudlnt'
> backup things and I didn't have enough space (50GB) spare for a disk
> image).
> 
> attached my logfiles and (where i remembered to save it the stdout
> output)
> 
> It alwasy aborts at the same place.
> 
> (i did the same for another partition and there after running reiserfsck
> --rebuild-tree about 10 times it worked out ok but this one seems to be
> a problem ..)
> 
> reiserfsck 3.6.19 (2003 www.namesys.com)
> Linux version 2.6.12-gentoo-r6 (root@desktop) (gcc version
> 3.4.3-20050110 (Gentoo 3.4.3.20050110-r2, ssp-3.4.3.20050110-0,
> pie-8.7.7)) #1 Thu Jul 21 20:21:20 BST 2005
> (i can provide kernel config file if needed)
> 
> Please let me know if ther'es anything I can do as there's quite a bit
> of data on that drive.

it is possible to check how reiserfsck works, you can extract 
the fs metadata and fsck them on another compter. this does 
not require you to have 50M as there are not real data:
	debugreiserfs -p /dev/discs/disc2/part6 | bzip2 -c > part6.bz2
go to another computer:
	touch part6.image
	bunzip2 -c part6.bz2 | debugreiserfs -u part6.image
	reiserfsck --rebuild-tree part6.image -l logfile

if it finishes successfully, the problem is in your hardware.
As the same block number repeats and there is also a failed 
block read, the problem is likely to be IO related.

it fsck fails on your metadata, I would like to have a look 
at part6.bz2.

-- 
Vitaly

Re: Reiserfsck can't fix FS

[Thomas Raschbacher]

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

Hi

just a quick addition:

I ran this:

desktop lordvan # dd if=/dev/discs/disc2/part6  of=/dev/null bs=8k
1192384+0 records in
1192384+0 records out
1209296+0 records in
1209296+0 records out
1275725+0 records in
1275725+0 records out
1326505+0 records in
1326505+0 records out
1790232+0 records in
1790232+0 records out
2255571+0 records in
2255571+0 records out
2447343+0 records in
2447343+0 records out
6220163+1 records in
6220163+1 records out

as you see it produced no errors at all so the HDD can be read fine. any
idea what could cause the problem?

Thanks,
  THomas

On Fri, 2005-10-14 at 20:08 +0400, Vitaly Fertman wrote:
> Hello Thomas!
> 
> On Friday 14 October 2005 19:21, Thomas Raschbacher wrote:
> > Hi,
> > 
> > I had to run reiserfsck on my usb hdd because there were some problems.
> > It told me to rebuild the tree (because I couldn't mount it I coudlnt'
> > backup things and I didn't have enough space (50GB) spare for a disk
> > image).
> > 
> > attached my logfiles and (where i remembered to save it the stdout
> > output)
> > 
> > It alwasy aborts at the same place.
> > 
> > (i did the same for another partition and there after running reiserfsck
> > --rebuild-tree about 10 times it worked out ok but this one seems to be
> > a problem ..)
> > 
> > reiserfsck 3.6.19 (2003 www.namesys.com)
> > Linux version 2.6.12-gentoo-r6 (root@desktop) (gcc version
> > 3.4.3-20050110 (Gentoo 3.4.3.20050110-r2, ssp-3.4.3.20050110-0,
> > pie-8.7.7)) #1 Thu Jul 21 20:21:20 BST 2005
> > (i can provide kernel config file if needed)
> > 
> > Please let me know if ther'es anything I can do as there's quite a bit
> > of data on that drive.
> 
> it is possible to check how reiserfsck works, you can extract 
> the fs metadata and fsck them on another compter. this does 
> not require you to have 50M as there are not real data:
> 	debugreiserfs -p /dev/discs/disc2/part6 | bzip2 -c > part6.bz2
> go to another computer:
> 	touch part6.image
> 	bunzip2 -c part6.bz2 | debugreiserfs -u part6.image
> 	reiserfsck --rebuild-tree part6.image -l logfile
> 
> if it finishes successfully, the problem is in your hardware.
> As the same block number repeats and there is also a failed 
> block read, the problem is likely to be IO related.
> 
> it fsck fails on your metadata, I would like to have a look 
> at part6.bz2.
> 
-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K
w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++
h-- !r
z- 
------END GEEK CODE BLOCK------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Reiserfsck can't fix FS

[evilninja]

Thomas Raschbacher schrieb:
> 
> as you see it produced no errors at all so the HDD can be read fine. any
> idea what could cause the problem?

looking once more on your logfiles:

 > Pass 1 (will try to insert 16439 leaves):
 > Looking for allocable blocks .. finished
 > 0%....20%....40%....60%....80%.                             left 1982,
 > 176 /sec
 > The problem has occurred looks like a hardware problem (perhaps
 > memory). Send us the bug report only if the second run dies at
 > the same place with the same block number.
 >
 > build_the_tree: Nothing but leaves are expected. Block 10059767 -
 > unknown

the block number is indeed the same on every (?) reiserfsck-run. so maybe 
you can put your disk into another machine and/or free your usb-disk from 
usb and use it via (S)ATA? (if possible, to rule out hw-problems).

and:

 > I had to run reiserfsck on my usb hdd because there were some problems.

your reiserfs seems to be heavily damaged. can you tell us more about 
these "problems"?

thanks,
Christian.
-- 
BOFH excuse #76:

Unoptimized hard drive

Re: Reiserfsck can't fix FS

[michael chang]

On 10/16/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
> Hi
>
> just a quick addition:
>
> I ran this:
>
> desktop lordvan # dd if=/dev/discs/disc2/part6  of=/dev/null bs=8k
> 1192384+0 records in
> 1192384+0 records out
> 1209296+0 records in
> 1209296+0 records out
> 1275725+0 records in
> 1275725+0 records out
> 1326505+0 records in
> 1326505+0 records out
> 1790232+0 records in
> 1790232+0 records out
> 2255571+0 records in
> 2255571+0 records out
> 2447343+0 records in
> 2447343+0 records out
> 6220163+1 records in
> 6220163+1 records out
>
> as you see it produced no errors at all so the HDD can be read fine. any
> idea what could cause the problem?

IIRC, if there were no errors, dd wouldn't have repeatedly told you
what records in/out it'd completed, unless you manually tell it to do
so.

If you didn't touch it and it's saying this, then dd is skipping over
some dysfunctional blocks.  Otherwise, then yes, dd can read it fine
(although that doesn't say anything about the data's integrity).

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: Reiserfsck can't fix FS

[Thomas Raschbacher]

Actually I did send it SIGUSR1 signals to get the progress so it really
seems to work fine.
I intend to get another HDD (internal) and see if i can copy the FS and
then fix it there.
how would I best copy the filesystem? DD ?
(The PRoblems I had before with this disc are USB-storage related where
the disc does stop working if one reads/writes too much data at once on
USB2)

-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h-- !r
z-
------END GEEK CODE BLOCK------

On Mon, October 17, 2005 20:34, michael chang said:
> On 10/16/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
>> Hi
>>
>> just a quick addition:
>>
>> I ran this:
>>
>> desktop lordvan # dd if=/dev/discs/disc2/part6  of=/dev/null bs=8k
>> 1192384+0 records in
>> 1192384+0 records out
>> 1209296+0 records in
>> 1209296+0 records out
>> 1275725+0 records in
>> 1275725+0 records out
>> 1326505+0 records in
>> 1326505+0 records out
>> 1790232+0 records in
>> 1790232+0 records out
>> 2255571+0 records in
>> 2255571+0 records out
>> 2447343+0 records in
>> 2447343+0 records out
>> 6220163+1 records in
>> 6220163+1 records out
>>
>> as you see it produced no errors at all so the HDD can be read fine. any
>> idea what could cause the problem?
>
> IIRC, if there were no errors, dd wouldn't have repeatedly told you
> what records in/out it'd completed, unless you manually tell it to do
> so.
>
> If you didn't touch it and it's saying this, then dd is skipping over
> some dysfunctional blocks.  Otherwise, then yes, dd can read it fine
> (although that doesn't say anything about the data's integrity).
>
> --
> ~Mike
>  - Just my two cents
>  - No man is an island, and no man is unable.
>

Re: Reiserfsck can't fix FS

[evilninja]

Thomas Raschbacher schrieb:
> how would I best copy the filesystem? DD ?

dd, if that does not work then try dd_rescue:

http://www.garloff.de/kurt/linux/ddrescue/

Christian.
-- 
BOFH excuse #34:

(l)user error

Re: Reiserfsck can't fix FS

[Thomas Raschbacher]

Hi,

Finally got my new HDD (300 GB UDMA133 :D no usb anymore ..)
i backed up my data and ran reiserfsck on one of the other partitions
which were supposedly damaged.
it didn't work out (stopped at same point always)

then i made a backup copy of my backup copy and ran reiserfsck on that and
it worked just fine.

-> it seems that my filesystems never had errors in the first place but
running reiserfsck on my USB hdd caused the problems in the first place.
fortunately i could recover all my digital camera photos (which i will
definitely back up on DVD from now on!
some mp3's lost the filenames but who really cares about that anyway.

i suggest adding to the reiserfsck docs that running it on usb-hdds might
cause problems due to usb hdd driver bugs or whatever .. or at least a
note that if it fails on usb-hdd copy it to a non usb hdd and try again.

Regards,
  Thomas R
P.S.: I never enforced bandwidth allocation. but i still dont' know what
the problem is with this stupid USB2 storage stuffs .. it worked fine with
some old kernel (either early 2.6 or still 2.4 ..) any ideas what can
cause this kind of problems with usb hdds? or should i post to some kernel
mailing list/newsgroup?


-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h-- !r
z-
------END GEEK CODE BLOCK------

On Thu, October 20, 2005 19:55, michael chang said:
> On 10/19/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
>> Actually I did send it SIGUSR1 signals to get the progress so it really
>> seems to work fine.
>> I intend to get another HDD (internal) and see if i can copy the FS and
>> then fix it there.
>> how would I best copy the filesystem? DD ?
>> (The PRoblems I had before with this disc are USB-storage related where
>> the disc does stop working if one reads/writes too much data at once on
>> USB2)
>
> The USB2 data loss thing sounds like a bandwidth-allocation problem;
> since it's not always advisible to enforce it by default (well, I
> don't know about that, but I don't enforce it in any of my hand-built
> kernels).  What you are doing next sounds reasonable, please inform us
> how well it goes.
>
> --
> ~Mike
>  - Just my two cents
>  - No man is an island, and no man is unable.
>

Re: Reiserfsck can't fix FS

[Bedros Hanounik]

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

I had the exact same problem on a 300GB hard drive over USB with ReiserFS

by running resiserfsck, the tools suggested running it again with
--rebuild-tree option and it was a mistake.

reiserfsck --rebuild-tree screwed things  up big time; but I had a backup
copy of my stuff, so I reformatted the HD.

I would probably never use the option --rebuild-tree, only --fix-fixable.

I'm not sure if the partition actually was corrupted. I was able to access
it, but on start when mounting the partition it gave me error messages;
something like "file system not clean"

On 12/10/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
>
> Hi,
>
> Finally got my new HDD (300 GB UDMA133 :D no usb anymore ..)
> i backed up my data and ran reiserfsck on one of the other partitions
> which were supposedly damaged.
> it didn't work out (stopped at same point always)
>
> then i made a backup copy of my backup copy and ran reiserfsck on that and
> it worked just fine.
>
> -> it seems that my filesystems never had errors in the first place but
> running reiserfsck on my USB hdd caused the problems in the first place.
> fortunately i could recover all my digital camera photos (which i will
> definitely back up on DVD from now on!
> some mp3's lost the filenames but who really cares about that anyway.
>
> i suggest adding to the reiserfsck docs that running it on usb-hdds might
> cause problems due to usb hdd driver bugs or whatever .. or at least a
> note that if it fails on usb-hdd copy it to a non usb hdd and try again.
>
> Regards,
>   Thomas R
> P.S.: I never enforced bandwidth allocation. but i still dont' know what
> the problem is with this stupid USB2 storage stuffs .. it worked fine with
> some old kernel (either early 2.6 or still 2.4 ..) any ideas what can
> cause this kind of problems with usb hdds? or should i post to some kernel
> mailing list/newsgroup?
>
>
> --
> -----BEGIN GEEK CODE BLOCK-----
> GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w--
> O
> M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h--
> !r
> z-
> ------END GEEK CODE BLOCK------
>
> On Thu, October 20, 2005 19:55, michael chang said:
> > On 10/19/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
> >> Actually I did send it SIGUSR1 signals to get the progress so it really
> >> seems to work fine.
> >> I intend to get another HDD (internal) and see if i can copy the FS and
> >> then fix it there.
> >> how would I best copy the filesystem? DD ?
> >> (The PRoblems I had before with this disc are USB-storage related where
> >> the disc does stop working if one reads/writes too much data at once on
> >> USB2)
> >
> > The USB2 data loss thing sounds like a bandwidth-allocation problem;
> > since it's not always advisible to enforce it by default (well, I
> > don't know about that, but I don't enforce it in any of my hand-built
> > kernels).  What you are doing next sounds reasonable, please inform us
> > how well it goes.
> >
> > --
> > ~Mike
> >  - Just my two cents
> >  - No man is an island, and no man is unable.
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 3668 bytes --]

Re: Reiserfsck can't fix FS

[michael chang]

On 12/12/05, Bedros Hanounik <2bedros@gmail.com> wrote:
> I had the exact same problem on a 300GB hard drive over USB with ReiserFS

USB isn't the same as other hard drive interfaces... maybe there's
something not acting nice.  IIRC, USB took longer than ATA/IDE and
SCSI to get reasonable bus speeds, and nowadays venders are still
pretty cheap when it comes to USB performance (maybe enough power to
use a mouse and keyboard, but rarely enough for any serious work on
anything larger than a 512 USB stick)

> by running resiserfsck, the tools suggested running it again with
> --rebuild-tree option and it was a mistake.
>
> reiserfsck --rebuild-tree screwed things  up big time; but I had a backup
> copy of my stuff, so I reformatted the HD.

IIRC, --rebuild-tree is known to bring back things from the dead. 
When you reformatted the HD, did you zero it out first?  If not, then
any future rebuild-tree might screw things up again.  Just something
to consider.

> I would probably never use the option --rebuild-tree, only --fix-fixable.

Yeah, probably a good idea... although if your reiserfs is in a state
where it's telling you to --rebuild-tree, it's time to dump it to
another disk or to CD-RWs or DVD or something and reformat, zero out,
and restore.

> I'm not sure if the partition actually was corrupted. I was able to access
> it, but on start when mounting the partition it gave me error messages;
> something like "file system not clean"

IIRC this is an internal thing - it doesn't mean there are errors on
it per se, it just means that you didn't shut down properly at least
once and the machine didn't mark the fileystem as clean - there may or
may not be an incomplete write => error on your disk.  So long as you
don't get any major errors, you should be okay.

>
> On 12/10/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
> > Hi,
> >
> > Finally got my new HDD (300 GB UDMA133 :D no usb anymore ..)
> > i backed up my data and ran reiserfsck on one of the other partitions
> > which were supposedly damaged.
> > it didn't work out (stopped at same point always)
> >
> > then i made a backup copy of my backup copy and ran reiserfsck on that and
> > it worked just fine.
> >
> > -> it seems that my filesystems never had errors in the first place but
> > running reiserfsck on my USB hdd caused the problems in the first place.
> > fortunately i could recover all my digital camera photos (which i will
> > definitely back up on DVD from now on!
> > some mp3's lost the filenames but who really cares about that anyway.
> >
> > i suggest adding to the reiserfsck docs that running it on usb-hdds might
> > cause problems due to usb hdd driver bugs or whatever .. or at least a
> > note that if it fails on usb-hdd copy it to a non usb hdd and try again.
> >
> > Regards,
> >   Thomas R
> > P.S.: I never enforced bandwidth allocation. but i still dont' know what
> > the problem is with this stupid USB2 storage stuffs .. it worked fine with
> > some old kernel (either early 2.6 or still 2.4 ..) any ideas what can
> > cause this kind of problems with usb hdds? or should i post to some kernel
> > mailing list/newsgroup?
> >
> >
> > --
> > -----BEGIN GEEK CODE BLOCK-----
> > GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w--
> O
> > M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h--
> !r
> > z-
> > ------END GEEK CODE BLOCK------
> >
> > On Thu, October 20, 2005 19:55, michael chang said:
> > > On 10/19/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
> > >> Actually I did send it SIGUSR1 signals to get the progress so it really
> > >> seems to work fine.
> > >> I intend to get another HDD (internal) and see if i can copy the FS and
> > >> then fix it there.
> > >> how would I best copy the filesystem? DD ?
> > >> (The PRoblems I had before with this disc are USB-storage related where
> > >> the disc does stop working if one reads/writes too much data at once on
> > >> USB2)
> > >
> > > The USB2 data loss thing sounds like a bandwidth-allocation problem;
> > > since it's not always advisible to enforce it by default (well, I
> > > don't know about that, but I don't enforce it in any of my hand-built
> > > kernels).  What you are doing next sounds reasonable, please inform us
> > > how well it goes.
> > >
> > > --
> > > ~Mike
> > >  - Just my two cents
> > >  - No man is an island, and no man is unable.
> > >
> >
> >
> >
>
>


--
~Mike
 - Just the crazy copy cat.

Re: Reiserfsck can't fix FS - part 2

[Thomas Raschbacher]

I just tried to mount my reiserfs (which i fixed) as loopback (it worked
before ..)

but this time i got this error (and a segfault):

any ideas what the problem is?
shall i run --fix-fixable?


loop: loaded (max 8 devices)
ReiserFS: loop0: found reiserfs format "3.6" with standard journal
ReiserFS: loop0: using ordered data mode
ReiserFS: loop0: journal params: device loop0, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max trans
age 30
ReiserFS: loop0: checking transaction log (loop0)
ReiserFS: loop0: replayed 3 transactions in 0 seconds
ReiserFS: loop0: Using r5 hash to sort names
ReiserFS: loop0: Removing [119485 119486 0x0 SD]..<1>Unable to handle
kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: loop nvidia eeprom asb100 i2c_sensor i2c_viapro lp
snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi
snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq ohci_hcd parport_pc parport pcspkr via_ircc
irda crc_ccitt ehci_hcd emu10k1_gp gameport snd_emu10k1 snd_rawmidi
snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc
snd_util_mem snd_hwdep snd zr36060 adv7175 eth1394 saa7110 zr36067
i2c_algo_bit videocodec b44 ohci1394 ieee1394 via_agp evdev dvb_ttpci
l64781 saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev
ves1820 tda8083 stv0297 sp8870 firmware_class ves1x93 ttpci_eeprom stv0299
i2c_core dvb_core usb_storage usblp uhci_hcd 8139too sg sr_mod
CPU:    0
EIP:    0060:[<00000000>]    Tainted: P      VLI
EFLAGS: 00010282   (2.6.12-gentoo-r6)
EIP is at stext+0x3feffdd8/0x8
eax: c0403bc0   ebx: fffffff4   ecx: cd90a7f0   edx: 00000001
esi: d0a50398   edi: d63725c4   ebp: 00000000   esp: c32b4bd4
ds: 007b   es: 007b   ss: 0068
Process mount (pid: 25469, threadinfo=c32b4000 task=c20c45c0)
Stack: c0172057 d0a50398 d63725c4 00000000 ffffffff c03b4071 dc38d979
e06c2c00
       c01720af c32b4c10 cd90a7c4 00000000 c017212b c32b4c10 cd90a7c4
dc38d979
       00000006 c03b406b efe27080 cd90a7c4 00000000 c03b4072 c01d7026
c03b406b
Call Trace:
 [<c0172057>] __lookup_hash+0xa7/0xe0
 [<c01720af>] lookup_hash+0x1f/0x30
 [<c017212b>] lookup_one_len+0x6b/0x80
 [<c01d7026>] __get_xa_root+0x66/0xf0
 [<c01d722b>] open_xa_dir+0x17b/0x1b0
 [<c039b8b2>] preempt_schedule+0x42/0x60
 [<c011970a>] release_console_sem+0xea/0x100
 [<c01d835d>] reiserfs_delete_xattrs+0x8d/0x240
 [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
 [<c01b1cc9>] reiserfs_delete_inode+0x69/0x130
 [<c0222917>] vsprintf+0x27/0x30
 [<c01c351d>] prepare_error_buf+0xed/0x1c0
 [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
 [<c017f885>] generic_delete_inode+0xc5/0x1b0
 [<c017fb3c>] iput+0x3c/0x90
 [<c01bf45f>] finish_unfinished+0x28f/0x4a0
 [<c01c1e6a>] reiserfs_fill_super+0x6fa/0x7a0
 [<c01b4960>] reiserfs_init_locked_inode+0x0/0x20
 [<c01695fe>] sb_set_blocksize+0x2e/0x60
 [<c0168eb8>] get_sb_bdev+0xf8/0x170
 [<c01c298f>] get_super_block+0x2f/0x33
 [<c01c1770>] reiserfs_fill_super+0x0/0x7a0
 [<c01691ae>] do_kern_mount+0xae/0x190
 [<c0182ba3>] do_new_mount+0x83/0xe0
 [<c01833be>] do_mount+0x1ee/0x200
 [<c0183170>] copy_mount_options+0x60/0xc0
 [<c039c9ee>] lock_kernel+0x2e/0x50
 [<c01837cf>] sys_mount+0x9f/0xe0
 [<c01033db>] sysenter_past_esp+0x54/0x75
Code:  Bad EIP value.
-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h-- !r
z-
------END GEEK CODE BLOCK------

On Mon, December 12, 2005 22:54, Bedros Hanounik said:
>>IIRC, --rebuild-tree is known to bring back things from the dead.
>>When you reformatted the HD, did you zero it out first?  If not, then
>>any future rebuild-tree might screw things up again.  Just something
>>to consider.
>
> I did "dd if=/dev/urandom of=/dev/sda" over night which should have
> overwritten all the old stuff before formatting the HD.
>
>>IIRC this is an internal thing - it doesn't mean there are errors on
>>it per se, it just means that you didn't shut down properly at least
>>once and the machine didn't mark the fileystem as clean
>
> it repeated the same message even after clean shut down and after
> reiserfsck.
>
> reiserfs in general is trouble free FS, and after couple years of using
> it,
> this is the first time I have issues with it.
>
>
> -B
>
>
> On 12/12/05, michael chang <thenewme91@gmail.com> wrote:
>>
>> On 12/12/05, Bedros Hanounik <2bedros@gmail.com> wrote:
>> > I had the exact same problem on a 300GB hard drive over USB with
>> ReiserFS
>>
>> USB isn't the same as other hard drive interfaces... maybe there's
>> something not acting nice.  IIRC, USB took longer than ATA/IDE and
>> SCSI to get reasonable bus speeds, and nowadays venders are still
>> pretty cheap when it comes to USB performance (maybe enough power to
>> use a mouse and keyboard, but rarely enough for any serious work on
>> anything larger than a 512 USB stick)
>>
>> > by running resiserfsck, the tools suggested running it again with
>> > --rebuild-tree option and it was a mistake.
>> >
>> > reiserfsck --rebuild-tree screwed things  up big time; but I had a
>> backup
>> > copy of my stuff, so I reformatted the HD.
>>
>> IIRC, --rebuild-tree is known to bring back things from the dead.
>> When you reformatted the HD, did you zero it out first?  If not, then
>> any future rebuild-tree might screw things up again.  Just something
>> to consider.
>>
>> > I would probably never use the option --rebuild-tree, only
>> --fix-fixable.
>>
>> Yeah, probably a good idea... although if your reiserfs is in a state
>> where it's telling you to --rebuild-tree, it's time to dump it to
>> another disk or to CD-RWs or DVD or something and reformat, zero out,
>> and restore.
>>
>> > I'm not sure if the partition actually was corrupted. I was able to
>> access
>> > it, but on start when mounting the partition it gave me error
>> messages;
>> > something like "file system not clean"
>>
>> IIRC this is an internal thing - it doesn't mean there are errors on
>> it per se, it just means that you didn't shut down properly at least
>> once and the machine didn't mark the fileystem as clean - there may or
>> may not be an incomplete write => error on your disk.  So long as you
>> don't get any major errors, you should be okay.
>>
>> >
>> > On 12/10/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
>> > > Hi,
>> > >
>> > > Finally got my new HDD (300 GB UDMA133 :D no usb anymore ..)
>> > > i backed up my data and ran reiserfsck on one of the other
>> partitions
>> > > which were supposedly damaged.
>> > > it didn't work out (stopped at same point always)
>> > >
>> > > then i made a backup copy of my backup copy and ran reiserfsck on
>> that
>> and
>> > > it worked just fine.
>> > >
>> > > -> it seems that my filesystems never had errors in the first place
>> but
>> > > running reiserfsck on my USB hdd caused the problems in the first
>> place.
>> > > fortunately i could recover all my digital camera photos (which i
>> will
>> > > definitely back up on DVD from now on!
>> > > some mp3's lost the filenames but who really cares about that
>> anyway.
>> > >
>> > > i suggest adding to the reiserfsck docs that running it on usb-hdds
>> might
>> > > cause problems due to usb hdd driver bugs or whatever .. or at least
>> a
>> > > note that if it fails on usb-hdd copy it to a non usb hdd and try
>> again.
>> > >
>> > > Regards,
>> > >   Thomas R
>> > > P.S.: I never enforced bandwidth allocation. but i still dont' know
>> what
>> > > the problem is with this stupid USB2 storage stuffs .. it worked
>> fine
>> with
>> > > some old kernel (either early 2.6 or still 2.4 ..) any ideas what
>> can
>> > > cause this kind of problems with usb hdds? or should i post to some
>> kernel
>> > > mailing list/newsgroup?
>> > >
>> > >
>> > > --
>> > > -----BEGIN GEEK CODE BLOCK-----
>> > > GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o--
>> K
>> w--
>> > O
>> > > M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++
>> e-->+++++
>> h--
>> > !r
>> > > z-
>> > > ------END GEEK CODE BLOCK------
>> > >
>> > > On Thu, October 20, 2005 19:55, michael chang said:
>> > > > On 10/19/05, Thomas Raschbacher <lordvan@lordvan.com> wrote:
>> > > >> Actually I did send it SIGUSR1 signals to get the progress so it
>> really
>> > > >> seems to work fine.
>> > > >> I intend to get another HDD (internal) and see if i can copy the
>> FS
>> and
>> > > >> then fix it there.
>> > > >> how would I best copy the filesystem? DD ?
>> > > >> (The PRoblems I had before with this disc are USB-storage related
>> where
>> > > >> the disc does stop working if one reads/writes too much data at
>> once on
>> > > >> USB2)
>> > > >
>> > > > The USB2 data loss thing sounds like a bandwidth-allocation
>> problem;
>> > > > since it's not always advisible to enforce it by default (well, I
>> > > > don't know about that, but I don't enforce it in any of my
>> hand-built
>> > > > kernels).  What you are doing next sounds reasonable, please
>> inform
>> us
>> > > > how well it goes.
>> > > >
>> > > > --
>> > > > ~Mike
>> > > >  - Just my two cents
>> > > >  - No man is an island, and no man is unable.
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>>
>>
>> --
>> ~Mike
>> - Just the crazy copy cat.
>>
>

Re: Reiserfsck can't fix FS - part 2

[Raymond A. Meijer]

On Thu 15 Dec 2005 14:09, Thomas Raschbacher wrote:

> I just tried to mount my reiserfs (which i fixed) as loopback (it worked
> before ..)
>
> but this time i got this error (and a segfault):

[snip]

Whooaah mate, this looks serious...

Are you sure your hardware is okay? Have you run MemTest86+ recently?


Ray

Re: Reiserfsck can't fix FS - part 2

[Vladimir V. Saveliev]

Hello

Thomas Raschbacher wrote:
> I just tried to mount my reiserfs (which i fixed) as loopback (it worked
> before ..)
> 
> but this time i got this error (and a segfault):
> 
> any ideas what the problem is?
> shall i run --fix-fixable?
> 

Please try reiserfsck without any options first.

> 
> loop: loaded (max 8 devices)
> ReiserFS: loop0: found reiserfs format "3.6" with standard journal
> ReiserFS: loop0: using ordered data mode
> ReiserFS: loop0: journal params: device loop0, size 8192, journal first
> block 18, max trans len 1024, max batch 900, max commit age 30, max trans
> age 30
> ReiserFS: loop0: checking transaction log (loop0)
> ReiserFS: loop0: replayed 3 transactions in 0 seconds
> ReiserFS: loop0: Using r5 hash to sort names
> ReiserFS: loop0: Removing [119485 119486 0x0 SD]..<1>Unable to handle
> kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: loop nvidia eeprom asb100 i2c_sensor i2c_viapro lp
> snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi
> snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq ohci_hcd parport_pc parport pcspkr via_ircc
> irda crc_ccitt ehci_hcd emu10k1_gp gameport snd_emu10k1 snd_rawmidi
> snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc
> snd_util_mem snd_hwdep snd zr36060 adv7175 eth1394 saa7110 zr36067
> i2c_algo_bit videocodec b44 ohci1394 ieee1394 via_agp evdev dvb_ttpci
> l64781 saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev
> ves1820 tda8083 stv0297 sp8870 firmware_class ves1x93 ttpci_eeprom stv0299
> i2c_core dvb_core usb_storage usblp uhci_hcd 8139too sg sr_mod
> CPU:    0
> EIP:    0060:[<00000000>]    Tainted: P      VLI

You have got tainted kernel. Can you try kernel without proprietary modules?

> EFLAGS: 00010282   (2.6.12-gentoo-r6)
> EIP is at stext+0x3feffdd8/0x8
> eax: c0403bc0   ebx: fffffff4   ecx: cd90a7f0   edx: 00000001
> esi: d0a50398   edi: d63725c4   ebp: 00000000   esp: c32b4bd4
> ds: 007b   es: 007b   ss: 0068
> Process mount (pid: 25469, threadinfo=c32b4000 task=c20c45c0)
> Stack: c0172057 d0a50398 d63725c4 00000000 ffffffff c03b4071 dc38d979
> e06c2c00
>        c01720af c32b4c10 cd90a7c4 00000000 c017212b c32b4c10 cd90a7c4
> dc38d979
>        00000006 c03b406b efe27080 cd90a7c4 00000000 c03b4072 c01d7026
> c03b406b
> Call Trace:
>  [<c0172057>] __lookup_hash+0xa7/0xe0
>  [<c01720af>] lookup_hash+0x1f/0x30
>  [<c017212b>] lookup_one_len+0x6b/0x80
>  [<c01d7026>] __get_xa_root+0x66/0xf0
>  [<c01d722b>] open_xa_dir+0x17b/0x1b0
>  [<c039b8b2>] preempt_schedule+0x42/0x60
>  [<c011970a>] release_console_sem+0xea/0x100
>  [<c01d835d>] reiserfs_delete_xattrs+0x8d/0x240
>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>  [<c01b1cc9>] reiserfs_delete_inode+0x69/0x130
>  [<c0222917>] vsprintf+0x27/0x30
>  [<c01c351d>] prepare_error_buf+0xed/0x1c0
>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>  [<c017f885>] generic_delete_inode+0xc5/0x1b0
>  [<c017fb3c>] iput+0x3c/0x90
>  [<c01bf45f>] finish_unfinished+0x28f/0x4a0
>  [<c01c1e6a>] reiserfs_fill_super+0x6fa/0x7a0
>  [<c01b4960>] reiserfs_init_locked_inode+0x0/0x20
>  [<c01695fe>] sb_set_blocksize+0x2e/0x60
>  [<c0168eb8>] get_sb_bdev+0xf8/0x170
>  [<c01c298f>] get_super_block+0x2f/0x33
>  [<c01c1770>] reiserfs_fill_super+0x0/0x7a0
>  [<c01691ae>] do_kern_mount+0xae/0x190
>  [<c0182ba3>] do_new_mount+0x83/0xe0
>  [<c01833be>] do_mount+0x1ee/0x200
>  [<c0183170>] copy_mount_options+0x60/0xc0
>  [<c039c9ee>] lock_kernel+0x2e/0x50
>  [<c01837cf>] sys_mount+0x9f/0xe0
>  [<c01033db>] sysenter_past_esp+0x54/0x75
> Code:  Bad EIP value.

Re: Reiserfsck can't fix FS - part 2

[Thomas Raschbacher]

reiserfsck didn't give me any errors:

desktop Storage3 # reiserfsck usb-reiser3.img
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** 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 read-only check consistency of the filesystem on usb-reiser3.img
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Thu Dec 15 18:08:00 2005
###########
Replaying journal..
Reiserfs journal 'usb-reiser3.img' in blocks [18..8211]: 0 transactions
replayed
Checking internal tree..finished
Comparing bitmaps..finished
Checking Semantic tree:
finished
No corruptions found
There are on the filesystem:
        Leaves 47328
        Internal nodes 321
        Directories 52464
        Other files 215525
        Data block pointers 11832978 (1842 of them are zero)
        Safe links 2
###########
reiserfsck finished at Thu Dec 15 18:16:33 2005
###########

The only tainted kernel module i'm using is the nvidia driver.
and i'm using many other reiserfs filesystems on my machine root, and ~ 5
other partitions.

any idea?

-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h-- !r
z-
------END GEEK CODE BLOCK------

On Thu, December 15, 2005 13:34, Vladimir V. Saveliev said:
> Hello
>
> Thomas Raschbacher wrote:
>> I just tried to mount my reiserfs (which i fixed) as loopback (it worked
>> before ..)
>>
>> but this time i got this error (and a segfault):
>>
>> any ideas what the problem is?
>> shall i run --fix-fixable?
>>
>
> Please try reiserfsck without any options first.
>
>>
>> loop: loaded (max 8 devices)
>> ReiserFS: loop0: found reiserfs format "3.6" with standard journal
>> ReiserFS: loop0: using ordered data mode
>> ReiserFS: loop0: journal params: device loop0, size 8192, journal first
>> block 18, max trans len 1024, max batch 900, max commit age 30, max
>> trans
>> age 30
>> ReiserFS: loop0: checking transaction log (loop0)
>> ReiserFS: loop0: replayed 3 transactions in 0 seconds
>> ReiserFS: loop0: Using r5 hash to sort names
>> ReiserFS: loop0: Removing [119485 119486 0x0 SD]..<1>Unable to handle
>> kernel NULL pointer dereference at virtual address 00000000
>>  printing eip:
>> 00000000
>> *pde = 00000000
>> Oops: 0000 [#1]
>> PREEMPT
>> Modules linked in: loop nvidia eeprom asb100 i2c_sensor i2c_viapro lp
>> snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi
>> snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss
>> snd_seq_midi_event snd_seq ohci_hcd parport_pc parport pcspkr via_ircc
>> irda crc_ccitt ehci_hcd emu10k1_gp gameport snd_emu10k1 snd_rawmidi
>> snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc
>> snd_util_mem snd_hwdep snd zr36060 adv7175 eth1394 saa7110 zr36067
>> i2c_algo_bit videocodec b44 ohci1394 ieee1394 via_agp evdev dvb_ttpci
>> l64781 saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev
>> ves1820 tda8083 stv0297 sp8870 firmware_class ves1x93 ttpci_eeprom
>> stv0299
>> i2c_core dvb_core usb_storage usblp uhci_hcd 8139too sg sr_mod
>> CPU:    0
>> EIP:    0060:[<00000000>]    Tainted: P      VLI
>
> You have got tainted kernel. Can you try kernel without proprietary
> modules?
>
>> EFLAGS: 00010282   (2.6.12-gentoo-r6)
>> EIP is at stext+0x3feffdd8/0x8
>> eax: c0403bc0   ebx: fffffff4   ecx: cd90a7f0   edx: 00000001
>> esi: d0a50398   edi: d63725c4   ebp: 00000000   esp: c32b4bd4
>> ds: 007b   es: 007b   ss: 0068
>> Process mount (pid: 25469, threadinfo=c32b4000 task=c20c45c0)
>> Stack: c0172057 d0a50398 d63725c4 00000000 ffffffff c03b4071 dc38d979
>> e06c2c00
>>        c01720af c32b4c10 cd90a7c4 00000000 c017212b c32b4c10 cd90a7c4
>> dc38d979
>>        00000006 c03b406b efe27080 cd90a7c4 00000000 c03b4072 c01d7026
>> c03b406b
>> Call Trace:
>>  [<c0172057>] __lookup_hash+0xa7/0xe0
>>  [<c01720af>] lookup_hash+0x1f/0x30
>>  [<c017212b>] lookup_one_len+0x6b/0x80
>>  [<c01d7026>] __get_xa_root+0x66/0xf0
>>  [<c01d722b>] open_xa_dir+0x17b/0x1b0
>>  [<c039b8b2>] preempt_schedule+0x42/0x60
>>  [<c011970a>] release_console_sem+0xea/0x100
>>  [<c01d835d>] reiserfs_delete_xattrs+0x8d/0x240
>>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>>  [<c01b1cc9>] reiserfs_delete_inode+0x69/0x130
>>  [<c0222917>] vsprintf+0x27/0x30
>>  [<c01c351d>] prepare_error_buf+0xed/0x1c0
>>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>>  [<c017f885>] generic_delete_inode+0xc5/0x1b0
>>  [<c017fb3c>] iput+0x3c/0x90
>>  [<c01bf45f>] finish_unfinished+0x28f/0x4a0
>>  [<c01c1e6a>] reiserfs_fill_super+0x6fa/0x7a0
>>  [<c01b4960>] reiserfs_init_locked_inode+0x0/0x20
>>  [<c01695fe>] sb_set_blocksize+0x2e/0x60
>>  [<c0168eb8>] get_sb_bdev+0xf8/0x170
>>  [<c01c298f>] get_super_block+0x2f/0x33
>>  [<c01c1770>] reiserfs_fill_super+0x0/0x7a0
>>  [<c01691ae>] do_kern_mount+0xae/0x190
>>  [<c0182ba3>] do_new_mount+0x83/0xe0
>>  [<c01833be>] do_mount+0x1ee/0x200
>>  [<c0183170>] copy_mount_options+0x60/0xc0
>>  [<c039c9ee>] lock_kernel+0x2e/0x50
>>  [<c01837cf>] sys_mount+0x9f/0xe0
>>  [<c01033db>] sysenter_past_esp+0x54/0x75
>> Code:  Bad EIP value.
>
>

Re: Reiserfsck can't fix FS - part 2

[Vladimir V. Saveliev]

Hello

Thomas Raschbacher wrote:
> reiserfsck didn't give me any errors:
> 
> desktop Storage3 # reiserfsck usb-reiser3.img
> reiserfsck 3.6.19 (2003 www.namesys.com)
> 
> *************************************************************
> ** 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 read-only check consistency of the filesystem on usb-reiser3.img
> Will put log info to 'stdout'
> 
> Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
> ###########
> reiserfsck --check started at Thu Dec 15 18:08:00 2005
> ###########
> Replaying journal..
> Reiserfs journal 'usb-reiser3.img' in blocks [18..8211]: 0 transactions
> replayed
> Checking internal tree..finished
> Comparing bitmaps..finished
> Checking Semantic tree:
> finished
> No corruptions found
> There are on the filesystem:
>         Leaves 47328
>         Internal nodes 321
>         Directories 52464
>         Other files 215525
>         Data block pointers 11832978 (1842 of them are zero)
>         Safe links 2
> ###########
> reiserfsck finished at Thu Dec 15 18:16:33 2005
> ###########
> 
> The only tainted kernel module i'm using is the nvidia driver.
> and i'm using many other reiserfs filesystems on my machine root, and ~ 5
> other partitions.
> 
> any idea?
> 

Would you, please, try to mount this filesystem with -o nouser_xattr?

Re: Reiserfsck can't fix FS - part 2

[Thomas Raschbacher]

done.
error looks pretty much the same to me:

ReiserFS: loop2: found reiserfs format "3.6" with standard journal
ReiserFS: loop2: using ordered data mode
ReiserFS: loop2: journal params: device loop2, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max trans
age 30
ReiserFS: loop2: checking transaction log (loop2)
ReiserFS: loop2: Using r5 hash to sort names
ReiserFS: loop2: Removing [119485 119486 0x0 SD]..<1>Unable to handle
kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#3]
PREEMPT
Modules linked in: smbfs isofs zlib_inflate loop nvidia eeprom asb100
i2c_sensor i2c_viapro lp snd_seq_midi snd_emu10k1_synth snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq ohci_hcd parport_pc parport pcspkr
via_ircc irda crc_ccitt ehci_hcd emu10k1_gp gameport snd_emu10k1
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc
snd_util_mem snd_hwdep snd zr36060 adv7175 eth1394 saa7110 zr36067
i2c_algo_bit videocodec b44 ohci1394 ieee1394 via_agp evdev dvb_ttpci
l64781 saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev
ves1820 tda8083 stv0297 sp8870 firmware_class ves1x93 ttpci_eeprom stv0299
i2c_core dvb_core usb_storage usblp uhci_hcd 8139too sg sr_mod
CPU:    0
EIP:    0060:[<00000000>]    Tainted: P      VLI
EFLAGS: 00010286   (2.6.12-gentoo-r6)
EIP is at stext+0x3feffdd8/0x8
eax: c0403bc0   ebx: fffffff4   ecx: dd719190   edx: 00000001
esi: d9dd56b8   edi: e7c9a4b4   ebp: 00000000   esp: eadacbd4
ds: 007b   es: 007b   ss: 0068
Process mount (pid: 13599, threadinfo=eadac000 task=d31fb0e0)
Stack: c0172057 d9dd56b8 e7c9a4b4 00000000 ffffffff c03b4071 dc38d979
ceb3c400
       c01720af eadacc10 dd719164 00000000 c017212b eadacc10 dd719164
dc38d979
       00000006 c03b406b efe27080 dd719164 00000000 c03b4072 c01d7026
c03b406b
Call Trace:
 [<c0172057>] __lookup_hash+0xa7/0xe0
 [<c01720af>] lookup_hash+0x1f/0x30
 [<c017212b>] lookup_one_len+0x6b/0x80
 [<c01d7026>] __get_xa_root+0x66/0xf0
 [<c01d722b>] open_xa_dir+0x17b/0x1b0
 [<c039b8b2>] preempt_schedule+0x42/0x60
 [<c011970a>] release_console_sem+0xea/0x100
 [<c01d835d>] reiserfs_delete_xattrs+0x8d/0x240
 [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
 [<c01b1cc9>] reiserfs_delete_inode+0x69/0x130
 [<c0222917>] vsprintf+0x27/0x30
 [<c01c351d>] prepare_error_buf+0xed/0x1c0
 [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
 [<c017f885>] generic_delete_inode+0xc5/0x1b0
 [<c017fb3c>] iput+0x3c/0x90
 [<c01bf45f>] finish_unfinished+0x28f/0x4a0
 [<c01c1e6a>] reiserfs_fill_super+0x6fa/0x7a0
 [<c01b4960>] reiserfs_init_locked_inode+0x0/0x20
 [<c01695fe>] sb_set_blocksize+0x2e/0x60
 [<c0168eb8>] get_sb_bdev+0xf8/0x170
 [<c01c298f>] get_super_block+0x2f/0x33
 [<c01c1770>] reiserfs_fill_super+0x0/0x7a0
 [<c01691ae>] do_kern_mount+0xae/0x190
 [<c0182ba3>] do_new_mount+0x83/0xe0
 [<c01833be>] do_mount+0x1ee/0x200
 [<c0183170>] copy_mount_options+0x60/0xc0
 [<c039c9ee>] lock_kernel+0x2e/0x50
 [<c01837cf>] sys_mount+0x9f/0xe0
 [<c01033db>] sysenter_past_esp+0x54/0x75
Code:  Bad EIP value.

-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h-- !r
z-
------END GEEK CODE BLOCK------

On Fri, December 16, 2005 7:43, Vladimir V. Saveliev said:
> Hello
>
> Thomas Raschbacher wrote:
>> reiserfsck didn't give me any errors:
>>
>> desktop Storage3 # reiserfsck usb-reiser3.img
>> reiserfsck 3.6.19 (2003 www.namesys.com)
>>
>> *************************************************************
>> ** 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 read-only check consistency of the filesystem on usb-reiser3.img
>> Will put log info to 'stdout'
>>
>> Do you want to run this program?[N/Yes] (note need to type Yes if you
>> do):Yes
>> ###########
>> reiserfsck --check started at Thu Dec 15 18:08:00 2005
>> ###########
>> Replaying journal..
>> Reiserfs journal 'usb-reiser3.img' in blocks [18..8211]: 0 transactions
>> replayed
>> Checking internal tree..finished
>> Comparing bitmaps..finished
>> Checking Semantic tree:
>> finished
>> No corruptions found
>> There are on the filesystem:
>>         Leaves 47328
>>         Internal nodes 321
>>         Directories 52464
>>         Other files 215525
>>         Data block pointers 11832978 (1842 of them are zero)
>>         Safe links 2
>> ###########
>> reiserfsck finished at Thu Dec 15 18:16:33 2005
>> ###########
>>
>> The only tainted kernel module i'm using is the nvidia driver.
>> and i'm using many other reiserfs filesystems on my machine root, and ~
>> 5
>> other partitions.
>>
>> any idea?
>>
>
> Would you, please, try to mount this filesystem with -o nouser_xattr?
>
>

Re: Reiserfsck can't fix FS - part 2

[Vladimir V. Saveliev]

Hello

Thomas Raschbacher wrote:
> done.
> error looks pretty much the same to me:
> 

It looks like we did not achieve the goal. Which was to avoid calling
reiserfs_delete_xattrs. Would you try to recompile with reiserfs's xattrs not
configured in?


> ReiserFS: loop2: found reiserfs format "3.6" with standard journal
> ReiserFS: loop2: using ordered data mode
> ReiserFS: loop2: journal params: device loop2, size 8192, journal first
> block 18, max trans len 1024, max batch 900, max commit age 30, max trans
> age 30
> ReiserFS: loop2: checking transaction log (loop2)
> ReiserFS: loop2: Using r5 hash to sort names
> ReiserFS: loop2: Removing [119485 119486 0x0 SD]..<1>Unable to handle
> kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000 [#3]
> PREEMPT
> Modules linked in: smbfs isofs zlib_inflate loop nvidia eeprom asb100
> i2c_sensor i2c_viapro lp snd_seq_midi snd_emu10k1_synth snd_emux_synth
> snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_dummy
> snd_seq_oss snd_seq_midi_event snd_seq ohci_hcd parport_pc parport pcspkr
> via_ircc irda crc_ccitt ehci_hcd emu10k1_gp gameport snd_emu10k1
> snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc
> snd_util_mem snd_hwdep snd zr36060 adv7175 eth1394 saa7110 zr36067
> i2c_algo_bit videocodec b44 ohci1394 ieee1394 via_agp evdev dvb_ttpci
> l64781 saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev
> ves1820 tda8083 stv0297 sp8870 firmware_class ves1x93 ttpci_eeprom stv0299
> i2c_core dvb_core usb_storage usblp uhci_hcd 8139too sg sr_mod
> CPU:    0
> EIP:    0060:[<00000000>]    Tainted: P      VLI
> EFLAGS: 00010286   (2.6.12-gentoo-r6)
> EIP is at stext+0x3feffdd8/0x8
> eax: c0403bc0   ebx: fffffff4   ecx: dd719190   edx: 00000001
> esi: d9dd56b8   edi: e7c9a4b4   ebp: 00000000   esp: eadacbd4
> ds: 007b   es: 007b   ss: 0068
> Process mount (pid: 13599, threadinfo=eadac000 task=d31fb0e0)
> Stack: c0172057 d9dd56b8 e7c9a4b4 00000000 ffffffff c03b4071 dc38d979
> ceb3c400
>        c01720af eadacc10 dd719164 00000000 c017212b eadacc10 dd719164
> dc38d979
>        00000006 c03b406b efe27080 dd719164 00000000 c03b4072 c01d7026
> c03b406b
> Call Trace:
>  [<c0172057>] __lookup_hash+0xa7/0xe0
>  [<c01720af>] lookup_hash+0x1f/0x30
>  [<c017212b>] lookup_one_len+0x6b/0x80
>  [<c01d7026>] __get_xa_root+0x66/0xf0
>  [<c01d722b>] open_xa_dir+0x17b/0x1b0
>  [<c039b8b2>] preempt_schedule+0x42/0x60
>  [<c011970a>] release_console_sem+0xea/0x100
>  [<c01d835d>] reiserfs_delete_xattrs+0x8d/0x240
>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>  [<c01b1cc9>] reiserfs_delete_inode+0x69/0x130
>  [<c0222917>] vsprintf+0x27/0x30
>  [<c01c351d>] prepare_error_buf+0xed/0x1c0
>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>  [<c017f885>] generic_delete_inode+0xc5/0x1b0
>  [<c017fb3c>] iput+0x3c/0x90
>  [<c01bf45f>] finish_unfinished+0x28f/0x4a0
>  [<c01c1e6a>] reiserfs_fill_super+0x6fa/0x7a0
>  [<c01b4960>] reiserfs_init_locked_inode+0x0/0x20
>  [<c01695fe>] sb_set_blocksize+0x2e/0x60
>  [<c0168eb8>] get_sb_bdev+0xf8/0x170
>  [<c01c298f>] get_super_block+0x2f/0x33
>  [<c01c1770>] reiserfs_fill_super+0x0/0x7a0
>  [<c01691ae>] do_kern_mount+0xae/0x190
>  [<c0182ba3>] do_new_mount+0x83/0xe0
>  [<c01833be>] do_mount+0x1ee/0x200
>  [<c0183170>] copy_mount_options+0x60/0xc0
>  [<c039c9ee>] lock_kernel+0x2e/0x50
>  [<c01837cf>] sys_mount+0x9f/0xe0
>  [<c01033db>] sysenter_past_esp+0x54/0x75
> Code:  Bad EIP value.
> 

Re: Reiserfsck can't fix FS - part 2

[Thomas Raschbacher]

i just tried the -o nouser_xattr again .. and it seems like i only get
this error when i have -o rw... it works with -o ro .. any idea why
readwrite would cause this?

regards
-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h-- !r
z-
------END GEEK CODE BLOCK------

On Mon, December 19, 2005 9:33, Vladimir V. Saveliev said:
> Hello
>
> Thomas Raschbacher wrote:
>> done.
>> error looks pretty much the same to me:
>>
>
> It looks like we did not achieve the goal. Which was to avoid calling
> reiserfs_delete_xattrs. Would you try to recompile with reiserfs's xattrs
> not
> configured in?
>
>
>> ReiserFS: loop2: found reiserfs format "3.6" with standard journal
>> ReiserFS: loop2: using ordered data mode
>> ReiserFS: loop2: journal params: device loop2, size 8192, journal first
>> block 18, max trans len 1024, max batch 900, max commit age 30, max
>> trans
>> age 30
>> ReiserFS: loop2: checking transaction log (loop2)
>> ReiserFS: loop2: Using r5 hash to sort names
>> ReiserFS: loop2: Removing [119485 119486 0x0 SD]..<1>Unable to handle
>> kernel NULL pointer dereference at virtual address 00000000
>>  printing eip:
>> 00000000
>> *pde = 00000000
>> Oops: 0000 [#3]
>> PREEMPT
>> Modules linked in: smbfs isofs zlib_inflate loop nvidia eeprom asb100
>> i2c_sensor i2c_viapro lp snd_seq_midi snd_emu10k1_synth snd_emux_synth
>> snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss
>> snd_seq_dummy
>> snd_seq_oss snd_seq_midi_event snd_seq ohci_hcd parport_pc parport
>> pcspkr
>> via_ircc irda crc_ccitt ehci_hcd emu10k1_gp gameport snd_emu10k1
>> snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer
>> snd_page_alloc
>> snd_util_mem snd_hwdep snd zr36060 adv7175 eth1394 saa7110 zr36067
>> i2c_algo_bit videocodec b44 ohci1394 ieee1394 via_agp evdev dvb_ttpci
>> l64781 saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev
>> ves1820 tda8083 stv0297 sp8870 firmware_class ves1x93 ttpci_eeprom
>> stv0299
>> i2c_core dvb_core usb_storage usblp uhci_hcd 8139too sg sr_mod
>> CPU:    0
>> EIP:    0060:[<00000000>]    Tainted: P      VLI
>> EFLAGS: 00010286   (2.6.12-gentoo-r6)
>> EIP is at stext+0x3feffdd8/0x8
>> eax: c0403bc0   ebx: fffffff4   ecx: dd719190   edx: 00000001
>> esi: d9dd56b8   edi: e7c9a4b4   ebp: 00000000   esp: eadacbd4
>> ds: 007b   es: 007b   ss: 0068
>> Process mount (pid: 13599, threadinfo=eadac000 task=d31fb0e0)
>> Stack: c0172057 d9dd56b8 e7c9a4b4 00000000 ffffffff c03b4071 dc38d979
>> ceb3c400
>>        c01720af eadacc10 dd719164 00000000 c017212b eadacc10 dd719164
>> dc38d979
>>        00000006 c03b406b efe27080 dd719164 00000000 c03b4072 c01d7026
>> c03b406b
>> Call Trace:
>>  [<c0172057>] __lookup_hash+0xa7/0xe0
>>  [<c01720af>] lookup_hash+0x1f/0x30
>>  [<c017212b>] lookup_one_len+0x6b/0x80
>>  [<c01d7026>] __get_xa_root+0x66/0xf0
>>  [<c01d722b>] open_xa_dir+0x17b/0x1b0
>>  [<c039b8b2>] preempt_schedule+0x42/0x60
>>  [<c011970a>] release_console_sem+0xea/0x100
>>  [<c01d835d>] reiserfs_delete_xattrs+0x8d/0x240
>>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>>  [<c01b1cc9>] reiserfs_delete_inode+0x69/0x130
>>  [<c0222917>] vsprintf+0x27/0x30
>>  [<c01c351d>] prepare_error_buf+0xed/0x1c0
>>  [<c01b1c60>] reiserfs_delete_inode+0x0/0x130
>>  [<c017f885>] generic_delete_inode+0xc5/0x1b0
>>  [<c017fb3c>] iput+0x3c/0x90
>>  [<c01bf45f>] finish_unfinished+0x28f/0x4a0
>>  [<c01c1e6a>] reiserfs_fill_super+0x6fa/0x7a0
>>  [<c01b4960>] reiserfs_init_locked_inode+0x0/0x20
>>  [<c01695fe>] sb_set_blocksize+0x2e/0x60
>>  [<c0168eb8>] get_sb_bdev+0xf8/0x170
>>  [<c01c298f>] get_super_block+0x2f/0x33
>>  [<c01c1770>] reiserfs_fill_super+0x0/0x7a0
>>  [<c01691ae>] do_kern_mount+0xae/0x190
>>  [<c0182ba3>] do_new_mount+0x83/0xe0
>>  [<c01833be>] do_mount+0x1ee/0x200
>>  [<c0183170>] copy_mount_options+0x60/0xc0
>>  [<c039c9ee>] lock_kernel+0x2e/0x50
>>  [<c01837cf>] sys_mount+0x9f/0xe0
>>  [<c01033db>] sysenter_past_esp+0x54/0x75
>> Code:  Bad EIP value.
>>
>
>

Re: Reiserfsck can't fix FS - part 2

[Vladimir V. Saveliev]

Hello

Thomas Raschbacher wrote:
> i just tried the -o nouser_xattr again .. and it seems like i only get
> this error when i have -o rw... it works with -o ro .. any idea why
> readwrite would cause this?
> 

yes, because with -o ro - reiserfs does not handle safe links.

And this "safe link handling" is what you have crashing.
Am I correct that you do not have possibility to recompile the kernel without
xattr support?

Re: Reiserfsck can't fix FS - part 2

[Thomas Raschbacher]

hmm.. "safe links" ?? u as in 'ln' ?

i can recompile my kernel anytime .. i'll just feel a lot better if i get
a chance to back up my > 8GB digital photographs first .. :D
-- 
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/M/MU/S d- s: a--- C++++(++) UL++++ P+ L++++ E W+++ N+++ o-- K w-- O
M-- V- PS+ PE-- Y++ PGP+++ t+++ 5+ X- R tv b++++ DI- D+ G++ e-->+++++ h-- !r
z-
------END GEEK CODE BLOCK------

On Tue, December 20, 2005 8:14, Vladimir V. Saveliev said:
> Hello
>
> Thomas Raschbacher wrote:
>> i just tried the -o nouser_xattr again .. and it seems like i only get
>> this error when i have -o rw... it works with -o ro .. any idea why
>> readwrite would cause this?
>>
>
> yes, because with -o ro - reiserfs does not handle safe links.
>
> And this "safe link handling" is what you have crashing.
> Am I correct that you do not have possibility to recompile the kernel
> without
> xattr support?
>

Re: Reiserfsck can't fix FS - part 2

[Vladimir V. Saveliev]

Hello

Thomas Raschbacher wrote:
> hmm.. "safe links" ?? u as in 'ln' ?
> 

no. "safe links" are internal reiserfs things which indicate that there is
something which has to be done with filesystem on mount. In your case crash
happens handling those safe links.  Stack trace also shows that xattr code is
involved.

> i can recompile my kernel anytime .. 

Please recompile the kernel without xattr. If mount will work - then we have
figured out that something is wrong with xattrs removal.

> i'll just feel a lot better if i get
> a chance to back up my > 8GB digital photographs first .. :D

You said that you mounted it read-only. Were you able to read the data?

Re: Reiserfsck can't fix FS - part 2

[Thomas Raschbacher]

On Thu, December 22, 2005 14:38, Vladimir V. Saveliev said:
> Hello
>
> Thomas Raschbacher wrote:
>> hmm.. "safe links" ?? u as in 'ln' ?
>>
>
> no. "safe links" are internal reiserfs things which indicate that there is
> something which has to be done with filesystem on mount. In your case
> crash
> happens handling those safe links.  Stack trace also shows that xattr code
> is
> involved.
>
ok makes sense
>> i can recompile my kernel anytime ..
>
> Please recompile the kernel without xattr. If mount will work - then we
> have
> figured out that something is wrong with xattrs removal.
>
i will do so
>> i'll just feel a lot better if i get
>> a chance to back up my > 8GB digital photographs first .. :D
>
> You said that you mounted it read-only. Were you able to read the data?
>
yes i backed up almost all my data already.

Re: Reiserfsck can't fix FS - part 2

[Thomas Raschbacher]

Hi!

On Thu, December 22, 2005 14:38, Vladimir V. Saveliev said:
>> i can recompile my kernel anytime ..
>
> Please recompile the kernel without xattr. If mount will work - then we
> have
> figured out that something is wrong with xattrs removal.
>
Done that. it seems to work now. any idea why this happened and why the
mount -o nouser_xattr didnt work?
>> i'll just feel a lot better if i get
>> a chance to back up my > 8GB digital photographs first .. :D
>
> You said that you mounted it read-only. Were you able to read the data?
>
copied yes .. making sure now everything is working :)

Trying to mount ReiserFS file system read only results in change

[Linux Tard]

Hi,

I'm trying to mount a ReiserFS file system read only
from a SATA drive.  Unfortunately the mount results in
a change to the file system (the journal count is
incremented?).  

Is there a way to mount a ReiserFS file system truly
read only, such that *no* changes occur (IE, the
authentication, MD5/SHA1 matches pre and post
mounting)?

Perhaps an undocumented mount option?  Or are we
forced to change the mount_id increment in the
journal.c code to '0'?  IF we change this code, how
dangerous is this?

kind regards,
-lt


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Trying to mount ReiserFS file system read only results in change

[Vladimir V. Saveliev]

Hello

Linux Tard wrote:
> Hi,
> 
> I'm trying to mount a ReiserFS file system read only
> from a SATA drive.  Unfortunately the mount results in
> a change to the file system (the journal count is
> incremented?).  
> 
> Is there a way to mount a ReiserFS file system truly
> read only, such that *no* changes occur (IE, the
> authentication, MD5/SHA1 matches pre and post
> mounting)?
> 
> Perhaps an undocumented mount option?  Or are we
> forced to change the mount_id increment in the
> journal.c code to '0'?  IF we change this code, how
> dangerous is this?
> 

I think you can avoid mount_id increment when there were no transactions
replayed on mounting.

Re: Trying to mount ReiserFS file system read only results in change

[Linux Tard]

Hi Vladimir,

Thank you for reply.  Unfortunately in our testing the
journal count always is incremented (or we think that
is the change on the file system).  When we mount any
ReiserFS file system read only (ro) without
journalling (nolog) options and then unmount it, the
md5 value after unmount does not match the md5 value
before mount.  According to man page for mount the
'nolog' option is a work in progress, so we don't know
if this is why the count is still incremented or not?

We do know if we change that code in journal.c and
compile our kernel, the count is not incremented and
pre and post mounting authentication values are
equivalent.  We're trying to found out A) what is
being changed when mounted read only and B) why it's
being changed and ultimately C) is there something
else besides changing source code to stop this?

kind regards,
-lt


--- "Vladimir V. Saveliev" <vs@namesys.com> wrote:

> Hello
> 
> Linux Tard wrote:
> > Hi,
> > 
> > I'm trying to mount a ReiserFS file system read
> only
> > from a SATA drive.  Unfortunately the mount
> results in
> > a change to the file system (the journal count is
> > incremented?).  
> > 
> > Is there a way to mount a ReiserFS file system
> truly
> > read only, such that *no* changes occur (IE, the
> > authentication, MD5/SHA1 matches pre and post
> > mounting)?
> > 
> > Perhaps an undocumented mount option?  Or are we
> > forced to change the mount_id increment in the
> > journal.c code to '0'?  IF we change this code,
> how
> > dangerous is this?
> > 
> 
> I think you can avoid mount_id increment when there
> were no transactions
> replayed on mounting.
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Trying to mount ReiserFS file system read only results in change

[Vladimir V. Saveliev]

Hello

Linux Tard wrote:
> Hi Vladimir,
> 
> Thank you for reply.  Unfortunately in our testing the
> journal count always is incremented (or we think that
> is the change on the file system).  When we mount any
> ReiserFS file system read only (ro) without
> journalling (nolog) options and then unmount it, the
> md5 value after unmount does not match the md5 value
> before mount.  According to man page for mount the
> 'nolog' option is a work in progress, so we don't know
> if this is why the count is still incremented or not?
> 
> We do know if we change that code in journal.c and
> compile our kernel, the count is not incremented and
> pre and post mounting authentication values are
> equivalent.  We're trying to found out A) what is
> being changed when mounted read only

reiserfs has to replay journal before it can access any data. Even if it is
mounting readonly. Journal replay code does not distinguish whether filesystem
is being mounted read-only or not. So, it just replays journal and updates few
counters. If filesystem was umounted clean - no transactions are replayed, but
counters still get updated.

> and B) why it's
> being changed 

There were no reasons to distinguish cases of clean shutdown and unclean one.
Journal replay code does the same regardless to what happened with filesystem
before and to how it is being mounted.

> and ultimately C) is there something
> else besides changing source code to stop this?
> 
Please send your patch so that we could see first what you have done already.

Re: Trying to mount ReiserFS file system read only results in change

[Linux Tard]

Hi Vladimir,

Thank you again for replies.  



--- "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> reiserfs has to replay journal before it can access
> any data. Even if it is
> mounting readonly. Journal replay code does not
> distinguish whether filesystem
> is being mounted read-only or not. So, it just
> replays journal and updates few
> counters. If filesystem was umounted clean - no
> transactions are replayed, but
> counters still get updated.

Thank you for informational reply here.  This makes
sense, and we will note the reply, but in some
industry mounting read-only means truly read only with
nothing changed.  Computer forensics, one example.  If
we want to preview the file system before we acquire
we must mount read-only.  But journal increment
changes data, minimal as it is, the authentication no
longer matches and opposing counsel swoop in like
vultures.  


> > and ultimately C) is there something
> > else besides changing source code to stop this?
> > 
> Please send your patch so that we could see first
> what you have done already.
> 

What we have done is change two lines in kernel
source, fs/reiserfs/journal.c from;

 SB_JOURNAL(p_s_sb)->j_mount_id =
le32_to_cpu(jh->j_mount_id) + 1;
} else {
 SB_JOURNAL(p_s_sb)->j_mount_id = newest_mount_id + 1
;


to;

 SB_JOURNAL(p_s_sb)->j_mount_id =
le32_to_cpu(jh->j_mount_id) + 0;
} else {
 SB_JOURNAL(p_s_sb)->j_mount_id = newest_mount_id + 0
;


This has work for us - when we mount using this kernel
ReiserFS file systems do not change - the
authentication pre and post are equivalent.

We would never mount a ReiserFS file system we wish to
write to with this kernel, only those we preview.  

It would be nice to have a mount option that would not
increment journal count instead of going this kernel
route.

kind regards,
-lt


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Trying to mount ReiserFS file system read only results in change

[Vladimir V. Saveliev]

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

Hello

Linux Tard wrote:
> Hi Vladimir,
> 
> Thank you again for replies.  
> 
> 
> 
> --- "Vladimir V. Saveliev" <vs@namesys.com> wrote:
>>reiserfs has to replay journal before it can access
>>any data. Even if it is
>>mounting readonly. Journal replay code does not
>>distinguish whether filesystem
>>is being mounted read-only or not. So, it just
>>replays journal and updates few
>>counters. If filesystem was umounted clean - no
>>transactions are replayed, but
>>counters still get updated.
> 
> Thank you for informational reply here.  This makes
> sense, and we will note the reply, but in some
> industry mounting read-only means truly read only with
> nothing changed.  Computer forensics, one example.  If
> we want to preview the file system before we acquire
> we must mount read-only.  But journal increment
> changes data, minimal as it is, the authentication no
> longer matches and opposing counsel swoop in like
> vultures.  
> 

Yes, this is known problem, I remember that it was discussed some time ago, but
I do not rememeber that there was found any reasonable solution. There was  an
idea to keep journal replay changes in memory when mounting readonly, but I do
not think that it has even been implemented.

> 
>>>and ultimately C) is there something
>>>else besides changing source code to stop this?
>>>
>>Please send your patch so that we could see first
>>what you have done already.
>>
> 
> What we have done is change two lines in kernel
> source, fs/reiserfs/journal.c from;
> 
>  SB_JOURNAL(p_s_sb)->j_mount_id =
> le32_to_cpu(jh->j_mount_id) + 1;
> } else {
>  SB_JOURNAL(p_s_sb)->j_mount_id = newest_mount_id + 1
> ;
> 
> 
> to;
> 
>  SB_JOURNAL(p_s_sb)->j_mount_id =
> le32_to_cpu(jh->j_mount_id) + 0;
> } else {
>  SB_JOURNAL(p_s_sb)->j_mount_id = newest_mount_id + 0
> ;
> 
I do not think that this is  a good way.

> 
> This has work for us - when we mount using this kernel
> ReiserFS file systems do not change - the
> authentication pre and post are equivalent.
> 
> We would never mount a ReiserFS file system we wish to
> write to with this kernel, only those we preview.  
> 
> It would be nice to have a mount option that would not
> increment journal count instead of going this kernel
> route.
> 

I would propose the following patch.


[-- Attachment #2: reiserfs-dont-update-journla-header-mounting-readonly.patch --]
[-- Type: text/plain, Size: 867 bytes --]


This patch makes reiserfs to avoid journal header update when filesystem is being mounted readonly.


 fs/reiserfs/journal.c |    1 +
 1 files changed, 1 insertion(+)

diff -puN fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly fs/reiserfs/journal.c
--- linux-2.6.15-rc5-mm3/fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly	2005-12-20 13:09:28.000000000 +0300
+++ linux-2.6.15-rc5-mm3-vs/fs/reiserfs/journal.c	2005-12-20 13:10:51.000000000 +0300
@@ -2458,6 +2458,7 @@ static int journal_read(struct super_blo
 			      replay_count, get_seconds() - start);
 	}
 	if (!bdev_read_only(p_s_sb->s_bdev) &&
+	    !(p_s_sb->s_flags & MS_RDONLY) &&
 	    _update_journal_header_block(p_s_sb, journal->j_start,
 					 journal->j_last_flush_trans_id)) {
 		/* replay failed, caller must call free_journal_ram and abort

_

Re: Trying to mount ReiserFS file system read only results in change

[Linux Tard]

Hi Vladimar,

Thank you again.  

--- "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> I do not think that this is  a good way.
> 

Why is this?  Is there something else other than
preventing journal increment this would do?  Again, we
use this kernel only in certain situations.

> I would propose the following patch.
>  
>  fs/reiserfs/journal.c |    1 +
>  1 files changed, 1 insertion(+)
> 
> diff -puN
>
fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
> fs/reiserfs/journal.c
> ---
>
linux-2.6.15-rc5-mm3/fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
> 2005-12-20 13:09:28.000000000 +0300
> +++ linux-2.6.15-rc5-mm3-vs/fs/reiserfs/journal.c
> 2005-12-20 13:10:51.000000000 +0300
> @@ -2458,6 +2458,7 @@ static int journal_read(struct
> super_blo
>  			      replay_count, get_seconds() - start);
>  	}
>  	if (!bdev_read_only(p_s_sb->s_bdev) &&
> +	    !(p_s_sb->s_flags & MS_RDONLY) &&
>  	    _update_journal_header_block(p_s_sb,
> journal->j_start,
>  					 journal->j_last_flush_trans_id)) {
>  		/* replay failed, caller must call
> free_journal_ram and abort

We not able to test this patch.  We're using 2.4.32
kernel.  Output of patch;

[root@dumb linux-2.4.32]# patch -p1 <
reiserfs_dont_update_journla_header_mounting_readonly.patch
 --dry-run
patching file fs/reiserfs/journal.c
Hunk #1 FAILED at 2458.
1 out of 1 hunk FAILED -- saving rejects to file
fs/reiserfs/journal.c.rej
[root@dumb linux-2.4.32]#

And the REJ file;

[root@dumb reiserfs]# more journal.c.rej 
***************
*** 2458,2463 ****
                              replay_count,
get_seconds() - start);
        }
        if (!bdev_read_only(p_s_sb->s_bdev) &&
            _update_journal_header_block(p_s_sb,
journal->j_start,
                                        
journal->j_last_flush_trans_id)) {
                /* replay failed, caller must call
free_journal_ram and abort
--- 2458,2464 ----
                              replay_count,
get_seconds() - start);
        }
        if (!bdev_read_only(p_s_sb->s_bdev) &&
+           !(p_s_sb->s_flags & MS_RDONLY) &&
            _update_journal_header_block(p_s_sb,
journal->j_start,
                                        
journal->j_last_flush_trans_id)) {
                /* replay failed, caller must call
free_journal_ram and abort
[root@dumb reiserfs]#





I'm guessing you made patch for 2.6 kernel?  Or
failure for some other reason?  
We have to use 2.4 series kernel now.  Would you be
able to write this patch for 2.4 kernel if it was for
2.6?

kind regards,
-lt



	
		
__________________________________ 
Yahoo! for Good - Make a difference this year. 
http://brand.yahoo.com/cybergivingweek2005/

Re: Trying to mount ReiserFS file system read only results in change

[Vladimir V. Saveliev]

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

Hello

Linux Tard wrote:
> Hi Vladimar,
> 
> Thank you again.  
> 
> --- "Vladimir V. Saveliev" <vs@namesys.com> wrote:
>>I do not think that this is  a good way.
>>
> 
> Why is this?  

reiserfs used to increment mount id on each mount. Not updating it might confuse
code which relays on that fact: journal replay and/or reiserfsck.

> Is there something else other than
> preventing journal increment this would do?  Again, we
> use this kernel only in certain situations.
> 
>>I would propose the following patch.
>> 
>> fs/reiserfs/journal.c |    1 +
>> 1 files changed, 1 insertion(+)
>>
>>diff -puN
>>
> fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
>>fs/reiserfs/journal.c
>>---
>>
> linux-2.6.15-rc5-mm3/fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
>>2005-12-20 13:09:28.000000000 +0300
>>+++ linux-2.6.15-rc5-mm3-vs/fs/reiserfs/journal.c
>>2005-12-20 13:10:51.000000000 +0300
>>@@ -2458,6 +2458,7 @@ static int journal_read(struct
>>super_blo
>> 			      replay_count, get_seconds() - start);
>> 	}
>> 	if (!bdev_read_only(p_s_sb->s_bdev) &&
>>+	    !(p_s_sb->s_flags & MS_RDONLY) &&
>> 	    _update_journal_header_block(p_s_sb,
>>journal->j_start,
>> 					 journal->j_last_flush_trans_id)) {
>> 		/* replay failed, caller must call
>>free_journal_ram and abort
> 
> We not able to test this patch.  We're using 2.4.32
> kernel.  Output of patch;
> 
> [root@dumb linux-2.4.32]# patch -p1 <
> reiserfs_dont_update_journla_header_mounting_readonly.patch
>  --dry-run
> patching file fs/reiserfs/journal.c
> Hunk #1 FAILED at 2458.
> 1 out of 1 hunk FAILED -- saving rejects to file
> fs/reiserfs/journal.c.rej
> [root@dumb linux-2.4.32]#
> 
> And the REJ file;
> 
> [root@dumb reiserfs]# more journal.c.rej 
> ***************
> *** 2458,2463 ****
>                               replay_count,
> get_seconds() - start);
>         }
>         if (!bdev_read_only(p_s_sb->s_bdev) &&
>             _update_journal_header_block(p_s_sb,
> journal->j_start,
>                                         
> journal->j_last_flush_trans_id)) {
>                 /* replay failed, caller must call
> free_journal_ram and abort
> --- 2458,2464 ----
>                               replay_count,
> get_seconds() - start);
>         }
>         if (!bdev_read_only(p_s_sb->s_bdev) &&
> +           !(p_s_sb->s_flags & MS_RDONLY) &&
>             _update_journal_header_block(p_s_sb,
> journal->j_start,
>                                         
> journal->j_last_flush_trans_id)) {
>                 /* replay failed, caller must call
> free_journal_ram and abort
> [root@dumb reiserfs]#
> 
> 
> 
> 
> 
> I'm guessing you made patch for 2.6 kernel?  Or
> failure for some other reason?  

yes, it was for 2.6. Please try the attached, it is for 2.4.32.

> We have to use 2.4 series kernel now.  Would you be
> able to write this patch for 2.4 kernel if it was for
> 2.6?
> 
> kind regards,
> -lt
> 
> 
> 
> 	
> 		
> __________________________________ 
> Yahoo! for Good - Make a difference this year. 
> http://brand.yahoo.com/cybergivingweek2005/
> 
> 


[-- Attachment #2: reiserfs-dont-update-journla-header-mounting-readonly.patch --]
[-- Type: text/plain, Size: 1051 bytes --]


This patch makes reiserfs to avoid journal header update when filesystem is being mounted readonly.

diff -puN fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly fs/reiserfs/journal.c


 fs/reiserfs/journal.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly fs/reiserfs/journal.c
--- linux-2.4.32/fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly	2005-12-23 17:54:14.222498915 +0300
+++ linux-2.4.32-vs/fs/reiserfs/journal.c	2005-12-23 17:57:46.063947196 +0300
@@ -1804,7 +1804,8 @@ start_log_replay:
     printk("reiserfs: replayed %d transactions in %lu seconds\n", replay_count, 
 	    CURRENT_TIME - start) ;
   }
-  if (!is_read_only(p_s_sb->s_dev) && 
+  if (!is_read_only(p_s_sb->s_dev) &&
+      !(p_s_sb->s_flags & MS_RDONLY) &&
        _update_journal_header_block(p_s_sb, SB_JOURNAL(p_s_sb)->j_start, 
                                    SB_JOURNAL(p_s_sb)->j_last_flush_trans_id))
   {

_

Re: Trying to mount ReiserFS file system read only results in change

[Linux Tard]

Hi Vladimar,

Thank you kindly.  This patch worked for 2.4.32 and
testing indicates journal count is not incremented
when ReiserFS is mounted read only.  Very happy. 
Thank you!

Happy Holidays!

kind regards,
-lt


--- "Vladimir V. Saveliev" <vs@namesys.com> wrote:

> Hello
> 
> Linux Tard wrote:
> > Hi Vladimar,
> > 
> > Thank you again.  
> > 
> > --- "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> >>I do not think that this is  a good way.
> >>
> > 
> > Why is this?  
> 
> reiserfs used to increment mount id on each mount.
> Not updating it might confuse
> code which relays on that fact: journal replay
> and/or reiserfsck.
> 
> > Is there something else other than
> > preventing journal increment this would do? 
> Again, we
> > use this kernel only in certain situations.
> > 
> >>I would propose the following patch.
> >> 
> >> fs/reiserfs/journal.c |    1 +
> >> 1 files changed, 1 insertion(+)
> >>
> >>diff -puN
> >>
> >
>
fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
> >>fs/reiserfs/journal.c
> >>---
> >>
> >
>
linux-2.6.15-rc5-mm3/fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
> >>2005-12-20 13:09:28.000000000 +0300
> >>+++ linux-2.6.15-rc5-mm3-vs/fs/reiserfs/journal.c
> >>2005-12-20 13:10:51.000000000 +0300
> >>@@ -2458,6 +2458,7 @@ static int
> journal_read(struct
> >>super_blo
> >> 			      replay_count, get_seconds() - start);
> >> 	}
> >> 	if (!bdev_read_only(p_s_sb->s_bdev) &&
> >>+	    !(p_s_sb->s_flags & MS_RDONLY) &&
> >> 	    _update_journal_header_block(p_s_sb,
> >>journal->j_start,
> >> 					 journal->j_last_flush_trans_id)) {
> >> 		/* replay failed, caller must call
> >>free_journal_ram and abort
> > 
> > We not able to test this patch.  We're using
> 2.4.32
> > kernel.  Output of patch;
> > 
> > [root@dumb linux-2.4.32]# patch -p1 <
> >
>
reiserfs_dont_update_journla_header_mounting_readonly.patch
> >  --dry-run
> > patching file fs/reiserfs/journal.c
> > Hunk #1 FAILED at 2458.
> > 1 out of 1 hunk FAILED -- saving rejects to file
> > fs/reiserfs/journal.c.rej
> > [root@dumb linux-2.4.32]#
> > 
> > And the REJ file;
> > 
> > [root@dumb reiserfs]# more journal.c.rej 
> > ***************
> > *** 2458,2463 ****
> >                               replay_count,
> > get_seconds() - start);
> >         }
> >         if (!bdev_read_only(p_s_sb->s_bdev) &&
> >             _update_journal_header_block(p_s_sb,
> > journal->j_start,
> >                                         
> > journal->j_last_flush_trans_id)) {
> >                 /* replay failed, caller must call
> > free_journal_ram and abort
> > --- 2458,2464 ----
> >                               replay_count,
> > get_seconds() - start);
> >         }
> >         if (!bdev_read_only(p_s_sb->s_bdev) &&
> > +           !(p_s_sb->s_flags & MS_RDONLY) &&
> >             _update_journal_header_block(p_s_sb,
> > journal->j_start,
> >                                         
> > journal->j_last_flush_trans_id)) {
> >                 /* replay failed, caller must call
> > free_journal_ram and abort
> > [root@dumb reiserfs]#
> > 
> > 
> > 
> > 
> > 
> > I'm guessing you made patch for 2.6 kernel?  Or
> > failure for some other reason?  
> 
> yes, it was for 2.6. Please try the attached, it is
> for 2.4.32.
> 
> > We have to use 2.4 series kernel now.  Would you
> be
> > able to write this patch for 2.4 kernel if it was
> for
> > 2.6?
> > 
> > kind regards,
> > -lt
> > 
> > 
> > 
> > 	
> > 		
> > __________________________________ 
> > Yahoo! for Good - Make a difference this year. 
> > http://brand.yahoo.com/cybergivingweek2005/
> > 
> > 
> 
> > 
> This patch makes reiserfs to avoid journal header
> update when filesystem is being mounted readonly.
> 
> diff -puN
>
fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
> fs/reiserfs/journal.c
> 
> 
>  fs/reiserfs/journal.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff -puN
>
fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
> fs/reiserfs/journal.c
> ---
>
linux-2.4.32/fs/reiserfs/journal.c~reiserfs-dont-update-journla-header-mounting-readonly
> 2005-12-23 17:54:14.222498915 +0300
> +++ linux-2.4.32-vs/fs/reiserfs/journal.c	2005-12-23
> 17:57:46.063947196 +0300
> @@ -1804,7 +1804,8 @@ start_log_replay:
>      printk("reiserfs: replayed %d transactions in
> %lu seconds\n", replay_count, 
>  	    CURRENT_TIME - start) ;
>    }
> -  if (!is_read_only(p_s_sb->s_dev) && 
> +  if (!is_read_only(p_s_sb->s_dev) &&
> +      !(p_s_sb->s_flags & MS_RDONLY) &&
>         _update_journal_header_block(p_s_sb,
> SB_JOURNAL(p_s_sb)->j_start, 
>                                    
> SB_JOURNAL(p_s_sb)->j_last_flush_trans_id))
>    {
> 
> _
> 



		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com