All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gert Menke <gert@menke.ac>
To: linux-btrfs@vger.kernel.org
Subject: Re: BTRFS as image store for KVM?
Date: Thu, 17 Sep 2015 19:56:08 +0200	[thread overview]
Message-ID: <55FAFEB8.6030404@menke.ac> (raw)
In-Reply-To: <pan$a7c37$760f233d$6b18271c$f9ac2029@cox.net>

Hi,

thank you for your answers!

So it seems there are several suboptimal alternatives here...

MD+LVM is very close to what I want, but md has no way to cope with 
silent data corruption. So if I'd want to use a guest filesystem that 
has no checksums either, I'm out of luck.
I'm honestly a bit confused here - isn't checksumming one of the most 
obvious things to want in a software RAID setup? Is it a feature that 
might appear in the future? Maybe I should talk to the md guys...

BTRFS looks really nice feature-wise, but is not (yet) optimized for my 
use-case I guess. Disabling COW would certainly help, but I don't want 
to lose the data checksums. Is nodatacowbutkeepdatachecksums a feature 
that might turn up in the future?

Maybe ZFS is the best choice for my scenario. At least, it seems to work 
fine for Joyent - their SmartOS virtualization OS is essentially Illumos 
(Solaris) with ZFS, and KVM ported from Linux.
Since ZFS supports "Volumes" (virtual block devices inside a ZPool), I 
suspect these are probably optimized to be used for VM images (i.e. do 
as little COW as possible). Of course, snapshots will always degrade 
performance to a degree.

However, there are some drawbacks to ZFS:
- It's less flexible, especially when it comes to reconfiguration of 
disk arrays. Add or remove a disk to/from a RaidZ and rebalance, that 
would be just awesome. It's possible in BTRFS, but not ZFS. :-(
- The not-so-good integration of the fs cache, at least on Linux. I 
don't know if this is really an issue, though. Actually, I imagine it's 
more of an issue for guest systems, because it probably breaks memory 
ballooning. (?)

So it seems there are two options for me:
1. Go with ZFS for now, until BTRFS finds a better way to handle disk 
images, or until md gets data checksums.
2. Buy a bunch of SSDs for VM disk images and use spinning disks for 
data storage only. In that case, BTRFS should probably do fine.

Any comments on that? Am I missing something?

Thanks!
Gert

  parent reply	other threads:[~2015-09-17 17:56 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-15 21:34 BTRFS as image store for KVM? Gert Menke
2015-09-16  3:00 ` Chris Murphy
2015-09-16  3:57 ` Duncan
2015-09-16 11:35   ` Brendan Heading
2015-09-16 12:25     ` Austin S Hemmelgarn
2015-09-16 12:41     ` Paul Jones
2015-09-17 17:56   ` Gert Menke [this message]
2015-09-17 18:35     ` Chris Murphy
2015-09-17 21:32       ` Gert Menke
2015-09-18  2:00       ` Duncan
2015-09-18  8:32         ` Gert Menke
2015-09-23  7:28         ` Russell Coker
2015-09-18 14:13       ` Austin S Hemmelgarn
2015-09-23  7:24         ` Russell Coker
2015-09-17 18:46     ` Mike Fleetwood
2015-09-17 19:43     ` Hugo Mills
2015-09-17 21:49       ` Gert Menke
2015-09-18  2:22       ` Duncan
2015-09-18  8:59         ` Gert Menke
2015-09-17 22:41     ` Sean Greenslade
2015-09-18  7:34       ` Gert Menke
2015-09-17  4:19 ` Paul Harvey
2015-09-20  1:26 ` Jim Salter
2015-09-25 12:48   ` Rich Freeman
2015-09-25 12:56     ` Jim Salter
2015-09-25 13:04     ` Austin S Hemmelgarn
     [not found]       ` <5605483A.7040103@jrs-s.net>
2015-09-25 13:46         ` Austin S Hemmelgarn
2015-09-25 13:52       ` Jim Salter
2015-09-25 14:02         ` Timofey Titovets
2015-09-25 14:20           ` Austin S Hemmelgarn
2015-09-29 14:12             ` Gert Menke
2015-10-02  4:21             ` Russell Coker
2015-10-02 12:07               ` Austin S Hemmelgarn
2015-10-03  8:32                 ` Russell Coker
2015-10-04  2:09                   ` Duncan
2015-10-04 12:03                     ` Lionel Bouton
2015-10-04 12:21                       ` Rich Freeman
2015-10-05  8:19                         ` Duncan
2015-10-05  8:43                       ` Erkki Seppala
2015-10-05  8:51                         ` Roman Mamedov
2015-10-05 11:16                       ` Lionel Bouton
2015-10-05 11:40                         ` Rich Freeman
2015-10-05 11:54                         ` Austin S Hemmelgarn
     [not found]                       ` <RPG31r00t34oj7R01PG5Us>
2015-10-05 14:04                         ` Duncan
2015-10-05 15:59                           ` Austin S Hemmelgarn

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=55FAFEB8.6030404@menke.ac \
    --to=gert@menke.ac \
    --cc=linux-btrfs@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.