diff options
author | Liu Bo <bo.li.liu@oracle.com> | 2018-03-07 12:08:09 -0700 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2018-03-31 01:26:52 +0200 |
commit | 6ca1765b366e3a678e143de0decc3d1d39c15429 (patch) | |
tree | 07c31e4f1b9e27df77b5c7e5d1b433def9d77bb3 /fs/btrfs/extent_io.c | |
parent | 416a72022e43b4c1c5e144ec6af3f95870e8f71a (diff) |
Btrfs: scrub: batch rebuild for raid56
In case of raid56, writes and rebuilds always take BTRFS_STRIPE_LEN(64K)
as unit, however, scrub_extent() sets blocksize as unit, so rebuild
process may be triggered on every block on a same stripe.
A typical example would be that when we're replacing a disappeared disk,
all reads on the disks get -EIO, every block (size is 4K if blocksize is
4K) would go thru these,
scrub_handle_errored_block
scrub_recheck_block # re-read pages one by one
scrub_recheck_block # rebuild by calling raid56_parity_recover()
page by page
Although with raid56 stripe cache most of reads during rebuild can be
avoided, the parity recover calculation(xor or raid6 algorithms) needs to
be done $(BTRFS_STRIPE_LEN / blocksize) times.
This makes it smarter by doing raid56 scrub/replace on stripe length.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/extent_io.c')
0 files changed, 0 insertions, 0 deletions