Tunable to allow block allocation even on degraded vdevs
|Assignee:||Sašo Kiselkov||% Done:|
|Category:||zfs - Zettabyte File System|
This patch introduces a new boolean tunable named "zfs_write_to_degraded" which allows administrators to override the default behavior of skipping degraded vdevs during writes.
This is a problem that's hurting us during a ZFS resilver. In multimedia streaming, read and write throughput of the storage pool must be carefully guarded, since multimedia systems are inherently real-time (or "DIRT" as Bryan Cantrill calls it). As such, when a resilver of a degraded vdev is performed, this needs to be done at a rather slow, predictable rate (to make sure it doesn't impact standard pool operation), however during all this time the pool might be taking in more writes (as new media is recorded). After a short while, this results in a very imbalanced pool, where the good vdevs contain essentially all the data and are nearly full, and the degraded (and slowly resilvering) vdev is mostly empty. Once resilver completes, the situation is reversed and the degraded vdev starts absorbing almost 100% of the write load, which in turn worsens as it will be later providing almost all of the reads for the media data stored there.
Needless to say, this results in some very unpredictable real-time parameters from the pool. Systems like that would prefer to rather continue writing to the degraded vdev, since the potential (and rather slim chance of) total loss of the data is much less of a problem than the persistent suckiness of pool performance that will inevitably follow a drive loss. "Either do it right, or don't do it at all" is the motto in real-time.
#2 Updated by Christopher Siden over 4 years ago
- % Done changed from 90 to 100
- Status changed from New to Closed
commit 9dc3941 Author: Sašo Kiselkov <email@example.com> Date: Tue Feb 5 11:15:10 2013 3507 Tunable to allow block allocation even on degraded vdevs Reviewed by: George Wilson <firstname.lastname@example.org> Reviewed by: Matthew Ahrens <email@example.com> Approved by: Christopher Siden <firstname.lastname@example.org>
Also available in: Atom