FS#37402 - [pacman] pacman try to download packages enen if no space left on deice
Attached to Project:
Pacman
Opened by Pablo Lezaeta (Jristz) - Saturday, 19 October 2013, 00:54 GMT
Last edited by Allan McRae (Allan) - Wednesday, 02 November 2016, 04:11 GMT
Opened by Pablo Lezaeta (Jristz) - Saturday, 19 October 2013, 00:54 GMT
Last edited by Allan McRae (Allan) - Wednesday, 02 November 2016, 04:11 GMT
|
Details
Description:
PAcman try to download (and obvious fail) packages on standar location een if that location is a mount point and is full (aka 100%) I think that this is because pacman check space only for intal but not for download the other part is that the error mesage is cryptic: Package error (size != sizetotal) and in english. so the feature is a proper mesaje of 'Cache is full' or make packman check space after download Additional info: * pacman in core Reproduce: Make /var/cache/pacman a mount point, make it full and try to download throw pacman a big package like linux |
This task depends upon
Closed by Allan McRae (Allan)
Wednesday, 02 November 2016, 04:11 GMT
Reason for closing: Fixed
Additional comments about closing: should be fixed in git commit 8c55c009
Wednesday, 02 November 2016, 04:11 GMT
Reason for closing: Fixed
Additional comments about closing: should be fixed in git commit 8c55c009
# mkdir tmp
# mount -t tmpfs none tmp -o size=1M
# pacman --cachedir=$PWD/tmp -Sddw sage-mathematics
Package (1) New Version Net Change Download Size
community/sage-mathematics 5.11-1 2259.18 MiB 370.22 MiB
Total Download Size: 370.22 MiB
:: Proceed with download? [Y/n]
error: Partition /root/tmp too full: 94790 blocks needed, 256 blocks free
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.
additional maybe another thing is that a package was downloaded partially but the error rise when pacman try to resume that because I do a upgrade that consoume space.
I can reproduce it as I want and eery time I want (so here is 100% reproducible) but I need time (slow internet during weekend...really slow), so please wait until monday for all type of logs
1) pacman.conf
2) /etc/fstab
3) a pacman log from the error happening with --debug
fstab (0.9 KiB)
Both those will be much smaller than the pacman.log you just uploaded.
I think (in my ignorance) that btrfs metadata isn't taken correctly in concideration on pacman for determinate if is possible or continue whit the operation
df-HT (0.7 KiB)
pacman-log (53.8 KiB)
btrfs-fi-show (0.6 KiB)
btrfs-fi-df-var-cache-pacman (0.2 KiB)
debug: partition /var/cache/pacman, needed 11990, cushion 5121, free 185216
Can you provide the output of "df -a"?
/dev/sda6 7.0G 6.3G 0 100% /var/cache/pacman
and say 100% because btrfs not respect standards..or that I think
remmember btrfs + autodefrag, I run whitout autodefrag but no change in output
and maybe metadata have influence here??
Once the FS was expanded pacman hadn't handled the install gracefully and the existing python files were treated as unowned, so the package had to be reinstalled with --force.
https://btrfs.wiki.kernel.org/index.php/FAQ
I hope this could help to almos know why this happend
df.c:888: bv->available = fsu->fsu_bavail;
vs.
diskspace.c:348ff:
_alpm_log(handle, ALPM_LOG_DEBUG,
"partition %s, needed %jd, cushion %ju, free %ju\n",
mp->mount_dir, (intmax_t)mp->max_blocks_needed,
(uintmax_t)cushion, (uintmax_t)mp->fsp.f_bfree);
if(needed >= 0 && (fsblkcnt_t)needed > mp->fsp.f_bfree) {
_alpm_log(handle, ALPM_LOG_ERROR,
_("Partition %s too full: %jd blocks needed, %ju blocks free\n"),
mp->mount_dir, (intmax_t)needed, (uintmax_t)mp->fsp.f_bfree);
return 1;
}
Are we supposed to switch the diskspace calculation to f_bavail?
Looks like all the real work is done in lib/fsusage.c
As a general rule of thumb applications should rely on the more pessimistic estimate f_bavail.
`man statvfs` says "It is unspecified whether all members of the returned struct have meaningful values on all filesystems."
According to irc, f_bfree's assumed meaning that it is greater because "space may be reserved for root" is not true for btrfs and these days and for some filesystems also includes free space for eg. filesystem-internal mechanisms.
It is reported to be always >= f_bavail because anything else would drive some applications crazy.
Btrfs updates metadata storage exhaustion only in f_bavail, and also gnu core utils run as root do their calculations using f_bavail.