Patrick O'Callaghan wrote:
Just installed Azureus and tested it. It behaves exactly the same as Ktorrent, both with and without preallocation. This is hardly surprising as we're talking about how the filesystem works, not about about a specific application. As someone else pointed out, a inconsistency between the results of 'du' and 'df' can occur when a running process has an open file which has been unlinked, meaning the space occupied by the file has not yet been reclaimed even though the file no longer has a name. However, any inconsistency arising from this would be in the *opposite* direction to what the OP is seeing, i.e. less actual free space than accounted for by the filesystem size less the space occupied by (visible) files. In all of this I've been assuming that preallocation means what it has always meant traditionally in Unix/Linux: write garbage into the file to make sure disk space is allocated. It turns out the system can now do this for you, with the fallocate() call. However this is a very recent addition and people were still arguing about its semantics less than a year ago -- see http://lwn.net/Articles/240571. One detail stands out: with the correct parameter, the apparent size of the file (as reported by the stat() call) does not change, even if space is allocated beyond its end. The effect of this on 'df' and 'du' doesn't seem to be documented anywhere. Furthermore, although it's not explicitly stated, one presumes that the unused space is reclaimed when the file is closed, so the OP's question still stands: how can 'du' report more space than is being used, even if no processes have open files? For that matter, how can the system preallocate more space than the size of the filesystem? Doesn't make sense. BTW, it might be worth knowing what filesystem the OP is using. In my case it's ext3.
FWIW, the OP is probably happy to have his problem solved. Chances are he is running ext3 as most people take the default.
What would be more interesting would be to know what file system you are running.
Never say Never.... :-)
