All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: John Dorminy <jdorminy@redhat.com>
Cc: Heinz Mauelshagen <heinzm@redhat.com>,
	Mike Snitzer <msnitzer@redhat.com>,
	device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH] dm-bufio: implement discard
Date: Fri, 7 Feb 2020 15:07:05 -0500 (EST)	[thread overview]
Message-ID: <alpine.LRH.2.02.2002071456370.16613@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <CAMeeMh-r9Hxj+FCxg510wrfYb=Hhnz2wVbxLHfjVTz3i23XHHA@mail.gmail.com>



On Fri, 7 Feb 2020, John Dorminy wrote:

> There's no obvious way for the other process to wait for the discard
> to be complete at the present time, though -- suppose there were two
> holders of a given buffer, and one decided to discard -- how will the
> second one to wait for the discard to complete, or even tell that it's
> currently being discarded from another thread? I would naively guess
> that __write_dirty_buffer() waits via wait_on_bit_io(&b->state,
> B_WRITING, ...) to make sure nobody else is doing IO on the buffer
> location at the moment, but a discard doesn't currently set that bit,
> as far as I can see.
> 
> (If there is a way to wait, perhaps it should be documented at
> dm_bufio_discard_buffers() -- "If there is another process holding the
> buffer, the other process should be sure to [do stuff] before issuing
> a write, lest the write potentially be dropped or corrupted."

If two processes write to the same buffer, it is undefined behavior. If 
both of them do this:
	1) dm_bufio_get
	2) ... write to the buffer
	3) dm_bufio_mark_buffer_dirty
	4) dm_bufio_release
it is undefined what data the buffer would hold. It can even hold mixture 
of data written by those two processes. You must design your code in such 
a way that this doesn't happen.

The same is with discards - if you want to use them, you must design your 
code so that it doesn't overlay discards with other I/O. If you can't 
design it this way, then don't use discard.

Mikulas

  reply	other threads:[~2020-02-07 20:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 16:44 [PATCH] dm-bufio: implement discard Mikulas Patocka
2020-02-07 17:57 ` John Dorminy
2020-02-07 18:04   ` Mikulas Patocka
2020-02-07 18:39     ` John Dorminy
2020-02-07 20:07       ` Mikulas Patocka [this message]
2020-02-10 17:54         ` John Dorminy

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=alpine.LRH.2.02.2002071456370.16613@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=heinzm@redhat.com \
    --cc=jdorminy@redhat.com \
    --cc=msnitzer@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.