diff options
author | Josef Bacik | 2015-03-13 20:01:24 +0100 |
---|---|---|
committer | Josef Bacik | 2015-03-17 21:28:21 +0100 |
commit | ba117213554bc747561c5b7bf274d60ac93b8598 (patch) | |
tree | baf4bb97cdf8edcf3397bef2030c9d458361c62b /virt/kvm/iodev.h | |
parent | Btrfs: prepare block group cache before writing (diff) | |
download | kernel-qcow2-linux-ba117213554bc747561c5b7bf274d60ac93b8598.tar.gz kernel-qcow2-linux-ba117213554bc747561c5b7bf274d60ac93b8598.tar.xz kernel-qcow2-linux-ba117213554bc747561c5b7bf274d60ac93b8598.zip |
Btrfs: account merges/splits properly
My fix
Btrfs: fix merge delalloc logic
only fixed half of the problems, it didn't fix the case where we have two large
extents on either side and then join them together with a new small extent. We
need to instead keep track of how many extents we have accounted for with each
side of the new extent, and then see how many extents we need for the new large
extent. If they match then we know we need to keep our reservation, otherwise
we need to drop our reservation. This shows up with a case like this
[BTRFS_MAX_EXTENT_SIZE+4K][4K HOLE][BTRFS_MAX_EXTENT_SIZE+4K]
Previously the logic would have said that the number extents required for the
new size (3) is larger than the number of extents required for the largest side
(2) therefore we need to keep our reservation. But this isn't the case, since
both sides require a reservation of 2 which leads to 4 for the whole range
currently reserved, but we only need 3, so we need to drop one of the
reservations. The same problem existed for splits, we'd think we only need 3
extents when creating the hole but in reality we need 4. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Diffstat (limited to 'virt/kvm/iodev.h')
0 files changed, 0 insertions, 0 deletions