All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org, g.danti@assyoma.it
Subject: Re: XFS reflink vs ThinLVM
Date: Wed, 15 Jan 2020 18:45:09 +0100	[thread overview]
Message-ID: <761fcf8f9d68ee221a35d15c1a7120c5@assyoma.it> (raw)
In-Reply-To: <20200115163948.GF8257@magnolia>

Il 15-01-2020 17:39 Darrick J. Wong ha scritto:
> extszinherit > 0 disables delayed allocation, which means that (in your
> case above) if you wrote 1G to a file (using the pagecache) you'd get
> 8192x 128K calls to the allocator instead of making a single 1G
> allocation during writeback.

Thanks for the valuable information, I did not know that specific 
interaction between extsize and delalloc.

> If you have a lot of memory (or a high vmm
> dirty ratio) then you want delalloc over extsize.  Most of the time you
> want delalloc, frankly.

Let me briefly describe the expected workload: thinly provisioned 
virtual image storage. The problem with "plain" sparse file (ie: without 
extsize hint) is that, after some time, the underlying vdisk file will 
be very fragmented: consecutive physical blocks will be assigned to very 
different logical blocks, leading to sub-par performance when reading 
back the whole file (eg: for backup purpose).

I can easily simulate a worst-case scenario with fio, issuing random 
write to a pre-created sparse file. While the random writes complete 
very fast (because they are more-or-less sequentially written inside the 
sparse file), reading back that file will have very low performance: 10 
MB/s vs 600+ MB/s for a preallocated file.

Using a 128k extsize brings sequential read to ~100 MB/s (which is 
reasonable on that old hardware), and a 16M extsize is in the range of 
500+ MB/s.

Given that use case, do you suggest sticking with delalloc or setting an 
appropriate extsize?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  reply	other threads:[~2020-01-15 18:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 10:22 XFS reflink vs ThinLVM Gionatan Danti
2020-01-13 11:10 ` Carlos Maiolino
2020-01-13 11:25   ` Gionatan Danti
2020-01-13 11:43     ` Carlos Maiolino
2020-01-13 12:21       ` Gionatan Danti
2020-01-13 15:34         ` Gionatan Danti
2020-01-13 16:53           ` Darrick J. Wong
2020-01-13 17:00             ` Gionatan Danti
2020-01-13 18:09               ` Darrick J. Wong
2020-01-14  8:45                 ` Gionatan Danti
2020-01-15 11:37                   ` Gionatan Danti
2020-01-15 16:39                     ` Darrick J. Wong
2020-01-15 17:45                       ` Gionatan Danti [this message]
2020-01-17 21:58                         ` Gionatan Danti
2020-01-17 23:42                           ` Darrick J. Wong
2020-01-18 11:08                             ` Gionatan Danti
2020-01-18 23:06                               ` Darrick J. Wong
2020-01-19  8:45                                 ` Gionatan Danti
2020-01-13 16:14 ` Chris Murphy
2020-01-13 16:25   ` Gionatan Danti

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=761fcf8f9d68ee221a35d15c1a7120c5@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@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 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.