Re: raw partition or LV for btrfs? (FAQ updated)
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 ` 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On Tue, Aug 14, 2012 at 07:23:48AM -0400, Calvin Walton wrote: > A patch to add support for `btrfs fi defrag -c none ` 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On Tue, Aug 14, 2012 at 8:21 AM, Fajar A. Nugraha wrote: > On Tue, Aug 14, 2012 at 9:09 PM, 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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On Tue, Aug 14, 2012 at 9:09 PM, 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. I'm pretty sure you can do that with parted. At least, when your version of parted is NOT 2.2. -- Fajar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On Tue, Aug 14, 2012 at 8:28 PM, Daniel Pocock 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
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). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On 12/08/12 22:48, Fajar A. Nugraha wrote: > On Sun, Aug 12, 2012 at 11:46 PM, Daniel Pocock 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On Mon, 2012-08-13 at 05:48 +0700, Fajar A. Nugraha wrote:
> On Sun, Aug 12, 2012 at 11:46 PM, Daniel Pocock 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 ` 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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On Mon, Aug 13, 2012 at 11:19 AM, Kyle Gates 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw partition or LV for btrfs?
On Sun, Aug 12, 2012 at 11:46 PM, Daniel Pocock 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
raw partition or LV for btrfs?
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)? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
