PDA

View Full Version : df reports wrong space free on LVM volume



novhyten
09-May-2013, 14:27
Good day.
I have an issue with a logical volume in SLES 11 SP1, 64-bit, in VMware 5. I needed to add more space to the volume because it was down to 9% free so I added another VMDK. Then in YaST Partitioner, I added the new device to the volume group, then resized the logical volume, which seemed to resize the Ext3 file system too because total size in "df" jumped up.

But I have a discrepancy between what YaST Partitioner reports as the volume size and what "df" returns. Both report the same used amount, but differ in the volume's total size and free space. In fact, df's report doesn't even add up. I've seen that before with df.

Partitioner says:
"New Logical Volume Size (in GB): 659.9 GB"
"LV Size Restrictions: Minimum LV Size: 551.75 GB, Maximum LV Size: 659.9 GB"
"LV Used: 551.75 GB, LV Free: 107.24 GB"

df reports:
649 GB total (not 659 GB), 552 used, 64 GB free (90%)


Unfortunately I have an application that uses the values from "df" to determine free space. It won't kick off a job with disk free below a certain percentage.

Any advice?

TIA,
~Howard Hyten
Austin, TX

KBOYLE
09-May-2013, 18:26
novhyten wrote:

>
> Good day.
> I have an issue with a logical volume in SLES 11 SP1, 64-bit, in
> VMware 5. I needed to add more space to the volume because it was
> down to 9% free so I added another VMDK. Then in YaST Partitioner, I
> added the new device to the volume group, then resized the logical
> volume, which seemed to resize the Ext3 file system too because total
> size in "df" jumped up.

You have increased the size of the LV. IIRC, you now have to increase
the size of the filesystem.

Sorry, I don't have time at the moment to find the reference. Check the
documentation or the knowledgebase.


--
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

novhyten
09-May-2013, 20:36
[QUOTE=KBOYLE;13552]novhyten wrote:



You have increased the size of the LV. IIRC, you now have to increase
the size of the filesystem.

Sorry, I don't have time at the moment to find the reference. Check the
documentation or the knowledgebase.



Hmm, so I'm pretty sure YaST did increase the size of the Ext3 filesystem because it was 599 GB before, now df is reporting 649 GB,
though it should be 659 GB.

This is something I've seen in SLES with df, after manipulating a drive/volume/filesystem, sometimes Used + Free != Total space.

Does anyone think resize2fs will fix this?
I haven't run fsck.ext3 on the filesystem since the addition of space.

~Howard Hyten

jmozdzen
10-May-2013, 13:04
Hi Howard,

may I assume those are ext file systems?

If you look at the details via "tune2fs -l", you'll notice that extfs will reserve blocks for a special user (typically uid 0).

In a case I have here:

myhost:~ # df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/system-root 1032088 650388 329272 67% /

So the delta is 1032088-650388-329272 = 52428 blocks (of 1k each). Looking at the file system details, I see


myhost:~ # tune2fs -l /dev/mapper/system-root
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: root
Last mounted on: /root
[...]
Block count: 262144
Reserved block count: 13107
Free blocks: 95426
Free inodes: 106161
First block: 0
Block size: 4096
[...]
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
so 13107 block (of 4k each) are reserved, which makes 52428 blocks (of 1k each).

So I'd say, everything is in order, but not revealed at first sight ;)

Regards,
Jens

novhyten
10-May-2013, 13:58
Hi Howard,

may I assume those are ext file systems?

If you look at the details via "tune2fs -l", you'll notice that extfs will reserve blocks for a special user (typically uid 0).

In a case I have here:


So the delta is 1032088-650388-329272 = 52428 blocks (of 1k each). Looking at the file system details, I see


so 13107 block (of 4k each) are reserved, which makes 52428 blocks (of 1k each).

So I'd say, everything is in order, but not revealed at first sight ;)

Regards,
Jens


Yes, Jens, the filesystem is Ext3. Output of "tune2fs -l" shows

8637404 reserved blocks of size 4096 bytes = 32.95G. So this other class of blocks does make the totals reported by df add up:

32.95G + 64G + 552G = 649G

I'm still missing 10G, but noticed that "tune2fs -l" also reports data about inodes. They're each 256 bytes, 43188224 of them.
Which equals 10G. Mystery solved.

Now I need to go research what "reserved" blocks are used for. That's a rather annoying use of 5% of the drive.

Thanks for pointing me in the right direction, Jens.

~Howard Hyten
Austin, TX

jmozdzen
10-May-2013, 14:35
Hi Howard,


Now I need to go research what "reserved" blocks are used for. That's a rather annoying use of 5% of the drive.

Thanks for pointing me in the right direction, Jens.

~Howard Hyten
Austin, TX

the reservation is a security measure... to avoid running into a situation when regular users fill up the root file system and even root/administration processes run out of disk space, even for trivial tasks. While I haven't designed ExtFS, it nontheless adheres to my basic design rule ;) : Make assumptions, but make it configurable. You can change the percentage of blocks to be reserved, i.e. if you have a separate, dedicated file system accessed by non-root user's processes (i.e. some data storage): See "tune2fs -m".

Regards,
Jens

novhyten
10-May-2013, 14:41
Hi Howard,



the reservation is a security measure... to avoid running into a situation when regular users fill up the root file system and even root/administration processes run out of disk space, even for trivial tasks. While I haven't designed ExtFS, it nontheless adheres to my basic design rule ;) : Make assumptions, but make it configurable. You can change the percentage of blocks to be reserved, i.e. if you have a separate, dedicated file system accessed by non-root user's processes (i.e. some data storage): See "tune2fs -m".

Regards,
Jens

Yes, Jens, a bit of Internet research pulled up good results, like http://askubuntu.com/questions/19504/reasonable-size-for-filesystem-reserved-blocks-for-non-os-disks

Thanks so much for your replies. Since I'm dealing with a non-system volume, one written to by a single application, I'm going to dial down the percentage of reserved blocks.

~Howard