All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Peter Zaitsev <pz@percona.com>, Hugo Mills <hugo@carfax.org.uk>,
	linux-btrfs@vger.kernel.org
Subject: Re: BTRFS for OLTP Databases
Date: Tue, 7 Feb 2017 14:50:04 -0500	[thread overview]
Message-ID: <91c8a758-23b6-edf1-74b0-2d87acbb2560@gmail.com> (raw)
In-Reply-To: <CA+RUij3LJeFR1pz9QDOkMEVbh1cws5Rv2KPep3ghVAimJy7aLA@mail.gmail.com>

On 2017-02-07 14:31, Peter Zaitsev wrote:
> Hi Hugo,
>
> As I re-read it closely (and also other comments in the thread) I know
> understand there is a difference how nodatacow works even if snapshot are
> in place.
>
> On autodefrag I wonder is there some more detailed documentation about how
> autodefrag works.
>
> The manual  https://btrfs.wiki.kernel.org/index.php/Mount_options    has
> very general statement.
>
> What does "detect random IO" really means  ? It also talks about
>  defragmenting the file - is i really about the whole file which is
> triggered for defrag or is defrag locally ?      Ie I would understand what
> as writes happen the  1MB block is checked and if it is more than X
> fragments it is defragmented or something like that.
I don't know the exact algorithm, but I'm pretty sure it's similar to 
what bcache uses to bypass the cache device for sequential I/O.  In 
essence, it's going to trigger for database usage.
>
> Also does autodefrag works with nodatacow (ie with snapshot)  or are these
> exclusive ?
I'm not sure about this one.  I would assume based on the fact that many 
other things don't work with nodatacow and that regular defrag doesn't 
work on files which are currently mapped as executable code that it does 
not, but I could be completely wrong about this too.
>
>
>>
>>    There's another approach which might be worth testing, which is to
>> use autodefrag. This will increase data write I/O, because where you
>> have one or more small writes in a region, it will also read and write
>> the data in a small neghbourhood around those writes, so the
>> fragmentation is reduced. This will improve subsequent read
>> performance.
>>
>>    I could also suggest getting the latest kernel you can -- 16.04 is
>> already getting on for a year old, and there may be performance
>> improvements in upstream kernels which affect your workload. There's
>> an Ubuntu kernel PPA you can use to get the new kernels without too
>> much pain.
>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  reply	other threads:[~2017-02-07 19:50 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07 13:53 BTRFS for OLTP Databases Peter Zaitsev
2017-02-07 14:00 ` Hugo Mills
2017-02-07 14:13   ` Peter Zaitsev
2017-02-07 15:00     ` Timofey Titovets
2017-02-07 15:09       ` Austin S. Hemmelgarn
2017-02-07 15:20         ` Timofey Titovets
2017-02-07 15:43           ` Austin S. Hemmelgarn
2017-02-07 21:14             ` Kai Krakow
2017-02-07 16:22     ` Lionel Bouton
2017-02-07 19:57     ` Roman Mamedov
2017-02-07 20:36     ` Kai Krakow
2017-02-07 20:44       ` Lionel Bouton
2017-02-07 20:47       ` Austin S. Hemmelgarn
2017-02-07 21:25         ` Lionel Bouton
2017-02-07 21:35           ` Kai Krakow
2017-02-07 22:27             ` Hans van Kranenburg
2017-02-08 19:08             ` Goffredo Baroncelli
     [not found]         ` <b0de25a7-989e-d16a-2ce6-2b6c1edde08b@gmail.com>
2017-02-13 12:44           ` Austin S. Hemmelgarn
2017-02-13 17:16             ` linux-btrfs
2017-02-07 19:31   ` Peter Zaitsev
2017-02-07 19:50     ` Austin S. Hemmelgarn [this message]
2017-02-07 20:19       ` Kai Krakow
2017-02-07 20:27         ` Austin S. Hemmelgarn
2017-02-07 20:54           ` Kai Krakow
2017-02-08 12:12             ` Austin S. Hemmelgarn
2017-02-08  2:11   ` Peter Zaitsev
2017-02-08 12:14     ` Martin Raiber
2017-02-08 13:00       ` Adrian Brzezinski
2017-02-08 13:08       ` Austin S. Hemmelgarn
2017-02-08 13:26         ` Martin Raiber
2017-02-08 13:32           ` Austin S. Hemmelgarn
2017-02-08 14:28             ` Adrian Brzezinski
2017-02-08 13:38           ` Peter Zaitsev
2017-02-07 14:47 ` Peter Grandi
2017-02-07 15:06 ` Austin S. Hemmelgarn
2017-02-07 19:39   ` Kai Krakow
2017-02-07 19:59     ` Austin S. Hemmelgarn
2017-02-07 18:27 ` Jeff Mahoney
2017-02-07 18:59   ` Peter Zaitsev
2017-02-07 19:54     ` Austin S. Hemmelgarn
2017-02-07 20:40       ` Peter Zaitsev
2017-02-07 22:08     ` Hans van Kranenburg

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=91c8a758-23b6-edf1-74b0-2d87acbb2560@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=pz@percona.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.