[linux-lvm] show free space _inside_ logical volume

[linux-lvm] show free space _inside_ logical volume

[Gabriel]

Hi all,

I'm interested to know if it is possible to check the amount of free
space _inside_ a LV. I know that usually a LV is fully "occupied" by a
partition, but there is a (short) period when there is a gap between
the size of the partition and the size of the LV it resides on. That
happens _after_ doing a lvextend and _before_ doing the resize
(expand) of the filesystem.

First thing I thought of was lvdisplay. While I can see how many LEs
the LV has, I cannot see how many of them are in use by the filesystem
and how many are free (the way pvdisplay shows total/free/allocated
PEs).

It was suggested to me that I try some filesystem tools (resize2fs,
dumpe2fs, tune2fs etc.) that might show me the free space. resize2fs
does not have a 'dry-run' option that would have shown the new size
(in blocks) of the filesystem and I didn't find anything useful in
tune2fs' manual either.

dumpe2fs shows various information such as block count, free blocks
and block size, but I see no modifications when running this before
and after the lvextend command.

I also tried parted -l, but to no avail.

Re: [linux-lvm] show free space _inside_ logical volume

[Lyn Rees]

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

If you mount the filesystem, 'df' will tell you how big it is, you can 
compare that to the output of lvdisplay.
--------------------------------------------------
Mr Lyn Rees
Senior Engineer, UIG
Information Services Computing Centre
Cardiff University, 40-41 Park Place,
Cardiff. CF10 3BB.
--------------------------------------------------
Contact numbers:
 (029) 2087 9188 (direct)
 (029) 2087 4875 (reception)
 (029) 2087 4285 (fax)
--------------------------------------------------
Email: rees@cardiff.ac.uk
Web: www.cardiff.ac.uk



From:
Gabriel <jarod125@gmail.com>
To:
linux-lvm@redhat.com
Date:
01/12/2009 00:46
Subject:
[linux-lvm] show free space _inside_ logical volume



Hi all,

I'm interested to know if it is possible to check the amount of free
space _inside_ a LV. I know that usually a LV is fully "occupied" by a
partition, but there is a (short) period when there is a gap between
the size of the partition and the size of the LV it resides on. That
happens _after_ doing a lvextend and _before_ doing the resize
(expand) of the filesystem.

First thing I thought of was lvdisplay. While I can see how many LEs
the LV has, I cannot see how many of them are in use by the filesystem
and how many are free (the way pvdisplay shows total/free/allocated
PEs).

It was suggested to me that I try some filesystem tools (resize2fs,
dumpe2fs, tune2fs etc.) that might show me the free space. resize2fs
does not have a 'dry-run' option that would have shown the new size
(in blocks) of the filesystem and I didn't find anything useful in
tune2fs' manual either.

dumpe2fs shows various information such as block count, free blocks
and block size, but I see no modifications when running this before
and after the lvextend command.

I also tried parted -l, but to no avail.

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



[-- Attachment #2: Type: text/html, Size: 3118 bytes --]

Re: [linux-lvm] show free space _inside_ logical volume

[Mark H. Wood]

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

Well, the LVM tools will tell you the size of the LV, and filesystem
tools will tell you the size of the filesystem.  You have to do the
subtraction yourself.

Depending on what's most important to you, to have either set of tools
work with the other's data would either be a layering violation, cause
unnecessary and fragile coupling of unrelated tools, or make them
needlessly complex.  Both toolsets need to remain small, light,
rugged, and simple, because they're used for standing up and repairing
systems that may not be ready for daily use.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Friends don't let friends publish revisable-form documents.

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

Re: [linux-lvm] show free space _inside_ logical volume

[Stuart D. Gathman]

On Tue, 1 Dec 2009, Mark H. Wood wrote:

> Depending on what's most important to you, to have either set of tools
> work with the other's data would either be a layering violation, cause
> unnecessary and fragile coupling of unrelated tools, or make them
> needlessly complex.  Both toolsets need to remain small, light,
> rugged, and simple, because they're used for standing up and repairing
> systems that may not be ready for daily use.

The other option is the ZFS approach of integrating LVM and filesystem.
The drawback is that you can only ever use the one supported filesystem.
(Though there is probably a way to mount unsupported filesystems - but 
then you are back to having to use both tools and subtract.)

Linux LVM doesn't know or care what filesystem you use, which is super
for experimenting with filesystems - expecially in conjunction with
a virtual machine.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] show free space _inside_ logical volume

[Gabriel]

df tells me the actual usable space on the partition which is less
than the filesystem size. However, dumpe2fs shows some useful
information:

user@homepc:~$ sudo dumpe2fs -h /dev/mapper/myvg-root | grep -i block
dumpe2fs 1.41.9 (22-Aug-2009)
Block count:              171008000
Reserved block count:     8546960
Free blocks:              13915854
First block:              0
Block size:               4096
Reserved GDT blocks:      983
Blocks per group:         32768
Inode blocks per group:   512
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
Journal backup:           inode blocks

Multiplying block count by block size and dividing the result by
1024^3, I obtain the exact value reported by lvdisplay:

user@homepc:~$ sudo lvdisplay -v /dev/myvg/root
    Using logical volume(s) on command line
  --- Logical volume ---
  LV Name                /dev/myvg/root
  VG Name                myvg
  LV UUID                6poYWo-YHsp-dhLC-lDBA-3xfw-9EIn-DSDYL2
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                652.34 GB
  Current LE             167000
  Segments               4
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1

At the same time, df -h / shows this:

user@homepc:~$ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/myvg-root
                      643G  590G   21G  97% /

which is significantly less (the difference being used for filesystem
metadata information).

After doing a lvextend, output of dumpe2fs does not change. The block
count number is increased only after running resize2fs. So, the
difference between this value and the one reported by lvdisplay is the
free space "inside" the LV.

In case I'd want to shrink the LV, I would need to first shrink the
filesystem and then the LV. If I were to shrink the LV to a value
higher than the one reported by df but lower than the one obtained by
converting the block count to GBs, I would probably end up with a
corrupted filesystem.

While we're at it, I'm curious about what the "Reserved block count"
and "Free blocks" values mean. The former translates to 32.6 GB which
is way more than the difference between the total space reported by df
(643 GB) and the entire filesystem size (652.34 GB). The latter
translates to 53 GB which is available space reported by df (21 GB) +
aforementioned 32.6 GB value.

On Tue, Dec 1, 2009 at 8:33 PM, Stuart D. Gathman <stuart@bmsi.com> wrote:
> On Tue, 1 Dec 2009, Mark H. Wood wrote:
>
>> Depending on what's most important to you, to have either set of tools
>> work with the other's data would either be a layering violation, cause
>> unnecessary and fragile coupling of unrelated tools, or make them
>> needlessly complex. �Both toolsets need to remain small, light,
>> rugged, and simple, because they're used for standing up and repairing
>> systems that may not be ready for daily use.
>
> The other option is the ZFS approach of integrating LVM and filesystem.
> The drawback is that you can only ever use the one supported filesystem.
> (Though there is probably a way to mount unsupported filesystems - but
> then you are back to having to use both tools and subtract.)
>
> Linux LVM doesn't know or care what filesystem you use, which is super
> for experimenting with filesystems - expecially in conjunction with
> a virtual machine.
>
> --
> � � � � � � �Stuart D. Gathman <stuart@bmsi.com>
> � �Business Management Systems Inc. �Phone: 703 591-0911 Fax: 703 591-6154
> "Confutatis maledictis, flammis acribus addictis" - background song for
> a Microsoft sponsored "Where do you want to go from here?" commercial.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>