Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: mount option nodatacow for VMs on SSD?
Date: Fri, 25 Nov 2016 17:25:56 +0500	[thread overview]
Message-ID: <20161125172556.463a7796@natsu> (raw)
In-Reply-To: <pan$c85ad$dae9ebf5$a0482059$7c135fb1@cox.net>

On Fri, 25 Nov 2016 12:01:37 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Obviously this can be a HUGE problem on spinning rust due to its seek times,
> a problem zero-seek-time ssds don't have

They are not strictly zero seek time either. Sure you don't have the issue of
moving the physical head around, but still, sequential reads are way faster
even on SSDs, compared to random reads. Somewhat typical result for a
consumer SSD:

           Sequential Read :   382.301 MB/s
          Sequential Write :   315.124 MB/s
         Random Read 512KB :   261.751 MB/s
        Random Write 512KB :   334.615 MB/s
    Random Read 4KB (QD=1) :    19.859 MB/s [  4848.5 IOPS]
   Random Write 4KB (QD=1) :    61.794 MB/s [ 15086.3 IOPS]
   Random Read 4KB (QD=32) :   132.415 MB/s [ 32327.9 IOPS]
  Random Write 4KB (QD=32) :   203.051 MB/s [ 49573.0 IOPS]

If you have tons of 4K fragments, reading them in can go as low as 20 MB/sec,
compared to 382 MB/sec if they were all in one piece.

-- 
With respect,
Roman

  reply	other threads:[~2016-11-25 12:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-25  8:28 mount option nodatacow for VMs on SSD? Ulli Horlacher
2016-11-25 12:01 ` Duncan
2016-11-25 12:25   ` Roman Mamedov [this message]
2016-11-26 10:27 ` Kai Krakow
2016-11-28  0:38   ` Ulli Horlacher
2016-11-28  2:56     ` Duncan
2016-11-28  9:49       ` [Not TLS] " Graham Cobb
2016-11-29  5:14         ` Duncan
2016-11-29 10:34           ` [Not TLS] " Niccolò Belli
2016-11-29 12:18           ` [Not TLS] " Austin S. Hemmelgarn
2016-11-28  8:20     ` Kai Krakow
2016-11-28 11:11       ` Niccolò Belli
2016-11-29  5:06         ` Duncan
2016-11-29 12:20           ` Austin S. Hemmelgarn

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=20161125172556.463a7796@natsu \
    --to=rm@romanrm.net \
    --cc=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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