On 10/18/2012 01:43 PM, Jan Schmidt wrote:
Hi liubo,
On Wed, October 17, 2012 at 17:27 (+0200), Liu Bo wrote:
quoted
Hi Jan,
Here is the steps,
1. apply the three patches onto the latest btrfs
Can you give me a commit id? They don't apply to cmason/master as of today.
Patch 1 looks reversed, by the way.
Oh, I'm so sorry, there is a conflict of btrfs_drop_extents.
I've attached the new version test patches, which should work onto the latest for-linus branch.
I'd comment on patch 2, but it's hard to comment on something in a tar archive.
You probably wanted to add "add++" where you added "add = 0" for the second time.
Yeah, I noticed this, thanks for pointing it out ;)
quoted
2. run the script 'debug.sh'[1]
(NOTE: edit the script and the fio job file[2] to get device and mount point right before running it)
3. it will crash after a few seconds. [3]
[...]
quoted
[3]
[ 71.980881] device fsid bc47c36a-7e90-453d-aa6b-8c4a12e30dc0 devid 1 transid 4 /dev/sda5
[ 71.984162] btrfs: enabling auto defrag
[ 71.984168] btrfs: disk space caching is enabled
[ 72.051464] root last_snapshot 5
[ 95.789404] root last_snapshot 6
[ 100.229357] root last_snapshot 7
[ 103.252999] record_old_file_extents: ino 257 new file_pos 38273024 len 1048576 bytenr 2387300352 disk_len 1048576
[ 103.255989] record_extent_backrefs file_pos 38273024 len 1048576
[ 103.348648] eb->start 66080768 eb->len 4096 eb->level 1 nritems 66 n 176 rm 110 add 0
Even the first line tells us there's something wrong. n shouldn't exceed 124
with 4k leaves. If you lower the debug output restriction (n > 130) we might
already see through here.
ok, besides, I add two more index: rm_free and rm_move.
A guess is that we've probably queued some MOD_LOG_MOVE_KEYS operations that
should have modified n.
IMHO MOD_LOG_KEY_REMOVE_WHILE_MOVING does not need to modify n, since nritems remain
unchanged when we move items inside an node, don't they?
thanks,
liubo
Thanks,
-Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html