fsck.reiser4 problem (was: reiser4 corruption problem)

fsck.reiser4 problem (was: reiser4 corruption problem)

[Michael Weissenbacher]

> i've already had the exact same problems before, i mean errors like:
> FSCK: Directory [109e8:416c7400000000:109ee] (dir40), node [216782], 
> item [1],
> unit [22]: entry has wrong offset
> [109ee:0(NAME):142657765726275:6e6746fc72416e77:135160352fe624]. Should be
> [109ee:0(NAME):142657765726275:6e6746fc72416e77:13514d8cfe19f4].
> while doing random other things on reiser4 partitions and fsck'ing 
> afterwards. using --build-fs created lots of files under lost+found and 
> i started over. i will leave the fs this time, maybe i can try some 
> things to find the cause of the problem.
i've investigated this problem further the last days and came to the 
following conclusions:
- 2.6.9-rc1-mm1 has a bug that affects all filesystems (pointed out 
earlier today). so don't use if you love your data ;)
- reiser4 is stable for me on 2.6.8.1-mm4 (i compared the directories 
with diff and there were no differences)
- the problem with fsck.reiser4 mentioned above persists. it does not 
like some file names on my partition and then thinks that there are 
fatal corruptions. using "fsck.reiser4 --build-fs" actually destroys 
some data then by moving some correct files to lost+found. the filenames 
fsck does not like all contain german umlauts. but otoh there are 
filenames with umlauts that are ok!

here are some filenames that fail:
BewerbungFürAnwaltsbüro.doc
Graphik01Markenidentität.sxd
SkriptumzumSeminarFühren.doc
WieTeamseffizientwerdenkönnen.doc

but otoh these work:
WerbeKärntnerBallonwerbung.sxw
Vo 08 - 29. März 2001.pdf
TschöranKirche.jpg
VölkermarktKircheGross.jpg

i know that it's never a good idea to use such characters in a file 
name, but tell this to the users ... hopeless!
as i already mentioned earlier, this is with reiserfsprogs-1.0.1

what i learned: don't trust fsck.reiser4 if it says there is corruption 
(yes i know, it could have read README before... sigh)

Michael

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Adrian Ulrich]

Hello,


> - 2.6.9-rc1-mm1 has a bug that affects all filesystems (pointed out 
> earlier today). so don't use if you love your data ;)

Can you tell us more about this bug?

(I'm using 2.6.9-rc1-mm1 and would like to know, what will happen ;) )

fsck.reiser4 problem (was: reiser4 corruption problem)

[David Dabbs]

Michael Weissenbacher wrote:

>i've investigated this problem further the last days and came to the 
>following conclusions:
>[...]
>fsck does not like all contain german umlauts. but otoh there are 
>filenames with umlauts that are ok!
>
>here are some filenames that fail:
 0123456789012345
>BewerbungFürAnw   altsbüro.doc
>Graphik01Marken     identität.sxd
>SkriptumzumSemi   narFühren.doc
>WieTeamseffizie       ntwerdenkönnen.doc

 0123456789012345
>but otoh these work:
>WerbeKärntnerBa     llonwerbung.sxw
>Vo 08 - 29. Mär        z 2001.pdf
>TschöranKirche.        jpg
>VölkermarktKirc        heGross.jpg
>

Even though both file sets contain umlauts, or perhaps more accurately extended ASCII chartacters, there is something distinctive in the "failure" set: the umlauts/extended characters appear after the 15th character. If you are using REISER4_LARGE_KEYS, the first fifteen characters will be shifted into the second and third key elements with the final key el containing the hash of the remaining characters 

key = { [dirhash], [hash_bit+fibre_bits+1st 7 chars], [next 8 chars], [hash] }

Code in fs/reiser4/kassign.c assembles the key and uses your chosen hash, R5 being the default. If you created the files without failure, could read/opened them okay but then FSCK reported problems, could this point to a difference in the hash code (w.r.t. extended ASCII)? I'm on holiday now, so cannot check to see if this suspicion holds any water. 

David

p.s. One other possibility is that there is some extended ASCII variance in the the fibration code, but this seems unlikely. 

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Michael Weissenbacher]

> Even though both file sets contain umlauts, or perhaps more accurately extended ASCII chartacters, there is something distinctive in the "failure" set: the umlauts/extended characters appear after the 15th character. If you are using REISER4_LARGE_KEYS, the first fifteen characters will be shifted into the second and third key elements with the final key el containing the hash of the remaining characters 
exactly! the problem occurs when using extended characters that appear 
after the 15th character!
> Code in fs/reiser4/kassign.c assembles the key and uses your chosen hash, R5 being the default. If you created the files without failure, could read/opened them okay but then FSCK reported problems, could this point to a difference in the hash code (w.r.t. extended ASCII)? I'm on holiday now, so cannot check to see if this suspicion holds any water. 
yes, create/read/open works ok, a diff shows no difference. after my 
first tests i panicked because fsck.reiser4 reported "fatal corruptions" 
and used --build-fs as suggested. fsck.reiser4 then moved these files to 
the lost+found directory. fsck.reiser4 didn't report corruoption after 
that, but there was no way of finding out where the files were before or 
what their names were. so with this bug fsck.reiser4 is unusable for my 
situation.

would it do any good trying without the REISER4_LARGE_KEYS option?

thanks for your time,
Michael

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[David Dabbs]

| Michael Weissenbacher 
> David Dabbs wrote:
> Even though both file sets contain umlauts, or perhaps more accurately extended
> ASCII chartacters, there is something distinctive in the "failure" set: the 
> umlauts/extended characters appear after the 15th character. If you are using 
> REISER4_LARGE_KEYS, the first fifteen characters will be shifted into the second
> and third key elements with the final key el containing the hash of the remaining
> characters 
| exactly! the problem occurs when using extended characters that appear
| after the 15th character!

> Code in fs/reiser4/kassign.c assembles the key and uses your chosen hash, R5 
> being the default. If you created the files without failure, could read/opened
> them okay but then FSCK reported problems, could this point to a difference in
> the hash code (w.r.t. extended ASCII)? I'm on holiday now, so cannot check 
> to see if this suspicion holds any water. 

| yes, create/read/open works ok, a diff shows no difference. after my 
| first tests i panicked because fsck.reiser4 reported "fatal corruptions" 
| and used --build-fs as suggested. fsck.reiser4 then moved these files to 
| the lost+found directory. fsck.reiser4 didn't report corruoption after 
| that, but there was no way of finding out where the files were before or 
| what their names were. so with this bug fsck.reiser4 is unusable for my 
| situation.
| 
| would it do any good trying without the REISER4_LARGE_KEYS option?
| 

Probably not. All that will do is drop the third key element, so you will then likely see problems with names where the extended character(s) appear after the seventh character. If you feel energetic and want to do it, try disabling LARGE_KEY, and retesting. Before doing so, however, try setting the filesystem's default fibration plugin to none or whatever the 'no fibration' option is. This will remove fibration code from the suspect list if the retest is successful. 

| thanks for your time,
| Michael

My pleasure. Thank /you/ for helping to debug!

David D.

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[David Dabbs]

| Michael Weissenbacher 
> David Dabbs wrote:
> Even though both file sets contain umlauts, or perhaps more accurately extended
> ASCII chartacters, there is something distinctive in the "failure" set: the 
> umlauts/extended characters appear after the 15th character. If you are using 
> REISER4_LARGE_KEYS, the first fifteen characters will be shifted into the second
> and third key elements with the final key el containing the hash of the remaining
> characters 
| exactly! the problem occurs when using extended characters that appear
| after the 15th character!

> Code in fs/reiser4/kassign.c assembles the key and uses your chosen hash, R5 
> being the default. If you created the files without failure, could read/opened
> them okay but then FSCK reported problems, could this point to a difference in
> the hash code (w.r.t. extended ASCII)? I'm on holiday now, so cannot check 
> to see if this suspicion holds any water. 

| yes, create/read/open works ok, a diff shows no difference. after my 
| first tests i panicked because fsck.reiser4 reported "fatal corruptions" 
| and used --build-fs as suggested. fsck.reiser4 then moved these files to 
| the lost+found directory. fsck.reiser4 didn't report corruoption after 
| that, but there was no way of finding out where the files were before or 
| what their names were. so with this bug fsck.reiser4 is unusable for my 
| situation.
| 
| would it do any good trying without the REISER4_LARGE_KEYS option?
| 

Probably not. All that will do is drop the third key element, so you will then likely see problems with names where the extended character(s) appear after the seventh character. If you feel energetic and want to do it, try disabling LARGE_KEY, and retesting. Before doing so, however, try setting the filesystem's default fibration plugin to none or whatever the 'no fibration' option is. This will remove fibration code from the suspect list if the retest is successful. 

| thanks for your time,
| Michael

My pleasure. Thank /you/ for helping to debug!

David D.

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Michael Weissenbacher]

> 
> My pleasure. Thank /you/ for helping to debug!
> 
*-*-*-*-*-*-*-*-*-*
if have a rather long answer this time, this is a test run i made today. 
i wanted to include full details. i'm wondering if there is still 
something these files have in common. first i created some test files on 
a spare partition with "touch":
*-*-*-*-*-*-*-*-*-*

criminal tmp # ls -lha
total 1.5K
drwxr-xr-x   3 root root  20 31. Aug 10:28 .
drwxr-xr-x  12 root root 392 29. Aug 16:31 ..
-rw-r--r--   1 root root   0 31. Aug 10:23 123456789012345678901234ö
-rw-r--r--   1 root root   0 31. Aug 10:23 123456789012345678901234ö.doc
-rw-r--r--   1 root root   0 31. Aug 10:23 12345678901234567890123ö
-rw-r--r--   1 root root   0 31. Aug 10:23 1234567890123456789012ö
-rw-r--r--   1 root root   0 31. Aug 10:23 123456789012345678901ö
-rw-r--r--   1 root root   0 31. Aug 10:22 12345678901234567890ö
-rw-r--r--   1 root root   0 31. Aug 10:22 1234567890123456789ö
-rw-r--r--   1 root root   0 31. Aug 10:22 123456789012345678ö
-rw-r--r--   1 root root   0 31. Aug 10:22 12345678901234567ö
-rw-r--r--   1 root root   0 31. Aug 10:26 1234567890123456äöülala.txt
-rw-r--r--   1 root root   0 31. Aug 10:20 1234567890123456ö
-rw-r--r--   1 root root   0 31. Aug 10:20 123456789012345ö
-rw-r--r--   1 root root   0 31. Aug 10:25 BewerbungFürAnwaltsbü
-rw-r--r--   1 root root   0 31. Aug 10:21 BewerbungFürAnwaltsbüro.doc
-rw-r--r--   1 root root   0 31. Aug 10:27 BewerbungFürAnwaltsbüro.txt
-rw-r--r--   1 root root   0 31. Aug 10:28 Graphik01Markenidentitöt.txt
-rw-r--r--   1 root root   0 31. Aug 10:27 LässigerDaäeinaüasd.sxd
-rw-r--r--   1 root root   0 31. Aug 10:20 asdfghjklqwertzö

*-*-*-*-*-*-*-*-*-*
with these filename-set fsck reported only 1 fatal corruption
*-*-*-*-*-*-*-*-*-*

criminal mnt # fsck.reiser4 /dev/sda1
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************

Fscking the /dev/sda1 block device.
Will check the consistency of the Reiser4 SuperBlock.
Will check the consistency of the Reiser4 FileSystem.
Continue?
(Yes/No): y
***** fsck.reiser4 started at Tue Aug 31 10:31:22 2004
Reiser4 journal (journal40) on /dev/sda1: 0 transactions replayed of the 
total 0 blocks.
Reiser4 fs was detected on /dev/sda1.
Master super block (16):
magic:          ReIsEr4
blksize:        4096
format:         0x0 (format40)
uuid:           d0373d79-949c-4de8-aa88-fed3eb9690f9
label:          <none>

Format super block (17):
plugin:         format40
description:    Disk-format for reiser4, ver. 1.0.0
magic:          ReIsEr40FoRmAt
flushes:        0
mkfs id:        0x1b9004a9
blocks:         31271
free blocks:    31246
root block:     23
tail policy:    0x2 (smart)
next oid:       0x10014
file count:     19
tree height:    2
key policy:     LARGE


CHECKING STORAGE TREE
         Read nodes 2
         Nodes left in the tree 2
                 Leaves of them 1, Twigs of them 1
         Time interval: Tue Aug 31 10:31:22 2004 - Tue Aug 31 10:31:22 2004
CHECKING EXTENT REGIONS.
         Read twigs 1
         Time interval: Tue Aug 31 10:31:22 2004 - Tue Aug 31 10:31:22 2004
CHECKING SEMANTIC TREE
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:20c8b16c855]. Should be
[2a:0(NAME):131323334353637:3839303132333435:20c8b1617a5].
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [14]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:1689f9f584a0]. Should be
[2a:0(NAME):131323334353637:3839303132333435:1689f9f4d3f0].
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [15]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:dc740ba51264c]. Should be
[2a:0(NAME):131323334353637:3839303132333435:9326977e040dc].
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [16]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:5090910834f0e6c]. Should be
[2a:0(NAME):131323334353637:3839303132333435:50909105bd60cbc].
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [17]: entry 
has wrong offset
[2a:0(NAME):142657765726275:6e6746fc72416e77:135160352fe624]. Should be
[2a:0(NAME):142657765726275:6e6746fc72416e77:13514d8cfe19f4].
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [18]: entry 
has wrong offset
[2a:0(NAME):142657765726275:6e6746fc72416e77:13516035356e9b]. Should be
[2a:0(NAME):142657765726275:6e6746fc72416e77:13514d8d03a26b].
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [19]: entry 
has wrong offset
[2a:0(NAME):14772617068696b:30314d61726b656e:e284761c4e0e6f]. Should be
[2a:0(NAME):14772617068696b:30314d61726b656e:e284746a1afbdf].
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [20]: entry 
has wrong offset
[2a:0(NAME):15769655465616d:73456666697a6965:36c5742b38d77b7b]. Should be
[2a:0(NAME):15769655465616d:73456666697a6965:36c56b59b94df8cb].
         Found 1 objects.
         Time interval: Tue Aug 31 10:31:22 2004 - Tue Aug 31 10:31:22 2004
***** fsck.reiser4 finished at Tue Aug 31 10:31:22 2004
Closing fs...done

1 fatal corruptions were detected in FileSystem. Run with --build-fs 
option to fix them.

*-*-*-*-*-*-*-*-*-*
I know that this 1 fatal corruption appeared after "touching" the 
filename "BewerbungFürAnwaltsbüro.doc", because i always did (touch; 
umount; fsck.reiser4; mount; touch...). all other files did not seem to 
cause fatal corruption. So i wanted to see of only this filename gets 
moved to lost+found.
*-*-*-*-*-*-*-*-*-*

criminal mnt # fsck.reiser4 /dev/sda1 --build-fs
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************

Fscking the /dev/sda1 block device.
Will check the consistency of the Reiser4 SuperBlock.
Will build the Reiser4 FileSystem.
Continue?
(Yes/No): y
***** fsck.reiser4 started at Tue Aug 31 10:31:44 2004
Reiser4 journal (journal40) on /dev/sda1: 0 transactions replayed of the 
total 0 blocks.
Reiser4 fs was detected on /dev/sda1.
Master super block (16):
magic:          ReIsEr4
blksize:        4096
format:         0x0 (format40)
uuid:           d0373d79-949c-4de8-aa88-fed3eb9690f9
label:          <none>

Format super block (17):
plugin:         format40
description:    Disk-format for reiser4, ver. 1.0.0
magic:          ReIsEr40FoRmAt
flushes:        0
mkfs id:        0x1b9004a9
blocks:         31271
free blocks:    31246
root block:     23
tail policy:    0x2 (smart)
next oid:       0x10014
file count:     19
tree height:    2
key policy:     LARGE


CHECKING STORAGE TREE
         Read nodes 2
         Nodes left in the tree 2
                 Leaves of them 1, Twigs of them 1
         Time interval: Tue Aug 31 10:31:45 2004 - Tue Aug 31 10:31:45 2004
CHECKING EXTENT REGIONS.
         Read twigs 1
         Time interval: Tue Aug 31 10:31:45 2004 - Tue Aug 31 10:31:45 2004
LOOKING FOR UNCONNECTED NODES
         Read nodes 0
         Good nodes 0
                 Leaves of them 0, Twigs of them 0
         Time interval: Tue Aug 31 10:31:45 2004 - Tue Aug 31 10:31:45 2004
CHECKING EXTENT REGIONS.
         Read twigs 0
         Time interval: Tue Aug 31 10:31:45 2004 - Tue Aug 31 10:31:45 2004
INSERTING UNCONNECTED NODES
1. Twigs: done
2. Twigs by item: done
3. Leaves: done
4. Leaves by item: done
         Twigs: read 0, inserted 0, by item 0, empty 0
         Leaves: read 0, inserted 0, by item 0
         Time interval: Tue Aug 31 10:31:45 2004 - Tue Aug 31 10:31:45 2004
CHECKING SEMANTIC TREE
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:20c8b16c855]. Should be
[2a:0(NAME):131323334353637:3839303132333435:20c8b1617a5]. Removed.
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:1689f9f584a0]. Should be
[2a:0(NAME):131323334353637:3839303132333435:1689f9f4d3f0]. Removed.
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:dc740ba51264c]. Should be
[2a:0(NAME):131323334353637:3839303132333435:9326977e040dc]. Removed.
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:5090910834f0e6c]. Should be
[2a:0(NAME):131323334353637:3839303132333435:50909105bd60cbc]. Removed.
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):142657765726275:6e6746fc72416e77:135160352fe624]. Should be
[2a:0(NAME):142657765726275:6e6746fc72416e77:13514d8cfe19f4]. Removed.
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):142657765726275:6e6746fc72416e77:13516035356e9b]. Should be
[2a:0(NAME):142657765726275:6e6746fc72416e77:13514d8d03a26b]. Removed.
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):14772617068696b:30314d61726b656e:e284761c4e0e6f]. Should be
[2a:0(NAME):14772617068696b:30314d61726b656e:e284746a1afbdf]. Removed.
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry 
has wrong offset
[2a:0(NAME):15769655465616d:73456666697a6965:36c5742b38d77b7b]. Should be
[2a:0(NAME):15769655465616d:73456666697a6965:36c56b59b94df8cb]. Removed.
FSCK: Node (24), item (0), [29:0:2a] (stat40): wrong size (21), Fixed to 
(13).
FSCK: Node (24), item (0), [29:0:2a] (stat40): wrong bytes (1278), Fixed 
to (650).
FSCK: No 'lost+found' entry found. Building a new object with the key 
2a:0:ffff.
FSCK: Failed to recognize the plugin for the directory [2a:0:ffff].
FSCK: Trying to recover the directory [2a:0:ffff] with the default 
plugin--dir40.
FSCK: The file [2a:0:ffff] does not have a StatData item. Creating a new 
one. Plugin dir40.
FSCK: Directory [2a:0:ffff]: The entry "." is not found. Insert a new 
one. Plugin (dir40).
FSCK: Node (24), item (2), [2a:0:ffff] (stat40): wrong size (0), Fixed 
to (1).
FSCK: Node (24), item (2), [2a:0:ffff] (stat40): wrong bytes (0), Fixed 
to (50).
         Found 21 objects.
         Time interval: Tue Aug 31 10:31:45 2004 - Tue Aug 31 10:31:45 2004
CLEANUPING STORAGE TREE
         Removed items 0
         Time interval: Tue Aug 31 10:31:45 2004 - Tue Aug 31 10:31:45 2004
***** fsck.reiser4 finished at Tue Aug 31 10:31:45 2004
Closing fs...done

FS is consistent.

*-*-*-*-*-*-*-*-*-*
OK, let's see which filenames were moved:
*-*-*-*-*-*-*-*-*-*

criminal tmp # ls -lha
total 2.0K
drwxr-xr-x   5 root root  14 31. Aug 10:29 .
drwxr-xr-x  12 root root 392 29. Aug 16:31 ..
-rw-r--r--   1 root root   0 31. Aug 10:23 1234567890123456789012ö
-rw-r--r--   1 root root   0 31. Aug 10:23 123456789012345678901ö
-rw-r--r--   1 root root   0 31. Aug 10:22 12345678901234567890ö
-rw-r--r--   1 root root   0 31. Aug 10:22 1234567890123456789ö
-rw-r--r--   1 root root   0 31. Aug 10:22 123456789012345678ö
-rw-r--r--   1 root root   0 31. Aug 10:22 12345678901234567ö
-rw-r--r--   1 root root   0 31. Aug 10:20 1234567890123456ö
-rw-r--r--   1 root root   0 31. Aug 10:20 123456789012345ö
-rw-r--r--   1 root root   0 31. Aug 10:25 BewerbungFürAnwaltsbü
-rw-r--r--   1 root root   0 31. Aug 10:27 LässigerDaäeinaüasd.sxd
-rw-r--r--   1 root root   0 31. Aug 10:20 asdfghjklqwertzö
drwxr-xr-x   3 root root  10 31. Aug 10:31 lost+found

criminal tmp # ls lost+found/
lost_name_2a:131323334353637:1000bÿ¿`oÿ·êÓã·?? 
lost_name_2a:142657765726275:10004ÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000cÿ¿`oÿ·êÓã·?? 
lost_name_2a:142657765726275:10011ÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000dÿ¿`oÿ·êÓã·?? 
lost_name_2a:14772617068696b:10012ÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000fÿ¿`oÿ·êÓã·?? 
lost_name_2a:15769655465616d:10013ÿ¿`oÿ·êÓã·??

*-*-*-*-*-*-*-*-*-*
Hey, 8 files are trash now! And look at the filenames in lost+found! I 
can't even rm these files because they contain these weird characters... 
So i guess i'll have to reformat.
*-*-*-*-*-*-*-*-*-*

Michael

Re: fsck.reiser4 problem

[Michael Weissenbacher]

> 
> "rm lost*" should work...
> 
nope:
criminal lost+found # ls
lost_name_2a:131323334353637:1000bÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000cÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000dÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000fÿ¿`oÿ·êÓã·??
lost_name_2a:142657765726275:10004ÿ¿`oÿ·êÓã·??
lost_name_2a:142657765726275:10011ÿ¿`oÿ·êÓã·??
lost_name_2a:14772617068696b:10012ÿ¿`oÿ·êÓã·??
lost_name_2a:15769655465616d:10013ÿ¿`oÿ·êÓã·??
criminal lost+found # ls -l
ls: lost_name_2a:131323334353637:1000bÿ¿`oÿ·êÓã·        ”: No such file 
or directory
ls: lost_name_2a:131323334353637:1000cÿ¿`oÿ·êÓã·        ”: No such file 
or directory
ls: lost_name_2a:131323334353637:1000dÿ¿`oÿ·êÓã·        ”: No such file 
or directory
ls: lost_name_2a:131323334353637:1000fÿ¿`oÿ·êÓã·        ”: No such file 
or directory
ls: lost_name_2a:14772617068696b:10012ÿ¿`oÿ·êÓã·        ”: No such file 
or directory
ls: lost_name_2a:142657765726275:10004ÿ¿`oÿ·êÓã·        ”: No such file 
or directory
ls: lost_name_2a:142657765726275:10011ÿ¿`oÿ·êÓã·        ”: No such file 
or directory
ls: lost_name_2a:15769655465616d:10013ÿ¿`oÿ·êÓã·        ”: No such file 
or directory
total 0
criminal lost+found # rm lost*
rm: cannot remove `lost_name_2a:131323334353637:1000bÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
rm: cannot remove `lost_name_2a:131323334353637:1000cÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
rm: cannot remove `lost_name_2a:131323334353637:1000dÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
rm: cannot remove `lost_name_2a:131323334353637:1000fÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
rm: cannot remove `lost_name_2a:142657765726275:10004ÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
rm: cannot remove `lost_name_2a:142657765726275:10011ÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
rm: cannot remove `lost_name_2a:14772617068696b:10012ÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
rm: cannot remove `lost_name_2a:15769655465616d:10013ÿ¿`oÿ·êÓã·\t\224': 
No such file or directory
criminal lost+found # ls
lost_name_2a:131323334353637:1000bÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000cÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000dÿ¿`oÿ·êÓã·??
lost_name_2a:131323334353637:1000fÿ¿`oÿ·êÓã·??
lost_name_2a:142657765726275:10004ÿ¿`oÿ·êÓã·??
lost_name_2a:142657765726275:10011ÿ¿`oÿ·êÓã·??
lost_name_2a:14772617068696b:10012ÿ¿`oÿ·êÓã·??
lost_name_2a:15769655465616d:10013ÿ¿`oÿ·êÓã·??

still there :)
i guess removing lost+found would work, but how are these strange 
filenames created in the first place?

Michael

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Andreas]

Hello,

> Before doing so, however, try setting
> the filesystem's default fibration plugin to none or whatever the 'no
> fibration' option is. This will remove fibration code from the suspect list
> if the retest is successful.

I can reproduce the reporting of filesystem corruptions with and 
"without" fibration. But fsck.reiser4 crashes on --build-fs on my 
machine. :-(

System: 
linux-2.6.8.1-mm4 
libaal-1.0.0
reiser4progs-1.0.0

Bye
 Andreas

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Vladimir Saveliev]

Hello

On Tue, 2004-08-31 at 14:09, Andreas wrote:
> Hello,
> 
> > Before doing so, however, try setting
> > the filesystem's default fibration plugin to none or whatever the 'no
> > fibration' option is. This will remove fibration code from the suspect list
> > if the retest is successful.
> 
> I can reproduce the reporting of filesystem corruptions with and 
> "without" fibration. But fsck.reiser4 crashes on --build-fs on my 
> machine. :-(
> 

Would you, please, provide exact sequences of operations which confuses
reiser4?

> System: 
> linux-2.6.8.1-mm4 
> libaal-1.0.0
> reiser4progs-1.0.0
> 
> Bye
>  Andreas
> 

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Michael Weissenbacher]

> Would you, please, provide exact sequences of operations which confuses
> reiser4?

very simple:

criminal mnt # mkfs.reiser4 /dev/sda1
mkfs.reiser4 1.0.0
Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by
reiser4progs/COPYING.

Block size 4096 will be used.
Linux 2.6.8.1-mm2 is detected.
Uuid 7219a23f-d1ad-4baf-aa90-4194418af02f will be used.
Reiser4 is going to be created on /dev/sda1.
(Yes/No): y
Creating reiser4 on /dev/sda1 ... done
criminal mnt # mount /dev/sda1 tmp/
criminal mnt # ls
backup      cdrecorder  diff.txt       dvdrom  mp3            tmp
cardreader  cdrom       diff_fsck.txt  floppy  myfilesonline  windows
criminal mnt # cd tmp/
criminal tmp # ls
criminal tmp # touch BewerbungFürAnwaltsbüro.doc
criminal tmp # ls
BewerbungFürAnwaltsbüro.doc
criminal tmp # cd ..
criminal mnt # umount tmp/
criminal mnt # fsck.reiser4 /dev/sda1
*******************************************************************
This is an EXPERIMENTAL version of fsck.reiser4. Read README first.
*******************************************************************

Fscking the /dev/sda1 block device.
Will check the consistency of the Reiser4 SuperBlock.
Will check the consistency of the Reiser4 FileSystem.
Continue?
(Yes/No): y
***** fsck.reiser4 started at Tue Aug 31 14:34:46 2004
Reiser4 journal (journal40) on /dev/sda1: 0 transactions replayed of the 
total 0blocks.
Reiser4 fs was detected on /dev/sda1.
Master super block (16):
magic:          ReIsEr4
blksize:        4096
format:         0x0 (format40)
uuid:           7219a23f-d1ad-4baf-aa90-4194418af02f
label:          <none>

Format super block (17):
plugin:         format40
description:    Disk-format for reiser4, ver. 1.0.0
magic:          ReIsEr40FoRmAt
flushes:        0
mkfs id:        0x48d945af
blocks:         31271
free blocks:    31246
root block:     23
tail policy:    0x2 (smart)
next oid:       0x10001
file count:     1
tree height:    2
key policy:     LARGE


CHECKING STORAGE TREE
         Read nodes 2
         Nodes left in the tree 2
                 Leaves of them 1, Twigs of them 1
         Time interval: Tue Aug 31 14:34:46 2004 - Tue Aug 31 14:34:46 2004
CHECKING EXTENT REGIONS.
         Read twigs 1
         Time interval: Tue Aug 31 14:34:46 2004 - Tue Aug 31 14:34:46 2004
CHECKING SEMANTIC TREE
FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [2]: entry has
wrong offset [2a:0(NAME):142657765726275:6e6746fc72416e77:135160352fe624].
Should be [2a:0(NAME):142657765726275:6e6746fc72416e77:13514d8cfe19f4].
         Found 1 objects.
         Time interval: Tue Aug 31 14:34:46 2004 - Tue Aug 31 14:34:46 2004
***** fsck.reiser4 finished at Tue Aug 31 14:34:46 2004
Closing fs...done

1 fatal corruptions were detected in FileSystem. Run with --build-fs 
option to fix them.


that's enough...
Michael

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Andreas]

Hello,

> Would you, please, provide exact sequences of operations which confuses
> reiser4?

mkfs.reiser4 /dev/discs/disc0/part2
mount /dev/discs/disc0/part2 /mnt/d0p2
touch /mnt/d0p2/abcdefghijklmnopqäöüßßßß
umount /mnt/d0p2
fsck.reiser4 /dev/discs/disc0/part2


And as I now realize "fsck.reiser4 --build-fs" produces always a segmentation 
fault here, even on a newly created Reiser4 filesystem.

Bye
 Andreas

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Vladimir Saveliev]

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

Hello

On Tue, 2004-08-31 at 18:03, Andreas wrote:
> Hello,
> 
> > Would you, please, provide exact sequences of operations which confuses
> > reiser4?
> 
> mkfs.reiser4 /dev/discs/disc0/part2
> mount /dev/discs/disc0/part2 /mnt/d0p2
> touch /mnt/d0p2/abcdefghijklmnopqäöüßßßß
> umount /mnt/d0p2
> fsck.reiser4 /dev/discs/disc0/part2
> 
> 
> And as I now realize "fsck.reiser4 --build-fs" produces always a segmentation 
> fault here, even on a newly created Reiser4 filesystem.
> 

Would you please try with the attached patch.

> Bye
>  Andreas
> 

[-- Attachment #2: r5_hash.c.diff --]
[-- Type: text/plain, Size: 487 bytes --]

--- reiser4progs-1.0.0/plugin/hash/r5_hash/r5_hash.c.orig	2004-08-31 18:48:01.749889832 +0400
+++ reiser4progs-1.0.0/plugin/hash/r5_hash/r5_hash.c	2004-08-31 18:46:08.864051088 +0400
@@ -9,10 +9,12 @@
 uint64_t r5_hash_build(char *name, uint32_t len) {
 	uint32_t i;
 	uint64_t a = 0;
+	unsigned char *uname;
 	
+	uname = (unsigned char *)name;
 	for (i = 0; i < len; i++) {
-		a += name[i] << 4;
-		a += name[i] >> 4;
+		a += uname[i] << 4;
+		a += uname[i] >> 4;
 		a *= 11;
 	}
     

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Michael Weissenbacher]

> 
> Would you please try with the attached patch.
> 
hooray, i just tried it, your patch fixes my problem! after recompiling 
reiser4progs:

criminal mnt # fsck.reiser4 /dev/sda1
...
***** fsck.reiser4 finished at Tue Aug 31 16:59:05 2004
Closing fs...done

FS is consistent.

i'm planning to move my / partition to reiser4 soon if no other problems 
occur.
kind regards,
Michael

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[David Dabbs]

> 
> My pleasure. Thank /you/ for helping to debug!
> 
*-*-*-*-*-*-*-*-*-*
if have a rather long answer this time, this is a test run i made today. 
i wanted to include full details. i'm wondering if there is still 
something these files have in common. first i created some test files on 
a spare partition with "touch":
*-*-*-*-*-*-*-*-*-*

Michael, thank you for taking the time to retest and for sending the detailed traces. From the look of the messages like the following:

FSCK: Directory [29:0:2a] (dir40), node [24], item [1], unit [13]: entry has wrong offset
[2a:0(NAME):131323334353637:3839303132333435:20c8b16c855]. Should be
[2a:0(NAME):131323334353637:3839303132333435:20c8b1617a5].

the problem directory entries differ in the final key element, which is the hash value as I mentioned before. If I had access to the source I could look into this further. My suspicion is that the reiserfstools have slightly different hash calculation or some hash variance caused when extended ASCII chars appear in the hashed portion of a filename. 

Can anyone at Namesys comment on Michael's posts? 

David

Re: fsck.reiser4 problem (was: reiser4 corruption problem)

[Michael Weissenbacher]

Hello David,
> Can anyone at Namesys comment on Michael's posts? 
Vladimir Saveliev submitted a patch for the hash calculation code of 
reiser4progs today, which solved my problem. I'm running new tests at 
the moment and so far everything is stable.

don't forget to enjoy your vacation :)
Michael