We have met a situation when reiserfsck segfaulted on one of our
partitions. I have performed a small research and the cause appeared
to be wrong detection of transaction count.
Our FS had only one journal transaction, however trans_count which was
passed to progbar_update() as maximum transaction value was detected
as (last_transaction - first_transaction) which in our case was 0.
Thus progbar_update() resulted in segmentation fault:
(gdb) bt
"Replaying journal", curr=1, max=0, dpynum=1) at progbar.c:80
Here is part of debugreiserfs -j output
Journal header (block #8210 of ./partition.bug):
j_last_flush_trans_id 0
j_first_unflushed_offset 0
j_mount_id 10
Device [0x0]
Magic [0x4f0a099e]
Size 8193 blocks (including 1 for journal header) (first block 18)
Max transaction length 1024 blocks
Max batch size 900 blocks
Max commit age 30
Mountid 10, transid 10, desc 18, length 2, commit 21
I successfully reproduced it on versions 3.6.21 (which we were using)
and 3.6.23 (which I believe is the latest).
Attaching patch. Let me know your opinion. If I am wrong, please
comment, if I am correct, feel free to include patch into sources.
Thanks.
Signed-off-by: Victor Leschuk <vleschuk@gmail.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Now that we handle file systems > 8 TB, we end up printing large negative
numbers instead of actual block numbers. This patch fixes those places
to use unsigned ints for block numbers.
Signed-by: Jeff Mahoney <jeffm@suse.com>
Victor Leschuck
Jeff Mahoney