How can I shrink a Logical Volume, and re-allocate the freed space into a new partition on the same drive?
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.
linux hard-drive partitioning lvm lvm2
add a comment |
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.
linux hard-drive partitioning lvm lvm2
add a comment |
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.
linux hard-drive partitioning lvm lvm2
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.
linux hard-drive partitioning lvm lvm2
linux hard-drive partitioning lvm lvm2
asked Mar 27 '14 at 21:45
CptSupermrkt
205128
205128
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
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 errorsRequested size is less than real size
andcannot resize to <bitcount> extents, as later ones are allocated
have a look here that explains to usepvmove
to make the volumes adjacent to each other.
– Matthias Braun
Jan 10 at 14:56
Instead of usingfdisk
I usedcfdisk
. I had the problem that I couldn't keep the original start block withfdisk
.cfdisk
could do it right and much easier thenfdisk
! 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, sogdisk
.
– Wyzard
Jun 3 at 3:46
add a comment |
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.
Use FS-specific tool (if any) to resize FS on lv_scratch
lvresize -L 50G /dev/volgrp01/lv_scratch
pvresize --setphysicalvolumesize 88G /dev/sda2
Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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 errorsRequested size is less than real size
andcannot resize to <bitcount> extents, as later ones are allocated
have a look here that explains to usepvmove
to make the volumes adjacent to each other.
– Matthias Braun
Jan 10 at 14:56
Instead of usingfdisk
I usedcfdisk
. I had the problem that I couldn't keep the original start block withfdisk
.cfdisk
could do it right and much easier thenfdisk
! 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, sogdisk
.
– Wyzard
Jun 3 at 3:46
add a comment |
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.
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 errorsRequested size is less than real size
andcannot resize to <bitcount> extents, as later ones are allocated
have a look here that explains to usepvmove
to make the volumes adjacent to each other.
– Matthias Braun
Jan 10 at 14:56
Instead of usingfdisk
I usedcfdisk
. I had the problem that I couldn't keep the original start block withfdisk
.cfdisk
could do it right and much easier thenfdisk
! 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, sogdisk
.
– Wyzard
Jun 3 at 3:46
add a comment |
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.
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.
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 errorsRequested size is less than real size
andcannot resize to <bitcount> extents, as later ones are allocated
have a look here that explains to usepvmove
to make the volumes adjacent to each other.
– Matthias Braun
Jan 10 at 14:56
Instead of usingfdisk
I usedcfdisk
. I had the problem that I couldn't keep the original start block withfdisk
.cfdisk
could do it right and much easier thenfdisk
! 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, sogdisk
.
– Wyzard
Jun 3 at 3:46
add a comment |
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 errorsRequested size is less than real size
andcannot resize to <bitcount> extents, as later ones are allocated
have a look here that explains to usepvmove
to make the volumes adjacent to each other.
– Matthias Braun
Jan 10 at 14:56
Instead of usingfdisk
I usedcfdisk
. I had the problem that I couldn't keep the original start block withfdisk
.cfdisk
could do it right and much easier thenfdisk
! 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, sogdisk
.
– 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
add a comment |
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.
Use FS-specific tool (if any) to resize FS on lv_scratch
lvresize -L 50G /dev/volgrp01/lv_scratch
pvresize --setphysicalvolumesize 88G /dev/sda2
Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)
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.
add a comment |
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.
Use FS-specific tool (if any) to resize FS on lv_scratch
lvresize -L 50G /dev/volgrp01/lv_scratch
pvresize --setphysicalvolumesize 88G /dev/sda2
Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)
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.
add a comment |
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.
Use FS-specific tool (if any) to resize FS on lv_scratch
lvresize -L 50G /dev/volgrp01/lv_scratch
pvresize --setphysicalvolumesize 88G /dev/sda2
Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)
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.
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.
Use FS-specific tool (if any) to resize FS on lv_scratch
lvresize -L 50G /dev/volgrp01/lv_scratch
pvresize --setphysicalvolumesize 88G /dev/sda2
Resize your /dev/sda2 (not sure whether it is possible with parted/cfdisk etc, may be you'll need some other partition editor)
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.
answered Mar 28 '14 at 0:38
F2nd
311
311
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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