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
next prev parent 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.