From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs recovery
Date: Fri, 20 Jan 2017 08:05:33 +0000 (UTC) [thread overview]
Message-ID: <pan$70181$45383b8f$72c6c22$19cae0fb@cox.net> (raw)
In-Reply-To: 7473ea27-9716-33fb-ecec-2ec52fac3820@dd-wrt.com
Sebastian Gottschall posted on Thu, 19 Jan 2017 11:06:19 +0100 as
excerpted:
> I have a question. after a power outage my system was turning into a
> unrecoverable state using btrfs (kernel 4.9)
> since im running --init-extent-tree now for 3 days i'm asking how long
> this process normally takes
QW has the better direct answer for you, but...
This is just a note to remind you, in general questions like "how long"
can be better answered if we know the size of your filesystem, the mode
(how many devices and what duplication mode for data and metadata) and
something about how you use it -- how many subvolumes and snapshots you
have, whether you have quotas enabled, etc.
Normally output from commands like btrfs fi usage can answer most of the
filesystem size and mode stuff, but of course that command requires a
mount, and you're doing an unmounted check ATM. However, btrfs fi show
should still work and give us basic information like file size and number
of devices, and you can fill in the blanks from there.
You did mention the kernel version (4.9) however, something that a lot of
reports miss, and you're current, so kudos for that. =:^)
As to your question, assuming a terabyte scale filesystem, as QW
suggested, a full extent tree rebuild is a big job and could indeed take
awhile (days).
>From a practical perspective...
Given the state of btrfs as a still stabilizing and maturing filesystem,
having backups for any data you value more than the time and hassle
necessary to do the backup is even more a given than on a fully stable
filesystem, which means, given the time for an extent tree rebuild on
that size of a filesystem, unless you're doing the rebuild specifically
to get the experience or test the code, as a practical matter it's
probably simply easier to restore from that backup if you valued the data
enough to have one, or simply scrap the filesystem and start over if you
considered the data worth less than the time and hassle of a backup, and
thus didn't have one.
--
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:[~2017-01-20 8:05 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 10:06 btrfs recovery Sebastian Gottschall
2017-01-20 1:08 ` Qu Wenruo
2017-01-20 9:45 ` Sebastian Gottschall
2017-01-23 11:15 ` Sebastian Gottschall
2017-01-24 0:39 ` Qu Wenruo
2017-01-20 8:05 ` Duncan [this message]
2017-01-20 9:59 ` Sebastian Gottschall
-- strict thread matches above, loose matches on Subject: below --
2017-01-26 9:18 Oliver Freyermuth
2017-01-26 9:25 ` Hugo Mills
2017-01-26 9:36 ` Oliver Freyermuth
2017-01-26 10:00 ` Hugo Mills
2017-01-26 11:01 ` Oliver Freyermuth
2017-01-27 11:01 ` Oliver Freyermuth
2017-01-27 12:58 ` Austin S. Hemmelgarn
2017-01-28 5:00 ` Duncan
2017-01-28 12:37 ` Janos Toth F.
2017-01-28 16:51 ` Oliver Freyermuth
2017-01-28 16:46 ` Oliver Freyermuth
2017-01-31 4:58 ` Duncan
2017-01-31 12:45 ` Austin S. Hemmelgarn
2017-02-01 4:36 ` Duncan
2017-01-30 12:41 ` Austin S. Hemmelgarn
2017-01-28 21:04 ` Oliver Freyermuth
2017-01-28 22:27 ` Hans van Kranenburg
2017-01-29 2:02 ` Oliver Freyermuth
2017-01-29 16:44 ` Hans van Kranenburg
2017-01-29 19:09 ` Oliver Freyermuth
2017-01-29 19:28 ` Hans van Kranenburg
2017-01-29 19:52 ` Oliver Freyermuth
2017-01-29 20:13 ` Hans van Kranenburg
2017-01-30 20:02 Michael Born
2017-01-30 20:27 ` Hans van Kranenburg
2017-01-30 20:51 ` Chris Murphy
2017-01-30 21:07 ` Michael Born
2017-01-30 21:16 ` Hans van Kranenburg
2017-01-30 22:24 ` GWB
2017-01-30 22:37 ` Michael Born
2017-01-31 0:29 ` GWB
2017-01-31 9:08 ` Graham Cobb
2017-01-30 21:20 ` Chris Murphy
2017-01-30 21:35 ` Chris Murphy
2017-01-30 21:40 ` Michael Born
2017-01-31 4:30 ` Duncan
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$70181$45383b8f$72c6c22$19cae0fb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).