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: Sat, 05 Sep 2020 13:47:15 +0200	[thread overview]
Message-ID: <53661d4eefb635710b51cf9bfee894ef@assyoma.it> (raw)
In-Reply-To: <79061390.1069833.1599071934227.JavaMail.zimbra@karlsbakk.net>

Il 2020-09-02 20:38 Roy Sigurd Karlsbakk ha scritto:
> Hi all
> 
> I just wonder how it could be possible some day, some year, to make
> lvm use tiering. I guess this has been debated numerous times before
> and I found this lvmts project, but it hasn't been updated for eight
> years or so.

Hi, having developed and supported file-level form of tiered storage in 
response to a specific customer request, I have the feeling that tiered 
storage (both file and block based) is not so useful as it seems. Let me 
explain why I feel so...

The key difference between caching and tiering is that the former does 
not increase total available space, while the latter provides as much 
space as available in each storage tier. For example, 1 TB SSD + 10 TB 
HDD can be combined for a 11 TB tiered volume.

Tiering is useful when the faster volume provides a significant portion 
of the total aggregated sum - which is often not the case. In the 
example above, the SSD only provides a 10% space increase over plain 
caching. You can argue that one can simple enlarge the performane tier, 
for example using a 4 TB SSD + 10 TB HDD, but you are now in the 
ballpark of affording a full-SSD volume - ditching *both* tiering and 
caching.

That said, LVM already provides the basic building block to provide 
tiering as you can pvmove between block devices. The difficult thing is 
how to determine which block to move, and managing them in an automated 
way.

Regards.

-- 
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-05 11:47 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 [this message]
2020-09-09 15:01   ` Roy Sigurd Karlsbakk
2020-09-09 18:16     ` Gionatan Danti
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=53661d4eefb635710b51cf9bfee894ef@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).