From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>,
"Qu Wenruo" <quwenruo@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v4 1/2] btrfs: Introduce new mount option backuproot to replace recovery
Date: Tue, 22 Dec 2015 11:55:47 -0500 [thread overview]
Message-ID: <56798093.9020205@gmail.com> (raw)
In-Reply-To: <CAHji153JzZu0BW80fJo38GwEesAGWbwWcLhrianwXqbvTFjJaA@mail.gmail.com>
On 2015-12-22 07:30, Holger Hoffstätte wrote:
> On Tue, Dec 22, 2015 at 3:16 AM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>> Current "recovery" mount option will only try to use backup root.
>> However the word "recovery" is too generic and may be confusing for some
>> users.
>>
>> Here introduce a new and more specific mount option, "backuproot" to
>> replace "recovery" mount option.
>> "Recovery" will be kept for compatibility reason, but will be
>> deprecated.
>
> I agree that this makes much more sense from a user's perspective, so +1.
>
> But why not go all the way: try backuproot automatically when the
> initial mount fails,
> log the fallback and simply deprecate/ignore the option?
>
> Either this works - in which case there is no need to involve a human,
> which may not
> even exist - or it does not. If it does not, things are hosed anyway
> and we can fail
> properly.
I have seen cases where mounting -o ro,recovery didn't work, but restore
did, so there are cases where data is recoverable but this mount option
won't work.
>
> Any reasons not to do this?
I'm not 100% certain, but I think that there is a chance if it doesn't
work that it will make things worse. That, and TBH, it really should be
the administrator's choice; personally, if I come across a filesystem on
one of my systems that needs this, then I'm nuking the filesystem and
restoring from backup, because I don't trust that the rest of the
filesystem isn't broken. It's also consistent with other filesystems
(at least ext4 requires an option to force using a backup superblock).
Perhaps we could add a module parameter that specifies whether or not to
automatically try this?
next prev parent reply other threads:[~2015-12-22 16:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-22 2:16 [PATCH v4 1/2] btrfs: Introduce new mount option backuproot to replace recovery Qu Wenruo
2015-12-22 2:16 ` [PATCH v4 2/2] btrfs: Introduce new mount option to disable tree log replay Qu Wenruo
2015-12-22 12:30 ` [PATCH v4 1/2] btrfs: Introduce new mount option backuproot to replace recovery Holger Hoffstätte
2015-12-22 14:21 ` Qu Wenruo
2015-12-22 16:55 ` Austin S. Hemmelgarn [this message]
2015-12-22 12:44 ` Austin S. Hemmelgarn
2015-12-22 21:35 ` Christoph Anton Mitterer
2015-12-23 5:09 ` Qu Wenruo
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=56798093.9020205@gmail.com \
--to=ahferroin7@gmail.com \
--cc=holger.hoffstaette@googlemail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
/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.