Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#33000 - [pacman] extend CheckSpace to check for available inodes
Attached to Project:
Pacman
Opened by Christian Hesse (eworm) - Friday, 07 December 2012, 08:52 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 03:51 GMT
Opened by Christian Hesse (eworm) - Friday, 07 December 2012, 08:52 GMT
Last edited by Allan McRae (Allan) - Saturday, 09 February 2013, 03:51 GMT
|
DetailsSummary and Info:
Enabling CheckSpace makes pacman check for free blocks, but it does not notice if filesystems run out of free inodes. Would be great if pacman could check for free inodes as well. |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 09 February 2013, 03:51 GMT
Reason for closing: Won't implement
Saturday, 09 February 2013, 03:51 GMT
Reason for closing: Won't implement
However, this gets a little bit tricky. For instance, nilfs returns "0" for free inodes (but gives you a correct number for total); btrfs reports 0 for both numbers. I'd be wary of adding filesystem-specific code here; I think we'd just skip inode checks completely if we saw a 0 in either place?
In my case I created Arch Linux live media, which has some directories split off into filesystems to share data for i686 and x86_64. When I hit the problem I tried to install a package with a lot of include files. Disk space was not a problem, but inodes were. (First I thought this is a problem of device mapper snapshots, took some time to find the real culprit.)
In the future I will switch to XFS which does not have an inode limitation. So I am fine if you close this with "won't fix", though I think this can be of real interest (for a small number of people).