Messages in this thread Patch in this message | | | From | Martin Schaffner <> | Subject | Re: hfsplus bugs in linux-2.6.5 | Date | Sat, 22 May 2004 04:27:44 +0100 |
| |
On 17.05.2004, at 00:19, Roman Zippel wrote:
>> Here's how to trigger a hfsplus bug in linux-2.6.5: >> [...] >> mkdir a; mkdir b >> mv a b > > Thanks for the report, renames of directories were broken, the patch > below > fixes this. Could you please try again, if it solves your problem?
Your patch fixes the above problem, thanks.
Unfortunately, the first bug I encountered (which lead me to stress-test hfsplus support in the first place) is still present.
I still wasn't able to reproduce it on another partition than my Mac OS X root partition. :-(
The symptoms are as follows: Whenever I try to write a sufficently large file (always larger than 512k), or try to read a sufficiently large file (say a 4 MB file) with any program, I get:
HFS+-fs: request for non-existent node 1929183232 in B*Tree
after which the I/O operation fails like this:
dd: writing 'bla': Cannot allocate memory
The number of the non-existent node will not change until I do a fsck.
After linux handled the partition, Apple's fsck_hfs will always report errors, which it usually can't fix, but TechTool Deluxe can.
In the past, hpfsck (from ftp.penguinppc.org/users/hasi/) would report lots of cases of:
Backpointers in Node 239 index 70 out of order (0x1001e982 >= 0x1002298e)
with differing indices but constant node number (until the next fsck).
However, lately, all I get is:
[...] *** Checking Backup Volume Header: Unexpected Volume signature ' ' expected 'H+' hpfsck: hpfsck: This is not a HFS+ volume (Unknown error 4294967295)
However, I think I have narrowed it down somewhat: If I apply:
diff -ur linux-2.6.6/fs/hfsp.bak/bfind.c linux-2.6.6/fs/hfsplus/bfind.c --- linux-2.6.6/fs/hfsp.bak/bfind.c Fri May 21 11:38:33 2004 +++ linux-2.6.6/fs/hfsplus/bfind.c Fri May 21 15:31:16 2004 @@ -64,7 +64,7 @@ else e = rec - 1; } while (b <= e); - //printk("%d: %d,%d,%d\n", bnode->this, b, e, rec); + printk("problem is here: %d: %d,%d,%d\n", bnode->this, b, e, rec); if (rec != e && e >= 0) { len = hfs_brec_lenoff(bnode, e, &off); keylen = hfs_brec_keylen(bnode, e); then, this new printk happens often. More importantly, it happens ALWAYS before the "request for non-existent node" message and subsequent failure.
I guess that sometimes, the bnodes aren't ordered correctly, and therefore we don't find the correct one. If the while loop is terminated without "goto done;", shouldn't we fall back to checking all bnodes for a matching key, in case the inodes aren't ordered correctly? I've tried to implement exactly that, but this resulted in lots of Oopses - I guess I'd have to dig deeper, guess less, and understand more to find out more. Unfortunately, I can't debug the problem while it's happening, because my ibook doesn't have a serial port...
How could I get to the root of the problem?
Thanks,
Martin
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |