On 2016-04-19 09:58, Duncan wrote:
> 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.
I have the same situation here: there is a backup, but the most recent
modifications in files are preferable.
> 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.
Yes, this is exactly the problem discussed a while ago. Would be nice if
"btrfs restore -i" applies "(a)lways" option to all questions or there is
a separate option for that ("-y").
For me personally "looping" is too low-level problem. System administrators
(that are going to use this utility) should operate with some more reasonable
terms. If "looping" is some analogy of "time consumption" then I would say
that during restore time does not matter so much: I am ready to wait for 1
minute until a specific file is restored. So I think not the number of loops
but number of time spent should be measured.
Also I have difficulties in finding out what files have not been restored
due to uncorrectable errors. As I cannot redirect the output of
"btrfs restore" and it does not print the final stats, I cannot tell what
files have to be restored from backup.
> (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.)
I would be happy if I am able to replace the failing drive on the fly, without
stopping the system. Unfortunately I cannot do that due to kernel crashes :(
btrfs is still not resistant to these corner cases.
--
With best regards,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
