All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Yang <dennisyang@qnap.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Possible data corruption with dm-thin
Date: Tue, 21 Jun 2016 15:56:26 +0800	[thread overview]
Message-ID: <CAAR726JWQ4VKOVR87QX6Tmuhu1JnCymm7coLT=TFn3BseKm8XA@mail.gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1674 bytes --]

Hi,

We have been dealing with a data corruption issue when we run out I/O
test suite made by ourselves with multiple thin devices built on top of a
thin-pool. In our test suites, we will create multiple thin devices and
continually write to them, check the file checksum, and delete all files
and issue DISCARD to reclaim space if no checksum error takes place.

We found that there is one data access pattern could corrupt the data.
Suppose that there are two thin devices A and B, and device A receives
a DISCARD bio to discard a physical(pool) block 100. Device A will quiesce
all previous I/O and held both virtual and physical data cell before it
actually remove the corresponding data mapping. After the data mapping
is removed, both data cell will be released and this DISCARD bio will
be passed down to underlying devices. If device B tries to allocate
a new block at the very same moment, it could reuse the block 100 which
was just been discarded by device A (suppose metadata commit had
been triggered, for a block cannot be reused in the same transaction).
In this case, we will have a race between the WRITE bio coming from
device B and the DISCARD bio coming from device A. Once the WRITE
bio completes before the DISCARD bio, there would be checksum error
for device B.

So my question is, does dm-thin have any mechanism to eliminate the race
when
discarded block is reused right away by another device?

Any help would be grateful.
Thanks,

Dennis


-- 
Dennis Yang
QNAP Systems, Inc.
Skype: qnap.dennis.yang
Email: dennisyang@qnap.com
Tel: (+886)-2-2393-5152 ext. 15018
Address: 13F., No.56, Sec. 1, Xinsheng S. Rd., Zhongzheng Dist., Taipei
City, Taiwan

[-- Attachment #1.2: Type: text/html, Size: 3147 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



             reply	other threads:[~2016-06-21  7:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21  7:56 Dennis Yang [this message]
2016-06-21  8:59 ` Possible data corruption with dm-thin Zdenek Kabelac
2016-06-21 10:40   ` Dennis Yang
2016-06-21 10:46     ` Zdenek Kabelac
2016-06-24 13:55 ` Edward Thornber
2016-06-27  9:32   ` Dennis Yang
2016-07-01 13:18     ` Edward Thornber
2016-09-06  4:51       ` Dennis Yang

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='CAAR726JWQ4VKOVR87QX6Tmuhu1JnCymm7coLT=TFn3BseKm8XA@mail.gmail.com' \
    --to=dennisyang@qnap.com \
    --cc=dm-devel@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.