I don't know if that has gone through that pattern during the week but
at a-week-a-time, this is not going to finish in reasonable time.
How come so very slow?
Any hints/tips/fixes or abandon the test?
You're a patient man. =:^)
Sort of... I can leave it running in the background until
On 20/11/13 20:00, Martin wrote:
On 20/11/13 17:08, Duncan wrote:
Martin posted on Wed, 20 Nov 2013 06:51:20 + as excerpted:
It's now gone back to a pattern from a full week ago:
(gdb) bt #0 0x0042d576 in read_extent_buffer ()
#1 0x0041ee79 in btrfs_check_node ()
#2
Martin posted on Wed, 20 Nov 2013 06:51:20 + as excerpted:
It's now gone back to a pattern from a full week ago:
(gdb) bt #0 0x0042d576 in read_extent_buffer ()
#1 0x0041ee79 in btrfs_check_node ()
#2 0x00420211 in check_block ()
#3 0x00420813 in
On 20/11/13 17:08, Duncan wrote:
Martin posted on Wed, 20 Nov 2013 06:51:20 + as excerpted:
It's now gone back to a pattern from a full week ago:
(gdb) bt #0 0x0042d576 in read_extent_buffer ()
#1 0x0041ee79 in btrfs_check_node ()
#2 0x00420211 in check_block
On 20/11/13 17:08, Duncan wrote:
Which leads to the question of what to do next. Obviously, there have
been a number of update patches since then, some of which might address
your problem. You could update your kernel and userspace and try
again... /if/ you have the patience...
This is
It's now gone back to a pattern from a full week ago:
(gdb) bt
#0 0x0042d576 in read_extent_buffer ()
#1 0x0041ee79 in btrfs_check_node ()
#2 0x00420211 in check_block ()
#3 0x00420813 in btrfs_search_slot ()
#4 0x00427bb4 in btrfs_read_block_groups ()
