From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Kernel crash if both devices in raid1 are failing
Date: Tue, 19 Apr 2016 07:58:07 +0000 (UTC) [thread overview]
Message-ID: <pan$4b158$295907b$46fdde88$24c8df73@cox.net> (raw)
In-Reply-To: 5715C604.2070200@gmail.com
Dmitry Katsubo posted on Tue, 19 Apr 2016 07:45:40 +0200 as excerpted:
> Actually btrfs restore has recovered many files, however I was not able
> to run in fully unattended mode as it complains about "looping a lot".
> Does it mean that files are corrupted / not correctly restored?
As long as you tell it to keep going each time, the loop complaints
shouldn't be an issue. The problem is that the loop counter is measuring
loops on a particular directory, because that's what it has available to
measure. But if you had a whole bunch of files in that dir, it's /going/
to loop a lot, to restore all of them.
I have one cache directory with over 200K files in it. They're all text
messages from various technical lists and newsgroups (like this list,
which I view as a newsgroup using gmane.org's list2news service) so
they're quite small, about 5 KiB on average by my quick calculation, but
that's still a LOT of files for a single dir, even if they're only using
just over a GiB of space.
I ended up doing a btrfs restore on that filesystem (/home), because
while I had a backup, restore was getting more recent copies of stuff
back, and that dir looped a *LOT* the first time it happened, now several
years ago, before they actually added the always option.
The second time it happened, about a year ago, restore worked much
better, and I was able to use the always option. But AFAIK, always only
applies to that dir. If you have multiple dirs with the problem, you'll
still get asked for the next one. But it did vastly improve the
situation for me, giving me only a handful of prompts instead of the very
many I had before the option was there.
(The main problem triggering the need to run restore for me, turned out
to be hardware. I've had no issues since I replaced that failing ssd,
and with a bit of luck, won't be running restore again for a few years,
now.)
--
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:[~2016-04-19 7:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-14 20:30 Kernel crash if both devices in raid1 are failing Dmitry Katsubo
2016-04-17 23:18 ` Dmitry Katsubo
2016-04-21 3:45 ` Liu Bo
[not found] ` <571DC34A.50509@gmail.com>
2016-04-27 2:44 ` Dmitry Katsubo
2016-05-02 20:51 ` Dmitry Katsubo
2016-04-18 0:19 ` Chris Murphy
2016-04-19 5:45 ` Dmitry Katsubo
2016-04-19 7:58 ` Duncan [this message]
2016-04-20 22:02 ` Dmitry Katsubo
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$4b158$295907b$46fdde88$24c8df73@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).