From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfsck --repair /dev/sdc (Was: [PATCH] Btrfs-progs: allow --init-extent-tree to work when extent tree is borked)
Date: Wed, 20 Nov 2013 17:08:17 +0000 (UTC) [thread overview]
Message-ID: <pan$809d5$4354febd$5ff6e929$a8235336@cox.net> (raw)
In-Reply-To: l6hm4u$s02$1@ger.gmane.org
Martin posted on Wed, 20 Nov 2013 06:51:20 +0000 as excerpted:
> It's now gone back to a pattern from a full week ago:
>
> (gdb) bt #0 0x000000000042d576 in read_extent_buffer ()
> #1 0x000000000041ee79 in btrfs_check_node ()
> #2 0x0000000000420211 in check_block ()
> #3 0x0000000000420813 in btrfs_search_slot ()
> #4 0x0000000000427bb4 in btrfs_read_block_groups ()
> #5 0x0000000000423e40 in btrfs_setup_all_roots ()
> #6 0x000000000042406d in __open_ctree_fd ()
> #7 0x0000000000424126 in open_ctree_fs_info ()
> #8 0x000000000041812e in cmd_check ()
> #9 0x0000000000404904 in main ()
>
>
> 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. =:^)
While I don't have any personal knowledge of btrfs on spinning rust
times, nor of TiB sized times even on SSD, there's a comment in the wiki
FAQ about balance times saying 20 hours is "normal" for 1 TB.
( https://btrfs.wiki.kernel.org/index.php/FAQ , search on "hours". )
OK, so we round that to a day a TB, double for your two TB, and double
again in case your drive is much slower than the "normal" drive the
comment might have been considering and because that's for a balance but
you're doing a btrfsck --repair, which for all we know takes longer.
That's still "only" four days, and you've been going well over a week.
At this point I think it's reasonably safe to conclude it's in some sort
of loop and likely will never finish.
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... or just consider it lost, get
anything you can off of it if you need to (I've forgotten what you tried
in terms of that previously, or how desperate you are for that data, but
if you've been waiting well over a week, I'd guess you have some reason
to try to save it), do a mkfs (possibly with a wipe first) and try
again. You're a patient man, definitely, but at a week a shot, there
comes a time when it's simply time to declare a loss and move on.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2013-11-20 17:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 18:01 [PATCH] Btrfs-progs: allow --init-extent-tree to work when extent tree is borked Josef Bacik
2013-10-25 18:27 ` Martin
2013-10-25 18:31 ` Josef Bacik
2013-10-26 23:16 ` Martin
2013-10-27 1:44 ` Josef Back
2013-10-28 15:11 ` Josef Bacik
2013-11-07 1:25 ` Martin
2013-11-11 22:52 ` Martin
2013-11-13 12:08 ` Martin
2013-11-13 13:46 ` Duncan
2013-11-15 17:18 ` Martin
2013-11-19 6:34 ` Martin
2013-11-20 6:51 ` btrfsck --repair /dev/sdc (Was: [PATCH] Btrfs-progs: allow --init-extent-tree to work when extent tree is borked) Martin
2013-11-20 17:08 ` Duncan [this message]
2013-11-20 20:00 ` Martin
2013-11-25 23:18 ` Martin
2013-11-27 6:29 ` Martin
2013-11-20 20:03 ` Martin
2013-11-19 6:25 ` [PATCH] Btrfs-progs: allow --init-extent-tree to work when extent tree is borked Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$809d5$4354febd$5ff6e929$a8235336@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.