All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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.