fsck.reiser4 problem (was: reiser4 corruption problem)
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ärz 2001.pdf
>TschöranKirche.jpg
>VölkermarktKircheGross.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)
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 ;) )
Re: fsck.reiser4 problem (was: reiser4 corruption problem)
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)
| 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 > 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.
