meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
linux:fs:zfs:tuning:hdd [2026/06/27 15:45] – niziaklinux:fs:zfs:tuning:hdd [2026/07/07 19:44] (current) – niziak
Line 2: Line 2:
  
 [[https://github.com/openzfs/zfs/discussions/14916|ZFS Send & RaidZ - Poor performance on HDD #14916]] [[https://github.com/openzfs/zfs/discussions/14916|ZFS Send & RaidZ - Poor performance on HDD #14916]]
 +
 +All ''zfs_vdev'' read/write parameters are for number of parallel requests to one vdev (i.e. for 2x HDD mirror it is for each HDD).
 +So for very slow 2xHDD mirror it is good to limit reads to 2 (2xHDD = 4 parallel reads), and write to 2.
  
 <code bash> <code bash>
Line 39: Line 42:
 </code> </code>
  
-Use of''bfq'' is mandatory. See [[#my_findings|my findings]].+<code bash> 
 +# zfs list 
 +rpool/data/vm-101-disk-0                       37.5G   854G  37.5G  - 
 +rpool/data/vm-101-disk-0-backup                41.9G   854G  41.9G  - 
 +</code> 
 + 
 +====== bfq ====== 
 + 
 +Use of''bfq'' is mandatory. See [[iosched#my_findings|my findings]]. 
 + 
 +====== prefetch ====== 
 + 
 +By default prefetech is enabled. Enabling it generates additional ''async'' reads. 
 + 
 +''/sys/module/zfs/parameters/zfs_prefetch_disable'' 
 +''/sys/module/zfs/parameters/zvol_prefetch_bytes'' 
 + 
 +NOTE: Disable it ! I was unable to peform full (dirty bitmap lost after restart) KVM backup to PBS due to huge sync read queue times (up to 25s) and backup times out with error. 
  
-===== SMR =====+====== SMR ======
  
   * SMR drives behaves correctly for sequential writes, but long working ZFS or LVM thin spread writes into lots of random location causing unusable IOPS. So never use SMR.   * SMR drives behaves correctly for sequential writes, but long working ZFS or LVM thin spread writes into lots of random location causing unusable IOPS. So never use SMR.