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.

(after lvresize got corrupted. Is it possible to. Use 'systemctl default' or ^D to activate default. First shrink the file system, then shrink the lvm.

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. 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 = ). 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 fdisk -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. 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.

Re: [linux-lvm] pvresize, resize 8e Linux LVM partition [][] [][] [] [] [] Re: [linux-lvm] pvresize, resize 8e Linux LVM partition • From: 'Lamont R. Peterson' • To: LVM • Subject: Re: [linux-lvm] pvresize, resize 8e Linux LVM partition • Date: Thu, 3 Aug 2006 11:54:29 -0600 On Wednesday 02 August 2006 11:27 pm, Stanislaw Senotrusov wrote: >Hello. >>Trying to figure out how to resize LVM partition. >>I cloned hard drive using Acronis True Image and now have some space >after LVM partition. >>As I see, before run pvresize I need to resize partition itself.

Which >tool can help me to do it? Man pvresize refers to fdisk, but I can't >understand how to use it for resize. Fdisk does not have a resize function. Delete the existing partition and recreate it, but bigger. Be ***VERY*** careful; the most important thing is that the new partition must *begin* exactly where the old one did. I would recommend writting down the cylinder numbers of the partition before deleting it. >Simply running pvresize does nothing.

Roger Eno Voices Rar Download. That's because he PV is already the full size of the partition it's living on. Although this is a case where using the disk raw would make things easier (you could run pvresize without having to alter the partition first), I would never recommend it. >Actually I am trying to build some pipeline to quick make a test and >production box from development one. I can make it manually by >creating new pv and dump/restore, but its a 3 page of commands. And I >still cant figure out that is the right tool for ext3 dump/restore. Are you talking about data on the LVs you want to copy?

Are you also including the entire OS? Here is how I would do it: 1. Kickstart install of new box (sets up LVM, includes packages, etc.) 2.

Run a script to install all of the needed configuration files for all the services the new server needs (could be run as part of the Kickstart). Copy the data the services will be 'serving' to the new machine. There are lots of ways to do step 3.

Personally, I like to avoid as much of computational overhead as possible at this stage, so I like NFS mounting and 'cp -a'. Plain, simple, fast and comprehensive.

>Another way is create new pv in free space and add it to volume group >- but after that this box will be a little different from the original >one, thus I need additional tracking of its configuration. I think you're right, that's not the right way to do it.

Peterson Founder [ ] GPG Key fingerprint: 0E35 93C5 4249 49F0 EC7B 4DDD BE46 4732 6460 CCB5 ___ ____ _ _ / _ _ __ ___ _ __ __ ) _ __ __ _(_)_ __ ___ _ ___ _ __ ___ '_ / _ '_ _ '__/ _` '_ / __ __/ _ '_ ` _ _ _) __/ _) (_ __ __/ ___/ .__/ ___ _ _ ____/ _ __,_ _ _ _ ___/ __ ___ _ _ _ _ Intelligent Open Source Software Engineering [ ] Attachment: Description: PGP signature • Follow-Ups: • • From: Stanislaw Senotrusov • References: • • From: Stanislaw Senotrusov [][] [][] [] [] [].