the basic problem is that you have exactly what it mentioned, too many files (descriptors actually) open.

from the log, it looks like it went something like this:
-) file descriptor allocation error
-) cant open new files/sockets
-) race condition as process fights with itself for resources and consumes CPU cycles.
-) you kill it, and all the open files are left in an unknown state.

If you were bumping the file descriptor limit then there are likely close to that many file descriptors open that were not closed properly and the files themselves possibly became corrupt. Bit torrent requires that space be set aside up front, so there are really 2 possibilities (?)
1) the files existed and then were corrupted because they werent closed properly.
2) the files were allocated but the blocks never consumed with data so you really didnt lose anything.
Either way the differing file sizes between 'du' and 'ls' speak to this i believe. Superblock says the file is one size (ls reads file size without traversing inode list, right?) but when the actual inodes are summed by 'du' the total sizes dont match up. Pretty sure 'du' is the one you should believe here :(

SOLUTION:

Well you probably cant get the data back (if it existed) without considerable work. Copy the good sheep to a backup so you dont lose them again. Do a little research on the following:

1) 'ulimit' linux command
2) /etc/security/limits.conf file

there are limits on the number of multiple classes of resources a single user can consume for reasons but they can also be raised to reasonably high limits without consequence. the safe way is to just bump them a couple times for your user until the problem goes away. i think doubling them each time is reasonable.

The easy way is probably just to peg 'nofile' at something like 65535 and be done with it. It WILL amplify the consequences of a runaway process running under that user (since it will be able to consume MORE resources) but given processes that behave you should have no problems.

Before you change anything, run 'ulimit -n' and note the number for a starting point.