linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Thornber <thornber@redhat.com>
To: Eric Wheeler <dm-devel@lists.ewheeler.net>
Cc: Mike Snitzer <snitzer@redhat.com>,
	ejt@redhat.com, Coly Li <colyli@suse.de>,
	dm-devel@redhat.com, linux-block@vger.kernel.org,
	linux-bcache@vger.kernel.org, lvm-devel@redhat.com,
	joe.thornber@gmail.com
Subject: Re: kernel BUG at drivers/md/persistent-data/dm-space-map-disk.c:178 with scsi_mod.use_blk_mq=y
Date: Fri, 27 Sep 2019 09:32:39 +0100	[thread overview]
Message-ID: <20190927083239.xy6jwbkbektwqu3h@reti> (raw)
In-Reply-To: <alpine.LRH.2.11.1909261819300.15810@mx.ewheeler.net>

Hi Eric,

On Thu, Sep 26, 2019 at 06:27:09PM +0000, Eric Wheeler wrote:
> I pvmoved the tmeta to an SSD logical volume (dm-linear) on a non-bcache 
> volume and we got the same trace this morning, so while the tdata still 
> passes through bcache, all meta operations are direct to an SSD. This is 
> still using multi-queue scsi, but dm_mod.use_blk_mq=N.
> 
> Since bcache is no longer involved with metadata operations, and since 
> this appears to be a metadata issue, are there any other reasons to 
> suspect bcache?

Did you recreate the pool, or are you just using the existing pool but with
a different IO path?  If it's the latter then there could still be something
wrong with the metadata, introduced while bcache was in the stack.

Would it be possible to send me a copy of the metadata device please so
I can double check the space maps (I presume you've run thin_check on it)?

[Assuming you're using the existing pool] Another useful experiment would be to 
thump_dump and then thin_restore the metadata, which will create totally fresh
metadata and see if you can still reproduce the issue.

Thanks,

- Joe

  reply	other threads:[~2019-09-27  8:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 18:40 kernel BUG at drivers/md/persistent-data/dm-space-map-disk.c:178 with scsi_mod.use_blk_mq=y Eric Wheeler
2019-09-25 20:01 ` Mike Snitzer
2019-09-25 20:33   ` Eric Wheeler
2019-09-26 18:27   ` Eric Wheeler
2019-09-27  8:32     ` Joe Thornber [this message]
2019-09-27 18:45       ` Eric Wheeler
2019-12-20 19:54 ` [dm-devel] " Eric Wheeler
2019-12-27  1:47   ` [dm-devel] kernel BUG at drivers/md/persistent-data/dm-space-map-disk.c:178 Eric Wheeler
2019-12-28  2:13     ` Eric Wheeler
2020-01-07 10:35       ` [lvm-devel] " Joe Thornber
2020-01-07 10:46         ` Joe Thornber
2020-01-07 12:28           ` [dm-devel] [lvm-devel] " Joe Thornber
2020-01-07 18:47             ` Eric Wheeler
2020-01-14 21:52             ` Eric Biggers
2020-01-15  1:22               ` Mike Snitzer

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=20190927083239.xy6jwbkbektwqu3h@reti \
    --to=thornber@redhat.com \
    --cc=colyli@suse.de \
    --cc=dm-devel@lists.ewheeler.net \
    --cc=dm-devel@redhat.com \
    --cc=ejt@redhat.com \
    --cc=joe.thornber@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=lvm-devel@redhat.com \
    --cc=snitzer@redhat.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).