summaryrefslogtreecommitdiffstats
path: root/fs/sync.c
diff options
context:
space:
mode:
authorMiao Xie <miaox@cn.fujitsu.com>2012-10-16 11:26:46 +0000
committerChris Mason <chris.mason@fusionio.com>2012-10-25 15:47:00 -0400
commit671415b7db49f62896f0b6d50fc4f312a0512983 (patch)
tree77ec90c39aa7fa567f2232e18a8c3440c16fd294 /fs/sync.c
parente515c18bfef718a7900924d50198d968565dd60e (diff)
downloadop-kernel-dev-671415b7db49f62896f0b6d50fc4f312a0512983.zip
op-kernel-dev-671415b7db49f62896f0b6d50fc4f312a0512983.tar.gz
Btrfs: fix deadlock caused by the nested chunk allocation
Steps to reproduce: # mkfs.btrfs -m raid1 <disk1> <disk2> # btrfstune -S 1 <disk1> # mount <disk1> <mnt> # btrfs device add <disk3> <disk4> <mnt> # mount -o remount,rw <mnt> # dd if=/dev/zero of=<mnt>/tmpfile bs=1M count=1 Deadlock happened. It is because of the nested chunk allocation. When we wrote the data into the filesystem, we would allocate the data chunk because there was no data chunk in the filesystem. At the end of the data chunk allocation, we should insert the metadata of the data chunk into the extent tree, but there was no raid1 chunk, so we tried to lock the chunk allocation mutex to allocate the new chunk, but we had held the mutex, the deadlock happened. By rights, we would allocate the raid1 chunk when we added the second device because the profile of the seed filesystem is raid1 and we had two devices. But we didn't do that in fact. It is because the last step of the first device insertion didn't commit the transaction. So when we added the second device, we didn't cow the tree, and just inserted the relative metadata into the leaves which were generated by the first device insertion, and its profile was dup. So, I fix this problem by commiting the transaction at the end of the first device insertion. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Diffstat (limited to 'fs/sync.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud