summaryrefslogtreecommitdiff
path: root/staging/mops_ext_arp.c
diff options
context:
space:
mode:
authorKen-ichirou MATSUZAWA <chamaken@gmail.com>2015-09-11 16:57:37 +0900
committerTobias Klauser <tklauser@distanz.ch>2015-09-15 10:47:37 +0200
commit67728607d5144cd36d056c4289c7e53f9113329a (patch)
tree7d259435a6dbde4ca70bb083df9705527117795f /staging/mops_ext_arp.c
parent4669e7a1ac2112b0e9ba7c0b865fdedffbb86055 (diff)
netsniff-ng: nlmsg: update pull size
It would be better to use NLMSG_HDRLEN instead of sizeof(*hdr) and not to use NLMSG_PAYLOAD to get payload length, I think. Signed-off-by: Ken-ichirou MATSUZAWA <chamas@h4.dion.ne.jp> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Diffstat (limited to 'staging/mops_ext_arp.c')
0 files changed, 0 insertions, 0 deletions
arches the device tree for extents belonging to the source device using the device tree's commit root --> 1st iteration finds extent belonging to block group A --> sets block group A to RO mode (btrfs_inc_block_group_ro) --> sets cursor left to found_key.offset which is 3Gb --> scrub_chunk() starts copies all allocated extents from block group's A stripe at source device into target device btrfs_alloc_chunk() --> allocates device extent in the range [4Gb, 5Gb[ from the source device for a new block group C extent allocated from block group C for a direct IO, buffered write or btree node/leaf extent is written to, perhaps in response to a writepages() call from the VM or directly through direct IO the write is made only against the source device and not against the target device because the extent's offset is in the interval [4Gb, 5Gb[ which is larger then the value of cursor_left (3Gb) --> scrub_chunks() finishes --> updates left cursor from 3Gb to 4Gb --> btrfs_dec_block_group_ro() sets block group A back to RW mode <we are still at transaction N> --> 2nd iteration finds extent belonging to block group B - it did not find the new extent in the range [4Gb, 5Gb[ for block group C because we are using the device tree's commit root or even because the block group's items are not all yet inserted in the respective btrees, that is, the block group is still attached to some transaction handle's new_bgs list and btrfs_create_pending_block_groups() was not called yet against that transaction handle, so the device extent items were not yet inserted into the devices tree <we are still at transaction N> --> so we end not copying anything from the newly allocated device extent from the source device to the target device So fix this by making __btrfs_map_block() always redirect writes to the target device as well, independently of the left cursor's value. With this change the left cursor is now used only for the purpose of tracking progress and allow a mount operation to resume a device replace. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com>
Diffstat