Update docs (#775)

* Update POSIX performance numbers
* Show output from fsck tool in README.

Author: AlCutter

cmd/fsck/README.md

@@ -16,10 +16,10 @@ It can be run with the following command:
 
 ```bash
 $ go run github.com/transparency-dev/tessera/cmd/fsck@main --storage_url=http://localhost:2024/ --public_key=tessera.pub
-I0519 12:48:18.776151   16532 fsck.go:61] Fsck: checking log of size 203150
-I0519 12:48:20.991727   16532 fsck.go:116] Successfully fsck'd log with size 203150 and root veoRTC8vvpl5VyXbG4mALWTBlz75rVKWKnSXoUX3UHU= (bdea114c2f2fbe99795725db1b89802d64c1973ef9ad52962a7497a145f75075)
 ```
 
+[!image](https://private-user-images.githubusercontent.com/7648032/490573648-7d06ffbb-acf6-4e2d-a1ef-7c848b58fb34.gif?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTgxMjk1NjUsIm5iZiI6MTc1ODEyOTI2NSwicGF0aCI6Ii83NjQ4MDMyLzQ5MDU3MzY0OC03ZDA2ZmZiYi1hY2Y2LTRlMmQtYTFlZi03Yzg0OGI1OGZiMzQuZ2lmP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDkxNyUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA5MTdUMTcxNDI1WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MjFhOGZiNDkxM2I5Zjg2ZmZmNjA0NjgzZWJmOTM5NTQ0MTEyYTQ0YzllZGFhZTAwYjc4ODcwZDYzYTUzYmRiNCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.FqR5NAJBVQUE5ulyEi5s09GhrRerGBUMCmnN3eSjwoI)
+
 Optional flags may be used to control the amount of parallelism used during the process, run the tool with `--help`
 for more details.
 

docs/performance.md

@@ -55,8 +55,29 @@ The table below shows some rough numbers of measured performance:
 
 ### POSIX
 
+Performance of the POSIX storage backend is highly dependent on the underlying infrastructure, some representative examples
+of the performance on different types of infratructure are given below.
+
 #### Local storage
 
+##### NVMe
+
+The log and hammer were both run in the same VM, with the log using a ZFS subvolume from the NVMe mirror.
+With antispam enabled, it was able to sustain around 10,000 write qps, using up to 7 cores for the server.
+
+```
+┌───────────────────────────────────────────────────────────────────────────┐
+│Read (8 workers): Current max: 20/s. Oversupply in last second: 0          │
+│Write (30000 workers): Current max: 10000/s. Oversupply in last second: 0  │
+│TreeSize: 5042936 (Δ 10567qps over 30s)                                    │
+│Time-in-queue: 1889ms/2990ms/3514ms (min/avg/max)                          │
+│Observed-time-to-integrate: 2255ms/3103ms/3607ms (min/avg/max)             │
+├───────────────────────────────────────────────────────────────────────────┤
+```
+
+
+##### SAS 12Gb HDD
+
 A single local instance on an 12-core VM with 8GB of RAM writing to local filesystem stored on a mirrored pair of SAS disks.
 
 Without antispam, it was able to sustain around 2900 writes/s.
@@ -90,7 +111,7 @@ A 4 node CephFS cluster (1 admin, 3x storage nodes) running on E2 nodes sustaine
 
 #### GCP Free Tier VM Instance
 
-A small `e2-micro` free-tier VM is able to sustain > 1500 writes/s.
+A small `e2-micro` free-tier VM is able to sustain > 1500 writes/s using a mounted PersistentDisk to store the log.
 
 > [!NOTE]
 > Virtual CPUs (vCPUs) in virtualized environments often share physical CPU cores with other vCPUs and introduce variability