ahrens 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;
Yeah, that downside is shared with e.g. the scrub code (see `scn_to_examine`
and `scn_examined`). I guess the tradeoff is between something that goes
relatively smoothly from 0% -> around 100%, and can therefore be used to
estimate when it'll be done, vs something that advances in jumps and spurts
from 0%-> exactly 100%, and (at least for some pools) won't be useful for
estimating when it'll complete.
--
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_r116117943
------------------------------------------
openzfs-developer
Archives: https://openzfs.topicbox-beta.com/groups/developer/
Powered by Topicbox: https://topicbox-beta.com
