From: Gionatan Danti <firstname.lastname@example.org> To: LVM general discussion and development <email@example.com> Cc: "Roy Sigurd Karlsbakk" <firstname.lastname@example.org>, Håkon <email@example.com> Subject: Re: [linux-lvm] Looking ahead - tiering with LVM? Date: Wed, 09 Sep 2020 20:16:26 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <83152674.4938205.1599663690759.JavaMail.email@example.com> 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: firstname.lastname@example.org - email@example.com GPG public key ID: FF5F32A8
next prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).