[PVE-User] BTRFS...

Adam Thompson athompso at athompso.net
Wed Feb 3 18:12:58 CET 2016


Ah.  Now I begin to understand what you're after.

(All commands from memory - check man pages for syntax)

Create a new disk in PVE.  (Suggest creating at as virt-scsi, not virtio, so that you get TRIM support.)

pvcreate /dev/vdb
vgcreate DATAVG /dev/vdb
lvcreate -l90%VG -n DATALV DATAVG #leave a little emergency expansion room for next time
mkfs.ext4 /dev/DATAVG/DATALV
mount /dev/DATAVG/DATALV /mnt
rsync -vaxHAXES /opt /mnt
# shut down daemons now
rsync -vaxHAXES /opt /mnt #yes, again
umount /opt
mount /dev/DATAVG/DATALV /opt
# start daemons again
vi /etc/fstab # make sure correct partition mounts at boot!

# optional so you don't remount the old files by accident..
dd if=/dev/zero of=/dev/vda9 bs=512 count=32768

Later, when you begin to run out again, either add a new disk, pvcreate, vgextend, lvextend, resize2fs, OR just grow it.
When you use an entire raw device as a PV, there's no partition table to worry about editing when you resize.  Others will argue that a partition table is an important safety measure - choose which benefit you prefer.

-Adam

On February 3, 2016 4:04:08 AM CST, Gilberto Nunes <gilberto.nunes32 at gmail.com> wrote:
>So, that's the idea...
>The FS I want grown, is /dev/vda9 that is mounted as /opt.
>I resize the this via PVE web portal.
>The /dev/vda had 2 TB and I added more 500 GB...
>Cfdisk, and parted as well, show that just after /dev/vda9, I have more
>500
>GB free space....
>I just want to know, with some certain degree, that I will not loose my
>data under /opt.... All I need...
>But, as you said: MAKE BACKUP!
>The problem is: backup from a 2 TB image, that is use as mail server is
>very slow and problematic....
>But I will give a way!
>Thanks btw!
>
>
>2016-02-03 5:07 GMT-02:00 Wolfgang Bumiller <w.bumiller at proxmox.com>:
>
>> > On February 2, 2016 at 8:07 PM Adam Thompson
><athompso at athompso.net>
>> wrote:
>> >
>> > On 16-02-02 11:24 AM, Gilberto Nunes wrote:
>> > > Hi
>> > >
>> > > And what if I work with BTRFS inside the VM???
>> > > The FS where VM image lay could be any other FS... Currently, I
>am use
>> > > GlusterFS + XFS.
>> > > I need LVM or BRTFS inside the VM, in order to resize disk
>partition...
>> > > And I am between LVM or BRTFS....
>> >
>> > Only if you need to do *online* resizes (without unmounting the
>> > filesystem).  If you can live with unmounting the filesystem, plain
>old
>> > ext3 (and ext4) can do what you need.  Of course, if it's the root
>> > filesystem you need to resize, the only way to unmount it is to
>shut
>> > down the VM and reboot it in single-user mode.  I think you might
>need
>> > to boot off a CD to resize the root fs, can't remember if there's a
>way
>> > around it.
>>
>> Actually resize2fs works on mounted file systems as long as you're
>only
>> growing it and not shrinking it, including the root filesystem.
>>
>> >><<
>>
>> > On February 2, 2016 at 4:38 PM Gilberto Nunes <
>> gilberto.nunes32 at gmail.com> wrote:
>> > That's other doubt... I will lose data if I do it with parted
>> resizepart???
>>
>> No, but naturally you should make a backup just in case, especially
>when
>> you do this the first time.
>> Of course there are some limitations when you need online resizing
>without
>> downtime. Then you can only grow a partition without moving it. In
>other
>> words you can only resize a partition if there's physical free space
>> directly
>> after it. (Most of the time this is the case since you usually have
>the
>> boot partition first and then the root and maybe a home or data
>partition,
>> and most of the time that last one is the one you want to resize ;-)
>)
>> Eg. with [boot, root, home] after resizing the physical disk you end
>up
>> with
>> [boot, root, home, <frees space>], so you can only resize the home
>> partition.
>> If you can afford down time you can also use parted to move
>partitions so
>> that
>> you can resize any of them.  This however takes a lot longer and is a
>bit
>> more risky, so in this case you should _always_ make a backup even if
>you
>> know
>> what you're doing.
>>
>>
>
>
>-- 
>
>Gilberto Ferreira
>+55 (47) 9676-7530
>Skype: gilberto.nunes36

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pve.proxmox.com/pipermail/pve-user/attachments/20160203/3e38489a/attachment-0015.html>


More information about the pve-user mailing list