All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: fsck.reiser4 problem (was: reiser4 corruption problem)
@ 2004-08-31  1:24 David Dabbs
  2004-08-31  8:52 ` Michael Weissenbacher
  2004-08-31 10:09 ` fsck.reiser4 problem (was: reiser4 corruption problem) Andreas
  0 siblings, 2 replies; 16+ messages in thread
From: David Dabbs @ 2004-08-31  1:24 UTC (permalink / raw)
  To: Michael Weissenbacher, reiserfs-list


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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: fsck.reiser4 problem (was: reiser4 corruption problem)
@ 2004-08-31 16:18 David Dabbs
  2004-08-31 16:32 ` Michael Weissenbacher
  0 siblings, 1 reply; 16+ messages in thread
From: David Dabbs @ 2004-08-31 16:18 UTC (permalink / raw)
  To: Michael Weissenbacher, ReiserFS List; +Cc: ReiserFS-Dev

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




^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: fsck.reiser4 problem (was: reiser4 corruption problem)
@ 2004-08-31  1:10 David Dabbs
  0 siblings, 0 replies; 16+ messages in thread
From: David Dabbs @ 2004-08-31  1:10 UTC (permalink / raw)
  To: Michael Weissenbacher, reiserfs-list


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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* fsck.reiser4 problem (was: reiser4 corruption problem)
@ 2004-08-30 21:07 David Dabbs
  2004-08-31  0:02 ` Michael Weissenbacher
  0 siblings, 1 reply; 16+ messages in thread
From: David Dabbs @ 2004-08-30 21:07 UTC (permalink / raw)
  To: reiserfs-list

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. 



^ permalink raw reply	[flat|nested] 16+ messages in thread
* reiser4 corruption problem (maybe related to "Broken reiser4 FS")
@ 2004-08-26 23:15 Michael Weissenbacher
  2004-08-28 21:49 ` fsck.reiser4 problem (was: reiser4 corruption problem) Michael Weissenbacher
  0 siblings, 1 reply; 16+ messages in thread
From: Michael Weissenbacher @ 2004-08-26 23:15 UTC (permalink / raw)
  To: reiserfs-list

i've tested reiser4 on a spare partition to see how well it would work 
for me. unfortunately i hit some corruption problem. it seems perfectly 
reproducable, so hardware error is very unlikely.

first some details on my system:
AMD Athlon(tm) XP 2400+
512 MB DDR-RAM (tested with memtest)
MSI K7N2G board (nforce2 chipset)
hard disk for testing: MAXTOR 6L080J4 (80GB), partitioned like:
    Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1        4866    39086113+  83  Linux
/dev/hdb2            4867        9732    39086145   83  Linux
criminal mnt # uname -a
Linux criminal 2.6.8.1-mm4 #4 Wed Aug 25 01:34:48 CEST 2004 i686 AMD 
Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux
the distro is gentoo and i use reiser4progs1.0.1

the test i did is rather simple: i have a 2.3GB .tar.bz2 file that 
cotains 66588 files and about 3.1GB of data. in the first test i 
formatted /dev/hdb1 as reiser4 and /dev/hdb2 as reiser3. i extracted the 
.tar.bz2 on both of them. after that i umounted both and ran a fsck on 
them. the reiser3 partition was ok, but the reiser4 partition was 
corrupted.

ok, but what's really intersting now:
i reformatted both partitions and switched hdb1 to reiser3 and hdb2 to 
reiser4. i extracted the same file on both and what happens? exaclty the 
same corrutions now on hdb2 (at least the count is the same and the 
errors look very similar)! and again reiser3 is ok!

i put the output of both tests into a file that is available at
http://www.dermichi.com/ablage/reiser4/reiser4_troubles.txt

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.

anyone got an idea?

thanks,
michael weissenbacher

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2004-08-31 16:32 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-31  1:24 fsck.reiser4 problem (was: reiser4 corruption problem) David Dabbs
2004-08-31  8:52 ` Michael Weissenbacher
     [not found]   ` <41344719.7040700@free.fr>
2004-08-31  9:43     ` fsck.reiser4 problem Michael Weissenbacher
2004-08-31 10:09 ` fsck.reiser4 problem (was: reiser4 corruption problem) Andreas
2004-08-31 12:30   ` Vladimir Saveliev
2004-08-31 12:37     ` Michael Weissenbacher
2004-08-31 14:03     ` Andreas
2004-08-31 14:43       ` Vladimir Saveliev
2004-08-31 15:04         ` Michael Weissenbacher
  -- strict thread matches above, loose matches on Subject: below --
2004-08-31 16:18 David Dabbs
2004-08-31 16:32 ` Michael Weissenbacher
2004-08-31  1:10 David Dabbs
2004-08-30 21:07 David Dabbs
2004-08-31  0:02 ` Michael Weissenbacher
2004-08-26 23:15 reiser4 corruption problem (maybe related to "Broken reiser4 FS") Michael Weissenbacher
2004-08-28 21:49 ` fsck.reiser4 problem (was: reiser4 corruption problem) Michael Weissenbacher
2004-08-29  6:54   ` Adrian Ulrich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.