rpmdrake size estimation fails: bug or design feature?

[jaywalker]

Symptom: rpmdrake fails to install a package. The error shown is

Code: Select all

1 installation transactions failed

There was a problem during the installation:

installing package gimp-data-extras-2.0.2-5.mga3.noarch needs 5MB on the /usr filesystem

Every way I look at it I have at least 300M available.

A few days ago I re-installed to a fresh disc because rpmdrake said it needed more space on /. I was surprised but I tried again with a couple of hundred Mbytes more - now it is getting on for 4x the size I normally use because trying to shuffle things around to make the root partition bigger is not fun.

Sadly, on a 10G drive, all this super-caution is wasting(?) a lot of space, if the warning on gimp-data-extras is anything to go by.

Are these over-generous guestimates configurable in rpmdrake?

Richard

[doktor5000]

Please show the output of

Code: Select all

mount

and

Code: Select all

df -m /usr

.

[jaywalker]

Can't do that at the moment. I'm in the middle of trying out fsarchive to transfer it to a bigger disc I just discovered, so it is not currently mounted. I will provide the info as soon as the system is free to re-boot.

R

[jaywalker]

Hidden in this splurge of information you'll find hdb1 and hdb5 which are the root and usr partitions respectively.

Code: Select all

proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=3775884k,nr_inodes=943971,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/hdb1 on / type ext4 (rw,relatime,data=ordered)
/dev/hdb5 on /usr type ext4 (rw,relatime,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
/dev/hdb6 on /home type ext4 (rw,relatime,data=ordered)
/dev/hdc1 on /home/games type ext4 (rw,relatime,data=ordered)


Here are the various sizes reported for the usr file system; first using df, then according to Midnight Commander's info screen, and finally as reported by fsarchiver

Code: Select all

df -m /usr
Filesystem     1M-blocks  Used Available Use% Mounted on                                                                                                   
/dev/hdb5           6091  5777         5 100% /usr

Code: Select all

Midnight Commander info:
Filesystem: /usr
Device:    /dev/hdb5
Type:      ext4
Free space: 314M/6090M (5%)
Free nodes: 228151/396704 (57%)

Code: Select all

===================== filesystem information ====================
Filesystem id in archive:       1
Filesystem format:              ext4
Filesystem label:               MGA3-1
Filesystem uuid:                80e68030-b226-4a0e-acd6-4788d6b553ef
Original device:                /dev/hdb5
Original filesystem size:       5.82 GB (6251905024 bytes)
Space used in filesystem:       5.52 GB (5922959360 bytes)


That last one is 328,945,664 bytes, pretty close to the number mc gets.

I'm guessing you're going to tell me that rpmdrake uses df to get a notion of the space on the filesystem, rather than some other, perhaps more generous measurement. Question is, which one is right?

Personally I very seriously hope fsarchiver is correct; if it isn't then I can't be too optimistic about the integrity of the backup. Could it be explained by the amount of space "free" in partially used allocated blocks?

R

[junk_no_spam]

Symptom: rpmdrake fails to install a package.

installing package gimp-data-extras-2.0.2-5.mga3.noarch needs 5MB on the /usr filesystem

Every way I look at it I have at least 300M available.

Looking through this thread, I will suggest that the ~5% space you can not get to, is the reserved disk space.
For a little background try, man tune2fs and at the prompt, enter
/reserved-blocks-percentage

[jaywalker]

Sorry I didn't respond straight away.You could well be right about the missing space, but it doesn't really explain why the information at the bottom of the rpmdrake screen doesn't take the reserved disc space into account and reduce its free-space figure accordingly. After all, Joe User doesn't care about the inner workings of ext2/3/4 file systems, he only wants to know how much space he has left to install one more package.

I think my main point is that if rpmdrake is showing the wrong information (the same information I got from two other sources), is this a design feature which needs more explanation, or is it something which needs to be fixed?

R