All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Dung <patdung100@gmail.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: dm-devel@redhat.com
Subject: Re: About dm-integrity layer and fsync
Date: Sun, 5 Jan 2020 20:20:53 +0800	[thread overview]
Message-ID: <CAJTWkducreuW2LcOaipUMnNRFhvjd4N_LdKrnND-wBfCS593jg@mail.gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.02.2001050431590.6830@file01.intranet.prod.int.rdu2.redhat.com>


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

OK, I see. Thanks Mikulas for the explanation.

On Sun, Jan 5, 2020 at 5:39 PM Mikulas Patocka <mpatocka@redhat.com> wrote:

>
>
> On Sat, 4 Jan 2020, Patrick Dung wrote:
>
> > Thanks for reply. After performing an additional testing with SSD. I
> have more questions.
> >
> > Firstly, about the additional testing with SSD:
> > I tested it with SSD (in Linux software raid level 10 setup). The result
> shown using dm-integrity is faster than using XFS directly. For using
> dm-integrity, fio shows
> > lots of I/O merges by the scheduler. Please find the attachment for the
> result.
> >
> > Finally, please find the questions below:
> > 1) So after the dm-integrity journal is written to the actual back end
> storage (hard drive), then fsync would then report completed?
>
> Yes.
>
> > 2) To my understanding, for using dm-integrity with journal mode. Data
> has to written into the storage device twice (one part is the dm-integrity
> journal, the other
> > one is the actual data). For the fio test, the data should be random and
> sustained for 60 seconds. But using dm-integrity with journal mode is still
> faster.
> >
> > Thanks,
> > Patrick
>
> With ioengine=sync, fio sends one I/O, waits for it to finish, send
> another I/O, wait for it to finish, etc.
>
> With dm-integrity, I/Os will be written to the journal (that is held in
> memory, no disk I/O is done), and when fio does the sync(), fsync() or
> fdatasync() syscall, the journal is written to the disk. After the journal
> is flushed, the blocks are written concurrently to the disk locations.
>
> The SSD has better performance for concurrent write then for
> block-by-block write, so that's why you see performance improvement with
> dm-integrity.
>
> Mikulas
>
>

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

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



      reply	other threads:[~2020-01-05 12:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-03 15:51 About dm-integrity layer and fsync Patrick Dung
2020-01-03 17:14 ` Mikulas Patocka
2020-01-03 19:05   ` Patrick Dung
2020-01-05  9:39     ` Mikulas Patocka
2020-01-05 12:20       ` Patrick Dung [this message]

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=CAJTWkducreuW2LcOaipUMnNRFhvjd4N_LdKrnND-wBfCS593jg@mail.gmail.com \
    --to=patdung100@gmail.com \
    --cc=dm-devel@redhat.com \
    --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.