How can I shrink a Logical Volume, and re-allocate the freed space into a new partition on the same drive?












5














I have a drive, sda. It has two partitions:



sda1: /boot
sda2: LVM managed in Volume Group volgrp01


volgrp01 contains the following Logical Volumes:



lv_root (30 GB)
lv_swap (8 GB)
lv_scratch (430 GB)


What I want to do is reduce lv_scratch to 50 GB, and re-allocate that newly freed 380 GB into a new partition, sda3 (which I'll then add to another Volume Group).



I've attached an image of my desired BEFORE and AFTER. I'm right in the middle of learning about LVM, and while I can grasp the idea of resizing Logical Volumes within a Volume Group, I'm unsure of how one would re-allocate that space into a new partition.



I'm using RHEL6.



enter image description here










share|improve this question



























    5














    I have a drive, sda. It has two partitions:



    sda1: /boot
    sda2: LVM managed in Volume Group volgrp01


    volgrp01 contains the following Logical Volumes:



    lv_root (30 GB)
    lv_swap (8 GB)
    lv_scratch (430 GB)


    What I want to do is reduce lv_scratch to 50 GB, and re-allocate that newly freed 380 GB into a new partition, sda3 (which I'll then add to another Volume Group).



    I've attached an image of my desired BEFORE and AFTER. I'm right in the middle of learning about LVM, and while I can grasp the idea of resizing Logical Volumes within a Volume Group, I'm unsure of how one would re-allocate that space into a new partition.



    I'm using RHEL6.



    enter image description here










    share|improve this question

























      5












      5








      5


      4





      I have a drive, sda. It has two partitions:



      sda1: /boot
      sda2: LVM managed in Volume Group volgrp01


      volgrp01 contains the following Logical Volumes:



      lv_root (30 GB)
      lv_swap (8 GB)
      lv_scratch (430 GB)


      What I want to do is reduce lv_scratch to 50 GB, and re-allocate that newly freed 380 GB into a new partition, sda3 (which I'll then add to another Volume Group).



      I've attached an image of my desired BEFORE and AFTER. I'm right in the middle of learning about LVM, and while I can grasp the idea of resizing Logical Volumes within a Volume Group, I'm unsure of how one would re-allocate that space into a new partition.



      I'm using RHEL6.



      enter image description here










      share|improve this question













      I have a drive, sda. It has two partitions:



      sda1: /boot
      sda2: LVM managed in Volume Group volgrp01


      volgrp01 contains the following Logical Volumes:



      lv_root (30 GB)
      lv_swap (8 GB)
      lv_scratch (430 GB)


      What I want to do is reduce lv_scratch to 50 GB, and re-allocate that newly freed 380 GB into a new partition, sda3 (which I'll then add to another Volume Group).



      I've attached an image of my desired BEFORE and AFTER. I'm right in the middle of learning about LVM, and while I can grasp the idea of resizing Logical Volumes within a Volume Group, I'm unsure of how one would re-allocate that space into a new partition.



      I'm using RHEL6.



      enter image description here







      linux hard-drive partitioning lvm lvm2






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Mar 27 '14 at 21:45









      CptSupermrkt

      205128




      205128






















          2 Answers
          2






          active

          oldest

          votes


















          7














          Step 1: Make backups.



          I know, most people skip this step, but you're making changes that can result in major data loss if you screw up, and you're taking guidance from a random stranger on the Internet. You are responsible for the safety of your data. I'm not.



          Step 2: Shrink the filesystem in lv_scratch. If it's an ext2/3/4 filesystem, unmount it and use resize2fs; if it's something else, you'll need to look up documentation on resizing that type of filesystem.



          For example:



          resize2fs /dev/volgrp01/lv_scratch 50G


          When it's done (assuming you're using resize2fs), it'll tell you the new size of the filesystem in bytes. Make a note of that number, because you can use it for a safety check in the next step.



          Step 3: Shrink the logical volume using lvreduce.




          • If you want to be simple, use lvreduce --size 50G volgrp01/lv_scratch.

          • If you want to be extra cautious about not shrinking the LV to a size smaller than the filesystem it contains, check the physical extent size of your volume group using vgdisplay volgrp01, and calculate how many physical extents are needed to hold the byte size of your filesystem (using 1MB = 1048576 bytes). Then specify that number using the --extents option instead of the --size 50G.


          Alternatively, you may be able to skip step 1 and instead use lvreduce's -r option to resize the filesystem automatically. That may be easier, but I don't have personal experience with it to know how reliable it is.



          At this point I'd recommend running fsck -f on your /dev/volgrp01/vg_scratch just to make sure it's intact. If you get any errors about "access beyond end of device", it means you shrunk the LV too much and need to lvextend it before you proceed.



          Step 4: Shrink the physical volume using pvresize.



          pvresize --setphysicalvolumesize 88G /dev/sda2


          You don't need an extra safety check here since pvresize will refuse to shrink the physical volume to a size that's too small for your existing logical volumes. But if the sizes of your other LVs aren't exact multiples of 1GB, the 88G might be too small and you may need use a different value.



          Step 5: Shrink the sda2 partition using fdisk.



          Run fdisk /dev/sda, and at its prompt, run p to look at your existing partitions. Note the starting sector number of your sda2 partition. Then delete the sda2 partition — this doesn't touch the actual data, just removes the record of where it starts and ends — and create a new sda2 with the same starting sector (this is vital) and a size of 88G. The partition's type code should be 8e, "Linux LVM".



          If you want to be extra cautious — and I'd recommend you do, especially if you had to specify a different size to the pvresize earlier — check the PE size and Total PE of your physical volume using pvdisplay /dev/sda2 and multiply them together to find the size of the physical volume in bytes (again using 1MB = 1048576 bytes). Then subtract your new sda2 partition's starting sector number from its ending one, add 1 so that the last sector is counted, and multiply by your disk's sector size (which should be either 512 or 4096 bytes). Make sure the two results match.



          Now create your new sda3 partition, save your changes, and quit fdisk. If you get a message about needing to reboot for the change to take effect, reboot.






          share|improve this answer























          • In your third to last paragraph, why 50G and not 88G? Typo?
            – Greg Bell
            Aug 11 '16 at 13:41










          • Oops, yes. Fixed now; thanks.
            – Wyzard
            Aug 11 '16 at 14:07










          • If you run into the errors Requested size is less than real size and cannot resize to <bitcount> extents, as later ones are allocated have a look here that explains to use pvmove to make the volumes adjacent to each other.
            – Matthias Braun
            Jan 10 at 14:56












          • Instead of using fdisk I used cfdisk. I had the problem that I couldn't keep the original start block with fdisk. cfdisk could do it right and much easier then fdisk! Just select 'resize' and enter the amount of diskspace. And 'write' when you are satisfied with your configuration. That's it!
            – ffonz
            Jun 2 at 19:35










          • These days I use GPT partition tables for everything, so gdisk.
            – Wyzard
            Jun 3 at 3:46



















          0














          Not sure whether it will work - I've only increased pv. And any way DO NOT TRY IT ON VALUABLE DATA UNLESS YOUR HAVE READABLE BACKUP.




          1. Use FS-specific tool (if any) to resize FS on lv_scratch


          2. lvresize -L 50G /dev/volgrp01/lv_scratch


          3. pvresize --setphysicalvolumesize 88G /dev/sda2


          4. Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)


          5. Create new partition, make new pv, create volume group etc.



          Double check all numbers when resizing as if you shrink you logical or physical volume more than FS you may end up with broken FS and lost data, usually it's better to left some unused space in case of confusion.






          share|improve this answer





















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "3"
            };
            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: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            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%2fsuperuser.com%2fquestions%2f734468%2fhow-can-i-shrink-a-logical-volume-and-re-allocate-the-freed-space-into-a-new-pa%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









            7














            Step 1: Make backups.



            I know, most people skip this step, but you're making changes that can result in major data loss if you screw up, and you're taking guidance from a random stranger on the Internet. You are responsible for the safety of your data. I'm not.



            Step 2: Shrink the filesystem in lv_scratch. If it's an ext2/3/4 filesystem, unmount it and use resize2fs; if it's something else, you'll need to look up documentation on resizing that type of filesystem.



            For example:



            resize2fs /dev/volgrp01/lv_scratch 50G


            When it's done (assuming you're using resize2fs), it'll tell you the new size of the filesystem in bytes. Make a note of that number, because you can use it for a safety check in the next step.



            Step 3: Shrink the logical volume using lvreduce.




            • If you want to be simple, use lvreduce --size 50G volgrp01/lv_scratch.

            • If you want to be extra cautious about not shrinking the LV to a size smaller than the filesystem it contains, check the physical extent size of your volume group using vgdisplay volgrp01, and calculate how many physical extents are needed to hold the byte size of your filesystem (using 1MB = 1048576 bytes). Then specify that number using the --extents option instead of the --size 50G.


            Alternatively, you may be able to skip step 1 and instead use lvreduce's -r option to resize the filesystem automatically. That may be easier, but I don't have personal experience with it to know how reliable it is.



            At this point I'd recommend running fsck -f on your /dev/volgrp01/vg_scratch just to make sure it's intact. If you get any errors about "access beyond end of device", it means you shrunk the LV too much and need to lvextend it before you proceed.



            Step 4: Shrink the physical volume using pvresize.



            pvresize --setphysicalvolumesize 88G /dev/sda2


            You don't need an extra safety check here since pvresize will refuse to shrink the physical volume to a size that's too small for your existing logical volumes. But if the sizes of your other LVs aren't exact multiples of 1GB, the 88G might be too small and you may need use a different value.



            Step 5: Shrink the sda2 partition using fdisk.



            Run fdisk /dev/sda, and at its prompt, run p to look at your existing partitions. Note the starting sector number of your sda2 partition. Then delete the sda2 partition — this doesn't touch the actual data, just removes the record of where it starts and ends — and create a new sda2 with the same starting sector (this is vital) and a size of 88G. The partition's type code should be 8e, "Linux LVM".



            If you want to be extra cautious — and I'd recommend you do, especially if you had to specify a different size to the pvresize earlier — check the PE size and Total PE of your physical volume using pvdisplay /dev/sda2 and multiply them together to find the size of the physical volume in bytes (again using 1MB = 1048576 bytes). Then subtract your new sda2 partition's starting sector number from its ending one, add 1 so that the last sector is counted, and multiply by your disk's sector size (which should be either 512 or 4096 bytes). Make sure the two results match.



            Now create your new sda3 partition, save your changes, and quit fdisk. If you get a message about needing to reboot for the change to take effect, reboot.






            share|improve this answer























            • In your third to last paragraph, why 50G and not 88G? Typo?
              – Greg Bell
              Aug 11 '16 at 13:41










            • Oops, yes. Fixed now; thanks.
              – Wyzard
              Aug 11 '16 at 14:07










            • If you run into the errors Requested size is less than real size and cannot resize to <bitcount> extents, as later ones are allocated have a look here that explains to use pvmove to make the volumes adjacent to each other.
              – Matthias Braun
              Jan 10 at 14:56












            • Instead of using fdisk I used cfdisk. I had the problem that I couldn't keep the original start block with fdisk. cfdisk could do it right and much easier then fdisk! Just select 'resize' and enter the amount of diskspace. And 'write' when you are satisfied with your configuration. That's it!
              – ffonz
              Jun 2 at 19:35










            • These days I use GPT partition tables for everything, so gdisk.
              – Wyzard
              Jun 3 at 3:46
















            7














            Step 1: Make backups.



            I know, most people skip this step, but you're making changes that can result in major data loss if you screw up, and you're taking guidance from a random stranger on the Internet. You are responsible for the safety of your data. I'm not.



            Step 2: Shrink the filesystem in lv_scratch. If it's an ext2/3/4 filesystem, unmount it and use resize2fs; if it's something else, you'll need to look up documentation on resizing that type of filesystem.



            For example:



            resize2fs /dev/volgrp01/lv_scratch 50G


            When it's done (assuming you're using resize2fs), it'll tell you the new size of the filesystem in bytes. Make a note of that number, because you can use it for a safety check in the next step.



            Step 3: Shrink the logical volume using lvreduce.




            • If you want to be simple, use lvreduce --size 50G volgrp01/lv_scratch.

            • If you want to be extra cautious about not shrinking the LV to a size smaller than the filesystem it contains, check the physical extent size of your volume group using vgdisplay volgrp01, and calculate how many physical extents are needed to hold the byte size of your filesystem (using 1MB = 1048576 bytes). Then specify that number using the --extents option instead of the --size 50G.


            Alternatively, you may be able to skip step 1 and instead use lvreduce's -r option to resize the filesystem automatically. That may be easier, but I don't have personal experience with it to know how reliable it is.



            At this point I'd recommend running fsck -f on your /dev/volgrp01/vg_scratch just to make sure it's intact. If you get any errors about "access beyond end of device", it means you shrunk the LV too much and need to lvextend it before you proceed.



            Step 4: Shrink the physical volume using pvresize.



            pvresize --setphysicalvolumesize 88G /dev/sda2


            You don't need an extra safety check here since pvresize will refuse to shrink the physical volume to a size that's too small for your existing logical volumes. But if the sizes of your other LVs aren't exact multiples of 1GB, the 88G might be too small and you may need use a different value.



            Step 5: Shrink the sda2 partition using fdisk.



            Run fdisk /dev/sda, and at its prompt, run p to look at your existing partitions. Note the starting sector number of your sda2 partition. Then delete the sda2 partition — this doesn't touch the actual data, just removes the record of where it starts and ends — and create a new sda2 with the same starting sector (this is vital) and a size of 88G. The partition's type code should be 8e, "Linux LVM".



            If you want to be extra cautious — and I'd recommend you do, especially if you had to specify a different size to the pvresize earlier — check the PE size and Total PE of your physical volume using pvdisplay /dev/sda2 and multiply them together to find the size of the physical volume in bytes (again using 1MB = 1048576 bytes). Then subtract your new sda2 partition's starting sector number from its ending one, add 1 so that the last sector is counted, and multiply by your disk's sector size (which should be either 512 or 4096 bytes). Make sure the two results match.



            Now create your new sda3 partition, save your changes, and quit fdisk. If you get a message about needing to reboot for the change to take effect, reboot.






            share|improve this answer























            • In your third to last paragraph, why 50G and not 88G? Typo?
              – Greg Bell
              Aug 11 '16 at 13:41










            • Oops, yes. Fixed now; thanks.
              – Wyzard
              Aug 11 '16 at 14:07










            • If you run into the errors Requested size is less than real size and cannot resize to <bitcount> extents, as later ones are allocated have a look here that explains to use pvmove to make the volumes adjacent to each other.
              – Matthias Braun
              Jan 10 at 14:56












            • Instead of using fdisk I used cfdisk. I had the problem that I couldn't keep the original start block with fdisk. cfdisk could do it right and much easier then fdisk! Just select 'resize' and enter the amount of diskspace. And 'write' when you are satisfied with your configuration. That's it!
              – ffonz
              Jun 2 at 19:35










            • These days I use GPT partition tables for everything, so gdisk.
              – Wyzard
              Jun 3 at 3:46














            7












            7








            7






            Step 1: Make backups.



            I know, most people skip this step, but you're making changes that can result in major data loss if you screw up, and you're taking guidance from a random stranger on the Internet. You are responsible for the safety of your data. I'm not.



            Step 2: Shrink the filesystem in lv_scratch. If it's an ext2/3/4 filesystem, unmount it and use resize2fs; if it's something else, you'll need to look up documentation on resizing that type of filesystem.



            For example:



            resize2fs /dev/volgrp01/lv_scratch 50G


            When it's done (assuming you're using resize2fs), it'll tell you the new size of the filesystem in bytes. Make a note of that number, because you can use it for a safety check in the next step.



            Step 3: Shrink the logical volume using lvreduce.




            • If you want to be simple, use lvreduce --size 50G volgrp01/lv_scratch.

            • If you want to be extra cautious about not shrinking the LV to a size smaller than the filesystem it contains, check the physical extent size of your volume group using vgdisplay volgrp01, and calculate how many physical extents are needed to hold the byte size of your filesystem (using 1MB = 1048576 bytes). Then specify that number using the --extents option instead of the --size 50G.


            Alternatively, you may be able to skip step 1 and instead use lvreduce's -r option to resize the filesystem automatically. That may be easier, but I don't have personal experience with it to know how reliable it is.



            At this point I'd recommend running fsck -f on your /dev/volgrp01/vg_scratch just to make sure it's intact. If you get any errors about "access beyond end of device", it means you shrunk the LV too much and need to lvextend it before you proceed.



            Step 4: Shrink the physical volume using pvresize.



            pvresize --setphysicalvolumesize 88G /dev/sda2


            You don't need an extra safety check here since pvresize will refuse to shrink the physical volume to a size that's too small for your existing logical volumes. But if the sizes of your other LVs aren't exact multiples of 1GB, the 88G might be too small and you may need use a different value.



            Step 5: Shrink the sda2 partition using fdisk.



            Run fdisk /dev/sda, and at its prompt, run p to look at your existing partitions. Note the starting sector number of your sda2 partition. Then delete the sda2 partition — this doesn't touch the actual data, just removes the record of where it starts and ends — and create a new sda2 with the same starting sector (this is vital) and a size of 88G. The partition's type code should be 8e, "Linux LVM".



            If you want to be extra cautious — and I'd recommend you do, especially if you had to specify a different size to the pvresize earlier — check the PE size and Total PE of your physical volume using pvdisplay /dev/sda2 and multiply them together to find the size of the physical volume in bytes (again using 1MB = 1048576 bytes). Then subtract your new sda2 partition's starting sector number from its ending one, add 1 so that the last sector is counted, and multiply by your disk's sector size (which should be either 512 or 4096 bytes). Make sure the two results match.



            Now create your new sda3 partition, save your changes, and quit fdisk. If you get a message about needing to reboot for the change to take effect, reboot.






            share|improve this answer














            Step 1: Make backups.



            I know, most people skip this step, but you're making changes that can result in major data loss if you screw up, and you're taking guidance from a random stranger on the Internet. You are responsible for the safety of your data. I'm not.



            Step 2: Shrink the filesystem in lv_scratch. If it's an ext2/3/4 filesystem, unmount it and use resize2fs; if it's something else, you'll need to look up documentation on resizing that type of filesystem.



            For example:



            resize2fs /dev/volgrp01/lv_scratch 50G


            When it's done (assuming you're using resize2fs), it'll tell you the new size of the filesystem in bytes. Make a note of that number, because you can use it for a safety check in the next step.



            Step 3: Shrink the logical volume using lvreduce.




            • If you want to be simple, use lvreduce --size 50G volgrp01/lv_scratch.

            • If you want to be extra cautious about not shrinking the LV to a size smaller than the filesystem it contains, check the physical extent size of your volume group using vgdisplay volgrp01, and calculate how many physical extents are needed to hold the byte size of your filesystem (using 1MB = 1048576 bytes). Then specify that number using the --extents option instead of the --size 50G.


            Alternatively, you may be able to skip step 1 and instead use lvreduce's -r option to resize the filesystem automatically. That may be easier, but I don't have personal experience with it to know how reliable it is.



            At this point I'd recommend running fsck -f on your /dev/volgrp01/vg_scratch just to make sure it's intact. If you get any errors about "access beyond end of device", it means you shrunk the LV too much and need to lvextend it before you proceed.



            Step 4: Shrink the physical volume using pvresize.



            pvresize --setphysicalvolumesize 88G /dev/sda2


            You don't need an extra safety check here since pvresize will refuse to shrink the physical volume to a size that's too small for your existing logical volumes. But if the sizes of your other LVs aren't exact multiples of 1GB, the 88G might be too small and you may need use a different value.



            Step 5: Shrink the sda2 partition using fdisk.



            Run fdisk /dev/sda, and at its prompt, run p to look at your existing partitions. Note the starting sector number of your sda2 partition. Then delete the sda2 partition — this doesn't touch the actual data, just removes the record of where it starts and ends — and create a new sda2 with the same starting sector (this is vital) and a size of 88G. The partition's type code should be 8e, "Linux LVM".



            If you want to be extra cautious — and I'd recommend you do, especially if you had to specify a different size to the pvresize earlier — check the PE size and Total PE of your physical volume using pvdisplay /dev/sda2 and multiply them together to find the size of the physical volume in bytes (again using 1MB = 1048576 bytes). Then subtract your new sda2 partition's starting sector number from its ending one, add 1 so that the last sector is counted, and multiply by your disk's sector size (which should be either 512 or 4096 bytes). Make sure the two results match.



            Now create your new sda3 partition, save your changes, and quit fdisk. If you get a message about needing to reboot for the change to take effect, reboot.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Dec 5 at 3:33

























            answered Mar 28 '14 at 1:01









            Wyzard

            5,64822223




            5,64822223












            • In your third to last paragraph, why 50G and not 88G? Typo?
              – Greg Bell
              Aug 11 '16 at 13:41










            • Oops, yes. Fixed now; thanks.
              – Wyzard
              Aug 11 '16 at 14:07










            • If you run into the errors Requested size is less than real size and cannot resize to <bitcount> extents, as later ones are allocated have a look here that explains to use pvmove to make the volumes adjacent to each other.
              – Matthias Braun
              Jan 10 at 14:56












            • Instead of using fdisk I used cfdisk. I had the problem that I couldn't keep the original start block with fdisk. cfdisk could do it right and much easier then fdisk! Just select 'resize' and enter the amount of diskspace. And 'write' when you are satisfied with your configuration. That's it!
              – ffonz
              Jun 2 at 19:35










            • These days I use GPT partition tables for everything, so gdisk.
              – Wyzard
              Jun 3 at 3:46


















            • In your third to last paragraph, why 50G and not 88G? Typo?
              – Greg Bell
              Aug 11 '16 at 13:41










            • Oops, yes. Fixed now; thanks.
              – Wyzard
              Aug 11 '16 at 14:07










            • If you run into the errors Requested size is less than real size and cannot resize to <bitcount> extents, as later ones are allocated have a look here that explains to use pvmove to make the volumes adjacent to each other.
              – Matthias Braun
              Jan 10 at 14:56












            • Instead of using fdisk I used cfdisk. I had the problem that I couldn't keep the original start block with fdisk. cfdisk could do it right and much easier then fdisk! Just select 'resize' and enter the amount of diskspace. And 'write' when you are satisfied with your configuration. That's it!
              – ffonz
              Jun 2 at 19:35










            • These days I use GPT partition tables for everything, so gdisk.
              – Wyzard
              Jun 3 at 3:46
















            In your third to last paragraph, why 50G and not 88G? Typo?
            – Greg Bell
            Aug 11 '16 at 13:41




            In your third to last paragraph, why 50G and not 88G? Typo?
            – Greg Bell
            Aug 11 '16 at 13:41












            Oops, yes. Fixed now; thanks.
            – Wyzard
            Aug 11 '16 at 14:07




            Oops, yes. Fixed now; thanks.
            – Wyzard
            Aug 11 '16 at 14:07












            If you run into the errors Requested size is less than real size and cannot resize to <bitcount> extents, as later ones are allocated have a look here that explains to use pvmove to make the volumes adjacent to each other.
            – Matthias Braun
            Jan 10 at 14:56






            If you run into the errors Requested size is less than real size and cannot resize to <bitcount> extents, as later ones are allocated have a look here that explains to use pvmove to make the volumes adjacent to each other.
            – Matthias Braun
            Jan 10 at 14:56














            Instead of using fdisk I used cfdisk. I had the problem that I couldn't keep the original start block with fdisk. cfdisk could do it right and much easier then fdisk! Just select 'resize' and enter the amount of diskspace. And 'write' when you are satisfied with your configuration. That's it!
            – ffonz
            Jun 2 at 19:35




            Instead of using fdisk I used cfdisk. I had the problem that I couldn't keep the original start block with fdisk. cfdisk could do it right and much easier then fdisk! Just select 'resize' and enter the amount of diskspace. And 'write' when you are satisfied with your configuration. That's it!
            – ffonz
            Jun 2 at 19:35












            These days I use GPT partition tables for everything, so gdisk.
            – Wyzard
            Jun 3 at 3:46




            These days I use GPT partition tables for everything, so gdisk.
            – Wyzard
            Jun 3 at 3:46













            0














            Not sure whether it will work - I've only increased pv. And any way DO NOT TRY IT ON VALUABLE DATA UNLESS YOUR HAVE READABLE BACKUP.




            1. Use FS-specific tool (if any) to resize FS on lv_scratch


            2. lvresize -L 50G /dev/volgrp01/lv_scratch


            3. pvresize --setphysicalvolumesize 88G /dev/sda2


            4. Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)


            5. Create new partition, make new pv, create volume group etc.



            Double check all numbers when resizing as if you shrink you logical or physical volume more than FS you may end up with broken FS and lost data, usually it's better to left some unused space in case of confusion.






            share|improve this answer


























              0














              Not sure whether it will work - I've only increased pv. And any way DO NOT TRY IT ON VALUABLE DATA UNLESS YOUR HAVE READABLE BACKUP.




              1. Use FS-specific tool (if any) to resize FS on lv_scratch


              2. lvresize -L 50G /dev/volgrp01/lv_scratch


              3. pvresize --setphysicalvolumesize 88G /dev/sda2


              4. Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)


              5. Create new partition, make new pv, create volume group etc.



              Double check all numbers when resizing as if you shrink you logical or physical volume more than FS you may end up with broken FS and lost data, usually it's better to left some unused space in case of confusion.






              share|improve this answer
























                0












                0








                0






                Not sure whether it will work - I've only increased pv. And any way DO NOT TRY IT ON VALUABLE DATA UNLESS YOUR HAVE READABLE BACKUP.




                1. Use FS-specific tool (if any) to resize FS on lv_scratch


                2. lvresize -L 50G /dev/volgrp01/lv_scratch


                3. pvresize --setphysicalvolumesize 88G /dev/sda2


                4. Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)


                5. Create new partition, make new pv, create volume group etc.



                Double check all numbers when resizing as if you shrink you logical or physical volume more than FS you may end up with broken FS and lost data, usually it's better to left some unused space in case of confusion.






                share|improve this answer












                Not sure whether it will work - I've only increased pv. And any way DO NOT TRY IT ON VALUABLE DATA UNLESS YOUR HAVE READABLE BACKUP.




                1. Use FS-specific tool (if any) to resize FS on lv_scratch


                2. lvresize -L 50G /dev/volgrp01/lv_scratch


                3. pvresize --setphysicalvolumesize 88G /dev/sda2


                4. Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)


                5. Create new partition, make new pv, create volume group etc.



                Double check all numbers when resizing as if you shrink you logical or physical volume more than FS you may end up with broken FS and lost data, usually it's better to left some unused space in case of confusion.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Mar 28 '14 at 0:38









                F2nd

                311




                311






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Super User!


                    • 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.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • 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%2fsuperuser.com%2fquestions%2f734468%2fhow-can-i-shrink-a-logical-volume-and-re-allocate-the-freed-space-into-a-new-pa%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

                    Plaza Victoria

                    Puebla de Zaragoza

                    Musa