How to shrink a physical volume?after adding one more physical volume and enlarging logical volume, grub...

What does this Swiss black on yellow rectangular traffic sign with a symbol looking like a dart mean?

My student in one course asks for paid tutoring in another course. Appropriate?

how to find which software is doing ssh connection?

What is the precise meaning of "подсел на мак"?

Is there any possible way to get these hearts as Adult Link?

Is there a polite way to ask about one's ethnicity?

Justifying Affordable Bespoke Spaceships

In windows systems, is renaming files functionally similar to deleting them?

Regex version of strip() - Ch. 7 Automate the Boring Stuff

How to ask if I can mow my neighbor's lawn

How much steel armor can you wear and still be able to swim?

Is there a risk to write an invitation letter for a stranger to obtain a Czech (Schengen) visa?

How to avoid offending original culture when making conculture inspired from original

Digital signature that is only verifiable by one specific person

How did the European Union reach the figure of 3% as a maximum allowed deficit?

How can I maintain game balance while allowing my player to craft genuinely useful items?

Using roof rails to set up hammock

Are there examples of rowers who also fought?

When is the phrase "j'ai bon" used?

I have found ports on my Samsung smart tv running a display service. What can I do with it?

Basic power tool set for Home repair and simple projects

Fill the maze with a wall-following Snake until it gets stuck

How can the US president give an order to a civilian?

Right indicator flash-frequency has increased and rear-right bulb is out



How to shrink a physical volume?


after adding one more physical volume and enlarging logical volume, grub failsHow to recover a physical volume in LVM that shows as an unknown device?How to mount sdb directly or using LVM partitions on sda?How to deallocate extents of physical volume? lvm, encryptedExtend partition using LVMHow do I increase the size of my active partition after resizing virtual disk?LVM volume on USB drive fails: Read-only file systemLVM partition issueWhat does pvmove do?How to replace faulty disk in software raid using lvm






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







0















I have a physical volume on a partition which extends across the whole disk, say /dev/sda1 using 100% of /dev/sda. Now I need to shrink it to create /dev/sda2. A logical volume actually uses ~50% of the PV, so theoretically there's plenty of room available, but it's all allocated withing the single PV. Is there a safe way to shrink the physical volume (and the underlying disk partition), to create some extra room for the second partition? Unfortunately, my configuration excludes possibility to temporarily pvmove the physical volume to another device.



Of course, I know that I can do it on a file level (like backing up the contents, repartitioning the disk drive and recreating the LVM configuration), but I would prefer to do the job without the need to configure LV from scratch.



Thank you upfront.










share|improve this question

























  • man lvresize and man pvresize

    – Emmanuel Rosa
    Nov 3 '18 at 11:08


















0















I have a physical volume on a partition which extends across the whole disk, say /dev/sda1 using 100% of /dev/sda. Now I need to shrink it to create /dev/sda2. A logical volume actually uses ~50% of the PV, so theoretically there's plenty of room available, but it's all allocated withing the single PV. Is there a safe way to shrink the physical volume (and the underlying disk partition), to create some extra room for the second partition? Unfortunately, my configuration excludes possibility to temporarily pvmove the physical volume to another device.



Of course, I know that I can do it on a file level (like backing up the contents, repartitioning the disk drive and recreating the LVM configuration), but I would prefer to do the job without the need to configure LV from scratch.



Thank you upfront.










share|improve this question

























  • man lvresize and man pvresize

    – Emmanuel Rosa
    Nov 3 '18 at 11:08














0












0








0


1






I have a physical volume on a partition which extends across the whole disk, say /dev/sda1 using 100% of /dev/sda. Now I need to shrink it to create /dev/sda2. A logical volume actually uses ~50% of the PV, so theoretically there's plenty of room available, but it's all allocated withing the single PV. Is there a safe way to shrink the physical volume (and the underlying disk partition), to create some extra room for the second partition? Unfortunately, my configuration excludes possibility to temporarily pvmove the physical volume to another device.



Of course, I know that I can do it on a file level (like backing up the contents, repartitioning the disk drive and recreating the LVM configuration), but I would prefer to do the job without the need to configure LV from scratch.



Thank you upfront.










share|improve this question
















I have a physical volume on a partition which extends across the whole disk, say /dev/sda1 using 100% of /dev/sda. Now I need to shrink it to create /dev/sda2. A logical volume actually uses ~50% of the PV, so theoretically there's plenty of room available, but it's all allocated withing the single PV. Is there a safe way to shrink the physical volume (and the underlying disk partition), to create some extra room for the second partition? Unfortunately, my configuration excludes possibility to temporarily pvmove the physical volume to another device.



Of course, I know that I can do it on a file level (like backing up the contents, repartitioning the disk drive and recreating the LVM configuration), but I would prefer to do the job without the need to configure LV from scratch.



Thank you upfront.







lvm






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 3 '18 at 9:48







Jasio

















asked Nov 3 '18 at 9:37









JasioJasio

717




717













  • man lvresize and man pvresize

    – Emmanuel Rosa
    Nov 3 '18 at 11:08



















  • man lvresize and man pvresize

    – Emmanuel Rosa
    Nov 3 '18 at 11:08

















man lvresize and man pvresize

– Emmanuel Rosa
Nov 3 '18 at 11:08





man lvresize and man pvresize

– Emmanuel Rosa
Nov 3 '18 at 11:08










2 Answers
2






active

oldest

votes


















2














If you just need another separate filesystem, you don't have to create a new partition: you can create another LVM logical volume within the existing volume group using the unallocated space in the PV. But if you specifically need a new partition, then you must do as you originally planned.



GParted is a GUI tool that can do the entire PV + partition resizing operation for you. You'll most likely find it in your distribution's package collection.



But if you cannot or don't want to use it for some reason, read on...



Reducing a LVM physical volume that has unallocated space in it is pretty simple. For example, to reduce the size of /dev/sda1 to 40 GiB:



# pvresize --setphysicalvolumesize 40G /dev/sda1


This command is safe, as it will refuse to do anything if the part of the PV it would cut away contains allocated extents.



But that's just the first step. The second step will be to reduce the size of the partition itself.



To be safe, it is recommended that you initially shrink the PV a bit more than you plan to actually shrink the partition, so that after shrinking the partition you can explicitly extend the PV to cover the full size of the partition. If the extend operation fails, you'll immediately know that something went wrong in resizing the partition and won't be leaving hidden errors to trap you or someone else in the future.



You can shrink a partition using a plain Linux fdisk command, but you must keep in mind a few things:




  • When using fdisk to resize a partition, make sure to set it to display all partition sizes and starting locations in sectors first. During the history of Linux fdisk, its behavior has varied here: modern versions do it by default, older versions may need a -u or -u=sectors option to do so.

  • When resizing an existing partition, you cannot move the starting point of the partition. (If you move the starting point, it will no longer be a simple resize operation, but a more complex partition move operation.)


When using fdisk, any changes are written to the disk only when you use the w command. So I would suggest proceeding like this:




  • use sfdisk -d /dev/sda > /safe/location/partition_table_backup.dump to backup the existing partition table.

  • start fdisk /dev/sda in interactive mode

  • use the p command to view the current partition table and verify the "start" and "end" values are displayed as sectors. Make a note of the "start" value.

  • use the d command to delete the current partition entry for sda1.

  • use the n command to recreate the primary partition entry 1 for sda1 in desired size, taking care to specify the location of the first sector exactly as it was (i.e. the same number as was displayed in the "start" value of the p command).

  • use the t command to set the type of the partition 1 to "Linux LVM".

  • double-check your work

  • use the w command to write the updated partition table and exit fdisk.


Pay attention to the message displayed by fdiskat the end. If it says "The kernel still uses the old table", something is blocking the on-line partition table update. You can try partprobe /dev/sda to tell the kernel to reread the partition table (using a newer interface than some older versions of fdisk use, so it might help and certainly won't hurt) and then look at cat /proc/partitions to see if the partition is now recognized by the kernel at the expected size.



If the partition resize is successful, you can now run pvresize /dev/sda1. If you followed my advice and resized the PV initially a bit smaller than the desired new size of the partition, it should now successfully extend the PV a bit to fully cover the resized partition automatically. If this command reports an error, you've probablu made a mistake in specifying the new size and should use sfdisk /dev/sda < /safe/location/partition_table_backup.dump to restore the partition table to what it initially was, and then try again.



(On very old systems, you might actually have to deactivate the VG before running partprobe or even reboot to allow the system re-read the updated partition table.)



Once the resizing operation is complete, you can now use fdisk again to create the second partition you needed. Yes, you could also do it together while resizing the partition, but doing just one thing at a time is safer and ensures you can easily roll back your changes if needed.






share|improve this answer
























  • Thank you very much for a detailed response. It worked like a charm.

    – Jasio
    Nov 3 '18 at 21:14











  • I just tried to resize a PV with Gparted v. 0.33.0 on CentOS 7.6, and indeed, it worked fine.

    – mivk
    Jun 10 at 16:58



















0














Could i ask an extension of this question please ?



I have a similar need to shrink the size of a PV that is being presented to a LV.



I am on Centos 7.6



I have an 18TB PV that is created from a 7 disk RAID6 group.



I have added another RAID 1 6TB PV to the LVM and PV Moved the last 4TB of data from the RAID6 array onto the 6TB RAID1 set. I therefore have 4TB of free space at the end of the 18TB PV.



I would like to now shrink this PV so i can ultimately reduce the size of the RAID6 array by removing a single disk from the array.



Will Gparted be able to do this safely ? or should i just stick with pvresize ?



Craig






share|improve this answer
























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f479545%2fhow-to-shrink-a-physical-volume%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2














    If you just need another separate filesystem, you don't have to create a new partition: you can create another LVM logical volume within the existing volume group using the unallocated space in the PV. But if you specifically need a new partition, then you must do as you originally planned.



    GParted is a GUI tool that can do the entire PV + partition resizing operation for you. You'll most likely find it in your distribution's package collection.



    But if you cannot or don't want to use it for some reason, read on...



    Reducing a LVM physical volume that has unallocated space in it is pretty simple. For example, to reduce the size of /dev/sda1 to 40 GiB:



    # pvresize --setphysicalvolumesize 40G /dev/sda1


    This command is safe, as it will refuse to do anything if the part of the PV it would cut away contains allocated extents.



    But that's just the first step. The second step will be to reduce the size of the partition itself.



    To be safe, it is recommended that you initially shrink the PV a bit more than you plan to actually shrink the partition, so that after shrinking the partition you can explicitly extend the PV to cover the full size of the partition. If the extend operation fails, you'll immediately know that something went wrong in resizing the partition and won't be leaving hidden errors to trap you or someone else in the future.



    You can shrink a partition using a plain Linux fdisk command, but you must keep in mind a few things:




    • When using fdisk to resize a partition, make sure to set it to display all partition sizes and starting locations in sectors first. During the history of Linux fdisk, its behavior has varied here: modern versions do it by default, older versions may need a -u or -u=sectors option to do so.

    • When resizing an existing partition, you cannot move the starting point of the partition. (If you move the starting point, it will no longer be a simple resize operation, but a more complex partition move operation.)


    When using fdisk, any changes are written to the disk only when you use the w command. So I would suggest proceeding like this:




    • use sfdisk -d /dev/sda > /safe/location/partition_table_backup.dump to backup the existing partition table.

    • start fdisk /dev/sda in interactive mode

    • use the p command to view the current partition table and verify the "start" and "end" values are displayed as sectors. Make a note of the "start" value.

    • use the d command to delete the current partition entry for sda1.

    • use the n command to recreate the primary partition entry 1 for sda1 in desired size, taking care to specify the location of the first sector exactly as it was (i.e. the same number as was displayed in the "start" value of the p command).

    • use the t command to set the type of the partition 1 to "Linux LVM".

    • double-check your work

    • use the w command to write the updated partition table and exit fdisk.


    Pay attention to the message displayed by fdiskat the end. If it says "The kernel still uses the old table", something is blocking the on-line partition table update. You can try partprobe /dev/sda to tell the kernel to reread the partition table (using a newer interface than some older versions of fdisk use, so it might help and certainly won't hurt) and then look at cat /proc/partitions to see if the partition is now recognized by the kernel at the expected size.



    If the partition resize is successful, you can now run pvresize /dev/sda1. If you followed my advice and resized the PV initially a bit smaller than the desired new size of the partition, it should now successfully extend the PV a bit to fully cover the resized partition automatically. If this command reports an error, you've probablu made a mistake in specifying the new size and should use sfdisk /dev/sda < /safe/location/partition_table_backup.dump to restore the partition table to what it initially was, and then try again.



    (On very old systems, you might actually have to deactivate the VG before running partprobe or even reboot to allow the system re-read the updated partition table.)



    Once the resizing operation is complete, you can now use fdisk again to create the second partition you needed. Yes, you could also do it together while resizing the partition, but doing just one thing at a time is safer and ensures you can easily roll back your changes if needed.






    share|improve this answer
























    • Thank you very much for a detailed response. It worked like a charm.

      – Jasio
      Nov 3 '18 at 21:14











    • I just tried to resize a PV with Gparted v. 0.33.0 on CentOS 7.6, and indeed, it worked fine.

      – mivk
      Jun 10 at 16:58
















    2














    If you just need another separate filesystem, you don't have to create a new partition: you can create another LVM logical volume within the existing volume group using the unallocated space in the PV. But if you specifically need a new partition, then you must do as you originally planned.



    GParted is a GUI tool that can do the entire PV + partition resizing operation for you. You'll most likely find it in your distribution's package collection.



    But if you cannot or don't want to use it for some reason, read on...



    Reducing a LVM physical volume that has unallocated space in it is pretty simple. For example, to reduce the size of /dev/sda1 to 40 GiB:



    # pvresize --setphysicalvolumesize 40G /dev/sda1


    This command is safe, as it will refuse to do anything if the part of the PV it would cut away contains allocated extents.



    But that's just the first step. The second step will be to reduce the size of the partition itself.



    To be safe, it is recommended that you initially shrink the PV a bit more than you plan to actually shrink the partition, so that after shrinking the partition you can explicitly extend the PV to cover the full size of the partition. If the extend operation fails, you'll immediately know that something went wrong in resizing the partition and won't be leaving hidden errors to trap you or someone else in the future.



    You can shrink a partition using a plain Linux fdisk command, but you must keep in mind a few things:




    • When using fdisk to resize a partition, make sure to set it to display all partition sizes and starting locations in sectors first. During the history of Linux fdisk, its behavior has varied here: modern versions do it by default, older versions may need a -u or -u=sectors option to do so.

    • When resizing an existing partition, you cannot move the starting point of the partition. (If you move the starting point, it will no longer be a simple resize operation, but a more complex partition move operation.)


    When using fdisk, any changes are written to the disk only when you use the w command. So I would suggest proceeding like this:




    • use sfdisk -d /dev/sda > /safe/location/partition_table_backup.dump to backup the existing partition table.

    • start fdisk /dev/sda in interactive mode

    • use the p command to view the current partition table and verify the "start" and "end" values are displayed as sectors. Make a note of the "start" value.

    • use the d command to delete the current partition entry for sda1.

    • use the n command to recreate the primary partition entry 1 for sda1 in desired size, taking care to specify the location of the first sector exactly as it was (i.e. the same number as was displayed in the "start" value of the p command).

    • use the t command to set the type of the partition 1 to "Linux LVM".

    • double-check your work

    • use the w command to write the updated partition table and exit fdisk.


    Pay attention to the message displayed by fdiskat the end. If it says "The kernel still uses the old table", something is blocking the on-line partition table update. You can try partprobe /dev/sda to tell the kernel to reread the partition table (using a newer interface than some older versions of fdisk use, so it might help and certainly won't hurt) and then look at cat /proc/partitions to see if the partition is now recognized by the kernel at the expected size.



    If the partition resize is successful, you can now run pvresize /dev/sda1. If you followed my advice and resized the PV initially a bit smaller than the desired new size of the partition, it should now successfully extend the PV a bit to fully cover the resized partition automatically. If this command reports an error, you've probablu made a mistake in specifying the new size and should use sfdisk /dev/sda < /safe/location/partition_table_backup.dump to restore the partition table to what it initially was, and then try again.



    (On very old systems, you might actually have to deactivate the VG before running partprobe or even reboot to allow the system re-read the updated partition table.)



    Once the resizing operation is complete, you can now use fdisk again to create the second partition you needed. Yes, you could also do it together while resizing the partition, but doing just one thing at a time is safer and ensures you can easily roll back your changes if needed.






    share|improve this answer
























    • Thank you very much for a detailed response. It worked like a charm.

      – Jasio
      Nov 3 '18 at 21:14











    • I just tried to resize a PV with Gparted v. 0.33.0 on CentOS 7.6, and indeed, it worked fine.

      – mivk
      Jun 10 at 16:58














    2












    2








    2







    If you just need another separate filesystem, you don't have to create a new partition: you can create another LVM logical volume within the existing volume group using the unallocated space in the PV. But if you specifically need a new partition, then you must do as you originally planned.



    GParted is a GUI tool that can do the entire PV + partition resizing operation for you. You'll most likely find it in your distribution's package collection.



    But if you cannot or don't want to use it for some reason, read on...



    Reducing a LVM physical volume that has unallocated space in it is pretty simple. For example, to reduce the size of /dev/sda1 to 40 GiB:



    # pvresize --setphysicalvolumesize 40G /dev/sda1


    This command is safe, as it will refuse to do anything if the part of the PV it would cut away contains allocated extents.



    But that's just the first step. The second step will be to reduce the size of the partition itself.



    To be safe, it is recommended that you initially shrink the PV a bit more than you plan to actually shrink the partition, so that after shrinking the partition you can explicitly extend the PV to cover the full size of the partition. If the extend operation fails, you'll immediately know that something went wrong in resizing the partition and won't be leaving hidden errors to trap you or someone else in the future.



    You can shrink a partition using a plain Linux fdisk command, but you must keep in mind a few things:




    • When using fdisk to resize a partition, make sure to set it to display all partition sizes and starting locations in sectors first. During the history of Linux fdisk, its behavior has varied here: modern versions do it by default, older versions may need a -u or -u=sectors option to do so.

    • When resizing an existing partition, you cannot move the starting point of the partition. (If you move the starting point, it will no longer be a simple resize operation, but a more complex partition move operation.)


    When using fdisk, any changes are written to the disk only when you use the w command. So I would suggest proceeding like this:




    • use sfdisk -d /dev/sda > /safe/location/partition_table_backup.dump to backup the existing partition table.

    • start fdisk /dev/sda in interactive mode

    • use the p command to view the current partition table and verify the "start" and "end" values are displayed as sectors. Make a note of the "start" value.

    • use the d command to delete the current partition entry for sda1.

    • use the n command to recreate the primary partition entry 1 for sda1 in desired size, taking care to specify the location of the first sector exactly as it was (i.e. the same number as was displayed in the "start" value of the p command).

    • use the t command to set the type of the partition 1 to "Linux LVM".

    • double-check your work

    • use the w command to write the updated partition table and exit fdisk.


    Pay attention to the message displayed by fdiskat the end. If it says "The kernel still uses the old table", something is blocking the on-line partition table update. You can try partprobe /dev/sda to tell the kernel to reread the partition table (using a newer interface than some older versions of fdisk use, so it might help and certainly won't hurt) and then look at cat /proc/partitions to see if the partition is now recognized by the kernel at the expected size.



    If the partition resize is successful, you can now run pvresize /dev/sda1. If you followed my advice and resized the PV initially a bit smaller than the desired new size of the partition, it should now successfully extend the PV a bit to fully cover the resized partition automatically. If this command reports an error, you've probablu made a mistake in specifying the new size and should use sfdisk /dev/sda < /safe/location/partition_table_backup.dump to restore the partition table to what it initially was, and then try again.



    (On very old systems, you might actually have to deactivate the VG before running partprobe or even reboot to allow the system re-read the updated partition table.)



    Once the resizing operation is complete, you can now use fdisk again to create the second partition you needed. Yes, you could also do it together while resizing the partition, but doing just one thing at a time is safer and ensures you can easily roll back your changes if needed.






    share|improve this answer













    If you just need another separate filesystem, you don't have to create a new partition: you can create another LVM logical volume within the existing volume group using the unallocated space in the PV. But if you specifically need a new partition, then you must do as you originally planned.



    GParted is a GUI tool that can do the entire PV + partition resizing operation for you. You'll most likely find it in your distribution's package collection.



    But if you cannot or don't want to use it for some reason, read on...



    Reducing a LVM physical volume that has unallocated space in it is pretty simple. For example, to reduce the size of /dev/sda1 to 40 GiB:



    # pvresize --setphysicalvolumesize 40G /dev/sda1


    This command is safe, as it will refuse to do anything if the part of the PV it would cut away contains allocated extents.



    But that's just the first step. The second step will be to reduce the size of the partition itself.



    To be safe, it is recommended that you initially shrink the PV a bit more than you plan to actually shrink the partition, so that after shrinking the partition you can explicitly extend the PV to cover the full size of the partition. If the extend operation fails, you'll immediately know that something went wrong in resizing the partition and won't be leaving hidden errors to trap you or someone else in the future.



    You can shrink a partition using a plain Linux fdisk command, but you must keep in mind a few things:




    • When using fdisk to resize a partition, make sure to set it to display all partition sizes and starting locations in sectors first. During the history of Linux fdisk, its behavior has varied here: modern versions do it by default, older versions may need a -u or -u=sectors option to do so.

    • When resizing an existing partition, you cannot move the starting point of the partition. (If you move the starting point, it will no longer be a simple resize operation, but a more complex partition move operation.)


    When using fdisk, any changes are written to the disk only when you use the w command. So I would suggest proceeding like this:




    • use sfdisk -d /dev/sda > /safe/location/partition_table_backup.dump to backup the existing partition table.

    • start fdisk /dev/sda in interactive mode

    • use the p command to view the current partition table and verify the "start" and "end" values are displayed as sectors. Make a note of the "start" value.

    • use the d command to delete the current partition entry for sda1.

    • use the n command to recreate the primary partition entry 1 for sda1 in desired size, taking care to specify the location of the first sector exactly as it was (i.e. the same number as was displayed in the "start" value of the p command).

    • use the t command to set the type of the partition 1 to "Linux LVM".

    • double-check your work

    • use the w command to write the updated partition table and exit fdisk.


    Pay attention to the message displayed by fdiskat the end. If it says "The kernel still uses the old table", something is blocking the on-line partition table update. You can try partprobe /dev/sda to tell the kernel to reread the partition table (using a newer interface than some older versions of fdisk use, so it might help and certainly won't hurt) and then look at cat /proc/partitions to see if the partition is now recognized by the kernel at the expected size.



    If the partition resize is successful, you can now run pvresize /dev/sda1. If you followed my advice and resized the PV initially a bit smaller than the desired new size of the partition, it should now successfully extend the PV a bit to fully cover the resized partition automatically. If this command reports an error, you've probablu made a mistake in specifying the new size and should use sfdisk /dev/sda < /safe/location/partition_table_backup.dump to restore the partition table to what it initially was, and then try again.



    (On very old systems, you might actually have to deactivate the VG before running partprobe or even reboot to allow the system re-read the updated partition table.)



    Once the resizing operation is complete, you can now use fdisk again to create the second partition you needed. Yes, you could also do it together while resizing the partition, but doing just one thing at a time is safer and ensures you can easily roll back your changes if needed.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 3 '18 at 12:12









    telcoMtelcoM

    23.6k12761




    23.6k12761













    • Thank you very much for a detailed response. It worked like a charm.

      – Jasio
      Nov 3 '18 at 21:14











    • I just tried to resize a PV with Gparted v. 0.33.0 on CentOS 7.6, and indeed, it worked fine.

      – mivk
      Jun 10 at 16:58



















    • Thank you very much for a detailed response. It worked like a charm.

      – Jasio
      Nov 3 '18 at 21:14











    • I just tried to resize a PV with Gparted v. 0.33.0 on CentOS 7.6, and indeed, it worked fine.

      – mivk
      Jun 10 at 16:58

















    Thank you very much for a detailed response. It worked like a charm.

    – Jasio
    Nov 3 '18 at 21:14





    Thank you very much for a detailed response. It worked like a charm.

    – Jasio
    Nov 3 '18 at 21:14













    I just tried to resize a PV with Gparted v. 0.33.0 on CentOS 7.6, and indeed, it worked fine.

    – mivk
    Jun 10 at 16:58





    I just tried to resize a PV with Gparted v. 0.33.0 on CentOS 7.6, and indeed, it worked fine.

    – mivk
    Jun 10 at 16:58













    0














    Could i ask an extension of this question please ?



    I have a similar need to shrink the size of a PV that is being presented to a LV.



    I am on Centos 7.6



    I have an 18TB PV that is created from a 7 disk RAID6 group.



    I have added another RAID 1 6TB PV to the LVM and PV Moved the last 4TB of data from the RAID6 array onto the 6TB RAID1 set. I therefore have 4TB of free space at the end of the 18TB PV.



    I would like to now shrink this PV so i can ultimately reduce the size of the RAID6 array by removing a single disk from the array.



    Will Gparted be able to do this safely ? or should i just stick with pvresize ?



    Craig






    share|improve this answer




























      0














      Could i ask an extension of this question please ?



      I have a similar need to shrink the size of a PV that is being presented to a LV.



      I am on Centos 7.6



      I have an 18TB PV that is created from a 7 disk RAID6 group.



      I have added another RAID 1 6TB PV to the LVM and PV Moved the last 4TB of data from the RAID6 array onto the 6TB RAID1 set. I therefore have 4TB of free space at the end of the 18TB PV.



      I would like to now shrink this PV so i can ultimately reduce the size of the RAID6 array by removing a single disk from the array.



      Will Gparted be able to do this safely ? or should i just stick with pvresize ?



      Craig






      share|improve this answer


























        0












        0








        0







        Could i ask an extension of this question please ?



        I have a similar need to shrink the size of a PV that is being presented to a LV.



        I am on Centos 7.6



        I have an 18TB PV that is created from a 7 disk RAID6 group.



        I have added another RAID 1 6TB PV to the LVM and PV Moved the last 4TB of data from the RAID6 array onto the 6TB RAID1 set. I therefore have 4TB of free space at the end of the 18TB PV.



        I would like to now shrink this PV so i can ultimately reduce the size of the RAID6 array by removing a single disk from the array.



        Will Gparted be able to do this safely ? or should i just stick with pvresize ?



        Craig






        share|improve this answer













        Could i ask an extension of this question please ?



        I have a similar need to shrink the size of a PV that is being presented to a LV.



        I am on Centos 7.6



        I have an 18TB PV that is created from a 7 disk RAID6 group.



        I have added another RAID 1 6TB PV to the LVM and PV Moved the last 4TB of data from the RAID6 array onto the 6TB RAID1 set. I therefore have 4TB of free space at the end of the 18TB PV.



        I would like to now shrink this PV so i can ultimately reduce the size of the RAID6 array by removing a single disk from the array.



        Will Gparted be able to do this safely ? or should i just stick with pvresize ?



        Craig







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 1 hour ago









        CraigCraig

        162




        162






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f479545%2fhow-to-shrink-a-physical-volume%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

            Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

            Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...