Editor
17
edits
Jlcampbell (talk | contribs) |
Jlcampbell (talk | contribs) |
||
Line 18: | Line 18: | ||
* Larger blocks are better. | * Larger blocks are better. | ||
* * 64K Only suitable as a write-once or receive-only pool | |||
* * 128K Reasonable choice for a receive-only pool | |||
512K | * * 256K Very good choice for a receive-only pool, probably the minimum size for a pool taking TxG commit writes. | ||
* * 512K and up: best choice for a TxG commit pool. | |||
Larger blocks are easier to merge during I/O processing but more importantly, | |||
they maintain more original data locality and fragment the pool less over time. Dealing with high | they maintain more original data locality and fragment the pool less over time. Dealing with high | ||
latency storage requires that we maximize our ability to merge our reads and writes. | latency storage requires that we maximize our ability to merge our reads and writes. | ||
Line 48: | Line 50: | ||
try a pool with logbias=throughput, the increased fragmentation will destroy read performance. | try a pool with logbias=throughput, the increased fragmentation will destroy read performance. | ||
* Lots of ARC is a good thing. | * Lots of ARC is a good thing. | ||
Lots of dirty data space can also be a good thing provided that | |||
dirty data stabilizes without hitting the maximum per-pool or the ARC limit. | dirty data stabilizes without hitting the maximum per-pool or the ARC limit. | ||