Very cool. I just tried it on my own machine and got this (archlinux with lots and lots of python libraries/data junk):

Changed the command up a bit since it was including zero byte files and directories:

  sudo find / -size +0 -type f -ls | awk '{print $7,$NF}' > /tmp/filesizes
 110920 7
 111306 5
 111312 1
 111345 9
 111362 3
 130138 0
 130511 4
 131528 8
 139000 2
 152213 6

Some other interesting things (dirname is too slow...):

  cat filesizes | grep "6 " | awk '{print $NF}' | sed 's/\/[^/]*$//' | sort | uniq -c | sort -nr | head
   1607 /usr/share/man/man3
    906 /home/matt/.cache/mozilla/firefox/8jc2n3qa.default/cache2/entries
    825 /usr/bin
    808 /home/matt/.tmux/resurrect

Then again a lot of this is flawed because it's looking at /sys. Too lazy to fix it now :)

Any idea why 2 is so common? This same trend shows up on my system and seems to be caused by 102-byte files.

Good question. On OS X it seems the size of a directory is typically a multiple of 102 bytes (often 102 or 306). I ran my script again with "find / -type f" to select only regular files, and it showed file sizes ending in 2 being just slightly more common than 0. Odd sizes are still less common than even ones, though, so the overall conclusion is unchanged regardless of whether you consider checksumming of directory entries to be a valid application.

thx for the nice answer!