linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Patrik Ostrihon <patrik.ostrihon@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs - kernel warning
Date: Thu, 1 Feb 2018 14:39:10 -0700	[thread overview]
Message-ID: <CAJCQCtS0xhj64YK3rxQ+_8y1dwZ-_vBe-D97PRNVFhmAPnaLmw@mail.gmail.com> (raw)
In-Reply-To: <CALvFGyCYKs_MMB5st-nm463_UBcA859iBDHX8xjRX8eCME7Ytw@mail.gmail.com>

On Thu, Feb 1, 2018 at 2:06 PM, Patrik Ostrihon
<patrik.ostrihon@gmail.com> wrote:
> Hi,
>
> Today I saw warning in dmesg output. But I don't know what it means.
> Could you help me please? Is it something dangerous for my dato on
> this filesystem?

Is this a persistent warning you're getting or is it a one time message?

Looks like it's happening when deallocating empty block groups. I'm
not sure why, but I also can't tell from the call trace which of the
two Btrfs file systems it's referring to.

Anyway, what I would do in order:

a. Backups. Your post suggests you're worried about your data, so
first order of business is to update the backups. Raid1 is not a
backup.
b. I'd find a relatively recent live, so that it has a relatively
recent btrfs-progs, v4.11.3 or newer. Create USB stick media to boot
from and run the following commands on both volumes (pick one of the
two drives for each Btrfs volume; it is not a per drive check it is a
per volume check and it doesn't matter which of the two drives you
pick).

btrfs check
btrfs check --mode=lowmem

The lowmem mode is a different implementation and sometimes there are
different results.

c. You only posted the df output for one of the two file systems. The
one you posted is not completely raid1, you have some single chunks
which don't appear to be used but that they're present can impact the
ability to mount degraded (i.e. degraded mount might fail in this
condition)

btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft /usr/local/data


That will leave existing raid1 block groups untouched and will
effectively remove the unused single chunks. You should check the
other volume and make sure all block groups are raid1.



-- 
Chris Murphy

  reply	other threads:[~2018-02-01 21:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 21:06 btrfs - kernel warning Patrik Ostrihon
2018-02-01 21:39 ` Chris Murphy [this message]
2018-02-01 21:40 ` Chris Murphy
2018-02-02  1:40 ` Qu Wenruo
2018-02-02  2:09   ` Chris Murphy
2018-02-02  2:49   ` Duncan
2018-02-05  4:52     ` Duncan

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=CAJCQCtS0xhj64YK3rxQ+_8y1dwZ-_vBe-D97PRNVFhmAPnaLmw@mail.gmail.com \
    --to=lists@colorremedies.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=patrik.ostrihon@gmail.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).