From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel <dm-devel@redhat.com>, Lukas Straub <lukasstraub2@web.de>
Subject: Re: [dm-devel] dm-integrity: Fix flush with external metadata device
Date: Fri, 8 Jan 2021 13:38:17 -0500 [thread overview]
Message-ID: <20210108183817.GA30360@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.02.2101081104490.17896@file01.intranet.prod.int.rdu2.redhat.com>
On Fri, Jan 08 2021 at 11:12am -0500,
Mikulas Patocka <mpatocka@redhat.com> wrote:
>
>
> On Mon, 4 Jan 2021, Mike Snitzer wrote:
>
> > On Sun, Dec 20 2020 at 8:02am -0500,
> > Lukas Straub <lukasstraub2@web.de> wrote:
> >
> > > With an external metadata device, flush requests aren't passed down
> > > to the data device.
> > >
> > > Fix this by issuing flush in the right places: In integrity_commit
> > > when not in journal mode, in do_journal_write after writing the
> > > contents of the journal to the disk and in dm_integrity_postsuspend.
> > >
> > > Signed-off-by: Lukas Straub <lukasstraub2@web.de>
> > > ---
> > > drivers/md/dm-integrity.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
> > > index 5a7a1b90e671..a26ed65869f6 100644
> > > --- a/drivers/md/dm-integrity.c
> > > +++ b/drivers/md/dm-integrity.c
> > > @@ -2196,6 +2196,8 @@ static void integrity_commit(struct work_struct *w)
> > > if (unlikely(ic->mode != 'J')) {
> > > spin_unlock_irq(&ic->endio_wait.lock);
> > > dm_integrity_flush_buffers(ic);
> > > + if (ic->meta_dev)
> > > + blkdev_issue_flush(ic->dev->bdev, GFP_NOIO);
> > > goto release_flush_bios;
> > > }
> > >
> > > @@ -2410,6 +2412,9 @@ static void do_journal_write(struct dm_integrity_c *ic, unsigned write_start,
> > > wait_for_completion_io(&comp.comp);
> > >
> > > dm_integrity_flush_buffers(ic);
> > > + if (ic->meta_dev)
> > > + blkdev_issue_flush(ic->dev->bdev, GFP_NOIO);
> > > +
> > > }
> > >
> > > static void integrity_writer(struct work_struct *w)
> > > @@ -2949,6 +2954,9 @@ static void dm_integrity_postsuspend(struct dm_target *ti)
> > > #endif
> > > }
> > >
> > > + if (ic->meta_dev)
> > > + blkdev_issue_flush(ic->dev->bdev, GFP_NOIO);
> > > +
> > > BUG_ON(!RB_EMPTY_ROOT(&ic->in_progress));
> > >
> > > ic->journal_uptodate = true;
> > > --
> > > 2.20.1
> >
> >
> > Seems like a pretty bad oversight... but shouldn't you also make sure to
> > flush the data device _before_ the metadata is flushed?
> >
> > Mike
>
> I think, ordering is not a problem.
>
> A disk may flush its cache spontaneously anytime, so it doesn't matter in
> which order do we flush them. Similarly a dm-bufio buffer may be flushed
> anytime - if the machine is running out of memory and a dm-bufio shrinker
> is called.
>
> I'll send another patch for this - I've created a patch that flushes the
> metadata device cache and data device cache in parallel, so that
> performance degradation is reduced.
>
> My patch also doesn't use GFP_NOIO allocation - which can in theory
> deadlock if we are swapping on dm-integrity device.
OK, I see your patch, but my concern about ordering was more to do with
crash consistency. What if metadata is updated but data isn't?
On the surface, your approach of issuing the flushes in parallel seems
to expose us to inconsistency upon recovery from a crash.
If that isn't the case please explain why not.
Thanks,
Mike
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-01-08 18:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-20 13:02 [dm-devel] [PATCH] dm-integrity: Fix flush with external metadata device Lukas Straub
2020-12-29 9:47 ` Lukas Straub
2021-01-04 20:30 ` [dm-devel] " Mike Snitzer
2021-01-08 16:12 ` Mikulas Patocka
2021-01-08 16:15 ` [dm-devel] [PATCH] " Mikulas Patocka
2021-01-10 10:04 ` Lukas Straub
2021-01-08 18:38 ` Mike Snitzer [this message]
2021-01-08 19:00 ` [dm-devel] " Mikulas Patocka
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=20210108183817.GA30360@redhat.com \
--to=snitzer@redhat.com \
--cc=dm-devel@redhat.com \
--cc=lukasstraub2@web.de \
--cc=mpatocka@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 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.