Difference between revisions of "ZFS on high latency devices"

Jump to navigation Jump to search
no edit summary
Line 18: Line 18:
* Larger blocks are better.
* Larger blocks are better.


A 128K average blocksize is ok for a receive-only pool, though 64K can be made
* * 64K Only suitable as a write-once or receive-only pool
to work adequately.  256K is better, and for a pool that directly takes non-zfs-receive writes, is probably the minimum size.
* * 128K Reasonable choice for a receive-only pool
512K would be better
* * 256K Very good choice for a receive-only pool, probably the minimum size for a pool taking TxG commit writes.
still.  Larger blocks are easier to merge during I/O processing but more importantly,
* * 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 dirty data space can also be a good thing provided that
* 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.


Editor
17

edits

Navigation menu