linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: "Roy Sigurd Karlsbakk" <roy@karlsbakk.net>, Håkon <hawken@thehawken.org>
Subject: Re: [linux-lvm] Looking ahead - tiering with LVM?
Date: Wed, 09 Sep 2020 20:16:26 +0200	[thread overview]
Message-ID: <3503b4f5b55345beb24de4b156ee75c7@assyoma.it> (raw)
In-Reply-To: <83152674.4938205.1599663690759.JavaMail.zimbra@karlsbakk.net>

Il 2020-09-09 17:01 Roy Sigurd Karlsbakk ha scritto:
> First, filelevel is usually useless. Say you have 50 VMs with Windows
> server something. A lot of them are bound to have a ton of equal
> storage in the same areas, but the file size and content will vary
> over time. With blocklevel tiering, that could work better.

It really depends on the use case. I applied it to a fileserver, so 
working at file level was the right choice. For VMs (or big files) it is 
useless, I agree.

> This is all known.

But the only reason to want tiering vs cache is the additional space the 
former provides. If this additional space is so small (compared to the 
combined, total volume space), tiering's advantage shrinks to (almost) 
nothing.

> If you look at IOPS instead of just sequencial speed, you'll see the
> difference. A set of 10 drives in a RAID-6 will perhaps, maybe, give
> you 1kIOPS, while a single SSD might give you 50kIOPS or even more.
> This makes a huge impact.

IOPs are already well server by LVM cache. So, I genuinely ask: what 
would be tiering advantage here? I'll love to ear a reasonable use case.

> …which was the reason I asked this question, and which should be quite
> clear in the original post.

Yeah, but this need a direct reply from a core LVM developer, which I 
wellcome ;)
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-09-09 18:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 18:38 Roy Sigurd Karlsbakk
2020-09-05 11:47 ` Gionatan Danti
2020-09-09 15:01   ` Roy Sigurd Karlsbakk
2020-09-09 18:16     ` Gionatan Danti [this message]
2020-09-09 18:47       ` John Stoffel
2020-09-09 19:10         ` Zdenek Kabelac
2020-09-09 19:21           ` John Stoffel
2020-09-09 19:44         ` Gionatan Danti
2020-09-09 19:53           ` John Stoffel
2020-09-09 20:20             ` Gionatan Danti
2020-09-09 19:41       ` Roy Sigurd Karlsbakk
2020-09-09 19:49         ` 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=3503b4f5b55345beb24de4b156ee75c7@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=hawken@thehawken.org \
    --cc=linux-lvm@redhat.com \
    --cc=roy@karlsbakk.net \
    --subject='Re: [linux-lvm] Looking ahead - tiering with LVM?' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).