Provide fuse.EEXIST error
Add simple read and write benchmarks

No-op bazil.org/fuse on Linux v3.13 can write at ~70 MB/s and read at
~800 MB/s with kernel caching + readahead, ~115 MB/s without. Future
work will improve these numbers.

Single-core benchmarks are omitted because that would make the client
compete with the FUSE logic on that single core.

For these workloads, going from 2 cores to 4 cores helps a little, but
4 to 8 is not a meaningful improvement. If the application logic in
the FUSE methods took more CPU time, there would still be benefit to
using even more cores, but this benchmark explicitly does minimal work
there.

The `BenchmarkWriteSync` variants call fsync(2) at end of every `b.N`
iteration, forcing the kernel page cache to flush the data to the FUSE
server. As the benchmark filesystem does nothing on fsync, that is the
only effect.

For these workloads, the cost of flushing data from the page cache to
the FUSE server is mostly in the <=20% range. Note that Linux v3.13
only has a writethrough cache for FUSE, not a writeback one. These
workloads also do not do overwrites, giving the kernel no opportunity
for write coalescing.

The measurements are well within one magnitude of similar,
independent, benchmarks done with the `fio` tool, and hence seem
trustworthy enough to measure future progress against.

On OS X, the benchmark process hangs, sometimes staying in the P_WEXIT
state for a long time, sometimes causing system-wide problems such as
`ps` hanging. The cause is still unknown, but it's clear that OSXFUSE
and/or the kernel should do a better job of protecting themselves.

Full results from a run on a fairly high-end desktop Linux machine:

$ go test ./fs/bench -test.run=- -test.bench=. -test.benchmem -test.benchtime=10s -test.timeout=20m -test.cpu=2,4,8
PASS
BenchmarkWrite100-2	  200000	    144286 ns/op	   0.69 MB/s	   50284 B/op	      19 allocs/op
BenchmarkWrite100-4	  100000	    151684 ns/op	   0.66 MB/s	   50328 B/op	      20 allocs/op
BenchmarkWrite100-8	  200000	    161905 ns/op	   0.62 MB/s	   50337 B/op	      20 allocs/op
BenchmarkWrite10MB-2	     100	 178506562 ns/op	  58.74 MB/s	24827052 B/op	   22519 allocs/op
BenchmarkWrite10MB-4	     100	 154929857 ns/op	  67.68 MB/s	24847544 B/op	   22676 allocs/op
BenchmarkWrite10MB-8	     100	 157978919 ns/op	  66.37 MB/s	24863971 B/op	   22761 allocs/op
BenchmarkWrite100MB-2	      10	1750102146 ns/op	  59.92 MB/s	247968886 B/op	  225145 allocs/op
BenchmarkWrite100MB-4	      10	1457782389 ns/op	  71.93 MB/s	248155160 B/op	  226609 allocs/op
BenchmarkWrite100MB-8	      10	1916572219 ns/op	  54.71 MB/s	248327718 B/op	  227501 allocs/op
BenchmarkDirectWrite100-2	  200000	     77629 ns/op	   1.29 MB/s	   41403 B/op	       9 allocs/op
BenchmarkDirectWrite100-4	  200000	     86154 ns/op	   1.16 MB/s	   41415 B/op	       9 allocs/op
BenchmarkDirectWrite100-8	  200000	     97743 ns/op	   1.02 MB/s	   41423 B/op	       9 allocs/op
BenchmarkDirectWrite10MB-2	     100	 153961665 ns/op	  68.11 MB/s	22055315 B/op	   19294 allocs/op
BenchmarkDirectWrite10MB-4	     100	 139884057 ns/op	  74.96 MB/s	22063725 B/op	   19361 allocs/op
BenchmarkDirectWrite10MB-8	     100	 152220647 ns/op	  68.89 MB/s	22076601 B/op	   19448 allocs/op
BenchmarkDirectWrite100MB-2	      10	1530952783 ns/op	  68.49 MB/s	220279283 B/op	  193026 allocs/op
BenchmarkDirectWrite100MB-4	      10	1383443858 ns/op	  75.79 MB/s	220340728 B/op	  193587 allocs/op
BenchmarkDirectWrite100MB-8	      10	1493149687 ns/op	  70.23 MB/s	220426796 B/op	  194186 allocs/op
BenchmarkWriteSync100-2	  100000	    209246 ns/op	   0.48 MB/s	   58836 B/op	      26 allocs/op
BenchmarkWriteSync100-4	  100000	    212820 ns/op	   0.47 MB/s	   58877 B/op	      27 allocs/op
BenchmarkWriteSync100-8	  100000	    229600 ns/op	   0.44 MB/s	   58891 B/op	      27 allocs/op
BenchmarkWriteSync10MB-2	     100	 191125937 ns/op	  54.86 MB/s	24835754 B/op	   22535 allocs/op
BenchmarkWriteSync10MB-4	     100	 163408540 ns/op	  64.17 MB/s	24853532 B/op	   22670 allocs/op
BenchmarkWriteSync10MB-8	     100	 183457765 ns/op	  57.16 MB/s	24869030 B/op	   22746 allocs/op
BenchmarkWriteSync100MB-2	      10	1880491415 ns/op	  55.76 MB/s	248025161 B/op	  225501 allocs/op
BenchmarkWriteSync100MB-4	      10	1805255368 ns/op	  58.08 MB/s	248152068 B/op	  226532 allocs/op
BenchmarkWriteSync100MB-8	      10	1879016696 ns/op	  55.80 MB/s	248292755 B/op	  227263 allocs/op
BenchmarkRead100-2	20000000	       970 ns/op	 103.02 MB/s	     245 B/op	       1 allocs/op
BenchmarkRead100-4	20000000	       920 ns/op	 108.61 MB/s	     245 B/op	       1 allocs/op
BenchmarkRead100-8	20000000	       990 ns/op	 100.91 MB/s	     245 B/op	       1 allocs/op
BenchmarkRead10MB-2	    1000	  20389413 ns/op	 514.27 MB/s	22317186 B/op	     823 allocs/op
BenchmarkRead10MB-4	    2000	  12235394 ns/op	 857.00 MB/s	22319790 B/op	     844 allocs/op
BenchmarkRead10MB-8	    1000	  17639019 ns/op	 594.46 MB/s	22323362 B/op	     871 allocs/op
BenchmarkRead100MB-2	     100	 200610078 ns/op	 522.69 MB/s	223171771 B/op	    8223 allocs/op
BenchmarkRead100MB-4	     100	 127667214 ns/op	 821.34 MB/s	223192353 B/op	    8386 allocs/op
BenchmarkRead100MB-8	     100	 178205386 ns/op	 588.41 MB/s	223229375 B/op	    8677 allocs/op
BenchmarkDirectRead100-2	  200000	     65861 ns/op	   1.52 MB/s	    8881 B/op	      11 allocs/op
BenchmarkDirectRead100-4	  500000	     58419 ns/op	   1.71 MB/s	    8883 B/op	      11 allocs/op
BenchmarkDirectRead100-8	  500000	     58641 ns/op	   1.71 MB/s	    8888 B/op	      11 allocs/op
BenchmarkDirectRead10MB-2	     200	  95833698 ns/op	 109.42 MB/s	32321373 B/op	   12878 allocs/op
BenchmarkDirectRead10MB-4	     200	  91996191 ns/op	 113.98 MB/s	32324582 B/op	   12900 allocs/op
BenchmarkDirectRead10MB-8	     100	 113746045 ns/op	  92.19 MB/s	32326392 B/op	   12913 allocs/op
BenchmarkDirectRead100MB-2	      20	 887960183 ns/op	 118.09 MB/s	323213244 B/op	  128771 allocs/op
BenchmarkDirectRead100MB-4	      20	 939794177 ns/op	 111.58 MB/s	323244247 B/op	  128986 allocs/op
BenchmarkDirectRead100MB-8	      20	 908678404 ns/op	 115.40 MB/s	323264908 B/op	  129153 allocs/op
ok  	bazil.org/fuse/fs/bench	903.297s
Use argument names in interface definitions

This makes https://github.com/josharian/impl much more pleasant to
use, and is just more intuitive.

Prefer `req` over `r` to avoid confusion with response.
Clarify StatfsResponse.Frsize meaning

Fixes #23
Typo in godoc
Add known values for InitFlags
Saner identifiers for kernel receive buffer size limits
Enforce outgoing InitResponse.MaxWrite values to fit in buffer
Pass kernel receive buffer size as OS X mount option `iosize`
Increase kernel receive buffer size to 128 KiB
Use the 128 KiB kernel receive buffer; set fuse.InitBigWrites

This is not directly tied to the constant because of package
boundaries. This FSIniter API will change to remove this wart.
FSIniter godoc was stale and wrong
Document InitRequest, InitResponse MaxWrite behavior
Add consts for open flags, including O_ACCMODE, and provide helper functions

O_ACCMODE has been confusing to people, and only exported by syscall.
Export it here for ease of discovery.

As O_RDONLY etc tests are easy to get wrong, if you mistakenly think
they are 1-bit flags, provide convenience methods like IsReadOnly().

We choose to go with Go-style names for the constants, instead of
the original C-style O_FOO names.
Use OpenFlag constants internally
Use the Go naming for OpenFlags constants consistently
Remove unused constant
Guard against a race in fuse.Conn.dev use vs close

`net.Conn` guarantees it's safe to use concurrently; `*os.File` does
not. My bad. Guard against writers with the existing `wio` lock. Add
analogous `rio` where readers can co-exist (let kernel decide who gets
next message), but closing excludes all readers.

Note that closing an `*os.File` does not wake up blocked readers, as
it would on a `net.Conn`, so the fact that fuse.Conn.Close waits for
readers to complete to get the lock does not really matter. Hangs
migrate from `ReadRequest` to `fuse.Conn.rio.Lock`. The correct way to
ensure `ReadRequest` returns is to tell the kernel to close the
device; that's done by unmounting the file system.

fixes #37
Document rules for debug functions
Document ReadRequest behavior dictated by kernel.

OSXFUSE will close /dev/fuse on a timeout, so each request must be
promptly responded to. Linux is more lenient.

All platforms require exactly one response to every request.