[linux-lvm] pvscan showing 0 free on all PV's.

[linux-lvm] pvscan showing 0 free on all PV's.

[Rene Olsen]

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

Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Tupshin Harper]

Rene Olsen wrote:

>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

Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Rickard Olsson]

Tupshin Harper wrote:

> 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/

Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Tupshin Harper]

Rickard Olsson wrote:

> Tupshin Harper wrote:
>
>> 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.

Yup, I misspoke. It's JFS and XFS that don't shrink.

-Tupshin

[linux-lvm] pvscan showing 0 free on all PV's.

[Rene Olsen]

[-- Attachment #1: Mail message body --]
[-- Type: text/html, Size: 3274 bytes --]

Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Tracy R Reed]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

On Tue, Sep 16, 2003 at 11:56:27AM -0700, Tupshin Harper spake thusly:
> 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.

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

-- 
Tracy Reed
http://copilotconsulting.com

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Tupshin Harper]

Rene Olsen wrote:

> So what I should do is the following:
>
> Lets say the 200GB disc is 6000 PE's big.
>
> e2fsadm -v -l -6076 /dev/vol1/lv_vol

yup,

> This should make the lvm 200GB smaler.
>
> Then after that I do
>
> pvmove /dev/hdh1

Not yet. e2fsadm reduced the size of the filesystem. But you need to 
then reduce the sze of the lvm with:
lvreduce -l 6076 /dev/vol1/lv_vol
Then use the pvmove command.

-Tupshin

Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Rickard Olsson]

Tracy R Reed wrote:

> 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/

Re: [linux-lvm] pvscan showing 0 free on all PV's.

[Heinz J . Mauelshagen]

On Wed, Sep 17, 2003 at 11:56:34AM -0700, Tupshin Harper wrote:
> Rene Olsen wrote:
> 
> > So what I should do is the following:
> >
> > Lets say the 200GB disc is 6000 PE's big.
> >
> > e2fsadm -v -l -6076 /dev/vol1/lv_vol
> 
> yup,
> 
> > This should make the lvm 200GB smaler.
> >
> > Then after that I do
> >
> > pvmove /dev/hdh1
> 
> Not yet. e2fsadm reduced the size of the filesystem. But you need to 
> then reduce the sze of the lvm with:
> lvreduce -l 6076 /dev/vol1/lv_vol
> Then use the pvmove command.

No need to lvreduce after running e2fsadm.

e2fsadm extends/reduces an unmounted ext[23] and grows/shrinks the Logical
Volume as well (unless a not automatically fixible fsck error occurs).

> 
> -Tupshin
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-