Comment 6 for bug 635854

I don't think you are quite understanding the issue. I'm not (particularly) interested in pre-transaction space checks. (Although I would be somewhat interested to know how much space on /u rpm *thought* it needed before running the transaction - can I get yum to print that out?) In this case /var is a separate partition and it had plenty of space to download the rpms. The out of space condition happened while rpm was unpacking the files. I'm also partly to blame by setting my reserved block percentage on / to % so that there is no slop for rpm if it gets the calculation wrong (though perhaps it needs to be more conservative?)

What I am concerned about is that rpm apparently did not detect the out of space condition, it seems like it could have handled it better, and it did not report any errors back to yum. Instead of aborting the transaction (if possible?) after the first cpio write error, it kept plowing on. Also for unknown reasons packages that yum/rpm thought it upgraded were not in the rpm database after the transaction - which seems doubly strange since the rpm database was on a separate /var partition and unaffected by the out of space condition.