linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: dsterba@suse.cz, Anand Jain <anand.jain@oracle.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 5/5] btrfs: Greatly simplify btrfs_read_dev_super
Date: Wed, 6 Dec 2017 17:24:48 +0100	[thread overview]
Message-ID: <20171206162448.GD3553@twin.jikos.cz> (raw)
In-Reply-To: <897b7a95-1fd6-9647-f959-1d5f8f275685@suse.com>

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.

> Otherwise we should explicitly
> state somewhere that the superblock copies are there only for the sake
> of the user-space tools, in which case this patch can go in, albeit with
> some rewording.

Unless there's something I'm missing to address the concerns above, I'm
for (an updated version) of your patch.

  reply	other threads:[~2017-12-06 16:26 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 [this message]
     [not found]             ` <24281483-900c-ab1b-c407-5fa6983f5311@oracle.com>
2017-12-08  8:13               ` Anand Jain

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=20171206162448.GD3553@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=anand.jain@oracle.com \
    --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 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).