Since we know the spot in the RB tree where the split off extent is going, streamline the insertion process for the new extent. Just compile tested, it''s really a question of how deep trees are expected to be (quite deep, I''d suspect), and how often splits are done (have no clue). Anyways, just checking to see if this is worth pursuing... Alan
Possibly Parallel Threads
- [PATCH 2/3] btrfs: remove unnecessary -ENOMEM BUG_ON check in extent-tree.c/btrfs_alloc_logged_file_extent
- PATCH: btrfs defrag ioctl, override extent count and size checks compression enabled.
- [PATCH] Btrfs: cache extent state in find_delalloc_range
- Extent back references pushed to -unstable
- [PATCH] Btrfs: do not hold the write_lock on the extent tree while logging V2
Wisdom of the Ancients
