summaryrefslogtreecommitdiff
path: root/fs/btrfs/volumes.c
diff options
context:
space:
mode:
authorMiao Xie <miaox@cn.fujitsu.com>2014-11-06 12:20:58 +0300
committerMiao Xie <miaox@cn.fujitsu.com>2014-12-03 05:18:45 +0300
commit5a6ac9eacb49143cbad3bbfda72263101cb1f3df (patch)
treea3da74777b8ffe20edbcd47f2b3e7c8cb17918ac /fs/btrfs/volumes.c
parent1b94b5567e9c70ad3b24bd5e576a422246875c2a (diff)
downloadlinux-5a6ac9eacb49143cbad3bbfda72263101cb1f3df.tar.xz
Btrfs, raid56: support parity scrub on raid56
The implementation is: - Read and check all the data with checksum in the same stripe. All the data which has checksum is COW data, and we are sure that it is not changed though we don't lock the stripe. because the space of that data just can be reclaimed after the current transction is committed, and then the fs can use it to store the other data, but when doing scrub, we hold the current transaction, that is that data can not be recovered, it is safe that read and check it out of the stripe lock. - Lock the stripe - Read out all the data without checksum and parity The data without checksum and the parity may be changed if we don't lock the stripe, so we need read it in the stripe lock context. - Check the parity - Re-calculate the new parity and write back it if the old parity is not right - Unlock the stripe If we can not read out the data or the data we read is corrupted, we will try to repair it. If the repair fails. we will mark the horizontal sub-stripe(pages on the same horizontal) as corrupted sub-stripe, and we will skip the parity check and repair of that horizontal sub-stripe. And in order to skip the horizontal sub-stripe that has no data, we introduce a bitmap. If there is some data on the horizontal sub-stripe, we will the relative bit to 1, and when we check and repair the parity, we will skip those horizontal sub-stripes that the relative bits is 0. Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Diffstat (limited to 'fs/btrfs/volumes.c')
0 files changed, 0 insertions, 0 deletions