Bug 1102359

Both checks should already be done by rpm (inodes and space). Maybe rpm has the accounting wrong somewhere (I wouldn't be shocked it nobody had tested inodes running out in a long time).

Strangely, this bug is in response to a customer problem where further inquiry uncovered exactly the opposite problem: the transaction failed with a useful error message when they ran out of inodes, but failed without good messages similar to the above example when out of space.

I asked and we both had the same versions of yum and rpm:
# rpm -q yum rpm
yum-3.2.29-43.el6_5.noarch
rpm-4.8.0-37.el6.x86_64

I am not sure what to make of it.

Prior to rpm 4.11.x, the inode accounting is so broken "useless" doesn't begin to describe it: inodes are only accounted for .rpmnew|.rpmsave|.rpmorig files. So its technically possible to get the related error message, but you have to try fairly hard. And yes there are all sorts of situations where rpm gets the diskspace calculation wrong as well.

4.11.x is much better in this area but the accounting fixes rely on other fixes and changes that go too deep for backporting. I'd say CLOSED NEXTRELEASE.

Thanks for the explanation. I can certainly see how it would be tricky to do the proper accounting for space and inodes, and no matter what you do it will be less than perfect. 

If it works exactly as you described, though, it sounds like RPM will essentially not check for inodes on most new RPM installs (where it would not be likely to have conflicts with existing config files). It wasn't hard at all for me to reproduce at least. It seems to me that could be improved, if imperfectly, without having to "backport the world".

Even if not, would it be possible to improve the reporting of what happens when we either run out of space or inodes during a transaction? "error: unpacking of archive failed on file /opt/rh: cpio: mkdir" isn't a very friendly error message to customers, being several steps removed from the command they entered (yum install x y z...) and buried in output that just essentially reports "Failure" at the end. Anyone can understand that things fail sometimes, but it's really frustrating when they don't at at least fail *helpfully*. Regardless of how well RPM detects the problem beforehand, the net result is that the user will have to fix their resource usage, so that's what should be communicated. I recognize getting this to bubble up helpful information may be non-trivial, but it may be worth considering.

I certainly can't determine product priorities, but assuming the NEXTRELEASE you're referring to is RHEL 7, it seems a shame to leave this so "known broken" for the duration of RHEL 6.

Yes, inodes are practically unchecked, and that's how its been since 2001. Prior to that, rpm grossly overestimated the number of inodes needed, and the current situation was considered "a fix" according to the commit log. Considering this is the first time I've ever come across anybody running out of inodes (except for the sole purpose of testing what happens in that case), it doesn't seem a very common situation.

I missed the reference to bug 1102123 - if there's now a case where these things commonly happen, sure we can see if it can be mitigated without backporting half the world.

Implementing a proper accounting for inodes might be done upstream at some point. But there are severe doubts if such code could be ported back to RHEL-6. Closing this as WONTFIX. 

Still thanks for bringing this to our attention. This issue is tracked upstream at http://rpm.org/ticket/882