Dear Mich,
thanks for your help and suggestion:
> It might be interesting for you to try a newer kernel, and use scrub
> on this volume if you have the two disks RAIDed.
I have now scrubbed the Disk:
./btrfs scrub status /mnt/other/
scrub status for a15eede9-1a92-47d8-940a-adc7cf97352d
scrub started at Sun Dec 9 13:48:57 2012 and finished after
3372 seconds
total bytes scrubbed: 1.10TB with 0 errors
That's odd, as in one folder, data is missing (I could have deleted it,
but I'd be very surprised...)
Also, when I run btrfsck, I get errors:
On sdc1:
root 261 inode 64370 errors 400
root 261 inode 64373 errors 400
root 261 inode 64375 errors 400
root 261 inode 64376 errors 400
found 1203899371520 bytes used err is 1
total csum bytes: 1173983136
total tree bytes: 1740640256
total fs tree bytes: 280260608
btree space waste bytes: 212383383
file data blocks allocated: 28032005304320
referenced 1190305632256
Btrfs v0.20-rc1-37-g91d9eec
On sdb1:
root 261 inode 64373 errors 400
root 261 inode 64375 errors 400
root 261 inode 64376 errors 400
found 1203899371520 bytes used err is 1
total csum bytes: 1173983136
total tree bytes: 1740640256
total fs tree bytes: 280260608
btree space waste bytes: 212383383
file data blocks allocated: 28032005304320
referenced 1190305632256
Btrfs v0.20-rc1-37-g91d9eec
And when I try to mount one of the two raided disks, I get:
[ 1173.773861] device fsid a15eede9-1a92-47d8-940a-adc7cf97352d devid 1
transid 140194 /dev/sdb1
[ 1173.774695] btrfs: failed to read the system array on sdb1
[ 1173.774854] btrfs: open_ctree failed
while the other works:
[ 1177.927096] device fsid a15eede9-1a92-47d8-940a-adc7cf97352d devid 2
transid 140194 /dev/sdc1
Do you have hints for me?
The Kernel now is 3.3.7-030307-generic (anything more recent, I would
have to compile myself, which I will do, if you suggest to)
Greetings,
Hendrik
Am 06.12.2012 20:09, schrieb Mitch Harder:
On Wed, Dec 5, 2012 at 2:50 PM, Hendrik Friedel <hend...@friedels.name> wrote:
Dear all,
thanks for developing btrfsck!
Now, I'd like to contribute -as far as I can. I'm not a developer, but I do
have some linux-experience.
I've been using btrfsck on two 3TB HDDs (mirrored) for a while now under
Kernel 3.0. Now it's corrupt. I had some hard resets of the machine -which
might have contributed. I do have a backup of the data -at least of the
important stuff. Some TV-Recordings are missing. The reason I am writing is,
to support the development.
Unfortunately, btrfsck (latest git-version) crashes with a segmentation
fault, when trying to repair this.
Here's the backtrace:
root 261 inode 64375 errors 400
root 261 inode 64376 errors 400
btrfsck: disk-io.c:382: __commit_transaction: Assertion `!(!eb || eb->start
!= start)' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff784c425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)
(gdb) backtrace
#0 0x00007ffff784c425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff784fb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff78450ee in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff7845192 in __assert_fail () from
/lib/x86_64-linux-gnu/libc.so.6
#4 0x000000000040d3ae in __commit_transaction (trans=0x62e010,
root=0xb66ae0) at disk-io.c:382
#5 0x000000000040d4d8 in btrfs_commit_transaction (trans=0x62e010,
root=0xb66ae0) at disk-io.c:415
#6 0x000000000040743d in main (ac=<optimized out>, av=<optimized out>) at
btrfsck.c:3587
Now, here's where my debugging knowledge ends. Are you interested in
debugging this further, or is it a known bug?
Line 382 in disk-io.c is:
BUG_ON(!eb || eb->start != start);
So, basically, btrfsck is intentionally crashing because it doesn't
know how to handle this condition.
Future refinements of btrfsck will probably include proper error
messages for issues that can't be handled, or perhaps even fix the
error.
It might be interesting for you to try a newer kernel, and use scrub
on this volume if you have the two disks RAIDed.
--
Hendrik Friedel
Auf dem Brink 12
28844 Weyhe
Mobil 0178 1874363
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
