skiselkov commented on this pull request.
> + ASSERT(spa->spa_num_auto_trimming > 0); + spa->spa_num_auto_trimming--; + if (spa->spa_num_auto_trimming == 0) + cv_broadcast(&spa->spa_auto_trim_done_cv); + mutex_exit(&spa->spa_auto_trim_lock); +} + +/* + * Determines the minimum sensible rate at which a manual TRIM can be + * performed on a given spa and returns it. Since we perform TRIM in + * metaslab-sized increments, we'll just let the longest step between + * metaslab TRIMs be 100s (random number, really). Thus, on a typical + * 200-metaslab vdev, the longest TRIM should take is about 5.5 hours. + * It *can* take longer if the device is really slow respond to + * zio_trim() commands or it contains more than 200 metaslabs, or + * metaslab sizes vary widely between top-level vdevs. The "random number" part above explains that this was largely arbitrarily chosen. The point was to make it so that the user can't choose a rate which would make the timing algorithm wait for excessive amounts of time each step (although that really isn't a problem with how it's designed). I suppose any positive rate of trimming would be good enough. I just like when rates are reasonably constrained so the user can't set something completely asinine. I'll reword the comment to be more legible and remove the reference to the metaslab-sized trimming steps. And I'll also add the type of value returned. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/172#discussion_r116136379 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox-beta.com/groups/developer/ Powered by Topicbox: https://topicbox-beta.com
