File descriptor leak + zero byte file leak on aggressive merge activity about bitcask

[slfritchie]

As @evanmcc pointed out in another forum, these files are cleaned out when the bitcask is reopened (e.g. on Riak restart), but their presence can slow down merge calculations if there are lots of them relative to non-empty casks.

[evanmcc]

I think the major expense here is actually in bitcask_fileops:create_file/2, and also perhaps fold and merge opens, since it'll list the entire directory when it tries to increment the counter and/or when it tries to get a fileset for the merge. I've added some logging to try and come to grips with the race, maybe I'll have some ideas soon.

[evanmcc]

NB. that you need to do -size 18c to see empty hintfiles.

What looks to me to be happening here is that this pathological case creates only live keys in a 1 or 2 data files at a time, so your merge set gets queued, and then not a single key in them is put into a data file because all of them have been overwritten.

I am not sure that there is a FD leak here. I am not certain how often this case would happen to customers, but I think that it's worth handling to at least make fixes for issues like #114 easier to test (PR incoming tomorrow or tuesday, BTW). My initial idea would just be to lazily create the write file on the first write, then if we never write we never create the file.