public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Tomasz Chmielewski <mangoo@wpkg.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: LVM vs btrfs as a "volume manager" for SANs
Date: Thu, 23 Apr 2009 14:45:13 -0400	[thread overview]
Message-ID: <1240512313.28015.14.camel@think.oraclecorp.com> (raw)
In-Reply-To: <49EF6DF7.9020406@wpkg.org>

On Wed, 2009-04-22 at 21:20 +0200, Tomasz Chmielewski wrote:
> Right now, the majority of Linux users probably have LVM on their SAN 
> devices (i.e those being iSCSI targets).
> 
> Using LVM on a SAN device is easy: just create a new logical volume or 
> its snapshot, make it a target to iSCSI initiators, done.
> 

This is definitely one of the target use cases for btrfs.

> I was wondering how btrfs would fit here and if it could replace LVM.
> 
> 
> I see the following benefits of using btrfs instead of LVM:
> 
> - you can create sparse files which would grow as iSCSI initators use 
> more space (you can do it with ext3 now as well)
>
> - you can use btrfs compression, to further reduce used space and 
> perhaps increase speed (SANs are mostly IO bound, not CPU bound)
> 
> - LVM has a big performance hit when using snapshots; btrfs doesn't
> 
> 
> 
> However, with btrfs, I'm not sure about:
> 
> - what happens if SAN machine crashes while the iSCSI file images were 
> being written to; with LVM and its block devices, I'm somehow more 
> confident it wouldn't make more data loss than necessary

If iscsi is writing with O_DIRECT|O_SYNC it should work.  But, tuning
for this config is something we have to concentrate more on.

> 
> - taking snapshots of individual files (file images on SAN) is not 
> possible with btrfs? Probably they would have to be placed in separate 
> directories first to make snapshots - some minor manageability issue

Btrfs can't snapshot a single dir, but it can snapshot a single file.
See the bcp command included with btrfs-progs.

I'd also suggest using preallocated files (via fallocate) instead of
sparse files.  I will perform better in general.

-chris



  parent reply	other threads:[~2009-04-23 18:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-22 19:20 LVM vs btrfs as a "volume manager" for SANs Tomasz Chmielewski
2009-04-23  0:13 ` Dmitri Nikulin
2009-04-23 18:45 ` Chris Mason [this message]
2009-04-23 23:34   ` Tomasz Chmielewski
2009-04-24 12:38     ` Chris Mason
2009-07-02 15:22       ` Tomasz Chmielewski
2009-07-06 18:51         ` Chris Mason

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=1240512313.28015.14.camel@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mangoo@wpkg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox