Linux-BTRFS Archive on lore.kernel.org
 help / Atom feed
From: STEVE LEUNG <sjleung@shaw.ca>
To: Thiago Ramon <thiagoramon@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: corruption with multi-device btrfs + single bcache, won't mount
Date: Sun, 10 Feb 2019 22:22:54 -0700 (MST)
Message-ID: <8939586.241815809.1549862574354.JavaMail.zimbra@shaw.ca> (raw)
In-Reply-To: <CAO1Y9wr7WA1PS+3cvyPBKGgd-_Xf-nnesWhLvmgV83_XTa7RUA@mail.gmail.com>



----- Original Message -----
> From: "Thiago Ramon" <thiagoramon@gmail.com>
> On Sun, Feb 10, 2019 at 5:07 AM STEVE LEUNG <sjleung@shaw.ca> wrote:
>>
>> Hi all,
>>
>> I decided to try something a bit crazy, and try multi-device raid1 btrfs on
>> top of dm-crypt and bcache.  That is:
>>
>>   btrfs -> dm-crypt -> bcache -> physical disks
>>
>> I have a single cache device in front of 4 disks.  Maybe this wasn't
>> that good of an idea, because the filesystem went read-only a few
>> days after setting it up, and now it won't mount.  I'd been running
>> btrfs on top of 4 dm-crypt-ed disks for some time without any
>> problems, and only added bcache (taking one device out at a time,
>> converting it over, adding it back) recently.
>>
>> This is complete speculation, but I do wonder if having the single
>> cache device for multiple btrfs disks triggered the problem.
> 
> But before you try to restore anything, can you go back in your kernel
> logs and check for errors? Either one of your devices is failing, you
> might have physical link issues or bad memory. Even with a complex
> setup like this you shouldn't be getting random corruption like this.

Indeed, it looks like plugging in the 5th device for caching may have
destabilized things (maybe I'm drawing too much power from the power
supply or something), as I've observed some spurious ATA errors
trying to boot from rescue media.  Things seem to go back to normal
if I take the cache device out.

This hardware is old, but has seemed reliable enough.  Although that
said, this is my second btrfs corruption I've run into (fortunately
no data lost), so maybe the hardware is not as solid as I'd thought.

I guess I should have given it more of a shakedown before rolling out
bcache everywhere.  :)  Thanks for the insight.

Steve

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10  6:56 STEVE LEUNG
2019-02-10 10:35 ` Thiago Ramon
2019-02-11  5:22   ` STEVE LEUNG [this message]
2019-02-10 13:52 ` Qu Wenruo
2019-02-11  5:25   ` STEVE LEUNG
2019-02-12  6:22   ` Steve Leung
2019-02-12  6:51     ` Qu Wenruo

Reply instructions:

You may reply publically 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=8939586.241815809.1549862574354.JavaMail.zimbra@shaw.ca \
    --to=sjleung@shaw.ca \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=thiagoramon@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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org linux-btrfs@archiver.kernel.org
	public-inbox-index linux-btrfs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox