Re: BTRFS concerns
On 06/02/2011 08:28 PM, Richard W.M. Jones wrote: Maybe I'm not understanding your question correctly, but a filesystem is more general than LVM. You can create directories corresponding to your current VGs and files for your LVs, with the advantage that you can nest directories which you can't do with LVM VGs. If you mean nesting in the sense that an LVM2 LV is used as a PV then the tools support this just fine: # lvcreate -n nested_pv1_lv -L5G bmr_vg1 Logical volume nested_pv1_lv created # pvcreate /dev/bmr_vg1/nested_pv1_lv Physical volume /dev/bmr_vg1/nested_pv1_lv successfully created # vgcreate bmr_nested_vg0 /dev/bmr_vg1/nested_pv1_lv Volume group bmr_nested_vg0 successfully created # lvcreate -n nested_pv2_lv -L5G bmr_nested_vg0 Insufficient free extents (1279) in volume group bmr_nested_vg0: 1280 required # lvcreate -n nested_pv2_lv -l 1279 bmr_nested_vg0 Logical volume nested_pv2_lv created # pvcreate /dev/bmr_nested_vg0/nested_pv2_lv Physical volume /dev/bmr_nested_vg0/nested_pv2_lv successfully created # vgcreate bmr_nested_vg1 /dev/bmr_nested_vg0/nested_pv2_lv Volume group bmr_nested_vg1 successfully created # lvcreate -n l0 -l 1278 bmr_nested_vg1 Logical volume l0 created The 1-extent-per-nesting-level size decrement is to allow for the MDA allocated on each PV. The pvcreates are also strictly speaking unnecessary on recent tool versions since a vgcreate will now label a new device automatically but I'm old-fashioned ;-) You can view the device nesting via dmsetup: # dmsetup ls --tree bmr_nested_vg1-l0 [...] bmr_nested_vg1-l0 (253:10) └─bmr_nested_vg0-nested_pv2_lv (253:9) └─bmr_vg1-nested_pv1_lv (253:8) └─ (9:1) [...] # vgs VG #PV #LV #SN Attr VSize VFree bmr_nested_vg0 1 1 0 wz--n- 5.00g 0 bmr_nested_vg1 1 1 0 wz--n- 4.99g 0 bmr_vg0 1 4 0 wz--n- 222.82g 25.68g bmr_vg1 1 3 0 wz--n- 19.53g 6.62g If things aren't activating properly on boot/reboot then it's likely an initscripts limitation or bug. Udev based activation should simplify that but you can also work around it depending on your distro via e.g. rc.local. Regards, Bryn. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
On Wed, Jun 01, 2011 at 04:15:59PM +0100, Peter Robinson wrote: I will be unable to attend tomorrow but I have concerns of making btrfs default without a well tested fsck. I'm aware one is due soon but I don't believe 3-4 months is enough time to test it well enough. On 2.6.38.x I still get regular kernel abrt crashes on resume. Is it even marked stable in the upstream kernel yet? Another concern is whether btrfs is going to work well to store virtual machine disk images (ie. to replace LVM for that purpose, where LVM is known to work very efficiently). Last time I looked -- which I admit was a really long time ago -- it behaved fairly pathologically with these huge monolithic files that are rewritten in-place. (Edit: just noticed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=689127 ) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
On Thu, Jun 2, 2011 at 11:46 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jun 01, 2011 at 04:15:59PM +0100, Peter Robinson wrote: I will be unable to attend tomorrow but I have concerns of making btrfs default without a well tested fsck. I'm aware one is due soon but I don't believe 3-4 months is enough time to test it well enough. On 2.6.38.x I still get regular kernel abrt crashes on resume. Is it even marked stable in the upstream kernel yet? Another concern is whether btrfs is going to work well to store virtual machine disk images (ie. to replace LVM for that purpose, where LVM is known to work very efficiently). Last time I looked -- which I admit was a really long time ago -- it behaved fairly pathologically with these huge monolithic files that are rewritten in-place. (Edit: just noticed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=689127 ) These sort of issues are my priority and I've spent the last 2 months specifically working on the kvm performance differences between ext4 and btrfs. Now we're not on par with ext4 yet, but we aren't 2-3 times slower any more, maybe at the most we're 20% slower. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns
On 06/02/2011 01:14 PM, Josef Bacik wrote: These sort of issues are my priority and I've spent the last 2 months specifically working on the kvm performance differences between ext4 and btrfs. Now we're not on par with ext4 yet, but we aren't 2-3 times slower any more, maybe at the most we're 20% slower. Thanks, Josef Wondering - Are all the pieces (user space included) in place for RAID 5 yet ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
On Thu, Jun 02, 2011 at 12:44:46PM -0500, Chris Adams wrote: Once upon a time, Josef Bacik jo...@toxicpanda.com said: These sort of issues are my priority and I've spent the last 2 months specifically working on the kvm performance differences between ext4 and btrfs. Now we're not on par with ext4 yet, but we aren't 2-3 times slower any more, maybe at the most we're 20% slower. Thanks, How does it compare to straight LVM for virtual images? I create a big LV and then only use part of it for the host OS VG; when I create VMs, I create a VG for each (or I can snapshot an existing base VG). It is my understanding that one goal for btrfs is to take LVM out of the picture for the common case; i.e. btrfs can do its own logical volume management. If that's the case, there needs to be something comparable to the VM-on-VG setup (in terms of ease-of-management and performance). Maybe I'm not understanding your question correctly, but a filesystem is more general than LVM. You can create directories corresponding to your current VGs and files for your LVs, with the advantage that you can nest directories which you can't do with LVM VGs. However the performance issue will be critical -- even 5% slower really matters for VMs. But I hope btrfs can close this gap because the filesystem design is really nice. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS concerns (was: Re: Plan for tomorrow's FESCo meeting (2011-06-01))
Once upon a time, Richard W.M. Jones rjo...@redhat.com said: Maybe I'm not understanding your question correctly, but a filesystem is more general than LVM. You can create directories corresponding to your current VGs and files for your LVs, with the advantage that you can nest directories which you can't do with LVM VGs. However the performance issue will be critical -- even 5% slower really matters for VMs. But I hope btrfs can close this gap because the filesystem design is really nice. That was really my original point (that I didn't really state clearly I guess); btrfs performance with VM disk images should be compared against LVM VGs as well against ext4. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
