Editor
17
edits
Difference between revisions of "ZFS on high latency devices"
Jump to navigation
Jump to search
m
no edit summary
Jlcampbell (talk | contribs) |
Jlcampbell (talk | contribs) m |
||
| Line 12: | Line 12: | ||
IOP size is possible. | IOP size is possible. | ||
--- | ------ | ||
There are a few requirements, though: | There are a few requirements, though: | ||
1. Larger blocks are better. A 128K blocksize is | 1. Larger blocks are better. A 128K average blocksize is ok for a receive-only pool, though 64K can be made | ||
to work adequately. 256K is better, and for a pool that directly takes non-zfs-receive writes, is probably the minimum size. | |||
512K would be better | |||
still. 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 126: | Line 128: | ||
sync taskq = 75 | sync taskq = 75 | ||
--- | ------ | ||
The approach taken works like this: | The approach taken works like this: | ||
| Line 159: | Line 161: | ||
the other max numbers are within 4 threads of SRmax | the other max numbers are within 4 threads of SRmax | ||
--- | ------ | ||
If AW dominates, decrease zfs_sync_taskq_batch_pct. | If AW dominates, decrease zfs_sync_taskq_batch_pct. | ||