skiselkov commented on this pull request.
> +
+ spa_config_enter(spa, SCL_STATE_ALL, FTAG, RW_READER);
+ ASSERT(vd->vdev_ms[0] != NULL);
+ cursor = vd->vdev_ms[0]->ms_start;
+ i = 0;
+ while (i < vti->vti_vdev->vdev_ms_count && !spa->spa_man_trim_stop) {
+ uint64_t delta;
+ metaslab_t *msp = vd->vdev_ms[i];
+ zio_t *trim_io;
+
+ trim_io = metaslab_trim_all(msp, &cursor, &delta, &was_loaded);
+ spa_config_exit(spa, SCL_STATE_ALL, FTAG);
+
+ if (trim_io != NULL) {
+ ASSERT3U(cursor, >=, vd->vdev_ms[0]->ms_start);
+ vd->vdev_trim_prog = cursor - vd->vdev_ms[0]->ms_start;
Here's the problem with this approach. If somebody writes new data to the pool
while we're trimming, some of the space we accounted in the `trim_prog` value
now becomes allocated, resulting in a reduction of free space (and therefore
our target). So it's possible for `trim_prog` to go over the total amount of
free space and zpool(1M) will report >100% progress. Consequently, freeing data
inflates the total amount of free space, so trim will finish before reaching
100%. Memorizing the free space value at the start of trim has similar problems.
Therefore I'd prefer to keep the progress indication as a simple proportion of
how much of the pool's vdevs has been passed.
--
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_r114586825
------------------------------------------
openzfs-developer
Archives: https://openzfs.topicbox-beta.com/groups/developer/
Powered by Topicbox: https://topicbox-beta.com
