If you are optimising for developer time, you are along the right tracks; if you choose a decent enough hashing algorithm, collisions should be extremely unlikely (see Yanis' link; but aside from those, people typically use MD5 or SHA1 for hashes, although MD5 is not recommended if you are security conscious). I would go with something that's available out of the box in your programming environment, since implementing and maintaining a hashing algorithm might not be worthwhile.
If you are worried about runtime performance, there are some things you can do to optimise the process. There are likely to be two areas which are slow - the reading in of all the data, and the actual hashing process itself. To give you an idea, most hash algorithms (even the slower, cryptographic ones) can typically go through a few hundred MB per second. So, unless you are using a (very fast) SSD, the bottleneck is more likely to be disk IO, so you should try to minimise that first.
One idea would be to group files by size first, and exclude any files with unique sizes. Then hash the first few kB of each remaining file, and using that to produce a list of potential matches (again, only compare against files of the exact same size). You would then only need to get the full hash of these potential matches, as opposed to every file on the drive. Depending on the exact characteristics of the drive, this may be faster than simply reading everything in (unless there are a very large number of duplicates, and we're wasting our time trying to exclude them - a worst case scenario). This should work fairly well for typical workloads, with more knowledge about the actual environment, you could probably tune it much more.