On 2011-02-23 at 23:32-06 Michael Cronenworth <mike(a)cchtml.com> wrote:
On 02/23/2011 05:38 PM, James Ralston wrote:
> None of these issues is a dealbreaker, but they *are* losses of
> functionality versus what LVM offers.
LVM isn't going anywhere. It just won't be the default during a
fresh installation, which you would still be free to override by
using an LVM again if you wished.
But I *don't* wish to discard btrfs and continue to use LVM.
What I want to do is *replace* my use of LVM with btrfs.
But to do that, I need to either figure out how to make btrfs do the
things I currently do with LVM, or I need to figure out how to change
the things I do to better leverage the capabilities of btrfs. I'm
open to the former, the latter, or some combination of both. But
right now, I've been unable to find enough information about btrfs to
A third thing that's important to me (which others have already
mentioned): disks for virtual guests. With LVM, I simply lvcreate a
new volume, and then when I create a new guest with virt-manager, I
tell it to use the block device for the LVM logical volume. This
avoids having a filesystem layer between the virtual guest and the LVM
block device, which I've assumed (but have not actually tested) is a
But in the "btrfs is your entire disk" model, it seems that my only
option is to create a big file on the filesystem, and tell
virt-manager to use that as the guest's disk. Even if I create the
big file efficiently (i.e., with fallocate(2)), how much of a
performance hit will I take by having the guest's disk I/O go through
the btrfs filesystem layer, versus the LVM layer? A little? A lot?
None at all, because it'll actually be a performance win? I have no
idea. And furthermore, I don't know if there's a better way to do it.