All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, Nikolay Borisov <nborisov@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 5/5] btrfs: Greatly simplify btrfs_read_dev_super
Date: Fri, 8 Dec 2017 16:13:49 +0800	[thread overview]
Message-ID: <acf7906d-3284-eaf2-a954-3acb8017dbbf@oracle.com> (raw)
In-Reply-To: <24281483-900c-ab1b-c407-5fa6983f5311@oracle.com>



On 12/07/2017 11:07 PM, Anand Jain wrote:
> 
> 
> On 12/07/2017 12:24 AM, David Sterba wrote:
>> On Mon, Dec 04, 2017 at 06:20:09PM +0200, Nikolay Borisov wrote:
>>>>> I don't understand what problem *should* be solved here...
>>>>
>>>> Without any further checks and validation, we cannot simply iterate 
>>>> over
>>>> all superblocks and try to mount anything that looks ok. Even if the
>>>> offsets exist on the block device.  The fsid should be at least 
>>>> checked,
>>>> but that's still not enough to ensure the 1st copy is what we want to
>>>> mount.
>>>
>>> I'm more inclined to agree with Anand here, that if the users wants to
>>> mount with -t btrfs then the filesystem should assume it's correct to
>>> use any of the additional superblocks.
>>
>> If and only if the additional superblocks are valid. And if we can't
>> read the primary superblock, we don't have enough information to
>> establish the validation.  EIO?  We don't have anything.  CRC mismatch?
>> Can't trust the whole data.  We need FSID and total_size at least. Other
>> actions are limited from inside kernel.

  ext4 has mount option -o sb=<copy_num> to specify the copy num to use.

  Not sure if I have dug enough but as of now I don't find any pitfall.
  Only funny thing is you can mount a device even after wipefs -a and
  recover its primary SB, to which my view is that the problem is at
  the wipefs -a end, not able to wipe all SB copies.

  I sent out an experimental RFC patch here:
    [PATCH RFC] btrfs: self heal from SB fail

  Pls try out, any problem that you could think off by this approach.

Thanks, Anand

      parent reply	other threads:[~2017-12-08  8:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01  9:19 [PATCH 0/5] Misc cleanups Nikolay Borisov
2017-12-01  9:19 ` [PATCH 1/5] btrfs: Remove dead code Nikolay Borisov
2017-12-04 13:45   ` David Sterba
2017-12-05 11:53     ` [PATCH] btrfs: Remove dead code btrfs_get_extent Nikolay Borisov
2017-12-01  9:19 ` [PATCH 2/5] btrfs: Remove dead code Nikolay Borisov
2017-12-04 13:50   ` David Sterba
2017-12-04 16:17     ` Nikolay Borisov
2017-12-01  9:19 ` [PATCH 3/5] btrfs: Fix possible off-by-one in btrfs_search_path_in_tree Nikolay Borisov
2017-12-06 15:48   ` David Sterba
2017-12-01  9:19 ` [PATCH 4/5] btrfs: Remove redundant NULL check Nikolay Borisov
2017-12-06 16:02   ` David Sterba
2017-12-01  9:19 ` [PATCH 5/5] btrfs: Greatly simplify btrfs_read_dev_super Nikolay Borisov
2017-12-01 23:23   ` Anand Jain
2017-12-03  9:43     ` Nikolay Borisov
2017-12-04  1:33       ` Anand Jain
2017-12-04 14:13       ` David Sterba
2017-12-04 16:20         ` Nikolay Borisov
2017-12-06 16:24           ` David Sterba
     [not found]             ` <24281483-900c-ab1b-c407-5fa6983f5311@oracle.com>
2017-12-08  8:13               ` Anand Jain [this message]

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=acf7906d-3284-eaf2-a954-3acb8017dbbf@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.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.