[PVE-User] BTRFS...

[Gilberto Nunes]

I see your point of view, Wolfgang...
But I just bring this matter at light because I see from other perspective:
inside the VM.
I usually work with KVM guest.
Now, occur to specific VM to run out of space in a virtual hard disk.
I forgot to use LVM and as consequently, I will need added a new disk and
format it as LVM or BTRFS, in order to be able to increase the virtual disk
later...
Now, the disk is /dev/vdaX format as XFS...
I already growed up the image to the necessary additional space, but I am
not can increase the volume...
I try xfs_growfs but doesn't work...
So, I make same research by myself I think about BTRFS or LVM...
So, follow your advice, is better to my sanity, continue my life with LVM,
at least for now...

2016-02-02 13:20 GMT-02:00 Gilberto Nunes <gilberto.nunes32 at gmail.com>:

> I see your point of view, Wolfgang...
> But I just bring this matter at light because I see from other
> perspective: inside the VM.
> I usually work with KVM guest.
> Now, occur to specific VM to run out of space in a virtual hard disk.
> I forgot to use LVM and as consequently, I will need added a new disk and
> format it as LVM or BTRFS, in order to be able to increase the virtual disk
> later...
> Now, the disk is /dev/vdaX format as XFS...
> I already growed up the image to the necessary additional space, but I am
> not can increase the volume...
> I try xfs_growfs but doesn't work...
> So, I make same research by myself I think about BTRFS or LVM...
> So, follow your advice, is better to my sanity, continue my life with LVM,
> at least for now...
>
>
> 2016-02-02 12:09 GMT-02:00 Wolfgang Bumiller <w.bumiller at proxmox.com>:
>
>> On Tue, Feb 02, 2016 at 11:40:47AM -0200, Gilberto Nunes wrote:
>> > Well
>> >
>> > I almost do it, 'cause one of feature I appreciate in btrfs is the
>> hability
>> > to increase or decrease disk size.
>> > I know LVM can do it as well, but LVM are always on top whatever X
>> > Filesystem.
>>
>> From our perspective it would bring a bunch more useful features to the
>> table like snapshots, but for this particular task it's not actually any
>> more convenient than running resize2fs on an image or LVM, so we only
>> see the "not-yet mature enough" side of the story. At least with our
>> current kernel version.
>> And we wouldn't get rid of the additional layers since it would still
>> have to be used on top of our storage backend management.
>>
>> As for convenience: eg. for the `pct resize` command if the container is
>> offline we just run our backend's resize function (which is still
>> required with btrfs to eg increase the image file or zvol or lvm
>> portion) and then run resize2fs on it. With btrfs we'd also have to
>> mount it for such operations because they only work on mountpoint-paths.
>> Although for a running container this isn't actually a problem as you
>> *can* pass a path like /proc/${ContainerPID}/root/ which I find almost
>> surprising since some other commands like 'mount' often do something
>> unexpectedly *bad* with paths like that.
>>
>> > So do you have more layers... Btrfs is direct into the device. Or am I
>> > wrong?!
>> >
>> >
>> > 2016-02-02 11:30 GMT-02:00 Paul Gray <gray at cs.uni.edu>:
>> >
>> > > On 02/02/2016 07:11 AM, Gilberto Nunes wrote:
>> > > > And more important: any one here already use or test BTRFS inside
>> > > > Proxmox? With qcow2 or raw images???
>> > >
>> > > I'm using btrfs for a trial vm image storage, but not yet at a point
>> > > where I could make a recommendation for or against it either way.
>> > >
>> > > -Paul
>>
>>
>
>
> --
>
> Gilberto Ferreira
> +55 (47) 9676-7530
> Skype: gilberto.nunes36
>
>


-- 

Gilberto Ferreira
+55 (47) 9676-7530
Skype: gilberto.nunes36
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20160202/02e5aeb1/attachment.htm>