All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell Coker <russell@coker.com.au>
To: Chris Murphy <lists@colorremedies.com>
Cc: "linux-btrfs Mailing list" <linux-btrfs@vger.kernel.org>
Subject: Re: Another novice question & comment
Date: Fri, 28 Dec 2012 11:34:10 +1100	[thread overview]
Message-ID: <201212281134.10604.russell@coker.com.au> (raw)
In-Reply-To: <5BAA2347-6336-4C05-B075-BEF93427EF07@colorremedies.com>

On Fri, 28 Dec 2012, Chris Murphy <lists@colorremedies.com> wrote:
> On Dec 27, 2012, at 12:27 PM, Gene Czarcinski <gene@czarc.net> wrote:
> > Oh thanks for that little reminder that you can put btrfs on an LV.
> 
> I find it's more trouble than it's worth. It doesn't bring much to the
> table.

I've tried using LVM and BTRFS together.  While they work the combination 
doesn't seem to offer much benefit.  LVM is good for snapshots (which BTRFS does 
better) and also for dividing a device that is larger than your filesystem can 
properly support (also not a problem for BTRFS).

http://etbe.coker.com.au/2012/12/17/using-btrfs/

At the above URL I've documented some of the things I'm currently doing with 
BTRFS in production.  I'm still considering what's the best way of managing 
virtual machines. My current method is to run a server with two disks that 
have separate LVM VGs and give each VM a pair of block devices to run BTRFS 
RAID-1.

The other option I'm considering is a single BTRFS RAID-1 taking all disk 
space and giving each VM a single block device that's a file on the BTRFS 
filesystem.  Presumably that will give a significant performance hit because of 
double filesystem overhead but will make management a little easier and 
possibly reduce seeks when multiple VMs are writing to disk.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

  reply	other threads:[~2012-12-28  0:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-27 14:29 Another novice question & comment Gene Czarcinski
2012-12-27 15:03 ` Hugo Mills
2012-12-27 16:47   ` Swâmi Petaramesh
2012-12-27 16:55     ` Chris Murphy
     [not found]       ` <50DC7F85.4020807@petaramesh.org>
2012-12-27 19:25         ` Chris Murphy
2012-12-27 19:27           ` Swâmi Petaramesh
2012-12-27 19:35             ` Chris Murphy
2012-12-27 22:10               ` Swâmi Petaramesh
2012-12-27 19:27       ` Gene Czarcinski
2012-12-27 19:29         ` Swâmi Petaramesh
2012-12-27 19:37         ` Chris Murphy
2012-12-28  0:34           ` Russell Coker [this message]
2012-12-28  5:03             ` Chris Murphy
2012-12-27 16:07 ` Chris Murphy
2012-12-27 19:14   ` Gene Czarcinski
2012-12-27 23:06     ` David Sterba

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=201212281134.10604.russell@coker.com.au \
    --to=russell@coker.com.au \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /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.