All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Lehmann <schmorp@schmorp.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: first mount(s) after unclean shutdown always fail
Date: Thu, 2 Jul 2020 03:11:34 +0200	[thread overview]
Message-ID: <20200702011134.GA5037@schmorp.de> (raw)
In-Reply-To: <25e94ec6-842c-310f-e105-6d8f1e6dfdce@gmx.com>

On Thu, Jul 02, 2020 at 08:02:52AM +0800, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> Well, if you want to go this way, let me show the code here.
> 
> From fs/btrfs/volumes.c:btrfs_read_chunk_tree():
> 
>         if (btrfs_super_total_bytes(fs_info->super_copy) <
>             fs_info->fs_devices->total_rw_bytes) {
>                 btrfs_err(fs_info,
>         "super_total_bytes %llu mismatch with fs_devices total_rw_bytes
> %llu",
>                           btrfs_super_total_bytes(fs_info->super_copy),
>                           fs_info->fs_devices->total_rw_bytes);
>                 ret = -EINVAL;
>                 goto error;
>         }
> 
> Doesn't this explain why we abort the mount?

I wouldn't see how, especially if the code doesn't do anything _unless_ it
also prints the message.

When it doesn't produce the message, all it does is compare two numbers
(unless btrfs_super_total_bytes does something very funny) - how does this
explain that the mount fails, then succeeds, in the cases where the message
is _not_ logged, as reported?

> > Also, shouldn't btrfs be fixed instead? I was under the impression that
> > one of the goals of btrfs is to be safe w.r.t. crashes.
> 
> That's why we provide the btrfs rescue fix-device-size.

Not sure how that follows - there is a bug in the kernel filesystem and
you provide a userspace tool that should be run on every crash, to what
end?

Spurious mount failures are a bug in the btrfs kernel driver.

> > The bug I reported has very little or nothing to with strict checking.
> 
> I have provide the code to prove why it's related.

The code proves only that you are wrong - the code _always_ prints the
message. Unless btrfs_super_total_bytes does more than just read some
data, it cannot explain the bug I reported, simply because the message is
not always produced, and the mount is not always aborted.

> Whether you believe is your problem then.

No, it's not, simply because I don't have a problem...

btrfs has problems, and I reported one, that's all that has happened.

I slowly get the distinct feeling that reporting bugs in btrfs us a futile
exercise, though.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

  reply	other threads:[~2020-07-02  1:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01  0:51 first mount(s) after unclean shutdown always fail Marc Lehmann
2020-07-01  1:30 ` Qu Wenruo
2020-07-01 20:14   ` Marc Lehmann
2020-07-01 23:45     ` Qu Wenruo
2020-07-01 23:55       ` Marc Lehmann
2020-07-02  0:02         ` Qu Wenruo
2020-07-02  1:11           ` Marc Lehmann [this message]
2020-07-02  1:28             ` Qu Wenruo
2020-07-02  2:13               ` Marc Lehmann
2020-07-02 18:31 ` Zygo Blaxell
2020-07-03  8:04   ` Marc Lehmann

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=20200702011134.GA5037@schmorp.de \
    --to=schmorp@schmorp.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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.