raw partition or LV for btrfs?

raw partition or LV for btrfs?

[Daniel Pocock]

I notice this question on the wiki/faq:


https://btrfs.wiki.kernel.org/index.php/UseCases#What_is_best_practice_when_partitioning_a_device_that_holds_one_or_more_btr-filesystems

and as it hasn't been answered, can anyone make any comments on the subject

Various things come to mind:

a) partition the disk, create an LVM partition, and create lots of small
LVs, format each as btrfs

b) partition the disk, create an LVM partition, and create one big LV,
format as btrfs, make subvolumes

c) what about using btrfs RAID1?  Does either approach (a) or (b) seem
better for someone who wants the RAID1 feature?

d) what about booting from a btrfs system?  Is it recommended to follow
the ages-old practice of keeping a real partition of 128-500MB,
formatting it as btrfs, even if all other data is in subvolumes as per (b)?

Re: raw partition or LV for btrfs?

[Fajar A. Nugraha]

On Sun, Aug 12, 2012 at 11:46 PM, Daniel Pocock <daniel@pocock.com.au> wrote:
>
>
> I notice this question on the wiki/faq:
>
>
> https://btrfs.wiki.kernel.org/index.php/UseCases#What_is_best_practice_when_partitioning_a_device_that_holds_one_or_more_btr-filesystems
>
> and as it hasn't been answered, can anyone make any comments on the subject
>
> Various things come to mind:
>
> a) partition the disk, create an LVM partition, and create lots of small
> LVs, format each as btrfs
>
> b) partition the disk, create an LVM partition, and create one big LV,
> format as btrfs, make subvolumes
>
> c) what about using btrfs RAID1?  Does either approach (a) or (b) seem
> better for someone who wants the RAID1 feature?

IMHO when the qgroup feature is "stable" (i.e. adopted by distros, or
at least in stable kernel) then simply creating one big partition (and
letting btrfs handle RAID1, if you use it) is better. When 3.6 is out,
perhaps?

Until then I'd use LVM.

>
> d) what about booting from a btrfs system?  Is it recommended to follow
> the ages-old practice of keeping a real partition of 128-500MB,
> formatting it as btrfs, even if all other data is in subvolumes as per (b)?

You can have one single partition only and boot directly from that.
However btrfs has the same problems as zfs in this regard:
- grub can read both, but can't write to either. In other words, no
support for grubenv
- the "best" compression method (gzip for zfs, lzo for btrfs) is not
supported by grub

For the first problem, an easy workaroud is just to disable the grub
configuration that uses grubenv. Easy enough, and no major
functionality loss.

The second one is harder for btrfs. zfs allows you to have separate
dataset (i.e. subvolume, in btfs terms) with different compression, so
you can have a dedicated dataset for /boot with different compression
setting from the rest of the dataset. With btrfs you're currently
stuck with using the same compression setting for everything, so if
you love lzo this might be a major setback.

There's also a btrfs-specific problem: it's hard to have a system
which have /boot on a separate subvol while managing it with current
automatic tools (e.g. update-grub).

Due to second and third problem, I'd recommend you just use a separate
partition with ext2/4 for now.

-- 
Fajar

Re: raw partition or LV for btrfs?

[Kyle Gates]

I'm currently running a 1GB raid1 btrfs /boot with no problems.
Also, I think the current grub2 has lzo support.

-----Original Message----- 
From: Fajar A. Nugraha
Sent: Sunday, August 12, 2012 5:48 PM
To: Daniel Pocock
Cc: linux-btrfs@vger.kernel.org
Subject: Re: raw partition or LV for btrfs?

On Sun, Aug 12, 2012 at 11:46 PM, Daniel Pocock <daniel@pocock.com.au> 
wrote:
>
>
> I notice this question on the wiki/faq:
>
>
> https://btrfs.wiki.kernel.org/index.php/UseCases#What_is_best_practice_when_partitioning_a_device_that_holds_one_or_more_btr-filesystems
>
> and as it hasn't been answered, can anyone make any comments on the 
> subject
>
> Various things come to mind:
>
> a) partition the disk, create an LVM partition, and create lots of small
> LVs, format each as btrfs
>
> b) partition the disk, create an LVM partition, and create one big LV,
> format as btrfs, make subvolumes
>
> c) what about using btrfs RAID1?  Does either approach (a) or (b) seem
> better for someone who wants the RAID1 feature?

IMHO when the qgroup feature is "stable" (i.e. adopted by distros, or
at least in stable kernel) then simply creating one big partition (and
letting btrfs handle RAID1, if you use it) is better. When 3.6 is out,
perhaps?

Until then I'd use LVM.

>
> d) what about booting from a btrfs system?  Is it recommended to follow
> the ages-old practice of keeping a real partition of 128-500MB,
> formatting it as btrfs, even if all other data is in subvolumes as per 
> (b)?

You can have one single partition only and boot directly from that.
However btrfs has the same problems as zfs in this regard:
- grub can read both, but can't write to either. In other words, no
support for grubenv
- the "best" compression method (gzip for zfs, lzo for btrfs) is not
supported by grub

For the first problem, an easy workaroud is just to disable the grub
configuration that uses grubenv. Easy enough, and no major
functionality loss.

The second one is harder for btrfs. zfs allows you to have separate
dataset (i.e. subvolume, in btfs terms) with different compression, so
you can have a dedicated dataset for /boot with different compression
setting from the rest of the dataset. With btrfs you're currently
stuck with using the same compression setting for everything, so if
you love lzo this might be a major setback.

There's also a btrfs-specific problem: it's hard to have a system
which have /boot on a separate subvol while managing it with current
automatic tools (e.g. update-grub).

Due to second and third problem, I'd recommend you just use a separate
partition with ext2/4 for now.

-- 
Fajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: raw partition or LV for btrfs?

[Fajar A. Nugraha]

On Mon, Aug 13, 2012 at 11:19 AM, Kyle Gates <kylegates@hotmail.com> wrote:
> Also, I think the current grub2 has lzo support.

You're right

grub2 (1.99-18) unstable; urgency=low

  [ Colin Watson ]
...
  * Backport from upstream:
    - Add support for LZO compression in btrfs (LP: #727535).

so Ubuntu has it since precise, which is roughly the time I switched
to zfs for rootfs :P

Thanks for letting us know about that.

-- 
Fajar

Re: raw partition or LV for btrfs?

[Calvin Walton]

On Mon, 2012-08-13 at 05:48 +0700, Fajar A. Nugraha wrote:
> On Sun, Aug 12, 2012 at 11:46 PM, Daniel Pocock <daniel@pocock.com.au> wrote:

> > d) what about booting from a btrfs system?  Is it recommended to follow
> > the ages-old practice of keeping a real partition of 128-500MB,
> > formatting it as btrfs, even if all other data is in subvolumes as per (b)?
> 
> You can have one single partition only and boot directly from that.
> However btrfs has the same problems as zfs in this regard:
> - grub can read both, but can't write to either. In other words, no
> support for grubenv
> - the "best" compression method (gzip for zfs, lzo for btrfs) is not
> supported by grub

This is actually not true; the grub 2.00 release does support reading
from lzo-compressed btrfs filesystems. (Of course, if any other new
compression algorithms are added, this issue will happen again.)

> For the first problem, an easy workaroud is just to disable the grub
> configuration that uses grubenv. Easy enough, and no major
> functionality loss.
> 
> The second one is harder for btrfs. zfs allows you to have separate
> dataset (i.e. subvolume, in btfs terms) with different compression, so
> you can have a dedicated dataset for /boot with different compression
> setting from the rest of the dataset. With btrfs you're currently
> stuck with using the same compression setting for everything, so if
> you love lzo this might be a major setback.

It's possible to disable compression on individual files on btrfs. If
you disable compression on everything in /boot/grub{2,} and on your
kernels and initramfses then grub will be able to read them no matter
what.

Unfortunately, this is a bit tricky to do at the moment: you have to
remount the filesystem with `-o compress=no`, then run `btrfs fi defrag`
individually on all the files that you want uncompressed.

A patch to add support for `btrfs fi defrag -c none <file>` or so would
make this easier, and shouldn't be to hard to do :)

> Due to second and third problem, I'd recommend you just use a separate
> partition with ext2/4 for now.

Even with my comments, this is still my recommendation. (Although if
you're using a EFI bios, you could just stick all the bootloader stuff
on the VFAT EFI system partition instead.)

-- 
Calvin Walton <calvin.walton@kepstin.ca>

Re: raw partition or LV for btrfs?

[David Sterba]

On Tue, Aug 14, 2012 at 07:23:48AM -0400, Calvin Walton wrote:
> A patch to add support for `btrfs fi defrag -c none <file>` or so would
> make this easier, and shouldn't be to hard to do :)

This one is on my list of 'nice to have', it's needed to extend the
ioctl to understand 'none' as to actually use no compression during the
defrag, while currently it means 'whatever compression the file has
set'.


david

Re: raw partition or LV for btrfs? (FAQ updated)

[Daniel Pocock]

On 22/08/12 17:42, David Sterba wrote:
> On Tue, Aug 14, 2012 at 07:23:48AM -0400, Calvin Walton wrote:
>> A patch to add support for `btrfs fi defrag -c none <file>` or so would
>> make this easier, and shouldn't be to hard to do :)
> 
> This one is on my list of 'nice to have', it's needed to extend the
> ioctl to understand 'none' as to actually use no compression during the
> defrag, while currently it means 'whatever compression the file has
> set'.
> 

Thanks for all the feedback about this, I've tried to gather the
responses into the FAQ:

https://btrfs.wiki.kernel.org/index.php/FAQ#Interaction_with_partitions.2C_device_managers_and_logical_volumes

Re: raw partition or LV for btrfs?

[Daniel Pocock]

On 12/08/12 22:48, Fajar A. Nugraha wrote:
> On Sun, Aug 12, 2012 at 11:46 PM, Daniel Pocock <daniel@pocock.com.au> wrote:
>>
>>
>> I notice this question on the wiki/faq:
>>
>>
>> https://btrfs.wiki.kernel.org/index.php/UseCases#What_is_best_practice_when_partitioning_a_device_that_holds_one_or_more_btr-filesystems
>>
>> and as it hasn't been answered, can anyone make any comments on the subject
>>
>> Various things come to mind:
>>
>> a) partition the disk, create an LVM partition, and create lots of small
>> LVs, format each as btrfs
>>
>> b) partition the disk, create an LVM partition, and create one big LV,
>> format as btrfs, make subvolumes
>>
>> c) what about using btrfs RAID1?  Does either approach (a) or (b) seem
>> better for someone who wants the RAID1 feature?
> 
> IMHO when the qgroup feature is "stable" (i.e. adopted by distros, or
> at least in stable kernel) then simply creating one big partition (and
> letting btrfs handle RAID1, if you use it) is better. When 3.6 is out,
> perhaps?
> 
> Until then I'd use LVM.
> 

Can you just elaborate on the qgroups feature?
- Does this just mean I can make the subvolume sizes rigid, like LV sizes?
- Or is it per-user restrictions or some other more elaborate solution?

If I create 10 LVs today, with btrfs on each, can I merge them all into
subvolumes on a single btrfs later?

If I just create a 1TB btrfs with subvolumes now, can I upgrade to
qgroups later?  Or would I have to recreate the filesystem?

I really appreciate the answers from people.  Reflecting on some of the
comments and past experience, my feeling is that I should do the following:

a) create the partition table as normal
b) create one big partition as LVM (type 0x8e)
c) create one big LV (for all of the disk)
d) format the LV as btrfs
e) create a subvolume to hold the data from each LV that I have on my
old disk

My reason for doing (b) and (c) is that I may want to have the following
options in future - would these still be possible without LVM at all,
using btrfs on a raw 1TB partition?
- using pvmove to move the filesystem to another physical device (e.g.
if I purchase a 2TB drive to replace the 1TB drive)
- using lvresize to expand the allocation onto such a new drive

If I understand correctly, if I don't use LVM, then such move and resize
operations can't be done for an online filesystem and it has more risk.

Re: raw partition or LV for btrfs?

[Olivier Bonvalet]

On 14/08/2012 15:28, Daniel Pocock wrote:
> If I create 10 LVs today, with btrfs on each,


 From my understanding of Btrfs, it achieve good write performance by 
making near all writes "sequential". But if you split your disk in 10 
sub-parts, and set btrfs on each of them, writes operations of Btrfs 
will not really be sequential anymore.

So, for me, to have good performance btrfs should manage all the disk
(maybe excepting the /boot/ directory, just to avoid any problem with grub).

Re: raw partition or LV for btrfs?

[Fajar A. Nugraha]

On Tue, Aug 14, 2012 at 8:28 PM, Daniel Pocock <daniel@pocock.com.au> wrote:
> Can you just elaborate on the qgroups feature?
> - Does this just mean I can make the subvolume sizes rigid, like LV sizes?

Pretty much.

> - Or is it per-user restrictions or some other more elaborate solution?

No

>
> If I create 10 LVs today, with btrfs on each, can I merge them all into
> subvolumes on a single btrfs later?

No

>
> If I just create a 1TB btrfs with subvolumes now, can I upgrade to
> qgroups later?

Yes

>  Or would I have to recreate the filesystem?

No

> If I understand correctly, if I don't use LVM, then such move and resize
> operations can't be done for an online filesystem and it has more risk.

You can resize, add, and remove devices from btrfs online without the
need for LVM. IIRC LVM has finer granularity though, you can do
something like "move only the first 10GB now, I'll move the rest
later".

-- 
Fajar

Re: raw partition or LV for btrfs?

[cwillu]

>> If I understand correctly, if I don't use LVM, then such move and resize
>> operations can't be done for an online filesystem and it has more risk.
>
> You can resize, add, and remove devices from btrfs online without the
> need for LVM. IIRC LVM has finer granularity though, you can do
> something like "move only the first 10GB now, I'll move the rest
> later".

You can certainly resize the filesystem itself, but without lvm I
don't believe you can resize the underlying partition online.

Re: raw partition or LV for btrfs?

[Fajar A. Nugraha]

On Tue, Aug 14, 2012 at 9:09 PM, cwillu <cwillu@cwillu.com> wrote:
>>> If I understand correctly, if I don't use LVM, then such move and resize
>>> operations can't be done for an online filesystem and it has more risk.
>>
>> You can resize, add, and remove devices from btrfs online without the
>> need for LVM. IIRC LVM has finer granularity though, you can do
>> something like "move only the first 10GB now, I'll move the rest
>> later".
>
> You can certainly resize the filesystem itself, but without lvm I
> don't believe you can resize the underlying partition online.

I'm pretty sure you can do that with parted. At least, when your
version of parted is NOT 2.2.

-- 
Fajar

Re: raw partition or LV for btrfs?

[cwillu]

On Tue, Aug 14, 2012 at 8:21 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Tue, Aug 14, 2012 at 9:09 PM, cwillu <cwillu@cwillu.com> wrote:
>>>> If I understand correctly, if I don't use LVM, then such move and resize
>>>> operations can't be done for an online filesystem and it has more risk.
>>>
>>> You can resize, add, and remove devices from btrfs online without the
>>> need for LVM. IIRC LVM has finer granularity though, you can do
>>> something like "move only the first 10GB now, I'll move the rest
>>> later".
>>
>> You can certainly resize the filesystem itself, but without lvm I
>> don't believe you can resize the underlying partition online.
>
> I'm pretty sure you can do that with parted. At least, when your
> version of parted is NOT 2.2.

block/ioctl.c:blkdev_reread_part calls into
block/partition-generic.c:rescan_partitions, which fails out early
with EBUSY if block/partition-generic.c:drop_partitions sees a
non-zero bdev->bd_part_count, which is a count of the open partition
bdev's.

Calvin mentions below that this may be changing shortly, but I'm going
to claim to be right on this one.

Re: raw partition or LV for btrfs?

[Calvin Walton]

On Tue, 2012-08-14 at 08:09 -0600, cwillu wrote:
> >> If I understand correctly, if I don't use LVM, then such move and resize
> >> operations can't be done for an online filesystem and it has more risk.
> >
> > You can resize, add, and remove devices from btrfs online without the
> > need for LVM. IIRC LVM has finer granularity though, you can do
> > something like "move only the first 10GB now, I'll move the rest
> > later".
> 
> You can certainly resize the filesystem itself, but without lvm I
> don't believe you can resize the underlying partition online.

There are actually some patches floating around that will allow
partitions (MBR/GPT) to be resized online, I think they're queued up to
be included in some upcoming linux release:
http://lwn.net/Articles/481141/

You still can't move partitions online, of course.

-- 
Calvin Walton <calvin.walton@kepstin.ca>