pvscan showing 0 free on all PV's.
Hi.
I have a LVM made out of 7 partitions and a total space of approx 760GB.
One of the drived is a 200GB drive and I would like to take that out of the lvm to use it for something else.
Easy enough I thought. I made sure that there was 260GB free on the lvm (using df) and then I unmounted the lvm and did this: pvmove /dev/hdh1
Now, according to all I have found that should do it. But, it comes back and tells me that there is not enough free space to do the operation.
When I do a pvscan it shows the following:
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE PV "/dev/hdl1" of VG "vol1" [76.66 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdi1" of VG "vol1" [115 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdj1" of VG "vol1" [71.53 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdg1" of VG "vol1" [57.22 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdh1" of VG "vol1" [189.88 GB / 0 free] pvscan -- ACTIVE PV "/dev/hde1" of VG "vol1" [115 GB / 0 free] pvscan -- ACTIVE PV "/dev/hdf1" of VG "vol1" [115 GB / 0 free]
pvscan -- total: 7 [740.58 GB] / in use: 7 [740.58 GB] / in no VG: 0 [0]
Now, why in the world does it show 0 free on all the PV's when a df told me that there were at least 260GB free on the lvm.
Am I doing something wrong or ?
Any help will be most appreciated.
Best regards.
Rene
Quoted 11 lines · Rene Olsen
Now, why in the world does it show 0 free on all the PV's when a df told me that there were at least 260GB free on the lvm.
Am I doing something wrong or ?
Any help will be most appreciated.
Best regards.
Rene
df shows how much free space there is on the *filesystem*. Even if the filesystem isn't full, it can occupy the entire lvm, which occupies the entire volume group. If you have only one filesystem on the lvm, then you may or may not have a problem, depending on what filesystem you are using. If you are using ext2 or ext3, then you can probably do an ext2resize to shrink it, followed by an lvreduce to reduce the size of the partition that the filesystem lives on, but *DANGER* *DANGER* *DANGER*. Reducing the size of an existing filesystem is inherently dangerous, so back up, tread with caution, and don't blame me when a meteorite flattens your house.
If you are using reiserfs, jfs, or xfs, you are probably out of luck, as these filesystems don't currently support reduction.
-Tupshin
Quoted 1 line · Tupshin Harper
If you are using reiserfs, jfs, or xfs, you are probably out of luck, as these filesystems don't currently support reduction.
resize_reiserfs shrinks or grows reiserfs3 filesystems.
http://www.namesys.com/resize_reiserfs.html
[evidence type=anecdotal] I have used it to grow and shrink my reiserfs filesystems on many occasions for several years with no problems whatsoever. [/evidence] I typically use ext3 on the / and /boot partitions and LVM with Reiser on all large storage areas, like /home and /files. This is specifically because it is easy to change the sizes of the filesystems and handle the disks - move them around and so on.
/ Rickard Olsson,IT-Konsult/
/ Telefon: +46 70 635 01 42/
/ http://www.webhackande.se/
Quoted 10 lines · Rickard Olsson
Quoted 1 line · Tupshin Harper
If you are using reiserfs, jfs, or xfs, you are probably out of luck, as these filesystems don't currently support reduction.
resize_reiserfsshrinks or grows reiserfs3 filesystems.http://www.namesys.com/resize_reiserfs.html
[evidence type=anecdotal] I have used it to grow and shrink my reiserfs filesystems on many occasions for several years with no problems whatsoever. [/evidence] I typically use ext3 on the / and /boot partitions and LVM with Reiser on all large storage areas, like /home and /files. This is specifically because it is easy to change the sizes of the filesystems and handle the disks - move them around and so on.
Yup, I misspoke. It's JFS and XFS that don't shrink.
-Tupshin
On Tue, Sep 16, 2003 at 11:56:27AM -0700, Tupshin Harper spake thusly:
Quoted 5 lines
ext2resize to shrink it, followed by an lvreduce to reduce the size of the partition that the filesystem lives on, but *DANGER* *DANGER* *DANGER*. Reducing the size of an existing filesystem is inherently dangerous, so back up, tread with caution, and don't blame me when a meteorite flattens your house.
Inherently dangerous? Nonsense. It should not be inherently dangerous if the resize tool and LVM do their jobs properly. Resizing should be a perfectly safe operation when done properly.
Quoted 2 lines
If you are using reiserfs, jfs, or xfs, you are probably out of luck, as these filesystems don't currently support reduction.
reiserfs supports reduction. I have done it many times. I wouldn't be surprised if the others do too but I haven't used them yet.
Signature · 2 lines
Tracy Reed http://copilotconsulting.com
Quoted 3 lines · Tracy R Reed
Inherently dangerous? Nonsense. It should not be inherently dangerous if the resize tool and LVM do their jobs properly. Resizing should be a perfectly safe operation when done properly.
While I agree with you on principle, there is an additional element of risk inherent in shrinking a filesystem - moving existing data off the shrinking part. Interruptions during this phase may severely damage your filesystem's structural integrity (and we can't just route more power to the structural integrity field yet).
Very early this morning, I even thought of a good, real-life example:
Imagine that the eastern seaboard of the continental US is your LV. Now, along comes hurricane Isabel, hell bent on reducing your VG with a PV or two. What do you do? You evacuate (lvreduce, pvmove and resize) the data to safer ground. During this evacuation, panic and chaos lurks underneath the surface at all times. Bits and bytes flee the still unseen enemy. You get traffic jams and the buses are filled with ones and zeroes. It's almost inevitable that an operation of this magnitude may leave behind some dead and wounded, but the alternative is worse and that's why we do it.
OK, it all sounded a lot better before I got my first cup of coffee, but still. :-)
A transaction-based pvmove and ditto resize_reiserfs (I don't know if it already is or if it turns journalling off during a resize) would solve this problem, but pvmove is already slow as it is... A pvmove with hooks into Reiser4 so it could use R4s fast transactions might however be ideal in this particular case. That almost brings me to my wish-list for LVM/EVMS/md/R4, but that's a different story.
/ Rickard Olsson,IT-Konsult/
/ Telefon: +46 70 635 01 42/
/ http://www.webhackande.se/