Lines Matching full:space
36 * Log Space Maps
38 * Log space maps are an optimization in ZFS metadata allocations for pools
42 * FREE records to almost every metaslab. With log space maps, we hold their
43 * changes in memory and log them altogether in one pool-wide space map on-disk
44 * for persistence. As more blocks are accumulated in the log space maps and
48 * flush any unflushed changes from memory to disk (i.e. the metaslab's space
49 * map) and saves import time by making old log space maps obsolete and
50 * eventually destroying them. [A log space map is said to be obsolete when all
51 * its entries have made it to their corresponding metaslab space maps].
56 * is activated when we create the first log space map and remains active
59 * pairs are of the form <key: txg, value: log space map object for that txg>.
60 * This entry is our on-disk reference of the log space maps that exist in
71 * to ignore any entries in the space map log that are for this metaslab but
76 * - A space map is created every TXG and, during that TXG, it is used to log
77 * all incoming changes (the log space map). When created, the log space map
79 * to the space map ZAP mentioned above. The log space map is closed at the
81 * know when a log space map has become obsolete by looking at the oldest
83 * than the log space map's TXG, then it means that there is no metaslab who
94 * oldest flushed metaslab to distinguish which log space maps have become
103 * counterpart of the space map ZAP mentioned above. It's an AVL tree whose
104 * nodes represent the log space maps in the pool. This in-memory
105 * representation of log space maps in the pool sorts the log space maps by
108 * space map:
112 * [2] The number of blocks of that space map. This field is used by the
121 * in each TXG by iterating over all the log space maps and looking at their
123 * iterate through each space map, minimizing the runtime overhead of the
147 * We try to keep the total number of blocks in the log space maps in check
150 * metaslabs too often as this would defeat the purpose of the log space map.
152 * acceptable for the log space maps to have and try not to cross it.
157 * and our history of log space map blocks. The main idea here is to answer
159 * at least an X amount of log space map blocks. We can answer this question
160 * by iterating backwards from the oldest log space map to the newest one
175 * This is used as the block size for the space maps used for the
176 * log space map feature. These space maps benefit from a bigger
201 * the log space maps. It is expressed as a percentage of the total number of
209 * less often can potentially lead to better utilization of the metaslab space
222 * say that, at any given time, about half of the entries in the whole space
224 * log space map, only one of them is valid and actually makes it to the
225 * metaslab's space map.
227 * 2] Each entry in the log space map is guaranteed to be two words while
228 * entries in metaslab space maps are generally single-word.
231 * account any consolidation of segments from the log space map to the
233 * then freed, then allocated again means 3 log space map entries but 0
234 * metaslab space map entries). Depending on the workload, we've seen ~1.8
235 * non-obsolete log space map entries per metaslab entry, for a total of
278 * creating log space maps and therefore we won't be flushing. On the other
358 * Ensure that the in-memory log space map structures and the summary
439 * while reading the log space maps.
452 * old log space maps. Since we can only destroy the oldest log space maps,
466 * metaslab and we destroyed the oldest log space map, more recent logs had 0
482 * metaslab will destroy all the log space maps older than its ms_unflushed_txg
488 * heuristics decided to do so). When that happens all the log space maps get
490 * any log blocks yet. As log space maps get destroyed with every metaslab that
492 * corner-case when we flush the last metaslab and the log space map of the
493 * current TXG is in the same summary entry with other log space maps that
500 * we close the syncing log space map). Thus we just decrement its current
556 * got an error while reading the log space maps.
792 * We need to generate a log space map before flushing because this
797 * That is not to say that we may generate a log space map when we
800 * not flushing, a log space map would have been created anyway in
808 * of log space map feature). We also decrement this as we flush
809 * metaslabs and attempt to destroy old log space maps.
868 * Close the log space map for this TXG and update the block counts
927 /* Free all log space maps older than the oldest_flushed_txg. */
986 * We pass UINT64_MAX as the space map's representation size
987 * and SPA_MINBLOCKSHIFT as the shift, to make the space map
999 * Find all the log space maps stored in the space map ZAP and sort
1013 /* the space map ZAP doesn't exist yet */
1101 * metaslab's space map, then ignore it. Note that we flush
1103 * the metaslab's space map only has entries from *before*
1138 * to read the log space maps.
1191 "Read %llu of %lu log space maps", (u_longlong_t)nsm,
1220 "Read %lu log space maps (%llu total blocks - blksz = %llu bytes) "
1241 * [1] recalculate their actual allocated space
1332 * Read all the log space map entries into their respective
1377 "Hard limit (upper-bound) in the size of the space map log "
1385 "Hard limit (upper-bound) in the size of the space map log "