On 7/12/18 9:44 am, G C wrote:
Correct we're adding a new physical device with larger capacity then using pvmove to relocate to new device, etc...

The problem is that it takes a long time to complete the pvmove and it out of space on the original device (hence the move) we wouldn't be able to use the system until the migration was completed.


I am pretty sure you could just allocate space from the new PV to the existing LV, that way, the LV will span both the old PV and the new PV. If you are using SSD storage, then this won't matter, if you are using spinning disks, then you might want to specifically allocate blocks from the new PV in the physical position where it will end up when finished, and then when you do the pvmove later, it will be contiguous with the old and new data all on the new PV.

Does that make sense?

Regards,
Adam



On Thu, Dec 6, 2018 at 4:35 PM Adam Goryachev <[email protected] <mailto:[email protected]>> wrote:

    On 7/12/18 9:30 am, G C wrote:
    Thank you for your response.

    In our scenario we're limited to a single PV on the LVM and while
    online does work it takes a long time for the pvmove to complete
    from say 2TB to a 3TB PV.

    We're trying the offline in hopes that it would speed things up a
    lot.

    Sorry, I still don't understand. If you have a single PV, what are
    you using pvmove for?

    In my scenario, I use lvextend and then drbdadm resize.

    Or do you mean you are adding additional physical devices with
    larger capacity, and then using pvmove to relocate to the new
    device, and then using lvextend to increase the size, and then
    drbdadm resize? and instead you are planning to drbdadm down
    <resource> and then fiddle with the underlying devices, and then
    drbdadm up ?

    Is the problem that pvmove takes a long time to complete, or that
    it affects performance too much during the move? Just curious...

    Regards,
    Adam



    On Thu, Dec 6, 2018 at 4:26 PM Adam Goryachev
    <[email protected]
    <mailto:[email protected]>> wrote:


        On 7/12/18 8:54 am, G C wrote:
        Version:
        drbd84-utils.x86_64  8.9.2-1.0.1.el7

        cat /proc/drbd
        version: 8.4.10 (api:1/proto:86-101)
        srcversion: 75EFA3DCEBEF5C771A0FCFC

        Following instructions located here for offline with
        internal metadata
        https://docs.linbit.com/docs/users-guide-8.4/#s-resizing
        I always get this error, I've found several issues that are
        similar but haven't found anyway to get past this issue.
        Architecture
        LVM > DRBD

                # drbdadm down <resource>

                # drbdadm dump-md clusterdb > /tmp/metadata

                Found meta data is "unclean", please apply-al first

                Command 'drbdmeta 0 v08 /dev/drbd/clusterdb internal
                dump-md' terminated with exit code 255



        Out of interest, why do you need to use offline resize? I
        always have used the online resize with no issues (LVM
        underneath). Simply increase the LV (on both nodes) and then
        issue a "drbdadm resize <resource>" command.

        Not sure if that helps, or if you have a reason for using
        offline resize, maybe someone else can assist with that.

        PS, using 8.4.x versions.

        Regards,
        Adam

-- Adam Goryachev Website Managers www.websitemanagers.com.au
        <http://www.websitemanagers.com.au>

        -- The information in this e-mail is confidential and may be
        legally privileged. It is intended solely for the addressee.
        Access to this e-mail by anyone else is unauthorised. If you
        are not the intended recipient, any disclosure, copying,
        distribution or any action taken or omitted to be taken in
        reliance on it, is prohibited and may be unlawful. If you
        have received this message in error, please notify us
        immediately. Please also destroy and delete the message from
        your computer. Viruses - Any loss/damage incurred by
        receiving this email is not the sender's responsibility.
        _______________________________________________
        drbd-user mailing list
        [email protected] <mailto:[email protected]>
        http://lists.linbit.com/mailman/listinfo/drbd-user


-- Adam Goryachev Website Managers www.websitemanagers.com.au
    <http://www.websitemanagers.com.au>

    -- The information in this e-mail is confidential and may be
    legally privileged. It is intended solely for the addressee.
    Access to this e-mail by anyone else is unauthorised. If you are
    not the intended recipient, any disclosure, copying, distribution
    or any action taken or omitted to be taken in reliance on it, is
    prohibited and may be unlawful. If you have received this message
    in error, please notify us immediately. Please also destroy and
    delete the message from your computer. Viruses - Any loss/damage
    incurred by receiving this email is not the sender's responsibility.


--
The information in this e-mail is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this e-mail by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you have received this message
in error, please notify us immediately. Please also destroy and delete the
message from your computer. Viruses - Any loss/damage incurred by receiving
this email is not the sender's responsibility.
--
Adam Goryachev Website Managers www.websitemanagers.com.au
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user

Reply via email to