fs/btrfs/block-group.c

23 #include "extent-tree.h"
153 		 * extent buffers, we could not do proper (and cheap) unaccounting
302  * Check if we can do a NOCOW write for a given extent.
305  * @bytenr:        Logical start address of the extent.
307  * Check if we can do a NOCOW write for the given extent, and increments the
308  * number of NOCOW writers in the block group that contains the extent, as long
347  * creating an ordered extent for a NOCOW write, to prevent races with scrub and
390 	 * some task might have had allocated an extent from it already, but it
391 	 * has not yet created a respective ordered extent (and added it to a
396 	 * the read access on that semaphore and creating the ordered extent.
435  * a free extent of a given size, but this is a good start.
566  * Get an arbitrary extent item index / max_index through the block group
616 		/* Success; sampled an extent item in the block group */
622 		/* We can't possibly find a valid extent item anymore */
642  * between a 100M extent and 100 contiguous 1M extents). So we need to read the
643  * file extent items. Reading all of them is quite wasteful, because usually
660  * In case 1, looking at any extent in the block group will yield the correct
664  * 3, we can either read every file extent, or admit that this is best effort
734 	 * extent for the extent root while also trying to search the extent
1227 	 * and the block group's item from the extent tree before marking the
1231 	 * the block group's extent map before the task calling this function
1232 	 * deletes the block group item from the extent tree, allowing for
1306 	 * 1 unit for deleting the block group item (located in the extent
1310 	 * N units for deleting N device extent items corresponding to each
2465 	 * Either no extent root (with ibadroots rescue option) or we have
2469 	 * This also allows new extent tree related changes to be RO compat,
2554 	 * We've hit some error while reading the extent tree, and have
2610 	struct btrfs_dev_extent *extent;
2624 	ret = btrfs_insert_empty_item(trans, root, path, &key, sizeof(*extent));
2629 	extent = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_dev_extent);
2630 	btrfs_set_dev_extent_chunk_tree(leaf, extent, BTRFS_CHUNK_TREE_OBJECTID);
2631 	btrfs_set_dev_extent_chunk_objectid(leaf, extent,
2633 	btrfs_set_dev_extent_chunk_offset(leaf, extent, chunk_offset);
2635 	btrfs_set_dev_extent_length(leaf, extent, num_bytes);
2669 	 * resulting in persisting a device extent item with such ID.
2747 		 * extent allocation only happens later. But often we don't
2752 		 * space or none at all (due to no need to COW, extent buffers
2778  * For extent tree v2 we use the block_group_item->chunk_offset to point at our
3405 			 * means its block group item isn't yet in the extent
3558 			 * finished yet (no block group item in the extent tree
3622 	/* An extent can not span multiple block groups. */
3859 	 *    for extent allocation.
3865 	 *    none of the block groups can be used for extent allocation since they
3885 	 *    allocate the last extent buffer we needed, a discard operation came
3935  *    group item to the extent btree and the device extent items to the devices
3939  * extent btree we are holding a write lock on the node's parent and if we
3941  * in the extent btree right way, we could deadlock because the path for the
3949  *    However later when the task actually tries to COW an extent buffer from
3950  *    the extent btree or from the device btree for example, it is forced to
3954  *    for allocating an extent and end up being forced to allocate a new one;
3959  *    groups might be suitable for extent allocation due to their incompatible
3962  *    when the task attempts to COW some extent buffer of the extent btree for
3968  *    it attempts to COW an extent buffer from the extent or device btree for
3969  *    example, it does not find any free extent in any metadata block group,
3976  *    tree extent buffers;
3979  *    before it tries to allocate the last extent buffer it needs, a discard
3988  * any of the block group items to the chunk, extent and device btrees. If we
4014  * an extent buffer from the chunks btree we never trigger allocation of a new
4016  * extent buffer of the chunk btree, first time before triggering the chunk
4060 	 * the chunk btree is attempting to COW an extent buffer while holding a
4063 	 * chunk mutex and we may need to access that extent buffer or its parent
4442 		 * extent buffers, we could not do proper (and cheap) unaccounting
4528  * Handle a block group allocating an extent in a size class