public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Andrea Gelmini <andrea.gelmini@linux.it>
Cc: "Michael Laß" <bevan@bi-co.net>,
	dm-devel@redhat.com, "Chris Murphy" <lists@colorremedies.com>,
	"Qu Wenruo" <quwenruo.btrfs@gmx.com>,
	"Btrfs BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: fstrim discarding too many or wrong blocks on Linux 5.1, leading to data loss
Date: Tue, 21 May 2019 16:12:27 -0400	[thread overview]
Message-ID: <20190521201226.GA23332@lobo> (raw)
In-Reply-To: <20190521190023.GA68070@glet>

On Tue, May 21 2019 at  3:00pm -0400,
Andrea Gelmini <andrea.gelmini@linux.it> wrote:

> On Tue, May 21, 2019 at 06:46:20PM +0200, Michael Laß wrote:
> > > I finished bisecting. Here’s the responsible commit:
> > > 
> > > commit 61697a6abd24acba941359c6268a94f4afe4a53d
> > > Author: Mike Snitzer <snitzer@redhat.com>
> > > Date:   Fri Jan 18 14:19:26 2019 -0500
> > > 
> > >    dm: eliminate 'split_discard_bios' flag from DM target interface
> > > 
> > >    There is no need to have DM core split discards on behalf of a DM target
> > >    now that blk_queue_split() handles splitting discards based on the
> > >    queue_limits.  A DM target just needs to set max_discard_sectors,
> > >    discard_granularity, etc, in queue_limits.
> > > 
> > >    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> > 
> > Reverting that commit solves the issue for me on Linux 5.1.3. Would
> that be an option until the root cause has been identified? I’d rather
> not let more people run into this issue.
> 
> Thanks a lot Michael, for your time/work.
> 
> This kind of bisecting are very boring and time consuming.
> 
> I CC: also the patch author.

Thanks for cc'ing me, this thread didn't catch my eye.

Sorry for your troubles.  Can you please try this patch?

Thanks,
Mike

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 1fb1333fefec..997385c1ca54 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1469,7 +1469,7 @@ static unsigned get_num_write_zeroes_bios(struct dm_target *ti)
 static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti,
 				       unsigned num_bios)
 {
-	unsigned len = ci->sector_count;
+	unsigned len;
 
 	/*
 	 * Even though the device advertised support for this type of
@@ -1480,6 +1480,8 @@ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *
 	if (!num_bios)
 		return -EOPNOTSUPP;
 
+	len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti));
+
 	__send_duplicate_bios(ci, ti, num_bios, &len);
 
 	ci->sector += len;

  parent reply	other threads:[~2019-05-21 20:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 22:16 Massive filesystem corruption after balance + fstrim on Linux 5.1.2 Michael Laß
2019-05-16 23:41 ` Qu Wenruo
2019-05-16 23:42 ` Chris Murphy
2019-05-17 17:37   ` Michael Laß
2019-05-18  4:09     ` Chris Murphy
2019-05-18  9:18       ` Michael Laß
2019-05-18  9:31         ` Roman Mamedov
2019-05-18 10:09           ` Michael Laß
2019-05-18 10:26         ` Qu Wenruo
2019-05-19 19:55           ` fstrim discarding too many or wrong blocks on Linux 5.1, leading to data loss Michael Laß
2019-05-20 11:38             ` [dm-devel] " Michael Laß
2019-05-21 16:46               ` Michael Laß
2019-05-21 19:00                 ` Andrea Gelmini
2019-05-21 19:59                   ` Michael Laß
2019-05-21 20:12                   ` Mike Snitzer [this message]
2019-05-24 15:00                     ` Andrea Gelmini
2019-05-24 15:10                       ` Greg KH
     [not found]             ` <CAK-xaQYPs62v971zm1McXw_FGzDmh_vpz3KLEbxzkmrsSgTfXw@mail.gmail.com>
2019-05-20 13:58               ` Michael Laß
2019-05-20 14:53                 ` Andrea Gelmini
2019-05-20 16:45                   ` Milan Broz
2019-05-20 19:58                     ` Michael Laß
2019-05-21 18:54                     ` Andrea Gelmini
2019-05-28 12:36 ` Massive filesystem corruption after balance + fstrim on Linux 5.1.2 Christoph Anton Mitterer
2019-05-28 12:43   ` Michael Laß

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=20190521201226.GA23332@lobo \
    --to=snitzer@redhat.com \
    --cc=andrea.gelmini@linux.it \
    --cc=bevan@bi-co.net \
    --cc=dm-devel@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox