Re: [tlug] Mysterious LVM issue

[Francois Cartegnie <fcartegnie@example.com>]

Le mercredi 11 mars 2009, Birkir A. Barkarson a écrit :
> Does anyone know if LVM is doing some voodoo behind the scenes that
> might lead to this situation. I'm a little uneasy about the whole thing
> so any wise words would be appreciated.

df can't tell you anything about LVM. 
If you think having a metadata inconsistency somewhere:
Check if the sum of LVM extends is equal to the filesystem size.
	tune2fs -l /dev/mapper/america_main-store
Multiply block count by block size. (or convert into PE size units below)
Then check if it match the volume sizes:
	pvdisplay
Check values and note your PE Size. (defaults to 4kb)
	lvdisplay
Check if "current LE" * PE Size (or fs in PE size units) match.
You can also do an extra check of the partition size against the sum of PV 
sizes.

If you've done nothing tricky with lvm (copying partitions, or the LVM cache 
directory...), for me It's more like a filesystem problem. When you reach the 
some filesystems limits, values can become unaccurate (bug ?).
After freeing some space, I once ran into strange things like:
/dev/hda6 20G -256Z 20G 101% /mnt/opt

In that case, you need to check your real free blocks (and free inodes!) with 
tune2fs. You'll see if it's accounted correctly in the superblock.