[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 at 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 at 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 at 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 at 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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>