Arch Linux

CheckSpace already does this...

# 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.

Also, "git grep sizetotal" gives me no results. So where is that message coming from? Or is there a typo?

I use btrfs and /var/cache/pacma is inside /var that is a mountpoint (so a mountpoint inside a mounpoint) in a i686
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

Please post:

1) pacman.conf
2) /etc/fstab
3) a pacman log from the error happening with --debug

Pacman log using --debug comming on moonday, so I post the other 2 for now

defrag is know to be default in the stable btrfs (if reach it some time)

Not the pacman.log file. We need the output when running pacman with the --debug flag. And pacman.conf.

Both those will be much smaller than the pacman.log you just uploaded.

I bet a pony that the problem are btrfs metadata

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

debug: loading fsinfo for /var/cache/pacman
debug: partition /var/cache/pacman, needed 11990, cushion 5121, free 185216


Can you provide the output of "df -a"?

I win my pony?

/dev/sda6 7.0G 6.3G 0 100% /var/cache/pacman
and say 100% because btrfs not respect standards..or that I think

Do you have df aliased as "df -h"? Run "\df -a". I want to see block counts.

/dev/sda6 7340032 6599168 0 100% /var/cache/pacman
remmember btrfs + autodefrag, I run whitout autodefrag but no change in output

The available output from coreutils is correct. I guess we need to look at what they are doing differently for btrfs to calculate that.

so this is confirmed now?

and maybe metadata have influence here??

Ran into this issue on an RPi today running btrfs. Initial partition is 2G. Pacman attempted to install python and made it half way through before failed with a bunch of write errors.

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.

I was looking to btrfs faq and under 'Aaargh! My filesystem is full, and I've put almost nothing into it!' part there some info
https://btrfs.wiki.kernel.org/index.php/FAQ

I hope this could help to almos know why this happend

the difference seems clear to me:

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?

f_bavail is the amount available to an unprivileged user. pacman is running as root.

Looks like all the real work is done in lib/fsusage.c

I kicked off quite the discussion on freenode.net/#btrfs, interviewing them on the fact that they report some things only on f_bavail, for example in https://patchwork.kernel.org/patch/7367271/ .
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.