linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).