Btrfs: check pending chunks when shrinking fs to avoid corruption
authorFilipe Manana <fdmanana@suse.com>
Tue, 2 Jun 2015 13:43:21 +0000 (14:43 +0100)
committerChris Mason <clm@fb.com>
Wed, 3 Jun 2015 02:34:33 +0000 (19:34 -0700)
commit53e489bc8cd9dcfe95be3e422121539250aa8221
treeab5a68e1d87085c1795c8a4f1450c21ee07953fe
parent64ad6c488975d7516230cf7849190a991fd615ae
Btrfs: check pending chunks when shrinking fs to avoid corruption

When we shrink the usable size of a device (its total_bytes), we go over
all the device extent items in the device tree and attempt to relocate
the chunk of any device extent that goes beyond the new usable size for
the device. We do that after setting the new usable size (total_bytes) in
the device object, so that all new allocations (and reallocations) don't
use areas of the device that go beyond the new (shorter) size. However we
were not considering that before setting the new size in the device,
pending chunks might have been created that use device extents that go
beyond the new size, and those device extents are not yet in the device
tree after we search the device tree - they are still attached to the
list of new block group for some ongoing transaction handle, and they are
only added to the device tree when the transaction handle is ended (via
btrfs_create_pending_block_groups()).

So check for pending chunks with device extents that go beyond the new
size and if any exists, commit the current transaction and repeat the
search in the device tree.

Not doing this it would mean we would return success to user space while
still having extents that go beyond the new size, and later user space
could override those locations on the device while the fs still references
them, causing all sorts of corruption and unexpected events.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
fs/btrfs/volumes.c