• Home
  • History
  • Annotate
  • Raw
  • Download
  • only in /freebsd-12-stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/

Lines Matching refs:space

167  * block allocations (SCL_ALLOC), which may require reading space maps
264 * in leaked space, or worse.
270 * blocks), space referenced by the missing metadata can not be freed.
273 * all remaining space to free from the error-encountering filesystem is
275 * permanently leak the space from indirect blocks that can not be read,
282 * space, with no leaks. However, note that this case is actually
291 * permanent, the best we can do is leak the minimum amount of space,
295 * leaking space in the "partial temporary" failure case.
323 * case the space requirement is exactly (VDEV_RAIDZ_MAXPARITY + 1)
397 * Normally, we don't allow the last 3.2% (1/(2^spa_slop_shift)) of space in
399 * completely out of space, due to unaccounted changes (e.g. to the MOS).
400 * It also limits the worst-case time to allocate space. If we have
401 * less than this amount of free space, most ZPL operations (e.g. write,
405 * use half the slop space. They will only return ENOSPC if less than half
406 * the slop space is free. Typically, once the pool has less than the slop
407 * space free, the user will use these operations to free up space in the pool.
411 * Operations that are almost guaranteed to free up space in the absence of
412 * a pool checkpoint can use up to three quarters of the slop space
416 * the amount of free space. These are the operations that call
418 * increase in the amount of space used, it is possible to run the pool
419 * completely out of space, causing it to be permanently read-only.
421 * Note that on very small pools, the slop space will be larger than
430 "Shift value of reserved space (1/(2^spa_slop_shift)).");
434 "Minimal value of reserved space");
479 * The percentage of special class final space reserved for metadata only.
494 "Percentage of space in the special class reserved solely for metadata");
1837 * Return the amount of slop space in bytes. It is 1/32 of the pool (3.2%),
1846 uint64_t space = spa_get_dspace(spa);
1847 return (MAX(space >> spa_slop_shift, MIN(space >> 1, spa_min_slop)));
1875 * how much space is allocated (it does its own tracking
1876 * of how much space has been logically used). So it
1991 uint64_t space = metaslab_class_get_space(special);
1993 (space * (100 - zfs_special_class_metadata_reserve_pct))
2504 * If there is a checkpoint, async destroys may consume more space from
2506 * getting suspended when it is about to run out of space, we stop