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 ()
On 07/11/13 01:25, Martin wrote:
[...]
And the patching fails due to mismatching code...
I have the Gentoo source for:
Btrfs v0.20-rc1-358-g194aa4a
(On Gentoo 3.11.5, will be on 3.11.6 later today.)
What are the magic incantations to download your version of source code
to try
Continuing:
gdb bt now gives:
#0 0x0042075a in btrfs_search_slot ()
#1 0x00427bb4 in btrfs_read_block_groups ()
#2 0x00423e40 in btrfs_setup_all_roots ()
#3 0x0042406d in __open_ctree_fd ()
#4 0x00424126 in open_ctree_fs_info ()
#5 0x0041812e
Another two days and a backtrace shows the hope of progress:
#0 0x0041de2f in btrfs_node_key ()
#1 0x0041ee79 in btrfs_check_node ()
#2 0x00420211 in check_block ()
#3 0x00420813 in btrfs_search_slot ()
#4 0x00427bb4 in btrfs_read_block_groups ()
#5
On 11/11/13 22:52, Martin wrote:
On 07/11/13 01:25, Martin wrote:
OK so Chris Mason and the Gentoo sys-fs/btrfs-progs- came to the
rescue to give:
# btrfs version
Btrfs v0.20-rc1-591-gc652e4e
From that, I've tried running again:
# btrfsck --repair /dev/sdc
giving thus far:
Martin posted on Wed, 13 Nov 2013 12:08:50 + as excerpted:
Which comes to a request:
Can the options -v (for verbose) and -s (to continuously show
status) be added to btrfsck to give some indication of progress and
what is happening? The -s should report progress by whatever
On 07/11/13 01:25, Martin wrote:
On 28/10/13 15:11, Josef Bacik wrote:
Ok I've sent
[PATCH] Btrfs-progs: rework open_ctree to take flags, add a new one
which should address your situation. Thanks,
Josef,
Tried your patch:
Signed-off-by: Josef Bacik jba...@fusionio.com
On 28/10/13 15:11, Josef Bacik wrote:
On Sun, Oct 27, 2013 at 12:16:12AM +0100, Martin wrote:
On 25/10/13 19:31, Josef Bacik wrote:
On Fri, Oct 25, 2013 at 07:27:24PM +0100, Martin wrote:
On 25/10/13 19:01, Josef Bacik wrote:
Unfortunately you can't run --init-extent-tree if you can't
On Sun, Oct 27, 2013 at 12:16:12AM +0100, Martin wrote:
On 25/10/13 19:31, Josef Bacik wrote:
On Fri, Oct 25, 2013 at 07:27:24PM +0100, Martin wrote:
On 25/10/13 19:01, Josef Bacik wrote:
Unfortunately you can't run --init-extent-tree if you can't actually read
the
extent root. Fix
On 25/10/13 19:31, Josef Bacik wrote:
On Fri, Oct 25, 2013 at 07:27:24PM +0100, Martin wrote:
On 25/10/13 19:01, Josef Bacik wrote:
Unfortunately you can't run --init-extent-tree if you can't actually read
the
extent root. Fix this by allowing partial starts with no extent root and
then
Yup I have another plan for your situation, I will wire it up Monday and send
it out. Thanks,
Josef
On Oct 26, 2013, at 7:16 PM, Martin m_bt...@ml1.co.uk wrote:
On 25/10/13 19:31, Josef Bacik wrote:
On Fri, Oct 25, 2013 at 07:27:24PM +0100, Martin wrote:
On 25/10/13 19:01, Josef Bacik
Unfortunately you can't run --init-extent-tree if you can't actually read the
extent root. Fix this by allowing partial starts with no extent root and then
have fsck only check to see if the extent root is uptodate _after_ the check to
see if we are init'ing the extent tree. Thanks,
On 25/10/13 19:01, Josef Bacik wrote:
Unfortunately you can't run --init-extent-tree if you can't actually read the
extent root. Fix this by allowing partial starts with no extent root and then
have fsck only check to see if the extent root is uptodate _after_ the check
to
see if we are
On Fri, Oct 25, 2013 at 07:27:24PM +0100, Martin wrote:
On 25/10/13 19:01, Josef Bacik wrote:
Unfortunately you can't run --init-extent-tree if you can't actually read
the
extent root. Fix this by allowing partial starts with no extent root and
then
have fsck only check to see if the
19 matches
Mail list logo
