Implement File Cache And Block Cache

[GGist]

Both of these are nice to haves, which should significantly speed up performance for users on a fast network (where disk transfer speed is the bottleneck, due to our implementation).

Two components that are required, FileHandleCache and ReadWriteCache. Each of these could implement FileSystem, and could take some inner object implementing FileSystem, that way, calls are forwarded on to the underlying FileSystem (like NativeFileSystem) when the cache doesn't have some entry and allows us to easily layer different FileSystems on top of one another.

Both of these will require us to support a new message, IDiskMessage::SyncTorrent(InfoHash). This will also create a new method, FileSystem::sync(Self::File), which will sync the contents of the file to disk. On NativeFileSystem, this could be a no-op (though we should decide if we should call fsync here...). For ReadWriteCache, this could flush any cached file contents to the underlying FileSystem, and for FileHandleCache, this could drop all of the file handles.

A separate thing which may be a nice feature in the future, would be to have different allocation methods for AddTorrent, implemented in terms of FileSystem:

• Full allocation (what we do currently, all files allocated fully with 0s filled in)
• Sparse allocation (uses OS sparse files to speed up AddTorrent)
• Block allocation (all torrent contents written to a single file, split to multiple files later)
  • Block allocation could actually be implemented on top of full allocation or sparse allocation, by just maintaining a mapping of file -> requested location, writing to a single file in the inner FileSystem, then untangling the files later (possibly when SyncTorrent is send to us)

Disk only benchmarks

Linux:

test benches::bench_native_fs_1_mb_pieces_128_kb_blocks ... bench:   2,122,092 ns/iter (+/- 137,163)
test benches::bench_native_fs_1_mb_pieces_16_kb_blocks  ... bench:   5,743,897 ns/iter (+/- 1,613,292)
test benches::bench_native_fs_1_mb_pieces_2_kb_blocks   ... bench:  26,742,021 ns/iter (+/- 11,962,446)

Windows (Antivirus Disabled):

test benches::bench_native_fs_1_mb_pieces_128_kb_blocks ... bench:   2,922,467 ns/iter (+/- 236,198)
test benches::bench_native_fs_1_mb_pieces_16_kb_blocks  ... bench:  22,277,612 ns/iter (+/- 3,752,197)
test benches::bench_native_fs_1_mb_pieces_2_kb_blocks   ... bench: 156,519,336 ns/iter (+/- 11,694,039)

Windows (Antivirus Enabled):

test benches::bench_native_fs_1_mb_pieces_128_kb_blocks ... bench:  39,069,596 ns/iter (+/- 8,133,512)
test benches::bench_native_fs_1_mb_pieces_16_kb_blocks  ... bench: 270,543,506 ns/iter (+/- 23,768,410)
test benches::bench_native_fs_1_mb_pieces_2_kb_blocks   ... bench: Too Damn Long!

Real world benchmarks

Windows Localhost (via Deluge):

Setup:
3.9GB Torrent
2MB Piece Size
16KB Block Size

Results (Best Timings):
200 MB/s Download
? (Reported 60MB/s Disk Activity)

[GGist]

I realize it probably doesnt make sense to call fsync in the case of NativeFileSystem, since we would have to open the file to do so (it wouldnt know about file handle caching upper layers...), and dropping any io::File handle should be good enough anyways.

[GGist]

Initial results, using just the FileHandleCache (no ReadWriteCache), networking is now our bottleneck again!

New real world benchmarks:

Setup:
3.9GB Torrent
2MB Piece Size
16KB Block Size

Results (Best Timings):
200 MB/s Download
? (Reported 200MB/s Disk Activity)