2018-04-04 01:23:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2012 Fusion-io All rights reserved.
|
|
|
|
* Copyright (C) 2012 Intel Corp. All rights reserved.
|
|
|
|
*/
|
2018-04-04 01:23:33 +08:00
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/bio.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/raid/pq.h>
|
|
|
|
#include <linux/hash.h>
|
|
|
|
#include <linux/list_sort.h>
|
|
|
|
#include <linux/raid/xor.h>
|
2017-06-01 00:40:02 +08:00
|
|
|
#include <linux/mm.h>
|
2022-10-19 22:50:49 +08:00
|
|
|
#include "messages.h"
|
2021-03-16 18:04:01 +08:00
|
|
|
#include "misc.h"
|
2013-01-30 07:40:14 +08:00
|
|
|
#include "ctree.h"
|
|
|
|
#include "disk-io.h"
|
|
|
|
#include "volumes.h"
|
|
|
|
#include "raid56.h"
|
|
|
|
#include "async-thread.h"
|
2022-11-14 08:26:33 +08:00
|
|
|
#include "file-item.h"
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
#include "btrfs_inode.h"
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
/* set when additional merges to this rbio are not allowed */
|
|
|
|
#define RBIO_RMW_LOCKED_BIT 1
|
|
|
|
|
2013-02-01 03:42:09 +08:00
|
|
|
/*
|
|
|
|
* set when this rbio is sitting in the hash, but it is just a cache
|
|
|
|
* of past RMW
|
|
|
|
*/
|
|
|
|
#define RBIO_CACHE_BIT 2
|
|
|
|
|
|
|
|
/*
|
|
|
|
* set when it is safe to trust the stripe_pages for caching
|
|
|
|
*/
|
|
|
|
#define RBIO_CACHE_READY_BIT 3
|
|
|
|
|
|
|
|
#define RBIO_CACHE_SIZE 1024
|
|
|
|
|
2019-08-22 01:06:17 +08:00
|
|
|
#define BTRFS_STRIPE_HASH_TABLE_BITS 11
|
|
|
|
|
|
|
|
/* Used by the raid56 code to lock stripes for read/modify/write */
|
|
|
|
struct btrfs_stripe_hash {
|
|
|
|
struct list_head hash_list;
|
|
|
|
spinlock_t lock;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Used by the raid56 code to lock stripes for read/modify/write */
|
|
|
|
struct btrfs_stripe_hash_table {
|
|
|
|
struct list_head stripe_cache;
|
|
|
|
spinlock_t cache_lock;
|
|
|
|
int cache_size;
|
|
|
|
struct btrfs_stripe_hash table[];
|
|
|
|
};
|
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
/*
|
|
|
|
* A bvec like structure to present a sector inside a page.
|
|
|
|
*
|
|
|
|
* Unlike bvec we don't need bvlen, as it's fixed to sectorsize.
|
|
|
|
*/
|
|
|
|
struct sector_ptr {
|
|
|
|
struct page *page;
|
2022-04-01 19:23:20 +08:00
|
|
|
unsigned int pgoff:24;
|
|
|
|
unsigned int uptodate:8;
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
};
|
|
|
|
|
2022-11-01 19:16:09 +08:00
|
|
|
static void rmw_rbio_work(struct work_struct *work);
|
|
|
|
static void rmw_rbio_work_locked(struct work_struct *work);
|
2013-01-30 07:40:14 +08:00
|
|
|
static void index_rbio_pages(struct btrfs_raid_bio *rbio);
|
|
|
|
static int alloc_rbio_pages(struct btrfs_raid_bio *rbio);
|
|
|
|
|
2022-11-01 19:16:11 +08:00
|
|
|
static int finish_parity_scrub(struct btrfs_raid_bio *rbio, int need_check);
|
|
|
|
static void scrub_rbio_work_locked(struct work_struct *work);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-10-10 18:36:09 +08:00
|
|
|
static void free_raid_bio_pointers(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
bitmap_free(rbio->error_bitmap);
|
2022-10-10 18:36:09 +08:00
|
|
|
kfree(rbio->stripe_pages);
|
|
|
|
kfree(rbio->bio_sectors);
|
|
|
|
kfree(rbio->stripe_sectors);
|
|
|
|
kfree(rbio->finish_pointers);
|
|
|
|
}
|
|
|
|
|
2022-10-10 18:36:08 +08:00
|
|
|
static void free_raid_bio(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!refcount_dec_and_test(&rbio->refs))
|
|
|
|
return;
|
|
|
|
|
|
|
|
WARN_ON(!list_empty(&rbio->stripe_cache));
|
|
|
|
WARN_ON(!list_empty(&rbio->hash_list));
|
|
|
|
WARN_ON(!bio_list_empty(&rbio->bio_list));
|
|
|
|
|
|
|
|
for (i = 0; i < rbio->nr_pages; i++) {
|
|
|
|
if (rbio->stripe_pages[i]) {
|
|
|
|
__free_page(rbio->stripe_pages[i]);
|
|
|
|
rbio->stripe_pages[i] = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
btrfs_put_bioc(rbio->bioc);
|
2022-10-10 18:36:09 +08:00
|
|
|
free_raid_bio_pointers(rbio);
|
2022-10-10 18:36:08 +08:00
|
|
|
kfree(rbio);
|
|
|
|
}
|
|
|
|
|
2022-04-18 12:43:11 +08:00
|
|
|
static void start_async_work(struct btrfs_raid_bio *rbio, work_func_t work_func)
|
2018-06-29 16:56:56 +08:00
|
|
|
{
|
2022-04-18 12:43:11 +08:00
|
|
|
INIT_WORK(&rbio->work, work_func);
|
|
|
|
queue_work(rbio->bioc->fs_info->rmw_workers, &rbio->work);
|
2018-06-29 16:56:56 +08:00
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* the stripe hash table is used for locking, and to collect
|
|
|
|
* bios in hopes of making a full stripe
|
|
|
|
*/
|
|
|
|
int btrfs_alloc_stripe_hash_table(struct btrfs_fs_info *info)
|
|
|
|
{
|
|
|
|
struct btrfs_stripe_hash_table *table;
|
|
|
|
struct btrfs_stripe_hash_table *x;
|
|
|
|
struct btrfs_stripe_hash *cur;
|
|
|
|
struct btrfs_stripe_hash *h;
|
|
|
|
int num_entries = 1 << BTRFS_STRIPE_HASH_TABLE_BITS;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (info->stripe_hash_table)
|
|
|
|
return 0;
|
|
|
|
|
2013-03-01 23:03:00 +08:00
|
|
|
/*
|
|
|
|
* The table is large, starting with order 4 and can go as high as
|
|
|
|
* order 7 in case lock debugging is turned on.
|
|
|
|
*
|
|
|
|
* Try harder to allocate and fallback to vmalloc to lower the chance
|
|
|
|
* of a failing mount.
|
|
|
|
*/
|
2019-03-29 09:07:02 +08:00
|
|
|
table = kvzalloc(struct_size(table, table, num_entries), GFP_KERNEL);
|
2017-06-01 00:40:02 +08:00
|
|
|
if (!table)
|
|
|
|
return -ENOMEM;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2013-02-01 03:42:09 +08:00
|
|
|
spin_lock_init(&table->cache_lock);
|
|
|
|
INIT_LIST_HEAD(&table->stripe_cache);
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
h = table->table;
|
|
|
|
|
|
|
|
for (i = 0; i < num_entries; i++) {
|
|
|
|
cur = h + i;
|
|
|
|
INIT_LIST_HEAD(&cur->hash_list);
|
|
|
|
spin_lock_init(&cur->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
x = cmpxchg(&info->stripe_hash_table, NULL, table);
|
2021-01-21 16:19:47 +08:00
|
|
|
kvfree(x);
|
2013-01-30 07:40:14 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-02-01 03:42:09 +08:00
|
|
|
/*
|
|
|
|
* caching an rbio means to copy anything from the
|
2022-04-01 19:23:27 +08:00
|
|
|
* bio_sectors array into the stripe_pages array. We
|
2013-02-01 03:42:09 +08:00
|
|
|
* use the page uptodate bit in the stripe cache array
|
|
|
|
* to indicate if it has valid data
|
|
|
|
*
|
|
|
|
* once the caching is done, we set the cache ready
|
|
|
|
* bit.
|
|
|
|
*/
|
|
|
|
static void cache_rbio_pages(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = alloc_rbio_pages(rbio);
|
|
|
|
if (ret)
|
|
|
|
return;
|
|
|
|
|
2022-04-01 19:23:20 +08:00
|
|
|
for (i = 0; i < rbio->nr_sectors; i++) {
|
|
|
|
/* Some range not covered by bio (partial write), skip it */
|
btrfs: raid56: make it more explicit that cache rbio should have all its data sectors uptodate
For Btrfs RAID56, we have a caching system for btrfs raid bios (rbio).
We call cache_rbio_pages() to mark a qualified rbio ready for cache.
The timing happens at:
- finish_rmw()
At this timing, we have already read all necessary sectors, along with
the rbio sectors, we have covered all data stripes.
- __raid_recover_end_io()
At this timing, we have rebuild the rbio, thus all data sectors
involved (either from stripe or bio list) are uptodate now.
Thus at the timing of cache_rbio_pages(), we should have all data
sectors uptodate.
This patch will make it explicit that all data sectors are uptodate at
cache_rbio_pages() timing, mostly to prepare for the incoming
verification at RMW time.
This patch will add:
- Extra ASSERT()s in cache_rbio_pages()
This is to make sure all data sectors, which are not covered by bio,
are already uptodate.
- Extra ASSERT()s in steal_rbio()
Since only cached rbio can be stolen, thus every data sector should
already be uptodate in the source rbio.
- Update __raid_recover_end_io() to update recovered sector->uptodate
Previously __raid_recover_end_io() will only mark failed sectors
uptodate if it's doing an RMW.
But this can trigger new ASSERT()s, as for recovery case, a recovered
failed sector will not be marked uptodate, and trigger ASSERT() in
later cache_rbio_pages() call.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-10-10 18:36:10 +08:00
|
|
|
if (!rbio->bio_sectors[i].page) {
|
|
|
|
/*
|
|
|
|
* Even if the sector is not covered by bio, if it is
|
|
|
|
* a data sector it should still be uptodate as it is
|
|
|
|
* read from disk.
|
|
|
|
*/
|
|
|
|
if (i < rbio->nr_data * rbio->stripe_nsectors)
|
|
|
|
ASSERT(rbio->stripe_sectors[i].uptodate);
|
2022-04-01 19:23:20 +08:00
|
|
|
continue;
|
btrfs: raid56: make it more explicit that cache rbio should have all its data sectors uptodate
For Btrfs RAID56, we have a caching system for btrfs raid bios (rbio).
We call cache_rbio_pages() to mark a qualified rbio ready for cache.
The timing happens at:
- finish_rmw()
At this timing, we have already read all necessary sectors, along with
the rbio sectors, we have covered all data stripes.
- __raid_recover_end_io()
At this timing, we have rebuild the rbio, thus all data sectors
involved (either from stripe or bio list) are uptodate now.
Thus at the timing of cache_rbio_pages(), we should have all data
sectors uptodate.
This patch will make it explicit that all data sectors are uptodate at
cache_rbio_pages() timing, mostly to prepare for the incoming
verification at RMW time.
This patch will add:
- Extra ASSERT()s in cache_rbio_pages()
This is to make sure all data sectors, which are not covered by bio,
are already uptodate.
- Extra ASSERT()s in steal_rbio()
Since only cached rbio can be stolen, thus every data sector should
already be uptodate in the source rbio.
- Update __raid_recover_end_io() to update recovered sector->uptodate
Previously __raid_recover_end_io() will only mark failed sectors
uptodate if it's doing an RMW.
But this can trigger new ASSERT()s, as for recovery case, a recovered
failed sector will not be marked uptodate, and trigger ASSERT() in
later cache_rbio_pages() call.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-10-10 18:36:10 +08:00
|
|
|
}
|
2022-04-01 19:23:20 +08:00
|
|
|
|
|
|
|
ASSERT(rbio->stripe_sectors[i].page);
|
|
|
|
memcpy_page(rbio->stripe_sectors[i].page,
|
|
|
|
rbio->stripe_sectors[i].pgoff,
|
|
|
|
rbio->bio_sectors[i].page,
|
|
|
|
rbio->bio_sectors[i].pgoff,
|
|
|
|
rbio->bioc->fs_info->sectorsize);
|
|
|
|
rbio->stripe_sectors[i].uptodate = 1;
|
|
|
|
}
|
2013-02-01 03:42:09 +08:00
|
|
|
set_bit(RBIO_CACHE_READY_BIT, &rbio->flags);
|
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* we hash on the first logical address of the stripe
|
|
|
|
*/
|
|
|
|
static int rbio_bucket(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
2023-02-17 13:37:03 +08:00
|
|
|
u64 num = rbio->bioc->full_stripe_logical;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* we shift down quite a bit. We're using byte
|
|
|
|
* addressing, and most of the lower bits are zeros.
|
|
|
|
* This tends to upset hash_64, and it consistently
|
|
|
|
* returns just one or two different values.
|
|
|
|
*
|
|
|
|
* shifting off the lower bits fixes things.
|
|
|
|
*/
|
|
|
|
return hash_64(num >> 16, BTRFS_STRIPE_HASH_TABLE_BITS);
|
|
|
|
}
|
|
|
|
|
2022-04-01 19:23:29 +08:00
|
|
|
static bool full_page_sectors_uptodate(struct btrfs_raid_bio *rbio,
|
|
|
|
unsigned int page_nr)
|
|
|
|
{
|
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
|
|
|
const u32 sectors_per_page = PAGE_SIZE / sectorsize;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
ASSERT(page_nr < rbio->nr_pages);
|
|
|
|
|
|
|
|
for (i = sectors_per_page * page_nr;
|
|
|
|
i < sectors_per_page * page_nr + sectors_per_page;
|
|
|
|
i++) {
|
|
|
|
if (!rbio->stripe_sectors[i].uptodate)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
/*
|
|
|
|
* Update the stripe_sectors[] array to use correct page and pgoff
|
|
|
|
*
|
|
|
|
* Should be called every time any page pointer in stripes_pages[] got modified.
|
|
|
|
*/
|
|
|
|
static void index_stripe_sectors(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
|
|
|
u32 offset;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0, offset = 0; i < rbio->nr_sectors; i++, offset += sectorsize) {
|
|
|
|
int page_index = offset >> PAGE_SHIFT;
|
|
|
|
|
|
|
|
ASSERT(page_index < rbio->nr_pages);
|
|
|
|
rbio->stripe_sectors[i].page = rbio->stripe_pages[page_index];
|
|
|
|
rbio->stripe_sectors[i].pgoff = offset_in_page(offset);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
btrfs: update stripe_sectors::uptodate in steal_rbio
[BUG]
With added debugging, it turns out the following write sequence would
cause extra read which is unnecessary:
# xfs_io -f -s -c "pwrite -b 32k 0 32k" -c "pwrite -b 32k 32k 32k" \
-c "pwrite -b 32k 64k 32k" -c "pwrite -b 32k 96k 32k" \
$mnt/file
The debug message looks like this (btrfs header skipped):
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=0 physical=323026944 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=32768 physical=22052864 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=0 physical=22020096 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=0 physical=277872640 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
^^^^
Still partial read, even 389152768 is already cached by the first.
write.
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=0 physical=22020096 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
^^^^
Still partial read for 298844160.
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=32768 physical=22052864 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=32768 physical=277905408 len=32768
This means every 32K writes, even they are in the same full stripe,
still trigger read for previously cached data.
This would cause extra RAID56 IO, making the btrfs raid56 cache useless.
[CAUSE]
Commit d4e28d9b5f04 ("btrfs: raid56: make steal_rbio() subpage
compatible") tries to make steal_rbio() subpage compatible, but during
that conversion, there is one thing missing.
We no longer rely on PageUptodate(rbio->stripe_pages[i]), but
rbio->stripe_nsectors[i].uptodate to determine if a sector is uptodate.
This means, previously if we switch the pointer, everything is done,
as the PageUptodate flag is still bound to that page.
But now we have to manually mark the involved sectors uptodate, or later
raid56_rmw_stripe() will find the stolen sector is not uptodate, and
assemble the read bio for it, wasting IO.
[FIX]
We can easily fix the bug, by also update the
rbio->stripe_sectors[].uptodate in steal_rbio().
With this fixed, now the same write pattern no longer leads to the same
unnecessary read:
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=0 physical=323026944 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=32768 physical=22052864 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=0 physical=22020096 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=0 physical=277872640 len=32768
^^^ No more partial read, directly into the write path.
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=32768 physical=22052864 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=32768 physical=277905408 len=32768
Fixes: d4e28d9b5f04 ("btrfs: raid56: make steal_rbio() subpage compatible")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-06-01 13:54:28 +08:00
|
|
|
static void steal_rbio_page(struct btrfs_raid_bio *src,
|
|
|
|
struct btrfs_raid_bio *dest, int page_nr)
|
|
|
|
{
|
|
|
|
const u32 sectorsize = src->bioc->fs_info->sectorsize;
|
|
|
|
const u32 sectors_per_page = PAGE_SIZE / sectorsize;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (dest->stripe_pages[page_nr])
|
|
|
|
__free_page(dest->stripe_pages[page_nr]);
|
|
|
|
dest->stripe_pages[page_nr] = src->stripe_pages[page_nr];
|
|
|
|
src->stripe_pages[page_nr] = NULL;
|
|
|
|
|
|
|
|
/* Also update the sector->uptodate bits. */
|
|
|
|
for (i = sectors_per_page * page_nr;
|
|
|
|
i < sectors_per_page * page_nr + sectors_per_page; i++)
|
|
|
|
dest->stripe_sectors[i].uptodate = true;
|
|
|
|
}
|
|
|
|
|
btrfs: raid56: make it more explicit that cache rbio should have all its data sectors uptodate
For Btrfs RAID56, we have a caching system for btrfs raid bios (rbio).
We call cache_rbio_pages() to mark a qualified rbio ready for cache.
The timing happens at:
- finish_rmw()
At this timing, we have already read all necessary sectors, along with
the rbio sectors, we have covered all data stripes.
- __raid_recover_end_io()
At this timing, we have rebuild the rbio, thus all data sectors
involved (either from stripe or bio list) are uptodate now.
Thus at the timing of cache_rbio_pages(), we should have all data
sectors uptodate.
This patch will make it explicit that all data sectors are uptodate at
cache_rbio_pages() timing, mostly to prepare for the incoming
verification at RMW time.
This patch will add:
- Extra ASSERT()s in cache_rbio_pages()
This is to make sure all data sectors, which are not covered by bio,
are already uptodate.
- Extra ASSERT()s in steal_rbio()
Since only cached rbio can be stolen, thus every data sector should
already be uptodate in the source rbio.
- Update __raid_recover_end_io() to update recovered sector->uptodate
Previously __raid_recover_end_io() will only mark failed sectors
uptodate if it's doing an RMW.
But this can trigger new ASSERT()s, as for recovery case, a recovered
failed sector will not be marked uptodate, and trigger ASSERT() in
later cache_rbio_pages() call.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-10-10 18:36:10 +08:00
|
|
|
static bool is_data_stripe_page(struct btrfs_raid_bio *rbio, int page_nr)
|
|
|
|
{
|
|
|
|
const int sector_nr = (page_nr << PAGE_SHIFT) >>
|
|
|
|
rbio->bioc->fs_info->sectorsize_bits;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have ensured PAGE_SIZE is aligned with sectorsize, thus
|
|
|
|
* we won't have a page which is half data half parity.
|
|
|
|
*
|
|
|
|
* Thus if the first sector of the page belongs to data stripes, then
|
|
|
|
* the full page belongs to data stripes.
|
|
|
|
*/
|
|
|
|
return (sector_nr < rbio->nr_data * rbio->stripe_nsectors);
|
|
|
|
}
|
|
|
|
|
2013-02-01 03:42:09 +08:00
|
|
|
/*
|
2022-04-01 19:23:29 +08:00
|
|
|
* Stealing an rbio means taking all the uptodate pages from the stripe array
|
|
|
|
* in the source rbio and putting them into the destination rbio.
|
|
|
|
*
|
|
|
|
* This will also update the involved stripe_sectors[] which are referring to
|
|
|
|
* the old pages.
|
2013-02-01 03:42:09 +08:00
|
|
|
*/
|
|
|
|
static void steal_rbio(struct btrfs_raid_bio *src, struct btrfs_raid_bio *dest)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!test_bit(RBIO_CACHE_READY_BIT, &src->flags))
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < dest->nr_pages; i++) {
|
btrfs: raid56: make it more explicit that cache rbio should have all its data sectors uptodate
For Btrfs RAID56, we have a caching system for btrfs raid bios (rbio).
We call cache_rbio_pages() to mark a qualified rbio ready for cache.
The timing happens at:
- finish_rmw()
At this timing, we have already read all necessary sectors, along with
the rbio sectors, we have covered all data stripes.
- __raid_recover_end_io()
At this timing, we have rebuild the rbio, thus all data sectors
involved (either from stripe or bio list) are uptodate now.
Thus at the timing of cache_rbio_pages(), we should have all data
sectors uptodate.
This patch will make it explicit that all data sectors are uptodate at
cache_rbio_pages() timing, mostly to prepare for the incoming
verification at RMW time.
This patch will add:
- Extra ASSERT()s in cache_rbio_pages()
This is to make sure all data sectors, which are not covered by bio,
are already uptodate.
- Extra ASSERT()s in steal_rbio()
Since only cached rbio can be stolen, thus every data sector should
already be uptodate in the source rbio.
- Update __raid_recover_end_io() to update recovered sector->uptodate
Previously __raid_recover_end_io() will only mark failed sectors
uptodate if it's doing an RMW.
But this can trigger new ASSERT()s, as for recovery case, a recovered
failed sector will not be marked uptodate, and trigger ASSERT() in
later cache_rbio_pages() call.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-10-10 18:36:10 +08:00
|
|
|
struct page *p = src->stripe_pages[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't need to steal P/Q pages as they will always be
|
|
|
|
* regenerated for RMW or full write anyway.
|
|
|
|
*/
|
|
|
|
if (!is_data_stripe_page(src, i))
|
2013-02-01 03:42:09 +08:00
|
|
|
continue;
|
|
|
|
|
btrfs: raid56: make it more explicit that cache rbio should have all its data sectors uptodate
For Btrfs RAID56, we have a caching system for btrfs raid bios (rbio).
We call cache_rbio_pages() to mark a qualified rbio ready for cache.
The timing happens at:
- finish_rmw()
At this timing, we have already read all necessary sectors, along with
the rbio sectors, we have covered all data stripes.
- __raid_recover_end_io()
At this timing, we have rebuild the rbio, thus all data sectors
involved (either from stripe or bio list) are uptodate now.
Thus at the timing of cache_rbio_pages(), we should have all data
sectors uptodate.
This patch will make it explicit that all data sectors are uptodate at
cache_rbio_pages() timing, mostly to prepare for the incoming
verification at RMW time.
This patch will add:
- Extra ASSERT()s in cache_rbio_pages()
This is to make sure all data sectors, which are not covered by bio,
are already uptodate.
- Extra ASSERT()s in steal_rbio()
Since only cached rbio can be stolen, thus every data sector should
already be uptodate in the source rbio.
- Update __raid_recover_end_io() to update recovered sector->uptodate
Previously __raid_recover_end_io() will only mark failed sectors
uptodate if it's doing an RMW.
But this can trigger new ASSERT()s, as for recovery case, a recovered
failed sector will not be marked uptodate, and trigger ASSERT() in
later cache_rbio_pages() call.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-10-10 18:36:10 +08:00
|
|
|
/*
|
|
|
|
* If @src already has RBIO_CACHE_READY_BIT, it should have
|
|
|
|
* all data stripe pages present and uptodate.
|
|
|
|
*/
|
|
|
|
ASSERT(p);
|
|
|
|
ASSERT(full_page_sectors_uptodate(src, i));
|
btrfs: update stripe_sectors::uptodate in steal_rbio
[BUG]
With added debugging, it turns out the following write sequence would
cause extra read which is unnecessary:
# xfs_io -f -s -c "pwrite -b 32k 0 32k" -c "pwrite -b 32k 32k 32k" \
-c "pwrite -b 32k 64k 32k" -c "pwrite -b 32k 96k 32k" \
$mnt/file
The debug message looks like this (btrfs header skipped):
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=0 physical=323026944 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=32768 physical=22052864 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=0 physical=22020096 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=0 physical=277872640 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
^^^^
Still partial read, even 389152768 is already cached by the first.
write.
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=0 physical=22020096 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
^^^^
Still partial read for 298844160.
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=32768 physical=22052864 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=32768 physical=277905408 len=32768
This means every 32K writes, even they are in the same full stripe,
still trigger read for previously cached data.
This would cause extra RAID56 IO, making the btrfs raid56 cache useless.
[CAUSE]
Commit d4e28d9b5f04 ("btrfs: raid56: make steal_rbio() subpage
compatible") tries to make steal_rbio() subpage compatible, but during
that conversion, there is one thing missing.
We no longer rely on PageUptodate(rbio->stripe_pages[i]), but
rbio->stripe_nsectors[i].uptodate to determine if a sector is uptodate.
This means, previously if we switch the pointer, everything is done,
as the PageUptodate flag is still bound to that page.
But now we have to manually mark the involved sectors uptodate, or later
raid56_rmw_stripe() will find the stolen sector is not uptodate, and
assemble the read bio for it, wasting IO.
[FIX]
We can easily fix the bug, by also update the
rbio->stripe_sectors[].uptodate in steal_rbio().
With this fixed, now the same write pattern no longer leads to the same
unnecessary read:
partial rmw, full stripe=389152768 opf=0x0 devid=3 type=1 offset=32768 physical=323059712 len=32768
partial rmw, full stripe=389152768 opf=0x0 devid=1 type=2 offset=0 physical=67174400 len=65536
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=0 physical=323026944 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=0 physical=323026944 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=1 type=1 offset=32768 physical=22052864 len=32768
partial rmw, full stripe=298844160 opf=0x0 devid=2 type=2 offset=0 physical=277872640 len=65536
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=0 physical=22020096 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=0 physical=277872640 len=32768
^^^ No more partial read, directly into the write path.
full stripe rmw, full stripe=389152768 opf=0x1 devid=3 type=1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=389152768 opf=0x1 devid=2 type=-1 offset=32768 physical=323059712 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=1 type=1 offset=32768 physical=22052864 len=32768
full stripe rmw, full stripe=298844160 opf=0x1 devid=3 type=-1 offset=32768 physical=277905408 len=32768
Fixes: d4e28d9b5f04 ("btrfs: raid56: make steal_rbio() subpage compatible")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-06-01 13:54:28 +08:00
|
|
|
steal_rbio_page(src, dest, i);
|
2013-02-01 03:42:09 +08:00
|
|
|
}
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
index_stripe_sectors(dest);
|
|
|
|
index_stripe_sectors(src);
|
2013-02-01 03:42:09 +08:00
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* merging means we take the bio_list from the victim and
|
|
|
|
* splice it into the destination. The victim should
|
|
|
|
* be discarded afterwards.
|
|
|
|
*
|
|
|
|
* must be called with dest->rbio_list_lock held
|
|
|
|
*/
|
|
|
|
static void merge_rbio(struct btrfs_raid_bio *dest,
|
|
|
|
struct btrfs_raid_bio *victim)
|
|
|
|
{
|
|
|
|
bio_list_merge(&dest->bio_list, &victim->bio_list);
|
|
|
|
dest->bio_list_bytes += victim->bio_list_bytes;
|
2022-05-27 15:28:19 +08:00
|
|
|
/* Also inherit the bitmaps from @victim. */
|
|
|
|
bitmap_or(&dest->dbitmap, &victim->dbitmap, &dest->dbitmap,
|
|
|
|
dest->stripe_nsectors);
|
2013-01-30 07:40:14 +08:00
|
|
|
bio_list_init(&victim->bio_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-02-01 03:42:09 +08:00
|
|
|
* used to prune items that are in the cache. The caller
|
|
|
|
* must hold the hash table lock.
|
|
|
|
*/
|
|
|
|
static void __remove_rbio_from_cache(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
int bucket = rbio_bucket(rbio);
|
|
|
|
struct btrfs_stripe_hash_table *table;
|
|
|
|
struct btrfs_stripe_hash *h;
|
|
|
|
int freeit = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* check the bit again under the hash table lock.
|
|
|
|
*/
|
|
|
|
if (!test_bit(RBIO_CACHE_BIT, &rbio->flags))
|
|
|
|
return;
|
|
|
|
|
2021-09-23 14:00:09 +08:00
|
|
|
table = rbio->bioc->fs_info->stripe_hash_table;
|
2013-02-01 03:42:09 +08:00
|
|
|
h = table->table + bucket;
|
|
|
|
|
|
|
|
/* hold the lock for the bucket because we may be
|
|
|
|
* removing it from the hash table
|
|
|
|
*/
|
|
|
|
spin_lock(&h->lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* hold the lock for the bio list because we need
|
|
|
|
* to make sure the bio list is empty
|
|
|
|
*/
|
|
|
|
spin_lock(&rbio->bio_list_lock);
|
|
|
|
|
|
|
|
if (test_and_clear_bit(RBIO_CACHE_BIT, &rbio->flags)) {
|
|
|
|
list_del_init(&rbio->stripe_cache);
|
|
|
|
table->cache_size -= 1;
|
|
|
|
freeit = 1;
|
|
|
|
|
|
|
|
/* if the bio list isn't empty, this rbio is
|
|
|
|
* still involved in an IO. We take it out
|
|
|
|
* of the cache list, and drop the ref that
|
|
|
|
* was held for the list.
|
|
|
|
*
|
|
|
|
* If the bio_list was empty, we also remove
|
|
|
|
* the rbio from the hash_table, and drop
|
|
|
|
* the corresponding ref
|
|
|
|
*/
|
|
|
|
if (bio_list_empty(&rbio->bio_list)) {
|
|
|
|
if (!list_empty(&rbio->hash_list)) {
|
|
|
|
list_del_init(&rbio->hash_list);
|
2017-03-03 16:55:26 +08:00
|
|
|
refcount_dec(&rbio->refs);
|
2013-02-01 03:42:09 +08:00
|
|
|
BUG_ON(!list_empty(&rbio->plug_list));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
|
|
|
spin_unlock(&h->lock);
|
|
|
|
|
|
|
|
if (freeit)
|
2022-10-10 18:36:08 +08:00
|
|
|
free_raid_bio(rbio);
|
2013-02-01 03:42:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* prune a given rbio from the cache
|
|
|
|
*/
|
|
|
|
static void remove_rbio_from_cache(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
struct btrfs_stripe_hash_table *table;
|
|
|
|
|
|
|
|
if (!test_bit(RBIO_CACHE_BIT, &rbio->flags))
|
|
|
|
return;
|
|
|
|
|
2021-09-23 14:00:09 +08:00
|
|
|
table = rbio->bioc->fs_info->stripe_hash_table;
|
2013-02-01 03:42:09 +08:00
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&table->cache_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
__remove_rbio_from_cache(rbio);
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&table->cache_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* remove everything in the cache
|
|
|
|
*/
|
2013-04-26 04:41:01 +08:00
|
|
|
static void btrfs_clear_rbio_cache(struct btrfs_fs_info *info)
|
2013-02-01 03:42:09 +08:00
|
|
|
{
|
|
|
|
struct btrfs_stripe_hash_table *table;
|
|
|
|
struct btrfs_raid_bio *rbio;
|
|
|
|
|
|
|
|
table = info->stripe_hash_table;
|
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&table->cache_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
while (!list_empty(&table->stripe_cache)) {
|
|
|
|
rbio = list_entry(table->stripe_cache.next,
|
|
|
|
struct btrfs_raid_bio,
|
|
|
|
stripe_cache);
|
|
|
|
__remove_rbio_from_cache(rbio);
|
|
|
|
}
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&table->cache_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* remove all cached entries and free the hash table
|
|
|
|
* used by unmount
|
2013-01-30 07:40:14 +08:00
|
|
|
*/
|
|
|
|
void btrfs_free_stripe_hash_table(struct btrfs_fs_info *info)
|
|
|
|
{
|
|
|
|
if (!info->stripe_hash_table)
|
|
|
|
return;
|
2013-02-01 03:42:09 +08:00
|
|
|
btrfs_clear_rbio_cache(info);
|
2014-11-22 21:13:10 +08:00
|
|
|
kvfree(info->stripe_hash_table);
|
2013-01-30 07:40:14 +08:00
|
|
|
info->stripe_hash_table = NULL;
|
|
|
|
}
|
|
|
|
|
2013-02-01 03:42:09 +08:00
|
|
|
/*
|
|
|
|
* insert an rbio into the stripe cache. It
|
|
|
|
* must have already been prepared by calling
|
|
|
|
* cache_rbio_pages
|
|
|
|
*
|
|
|
|
* If this rbio was already cached, it gets
|
|
|
|
* moved to the front of the lru.
|
|
|
|
*
|
|
|
|
* If the size of the rbio cache is too big, we
|
|
|
|
* prune an item.
|
|
|
|
*/
|
|
|
|
static void cache_rbio(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
struct btrfs_stripe_hash_table *table;
|
|
|
|
|
|
|
|
if (!test_bit(RBIO_CACHE_READY_BIT, &rbio->flags))
|
|
|
|
return;
|
|
|
|
|
2021-09-23 14:00:09 +08:00
|
|
|
table = rbio->bioc->fs_info->stripe_hash_table;
|
2013-02-01 03:42:09 +08:00
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&table->cache_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
spin_lock(&rbio->bio_list_lock);
|
|
|
|
|
|
|
|
/* bump our ref if we were not in the list before */
|
|
|
|
if (!test_and_set_bit(RBIO_CACHE_BIT, &rbio->flags))
|
2017-03-03 16:55:26 +08:00
|
|
|
refcount_inc(&rbio->refs);
|
2013-02-01 03:42:09 +08:00
|
|
|
|
|
|
|
if (!list_empty(&rbio->stripe_cache)){
|
|
|
|
list_move(&rbio->stripe_cache, &table->stripe_cache);
|
|
|
|
} else {
|
|
|
|
list_add(&rbio->stripe_cache, &table->stripe_cache);
|
|
|
|
table->cache_size += 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
|
|
|
|
|
|
|
if (table->cache_size > RBIO_CACHE_SIZE) {
|
|
|
|
struct btrfs_raid_bio *found;
|
|
|
|
|
|
|
|
found = list_entry(table->stripe_cache.prev,
|
|
|
|
struct btrfs_raid_bio,
|
|
|
|
stripe_cache);
|
|
|
|
|
|
|
|
if (found != rbio)
|
|
|
|
__remove_rbio_from_cache(found);
|
|
|
|
}
|
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&table->cache_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* helper function to run the xor_blocks api. It is only
|
|
|
|
* able to do MAX_XOR_BLOCKS at a time, so we need to
|
|
|
|
* loop through.
|
|
|
|
*/
|
|
|
|
static void run_xor(void **pages, int src_cnt, ssize_t len)
|
|
|
|
{
|
|
|
|
int src_off = 0;
|
|
|
|
int xor_src_cnt = 0;
|
|
|
|
void *dest = pages[src_cnt];
|
|
|
|
|
|
|
|
while(src_cnt > 0) {
|
|
|
|
xor_src_cnt = min(src_cnt, MAX_XOR_BLOCKS);
|
|
|
|
xor_blocks(xor_src_cnt, len, dest, pages + src_off);
|
|
|
|
|
|
|
|
src_cnt -= xor_src_cnt;
|
|
|
|
src_off += xor_src_cnt;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2018-06-29 16:57:05 +08:00
|
|
|
* Returns true if the bio list inside this rbio covers an entire stripe (no
|
|
|
|
* rmw required).
|
2013-01-30 07:40:14 +08:00
|
|
|
*/
|
2018-06-29 16:57:05 +08:00
|
|
|
static int rbio_is_full(struct btrfs_raid_bio *rbio)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
|
|
|
unsigned long size = rbio->bio_list_bytes;
|
|
|
|
int ret = 1;
|
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&rbio->bio_list_lock);
|
2022-06-17 18:04:05 +08:00
|
|
|
if (size != rbio->nr_data * BTRFS_STRIPE_LEN)
|
2013-01-30 07:40:14 +08:00
|
|
|
ret = 0;
|
2022-06-17 18:04:05 +08:00
|
|
|
BUG_ON(size > rbio->nr_data * BTRFS_STRIPE_LEN);
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2018-06-29 16:57:05 +08:00
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* returns 1 if it is safe to merge two rbios together.
|
|
|
|
* The merging is safe if the two rbios correspond to
|
|
|
|
* the same stripe and if they are both going in the same
|
|
|
|
* direction (read vs write), and if neither one is
|
|
|
|
* locked for final IO
|
|
|
|
*
|
|
|
|
* The caller is responsible for locking such that
|
|
|
|
* rmw_locked is safe to test
|
|
|
|
*/
|
|
|
|
static int rbio_can_merge(struct btrfs_raid_bio *last,
|
|
|
|
struct btrfs_raid_bio *cur)
|
|
|
|
{
|
|
|
|
if (test_bit(RBIO_RMW_LOCKED_BIT, &last->flags) ||
|
|
|
|
test_bit(RBIO_RMW_LOCKED_BIT, &cur->flags))
|
|
|
|
return 0;
|
|
|
|
|
2013-02-01 03:42:09 +08:00
|
|
|
/*
|
|
|
|
* we can't merge with cached rbios, since the
|
|
|
|
* idea is that when we merge the destination
|
|
|
|
* rbio is going to run our IO for us. We can
|
2016-05-20 09:18:45 +08:00
|
|
|
* steal from cached rbios though, other functions
|
2013-02-01 03:42:09 +08:00
|
|
|
* handle that.
|
|
|
|
*/
|
|
|
|
if (test_bit(RBIO_CACHE_BIT, &last->flags) ||
|
|
|
|
test_bit(RBIO_CACHE_BIT, &cur->flags))
|
|
|
|
return 0;
|
|
|
|
|
2023-02-17 13:37:03 +08:00
|
|
|
if (last->bioc->full_stripe_logical != cur->bioc->full_stripe_logical)
|
2013-01-30 07:40:14 +08:00
|
|
|
return 0;
|
|
|
|
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
/* we can't merge with different operations */
|
|
|
|
if (last->operation != cur->operation)
|
|
|
|
return 0;
|
|
|
|
/*
|
|
|
|
* We've need read the full stripe from the drive.
|
|
|
|
* check and repair the parity and write the new results.
|
|
|
|
*
|
|
|
|
* We're not allowed to add any new bios to the
|
|
|
|
* bio list here, anyone else that wants to
|
|
|
|
* change this stripe needs to do their own rmw.
|
|
|
|
*/
|
2017-12-05 06:40:35 +08:00
|
|
|
if (last->operation == BTRFS_RBIO_PARITY_SCRUB)
|
2013-01-30 07:40:14 +08:00
|
|
|
return 0;
|
|
|
|
|
2022-11-07 15:32:31 +08:00
|
|
|
if (last->operation == BTRFS_RBIO_REBUILD_MISSING ||
|
|
|
|
last->operation == BTRFS_RBIO_READ_REBUILD)
|
2015-06-20 02:52:50 +08:00
|
|
|
return 0;
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2022-04-01 19:23:21 +08:00
|
|
|
static unsigned int rbio_stripe_sector_index(const struct btrfs_raid_bio *rbio,
|
|
|
|
unsigned int stripe_nr,
|
|
|
|
unsigned int sector_nr)
|
|
|
|
{
|
|
|
|
ASSERT(stripe_nr < rbio->real_stripes);
|
|
|
|
ASSERT(sector_nr < rbio->stripe_nsectors);
|
|
|
|
|
|
|
|
return stripe_nr * rbio->stripe_nsectors + sector_nr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return a sector from rbio->stripe_sectors, not from the bio list */
|
|
|
|
static struct sector_ptr *rbio_stripe_sector(const struct btrfs_raid_bio *rbio,
|
|
|
|
unsigned int stripe_nr,
|
|
|
|
unsigned int sector_nr)
|
|
|
|
{
|
|
|
|
return &rbio->stripe_sectors[rbio_stripe_sector_index(rbio, stripe_nr,
|
|
|
|
sector_nr)];
|
|
|
|
}
|
|
|
|
|
2022-04-01 19:23:24 +08:00
|
|
|
/* Grab a sector inside P stripe */
|
|
|
|
static struct sector_ptr *rbio_pstripe_sector(const struct btrfs_raid_bio *rbio,
|
|
|
|
unsigned int sector_nr)
|
2015-03-03 20:38:46 +08:00
|
|
|
{
|
2022-04-01 19:23:24 +08:00
|
|
|
return rbio_stripe_sector(rbio, rbio->nr_data, sector_nr);
|
2015-03-03 20:38:46 +08:00
|
|
|
}
|
|
|
|
|
2022-04-01 19:23:24 +08:00
|
|
|
/* Grab a sector inside Q stripe, return NULL if not RAID6 */
|
|
|
|
static struct sector_ptr *rbio_qstripe_sector(const struct btrfs_raid_bio *rbio,
|
|
|
|
unsigned int sector_nr)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2022-04-01 19:23:24 +08:00
|
|
|
if (rbio->nr_data + 1 == rbio->real_stripes)
|
|
|
|
return NULL;
|
|
|
|
return rbio_stripe_sector(rbio, rbio->nr_data + 1, sector_nr);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The first stripe in the table for a logical address
|
|
|
|
* has the lock. rbios are added in one of three ways:
|
|
|
|
*
|
|
|
|
* 1) Nobody has the stripe locked yet. The rbio is given
|
|
|
|
* the lock and 0 is returned. The caller must start the IO
|
|
|
|
* themselves.
|
|
|
|
*
|
|
|
|
* 2) Someone has the stripe locked, but we're able to merge
|
|
|
|
* with the lock owner. The rbio is freed and the IO will
|
|
|
|
* start automatically along with the existing rbio. 1 is returned.
|
|
|
|
*
|
|
|
|
* 3) Someone has the stripe locked, but we're not able to merge.
|
|
|
|
* The rbio is added to the lock owner's plug list, or merged into
|
|
|
|
* an rbio already on the plug list. When the lock owner unlocks,
|
|
|
|
* the next rbio on the list is run and the IO is started automatically.
|
|
|
|
* 1 is returned
|
|
|
|
*
|
|
|
|
* If we return 0, the caller still owns the rbio and must continue with
|
|
|
|
* IO submission. If we return 1, the caller must assume the rbio has
|
|
|
|
* already been freed.
|
|
|
|
*/
|
|
|
|
static noinline int lock_stripe_add(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
2019-10-18 17:58:21 +08:00
|
|
|
struct btrfs_stripe_hash *h;
|
2013-01-30 07:40:14 +08:00
|
|
|
struct btrfs_raid_bio *cur;
|
|
|
|
struct btrfs_raid_bio *pending;
|
|
|
|
struct btrfs_raid_bio *freeit = NULL;
|
2013-02-01 03:42:09 +08:00
|
|
|
struct btrfs_raid_bio *cache_drop = NULL;
|
2013-01-30 07:40:14 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
2021-09-23 14:00:09 +08:00
|
|
|
h = rbio->bioc->fs_info->stripe_hash_table->table + rbio_bucket(rbio);
|
2019-10-18 17:58:21 +08:00
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&h->lock);
|
2013-01-30 07:40:14 +08:00
|
|
|
list_for_each_entry(cur, &h->hash_list, hash_list) {
|
2023-02-17 13:37:03 +08:00
|
|
|
if (cur->bioc->full_stripe_logical != rbio->bioc->full_stripe_logical)
|
2019-10-18 17:58:20 +08:00
|
|
|
continue;
|
2013-02-01 03:42:09 +08:00
|
|
|
|
2019-10-18 17:58:20 +08:00
|
|
|
spin_lock(&cur->bio_list_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
|
2019-10-18 17:58:20 +08:00
|
|
|
/* Can we steal this cached rbio's pages? */
|
|
|
|
if (bio_list_empty(&cur->bio_list) &&
|
|
|
|
list_empty(&cur->plug_list) &&
|
|
|
|
test_bit(RBIO_CACHE_BIT, &cur->flags) &&
|
|
|
|
!test_bit(RBIO_RMW_LOCKED_BIT, &cur->flags)) {
|
|
|
|
list_del_init(&cur->hash_list);
|
|
|
|
refcount_dec(&cur->refs);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2019-10-18 17:58:20 +08:00
|
|
|
steal_rbio(cur, rbio);
|
|
|
|
cache_drop = cur;
|
|
|
|
spin_unlock(&cur->bio_list_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
|
2019-10-18 17:58:20 +08:00
|
|
|
goto lockit;
|
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2019-10-18 17:58:20 +08:00
|
|
|
/* Can we merge into the lock owner? */
|
|
|
|
if (rbio_can_merge(cur, rbio)) {
|
|
|
|
merge_rbio(cur, rbio);
|
2013-01-30 07:40:14 +08:00
|
|
|
spin_unlock(&cur->bio_list_lock);
|
2019-10-18 17:58:20 +08:00
|
|
|
freeit = rbio;
|
2013-01-30 07:40:14 +08:00
|
|
|
ret = 1;
|
|
|
|
goto out;
|
|
|
|
}
|
2019-10-18 17:58:20 +08:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We couldn't merge with the running rbio, see if we can merge
|
|
|
|
* with the pending ones. We don't have to check for rmw_locked
|
|
|
|
* because there is no way they are inside finish_rmw right now
|
|
|
|
*/
|
|
|
|
list_for_each_entry(pending, &cur->plug_list, plug_list) {
|
|
|
|
if (rbio_can_merge(pending, rbio)) {
|
|
|
|
merge_rbio(pending, rbio);
|
|
|
|
spin_unlock(&cur->bio_list_lock);
|
|
|
|
freeit = rbio;
|
|
|
|
ret = 1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No merging, put us on the tail of the plug list, our rbio
|
|
|
|
* will be started with the currently running rbio unlocks
|
|
|
|
*/
|
|
|
|
list_add_tail(&rbio->plug_list, &cur->plug_list);
|
|
|
|
spin_unlock(&cur->bio_list_lock);
|
|
|
|
ret = 1;
|
|
|
|
goto out;
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
2013-02-01 03:42:09 +08:00
|
|
|
lockit:
|
2017-03-03 16:55:26 +08:00
|
|
|
refcount_inc(&rbio->refs);
|
2013-01-30 07:40:14 +08:00
|
|
|
list_add(&rbio->hash_list, &h->hash_list);
|
|
|
|
out:
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&h->lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
if (cache_drop)
|
|
|
|
remove_rbio_from_cache(cache_drop);
|
2013-01-30 07:40:14 +08:00
|
|
|
if (freeit)
|
2022-10-10 18:36:08 +08:00
|
|
|
free_raid_bio(freeit);
|
2013-01-30 07:40:14 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:05 +08:00
|
|
|
static void recover_rbio_work_locked(struct work_struct *work);
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* called as rmw or parity rebuild is completed. If the plug list has more
|
|
|
|
* rbios waiting for this stripe, the next one on the list will be started
|
|
|
|
*/
|
|
|
|
static noinline void unlock_stripe(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
int bucket;
|
|
|
|
struct btrfs_stripe_hash *h;
|
2013-02-01 03:42:09 +08:00
|
|
|
int keep_cache = 0;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
bucket = rbio_bucket(rbio);
|
2021-09-23 14:00:09 +08:00
|
|
|
h = rbio->bioc->fs_info->stripe_hash_table->table + bucket;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2013-02-01 03:42:09 +08:00
|
|
|
if (list_empty(&rbio->plug_list))
|
|
|
|
cache_rbio(rbio);
|
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&h->lock);
|
2013-01-30 07:40:14 +08:00
|
|
|
spin_lock(&rbio->bio_list_lock);
|
|
|
|
|
|
|
|
if (!list_empty(&rbio->hash_list)) {
|
2013-02-01 03:42:09 +08:00
|
|
|
/*
|
|
|
|
* if we're still cached and there is no other IO
|
|
|
|
* to perform, just leave this rbio here for others
|
|
|
|
* to steal from later
|
|
|
|
*/
|
|
|
|
if (list_empty(&rbio->plug_list) &&
|
|
|
|
test_bit(RBIO_CACHE_BIT, &rbio->flags)) {
|
|
|
|
keep_cache = 1;
|
|
|
|
clear_bit(RBIO_RMW_LOCKED_BIT, &rbio->flags);
|
|
|
|
BUG_ON(!bio_list_empty(&rbio->bio_list));
|
|
|
|
goto done;
|
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
list_del_init(&rbio->hash_list);
|
2017-03-03 16:55:26 +08:00
|
|
|
refcount_dec(&rbio->refs);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* we use the plug list to hold all the rbios
|
|
|
|
* waiting for the chance to lock this stripe.
|
|
|
|
* hand the lock over to one of them.
|
|
|
|
*/
|
|
|
|
if (!list_empty(&rbio->plug_list)) {
|
|
|
|
struct btrfs_raid_bio *next;
|
|
|
|
struct list_head *head = rbio->plug_list.next;
|
|
|
|
|
|
|
|
next = list_entry(head, struct btrfs_raid_bio,
|
|
|
|
plug_list);
|
|
|
|
|
|
|
|
list_del_init(&rbio->plug_list);
|
|
|
|
|
|
|
|
list_add(&next->hash_list, &h->hash_list);
|
2017-03-03 16:55:26 +08:00
|
|
|
refcount_inc(&next->refs);
|
2013-01-30 07:40:14 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&h->lock);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2014-11-06 16:14:21 +08:00
|
|
|
if (next->operation == BTRFS_RBIO_READ_REBUILD)
|
2022-11-01 19:16:05 +08:00
|
|
|
start_async_work(next, recover_rbio_work_locked);
|
2015-06-20 02:52:50 +08:00
|
|
|
else if (next->operation == BTRFS_RBIO_REBUILD_MISSING) {
|
|
|
|
steal_rbio(rbio, next);
|
2022-11-01 19:16:05 +08:00
|
|
|
start_async_work(next, recover_rbio_work_locked);
|
2015-06-20 02:52:50 +08:00
|
|
|
} else if (next->operation == BTRFS_RBIO_WRITE) {
|
2013-02-01 03:42:09 +08:00
|
|
|
steal_rbio(rbio, next);
|
2022-11-01 19:16:09 +08:00
|
|
|
start_async_work(next, rmw_rbio_work_locked);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
} else if (next->operation == BTRFS_RBIO_PARITY_SCRUB) {
|
|
|
|
steal_rbio(rbio, next);
|
2022-11-01 19:16:11 +08:00
|
|
|
start_async_work(next, scrub_rbio_work_locked);
|
2013-02-01 03:42:09 +08:00
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
goto done_nolock;
|
|
|
|
}
|
|
|
|
}
|
2013-02-01 03:42:09 +08:00
|
|
|
done:
|
2013-01-30 07:40:14 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&h->lock);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
done_nolock:
|
2013-02-01 03:42:09 +08:00
|
|
|
if (!keep_cache)
|
|
|
|
remove_rbio_from_cache(rbio);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
2018-01-10 09:36:25 +08:00
|
|
|
static void rbio_endio_bio_list(struct bio *cur, blk_status_t err)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2018-01-10 09:36:25 +08:00
|
|
|
struct bio *next;
|
|
|
|
|
|
|
|
while (cur) {
|
|
|
|
next = cur->bi_next;
|
|
|
|
cur->bi_next = NULL;
|
|
|
|
cur->bi_status = err;
|
|
|
|
bio_endio(cur);
|
|
|
|
cur = next;
|
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* this frees the rbio and runs through all the bios in the
|
|
|
|
* bio_list and calls end_io on them
|
|
|
|
*/
|
2017-06-03 15:38:06 +08:00
|
|
|
static void rbio_orig_end_io(struct btrfs_raid_bio *rbio, blk_status_t err)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
|
|
|
struct bio *cur = bio_list_get(&rbio->bio_list);
|
2018-01-10 09:36:25 +08:00
|
|
|
struct bio *extra;
|
2014-11-25 16:39:28 +08:00
|
|
|
|
2022-11-14 08:26:33 +08:00
|
|
|
kfree(rbio->csum_buf);
|
|
|
|
bitmap_free(rbio->csum_bitmap);
|
|
|
|
rbio->csum_buf = NULL;
|
|
|
|
rbio->csum_bitmap = NULL;
|
|
|
|
|
2022-05-27 15:28:19 +08:00
|
|
|
/*
|
|
|
|
* Clear the data bitmap, as the rbio may be cached for later usage.
|
|
|
|
* do this before before unlock_stripe() so there will be no new bio
|
|
|
|
* for this bio.
|
|
|
|
*/
|
|
|
|
bitmap_clear(&rbio->dbitmap, 0, rbio->stripe_nsectors);
|
2014-11-25 16:39:28 +08:00
|
|
|
|
2018-01-10 09:36:25 +08:00
|
|
|
/*
|
|
|
|
* At this moment, rbio->bio_list is empty, however since rbio does not
|
|
|
|
* always have RBIO_RMW_LOCKED_BIT set and rbio is still linked on the
|
|
|
|
* hash list, rbio may be merged with others so that rbio->bio_list
|
|
|
|
* becomes non-empty.
|
|
|
|
* Once unlock_stripe() is done, rbio->bio_list will not be updated any
|
|
|
|
* more and we can call bio_endio() on all queued bios.
|
|
|
|
*/
|
|
|
|
unlock_stripe(rbio);
|
|
|
|
extra = bio_list_get(&rbio->bio_list);
|
2022-10-10 18:36:08 +08:00
|
|
|
free_raid_bio(rbio);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2018-01-10 09:36:25 +08:00
|
|
|
rbio_endio_bio_list(cur, err);
|
|
|
|
if (extra)
|
|
|
|
rbio_endio_bio_list(extra, err);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
2022-10-27 20:21:42 +08:00
|
|
|
/*
|
|
|
|
* Get a sector pointer specified by its @stripe_nr and @sector_nr.
|
2022-04-01 19:23:21 +08:00
|
|
|
*
|
|
|
|
* @rbio: The raid bio
|
|
|
|
* @stripe_nr: Stripe number, valid range [0, real_stripe)
|
|
|
|
* @sector_nr: Sector number inside the stripe,
|
|
|
|
* valid range [0, stripe_nsectors)
|
|
|
|
* @bio_list_only: Whether to use sectors inside the bio list only.
|
|
|
|
*
|
|
|
|
* The read/modify/write code wants to reuse the original bio page as much
|
|
|
|
* as possible, and only use stripe_sectors as fallback.
|
|
|
|
*/
|
|
|
|
static struct sector_ptr *sector_in_rbio(struct btrfs_raid_bio *rbio,
|
|
|
|
int stripe_nr, int sector_nr,
|
|
|
|
bool bio_list_only)
|
|
|
|
{
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
int index;
|
|
|
|
|
|
|
|
ASSERT(stripe_nr >= 0 && stripe_nr < rbio->real_stripes);
|
|
|
|
ASSERT(sector_nr >= 0 && sector_nr < rbio->stripe_nsectors);
|
|
|
|
|
|
|
|
index = stripe_nr * rbio->stripe_nsectors + sector_nr;
|
|
|
|
ASSERT(index >= 0 && index < rbio->nr_sectors);
|
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&rbio->bio_list_lock);
|
2022-04-01 19:23:21 +08:00
|
|
|
sector = &rbio->bio_sectors[index];
|
|
|
|
if (sector->page || bio_list_only) {
|
|
|
|
/* Don't return sector without a valid page pointer */
|
|
|
|
if (!sector->page)
|
|
|
|
sector = NULL;
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2022-04-01 19:23:21 +08:00
|
|
|
return sector;
|
|
|
|
}
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2022-04-01 19:23:21 +08:00
|
|
|
|
|
|
|
return &rbio->stripe_sectors[index];
|
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* allocation and initial setup for the btrfs_raid_bio. Not
|
|
|
|
* this does not allocate any pages for rbio->pages.
|
|
|
|
*/
|
2016-06-23 06:54:24 +08:00
|
|
|
static struct btrfs_raid_bio *alloc_rbio(struct btrfs_fs_info *fs_info,
|
2022-06-17 18:04:05 +08:00
|
|
|
struct btrfs_io_context *bioc)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
const unsigned int real_stripes = bioc->num_stripes - bioc->replace_nr_stripes;
|
2022-06-17 18:04:05 +08:00
|
|
|
const unsigned int stripe_npages = BTRFS_STRIPE_LEN >> PAGE_SHIFT;
|
2022-04-01 19:23:16 +08:00
|
|
|
const unsigned int num_pages = stripe_npages * real_stripes;
|
2022-06-17 18:04:05 +08:00
|
|
|
const unsigned int stripe_nsectors =
|
|
|
|
BTRFS_STRIPE_LEN >> fs_info->sectorsize_bits;
|
2022-04-01 19:23:18 +08:00
|
|
|
const unsigned int num_sectors = stripe_nsectors * real_stripes;
|
2013-01-30 07:40:14 +08:00
|
|
|
struct btrfs_raid_bio *rbio;
|
|
|
|
|
2022-04-01 19:23:18 +08:00
|
|
|
/* PAGE_SIZE must also be aligned to sectorsize for subpage support */
|
|
|
|
ASSERT(IS_ALIGNED(PAGE_SIZE, fs_info->sectorsize));
|
2022-05-27 15:28:17 +08:00
|
|
|
/*
|
|
|
|
* Our current stripe len should be fixed to 64k thus stripe_nsectors
|
|
|
|
* (at most 16) should be no larger than BITS_PER_LONG.
|
|
|
|
*/
|
|
|
|
ASSERT(stripe_nsectors <= BITS_PER_LONG);
|
2022-04-01 19:23:16 +08:00
|
|
|
|
2022-10-10 18:36:09 +08:00
|
|
|
rbio = kzalloc(sizeof(*rbio), GFP_NOFS);
|
2014-10-23 14:42:50 +08:00
|
|
|
if (!rbio)
|
2013-01-30 07:40:14 +08:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2022-10-10 18:36:09 +08:00
|
|
|
rbio->stripe_pages = kcalloc(num_pages, sizeof(struct page *),
|
|
|
|
GFP_NOFS);
|
|
|
|
rbio->bio_sectors = kcalloc(num_sectors, sizeof(struct sector_ptr),
|
|
|
|
GFP_NOFS);
|
|
|
|
rbio->stripe_sectors = kcalloc(num_sectors, sizeof(struct sector_ptr),
|
|
|
|
GFP_NOFS);
|
|
|
|
rbio->finish_pointers = kcalloc(real_stripes, sizeof(void *), GFP_NOFS);
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
rbio->error_bitmap = bitmap_zalloc(num_sectors, GFP_NOFS);
|
2022-10-10 18:36:09 +08:00
|
|
|
|
|
|
|
if (!rbio->stripe_pages || !rbio->bio_sectors || !rbio->stripe_sectors ||
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
!rbio->finish_pointers || !rbio->error_bitmap) {
|
2022-10-10 18:36:09 +08:00
|
|
|
free_raid_bio_pointers(rbio);
|
|
|
|
kfree(rbio);
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
bio_list_init(&rbio->bio_list);
|
2022-11-01 19:16:05 +08:00
|
|
|
init_waitqueue_head(&rbio->io_wait);
|
2013-01-30 07:40:14 +08:00
|
|
|
INIT_LIST_HEAD(&rbio->plug_list);
|
|
|
|
spin_lock_init(&rbio->bio_list_lock);
|
2013-02-01 03:42:09 +08:00
|
|
|
INIT_LIST_HEAD(&rbio->stripe_cache);
|
2013-01-30 07:40:14 +08:00
|
|
|
INIT_LIST_HEAD(&rbio->hash_list);
|
2022-08-06 16:03:25 +08:00
|
|
|
btrfs_get_bioc(bioc);
|
2021-09-15 15:17:16 +08:00
|
|
|
rbio->bioc = bioc;
|
2013-01-30 07:40:14 +08:00
|
|
|
rbio->nr_pages = num_pages;
|
2022-04-01 19:23:18 +08:00
|
|
|
rbio->nr_sectors = num_sectors;
|
2014-11-14 16:06:25 +08:00
|
|
|
rbio->real_stripes = real_stripes;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
rbio->stripe_npages = stripe_npages;
|
2022-04-01 19:23:18 +08:00
|
|
|
rbio->stripe_nsectors = stripe_nsectors;
|
2017-03-03 16:55:26 +08:00
|
|
|
refcount_set(&rbio->refs, 1);
|
2014-10-15 11:18:44 +08:00
|
|
|
atomic_set(&rbio->stripes_pending, 0);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-05-13 16:34:30 +08:00
|
|
|
ASSERT(btrfs_nr_parity_stripes(bioc->map_type));
|
|
|
|
rbio->nr_data = real_stripes - btrfs_nr_parity_stripes(bioc->map_type);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
return rbio;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* allocate pages for all the stripes in the bio, including parity */
|
|
|
|
static int alloc_rbio_pages(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = btrfs_alloc_page_array(rbio->nr_pages, rbio->stripe_pages);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
/* Mapping all sectors */
|
|
|
|
index_stripe_sectors(rbio);
|
|
|
|
return 0;
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
2015-03-03 20:38:46 +08:00
|
|
|
/* only allocate pages for p/q stripes */
|
2013-01-30 07:40:14 +08:00
|
|
|
static int alloc_rbio_parity_pages(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
2022-04-01 19:23:25 +08:00
|
|
|
const int data_pages = rbio->nr_data * rbio->stripe_npages;
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
int ret;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
ret = btrfs_alloc_page_array(rbio->nr_pages - data_pages,
|
|
|
|
rbio->stripe_pages + data_pages);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
index_stripe_sectors(rbio);
|
|
|
|
return 0;
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
/*
|
2023-01-17 18:03:21 +08:00
|
|
|
* Return the total number of errors found in the vertical stripe of @sector_nr.
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
*
|
|
|
|
* @faila and @failb will also be updated to the first and second stripe
|
|
|
|
* number of the errors.
|
|
|
|
*/
|
|
|
|
static int get_rbio_veritical_errors(struct btrfs_raid_bio *rbio, int sector_nr,
|
|
|
|
int *faila, int *failb)
|
|
|
|
{
|
|
|
|
int stripe_nr;
|
|
|
|
int found_errors = 0;
|
|
|
|
|
2022-11-07 15:32:31 +08:00
|
|
|
if (faila || failb) {
|
|
|
|
/*
|
|
|
|
* Both @faila and @failb should be valid pointers if any of
|
|
|
|
* them is specified.
|
|
|
|
*/
|
|
|
|
ASSERT(faila && failb);
|
|
|
|
*faila = -1;
|
|
|
|
*failb = -1;
|
|
|
|
}
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
|
|
|
|
for (stripe_nr = 0; stripe_nr < rbio->real_stripes; stripe_nr++) {
|
|
|
|
int total_sector_nr = stripe_nr * rbio->stripe_nsectors + sector_nr;
|
|
|
|
|
|
|
|
if (test_bit(total_sector_nr, rbio->error_bitmap)) {
|
|
|
|
found_errors++;
|
2022-11-07 15:32:31 +08:00
|
|
|
if (faila) {
|
|
|
|
/* Update faila and failb. */
|
|
|
|
if (*faila < 0)
|
|
|
|
*faila = stripe_nr;
|
|
|
|
else if (*failb < 0)
|
|
|
|
*failb = stripe_nr;
|
|
|
|
}
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return found_errors;
|
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
2022-04-01 19:23:21 +08:00
|
|
|
* Add a single sector @sector into our list of bios for IO.
|
|
|
|
*
|
|
|
|
* Return 0 if everything went well.
|
|
|
|
* Return <0 for error.
|
2013-01-30 07:40:14 +08:00
|
|
|
*/
|
2022-04-01 19:23:21 +08:00
|
|
|
static int rbio_add_io_sector(struct btrfs_raid_bio *rbio,
|
|
|
|
struct bio_list *bio_list,
|
|
|
|
struct sector_ptr *sector,
|
|
|
|
unsigned int stripe_nr,
|
|
|
|
unsigned int sector_nr,
|
2022-07-15 02:07:16 +08:00
|
|
|
enum req_op op)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2022-04-01 19:23:21 +08:00
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
2013-01-30 07:40:14 +08:00
|
|
|
struct bio *last = bio_list->tail;
|
|
|
|
int ret;
|
|
|
|
struct bio *bio;
|
2021-09-15 15:17:16 +08:00
|
|
|
struct btrfs_io_stripe *stripe;
|
2013-01-30 07:40:14 +08:00
|
|
|
u64 disk_start;
|
|
|
|
|
2022-04-01 19:23:21 +08:00
|
|
|
/*
|
|
|
|
* Note: here stripe_nr has taken device replace into consideration,
|
|
|
|
* thus it can be larger than rbio->real_stripe.
|
|
|
|
* So here we check against bioc->num_stripes, not rbio->real_stripes.
|
|
|
|
*/
|
|
|
|
ASSERT(stripe_nr >= 0 && stripe_nr < rbio->bioc->num_stripes);
|
|
|
|
ASSERT(sector_nr >= 0 && sector_nr < rbio->stripe_nsectors);
|
|
|
|
ASSERT(sector->page);
|
|
|
|
|
2021-09-15 15:17:16 +08:00
|
|
|
stripe = &rbio->bioc->stripes[stripe_nr];
|
2022-04-01 19:23:21 +08:00
|
|
|
disk_start = stripe->physical + sector_nr * sectorsize;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
/* if the device is missing, just fail this stripe */
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
if (!stripe->dev->bdev) {
|
2022-11-07 15:32:31 +08:00
|
|
|
int found_errors;
|
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
set_bit(stripe_nr * rbio->stripe_nsectors + sector_nr,
|
|
|
|
rbio->error_bitmap);
|
2022-11-07 15:32:31 +08:00
|
|
|
|
|
|
|
/* Check if we have reached tolerance early. */
|
|
|
|
found_errors = get_rbio_veritical_errors(rbio, sector_nr,
|
|
|
|
NULL, NULL);
|
|
|
|
if (found_errors > rbio->bioc->max_errors)
|
|
|
|
return -EIO;
|
|
|
|
return 0;
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
/* see if we can add this page onto our existing bio */
|
|
|
|
if (last) {
|
2023-04-15 19:32:38 +08:00
|
|
|
u64 last_end = last->bi_iter.bi_sector << SECTOR_SHIFT;
|
2013-10-12 06:44:27 +08:00
|
|
|
last_end += last->bi_iter.bi_size;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* we can't merge these if they are from different
|
|
|
|
* devices or if they are not contiguous
|
|
|
|
*/
|
2020-07-02 21:46:42 +08:00
|
|
|
if (last_end == disk_start && !last->bi_status &&
|
2021-01-24 18:02:34 +08:00
|
|
|
last->bi_bdev == stripe->dev->bdev) {
|
2022-04-01 19:23:21 +08:00
|
|
|
ret = bio_add_page(last, sector->page, sectorsize,
|
|
|
|
sector->pgoff);
|
|
|
|
if (ret == sectorsize)
|
2013-01-30 07:40:14 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* put a new bio on the list */
|
2022-06-17 18:04:05 +08:00
|
|
|
bio = bio_alloc(stripe->dev->bdev,
|
|
|
|
max(BTRFS_STRIPE_LEN >> PAGE_SHIFT, 1),
|
2022-07-15 02:07:16 +08:00
|
|
|
op, GFP_NOFS);
|
2023-04-15 17:51:23 +08:00
|
|
|
bio->bi_iter.bi_sector = disk_start >> SECTOR_SHIFT;
|
2022-04-04 12:45:25 +08:00
|
|
|
bio->bi_private = rbio;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2023-03-30 18:43:51 +08:00
|
|
|
__bio_add_page(bio, sector->page, sectorsize, sector->pgoff);
|
2013-01-30 07:40:14 +08:00
|
|
|
bio_list_add(bio_list, bio);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-04-01 19:23:20 +08:00
|
|
|
static void index_one_bio(struct btrfs_raid_bio *rbio, struct bio *bio)
|
|
|
|
{
|
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
|
|
|
struct bio_vec bvec;
|
|
|
|
struct bvec_iter iter;
|
|
|
|
u32 offset = (bio->bi_iter.bi_sector << SECTOR_SHIFT) -
|
2023-02-17 13:37:03 +08:00
|
|
|
rbio->bioc->full_stripe_logical;
|
2022-04-01 19:23:20 +08:00
|
|
|
|
|
|
|
bio_for_each_segment(bvec, bio, iter) {
|
|
|
|
u32 bvec_offset;
|
|
|
|
|
|
|
|
for (bvec_offset = 0; bvec_offset < bvec.bv_len;
|
|
|
|
bvec_offset += sectorsize, offset += sectorsize) {
|
|
|
|
int index = offset / sectorsize;
|
|
|
|
struct sector_ptr *sector = &rbio->bio_sectors[index];
|
|
|
|
|
|
|
|
sector->page = bvec.bv_page;
|
|
|
|
sector->pgoff = bvec.bv_offset + bvec_offset;
|
|
|
|
ASSERT(sector->pgoff < PAGE_SIZE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* helper function to walk our bio list and populate the bio_pages array with
|
|
|
|
* the result. This seems expensive, but it is faster than constantly
|
|
|
|
* searching through the bio list as we setup the IO in finish_rmw or stripe
|
|
|
|
* reconstruction.
|
|
|
|
*
|
|
|
|
* This must be called before you trust the answers from page_in_rbio
|
|
|
|
*/
|
|
|
|
static void index_rbio_pages(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
struct bio *bio;
|
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&rbio->bio_list_lock);
|
2022-04-01 19:23:20 +08:00
|
|
|
bio_list_for_each(bio, &rbio->bio_list)
|
|
|
|
index_one_bio(rbio, bio);
|
|
|
|
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
2022-06-01 17:46:59 +08:00
|
|
|
static void bio_get_trace_info(struct btrfs_raid_bio *rbio, struct bio *bio,
|
|
|
|
struct raid56_bio_trace_info *trace_info)
|
|
|
|
{
|
|
|
|
const struct btrfs_io_context *bioc = rbio->bioc;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
ASSERT(bioc);
|
|
|
|
|
|
|
|
/* We rely on bio->bi_bdev to find the stripe number. */
|
|
|
|
if (!bio->bi_bdev)
|
|
|
|
goto not_found;
|
|
|
|
|
|
|
|
for (i = 0; i < bioc->num_stripes; i++) {
|
|
|
|
if (bio->bi_bdev != bioc->stripes[i].dev->bdev)
|
|
|
|
continue;
|
|
|
|
trace_info->stripe_nr = i;
|
|
|
|
trace_info->devid = bioc->stripes[i].dev->devid;
|
|
|
|
trace_info->offset = (bio->bi_iter.bi_sector << SECTOR_SHIFT) -
|
|
|
|
bioc->stripes[i].physical;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
not_found:
|
|
|
|
trace_info->devid = -1;
|
|
|
|
trace_info->offset = -1;
|
|
|
|
trace_info->stripe_nr = -1;
|
|
|
|
}
|
|
|
|
|
2023-01-11 14:23:28 +08:00
|
|
|
static inline void bio_list_put(struct bio_list *bio_list)
|
|
|
|
{
|
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
while ((bio = bio_list_pop(bio_list)))
|
|
|
|
bio_put(bio);
|
|
|
|
}
|
|
|
|
|
2023-01-17 18:03:21 +08:00
|
|
|
/* Generate PQ for one vertical stripe. */
|
2022-11-01 19:16:02 +08:00
|
|
|
static void generate_pq_vertical(struct btrfs_raid_bio *rbio, int sectornr)
|
|
|
|
{
|
|
|
|
void **pointers = rbio->finish_pointers;
|
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
int stripe;
|
|
|
|
const bool has_qstripe = rbio->bioc->map_type & BTRFS_BLOCK_GROUP_RAID6;
|
|
|
|
|
|
|
|
/* First collect one sector from each data stripe */
|
|
|
|
for (stripe = 0; stripe < rbio->nr_data; stripe++) {
|
|
|
|
sector = sector_in_rbio(rbio, stripe, sectornr, 0);
|
|
|
|
pointers[stripe] = kmap_local_page(sector->page) +
|
|
|
|
sector->pgoff;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Then add the parity stripe */
|
|
|
|
sector = rbio_pstripe_sector(rbio, sectornr);
|
|
|
|
sector->uptodate = 1;
|
|
|
|
pointers[stripe++] = kmap_local_page(sector->page) + sector->pgoff;
|
|
|
|
|
|
|
|
if (has_qstripe) {
|
|
|
|
/*
|
|
|
|
* RAID6, add the qstripe and call the library function
|
|
|
|
* to fill in our p/q
|
|
|
|
*/
|
|
|
|
sector = rbio_qstripe_sector(rbio, sectornr);
|
|
|
|
sector->uptodate = 1;
|
|
|
|
pointers[stripe++] = kmap_local_page(sector->page) +
|
|
|
|
sector->pgoff;
|
|
|
|
|
|
|
|
raid6_call.gen_syndrome(rbio->real_stripes, sectorsize,
|
|
|
|
pointers);
|
|
|
|
} else {
|
|
|
|
/* raid5 */
|
|
|
|
memcpy(pointers[rbio->nr_data], pointers[0], sectorsize);
|
|
|
|
run_xor(pointers + 1, rbio->nr_data - 1, sectorsize);
|
|
|
|
}
|
|
|
|
for (stripe = stripe - 1; stripe >= 0; stripe--)
|
|
|
|
kunmap_local(pointers[stripe]);
|
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:07 +08:00
|
|
|
static int rmw_assemble_write_bios(struct btrfs_raid_bio *rbio,
|
|
|
|
struct bio_list *bio_list)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2022-06-02 15:51:18 +08:00
|
|
|
/* The total sector number inside the full stripe. */
|
|
|
|
int total_sector_nr;
|
2022-04-01 19:23:21 +08:00
|
|
|
int sectornr;
|
2022-11-01 19:16:07 +08:00
|
|
|
int stripe;
|
2013-01-30 07:40:14 +08:00
|
|
|
int ret;
|
|
|
|
|
2022-11-01 19:16:07 +08:00
|
|
|
ASSERT(bio_list_size(bio_list) == 0);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-05-27 15:28:19 +08:00
|
|
|
/* We should have at least one data sector. */
|
|
|
|
ASSERT(bitmap_weight(&rbio->dbitmap, rbio->stripe_nsectors));
|
|
|
|
|
2022-11-01 19:16:08 +08:00
|
|
|
/*
|
|
|
|
* Reset errors, as we may have errors inherited from from degraded
|
|
|
|
* write.
|
|
|
|
*/
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
bitmap_clear(rbio->error_bitmap, 0, rbio->nr_sectors);
|
2022-11-01 19:16:08 +08:00
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
2022-11-01 19:16:07 +08:00
|
|
|
* Start assembly. Make bios for everything from the higher layers (the
|
2022-06-02 15:51:18 +08:00
|
|
|
* bio_list in our rbio) and our P/Q. Ignore everything else.
|
2013-01-30 07:40:14 +08:00
|
|
|
*/
|
2022-06-02 15:51:18 +08:00
|
|
|
for (total_sector_nr = 0; total_sector_nr < rbio->nr_sectors;
|
|
|
|
total_sector_nr++) {
|
|
|
|
struct sector_ptr *sector;
|
2022-04-01 19:23:21 +08:00
|
|
|
|
2022-06-02 15:51:18 +08:00
|
|
|
stripe = total_sector_nr / rbio->stripe_nsectors;
|
|
|
|
sectornr = total_sector_nr % rbio->stripe_nsectors;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-06-02 15:51:18 +08:00
|
|
|
/* This vertical stripe has no data, skip it. */
|
|
|
|
if (!test_bit(sectornr, &rbio->dbitmap))
|
|
|
|
continue;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-06-02 15:51:18 +08:00
|
|
|
if (stripe < rbio->nr_data) {
|
|
|
|
sector = sector_in_rbio(rbio, stripe, sectornr, 1);
|
|
|
|
if (!sector)
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
sector = rbio_stripe_sector(rbio, stripe, sectornr);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
2022-06-02 15:51:18 +08:00
|
|
|
|
2022-11-01 19:16:07 +08:00
|
|
|
ret = rbio_add_io_sector(rbio, bio_list, sector, stripe,
|
2022-06-17 18:04:05 +08:00
|
|
|
sectornr, REQ_OP_WRITE);
|
2022-06-02 15:51:18 +08:00
|
|
|
if (ret)
|
2022-11-01 19:16:07 +08:00
|
|
|
goto error;
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
if (likely(!rbio->bioc->replace_nr_stripes))
|
2022-11-01 19:16:07 +08:00
|
|
|
return 0;
|
2014-11-14 16:06:25 +08:00
|
|
|
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
/*
|
|
|
|
* Make a copy for the replace target device.
|
|
|
|
*
|
|
|
|
* Thus the source stripe number (in replace_stripe_src) should be valid.
|
|
|
|
*/
|
|
|
|
ASSERT(rbio->bioc->replace_stripe_src >= 0);
|
|
|
|
|
2022-06-02 15:51:18 +08:00
|
|
|
for (total_sector_nr = 0; total_sector_nr < rbio->nr_sectors;
|
|
|
|
total_sector_nr++) {
|
|
|
|
struct sector_ptr *sector;
|
2014-11-14 16:06:25 +08:00
|
|
|
|
2022-06-02 15:51:18 +08:00
|
|
|
stripe = total_sector_nr / rbio->stripe_nsectors;
|
|
|
|
sectornr = total_sector_nr % rbio->stripe_nsectors;
|
2022-04-01 19:23:21 +08:00
|
|
|
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
/*
|
|
|
|
* For RAID56, there is only one device that can be replaced,
|
|
|
|
* and replace_stripe_src[0] indicates the stripe number we
|
|
|
|
* need to copy from.
|
|
|
|
*/
|
|
|
|
if (stripe != rbio->bioc->replace_stripe_src) {
|
2022-06-02 15:51:18 +08:00
|
|
|
/*
|
|
|
|
* We can skip the whole stripe completely, note
|
|
|
|
* total_sector_nr will be increased by one anyway.
|
|
|
|
*/
|
|
|
|
ASSERT(sectornr == 0);
|
|
|
|
total_sector_nr += rbio->stripe_nsectors - 1;
|
|
|
|
continue;
|
|
|
|
}
|
2014-11-14 16:06:25 +08:00
|
|
|
|
2022-06-02 15:51:18 +08:00
|
|
|
/* This vertical stripe has no data, skip it. */
|
|
|
|
if (!test_bit(sectornr, &rbio->dbitmap))
|
|
|
|
continue;
|
2014-11-14 16:06:25 +08:00
|
|
|
|
2022-06-02 15:51:18 +08:00
|
|
|
if (stripe < rbio->nr_data) {
|
|
|
|
sector = sector_in_rbio(rbio, stripe, sectornr, 1);
|
|
|
|
if (!sector)
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
sector = rbio_stripe_sector(rbio, stripe, sectornr);
|
2014-11-14 16:06:25 +08:00
|
|
|
}
|
2022-06-02 15:51:18 +08:00
|
|
|
|
2022-11-01 19:16:07 +08:00
|
|
|
ret = rbio_add_io_sector(rbio, bio_list, sector,
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
rbio->real_stripes,
|
2022-06-17 18:04:05 +08:00
|
|
|
sectornr, REQ_OP_WRITE);
|
2022-06-02 15:51:18 +08:00
|
|
|
if (ret)
|
2022-11-01 19:16:07 +08:00
|
|
|
goto error;
|
2014-11-14 16:06:25 +08:00
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:07 +08:00
|
|
|
return 0;
|
|
|
|
error:
|
2023-01-11 14:23:28 +08:00
|
|
|
bio_list_put(bio_list);
|
2022-11-01 19:16:07 +08:00
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
static void set_rbio_range_error(struct btrfs_raid_bio *rbio, struct bio *bio)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = rbio->bioc->fs_info;
|
|
|
|
u32 offset = (bio->bi_iter.bi_sector << SECTOR_SHIFT) -
|
2023-02-17 13:37:03 +08:00
|
|
|
rbio->bioc->full_stripe_logical;
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
int total_nr_sector = offset >> fs_info->sectorsize_bits;
|
|
|
|
|
|
|
|
ASSERT(total_nr_sector < rbio->nr_data * rbio->stripe_nsectors);
|
|
|
|
|
|
|
|
bitmap_set(rbio->error_bitmap, total_nr_sector,
|
|
|
|
bio->bi_iter.bi_size >> fs_info->sectorsize_bits);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Special handling for raid56_alloc_missing_rbio() used by
|
|
|
|
* scrub/replace. Unlike call path in raid56_parity_recover(), they
|
|
|
|
* pass an empty bio here. Thus we have to find out the missing device
|
|
|
|
* and mark the stripe error instead.
|
|
|
|
*/
|
|
|
|
if (bio->bi_iter.bi_size == 0) {
|
|
|
|
bool found_missing = false;
|
|
|
|
int stripe_nr;
|
|
|
|
|
|
|
|
for (stripe_nr = 0; stripe_nr < rbio->real_stripes; stripe_nr++) {
|
|
|
|
if (!rbio->bioc->stripes[stripe_nr].dev->bdev) {
|
|
|
|
found_missing = true;
|
|
|
|
bitmap_set(rbio->error_bitmap,
|
|
|
|
stripe_nr * rbio->stripe_nsectors,
|
|
|
|
rbio->stripe_nsectors);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ASSERT(found_missing);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-04-01 19:23:28 +08:00
|
|
|
/*
|
2023-01-17 18:03:21 +08:00
|
|
|
* For subpage case, we can no longer set page Up-to-date directly for
|
2022-04-01 19:23:28 +08:00
|
|
|
* stripe_pages[], thus we need to locate the sector.
|
|
|
|
*/
|
|
|
|
static struct sector_ptr *find_stripe_sector(struct btrfs_raid_bio *rbio,
|
|
|
|
struct page *page,
|
|
|
|
unsigned int pgoff)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < rbio->nr_sectors; i++) {
|
|
|
|
struct sector_ptr *sector = &rbio->stripe_sectors[i];
|
|
|
|
|
|
|
|
if (sector->page == page && sector->pgoff == pgoff)
|
|
|
|
return sector;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* this sets each page in the bio uptodate. It should only be used on private
|
|
|
|
* rbio pages, nothing that comes in from the higher layers
|
|
|
|
*/
|
2022-04-01 19:23:28 +08:00
|
|
|
static void set_bio_pages_uptodate(struct btrfs_raid_bio *rbio, struct bio *bio)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2022-04-01 19:23:28 +08:00
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
2018-01-13 09:07:01 +08:00
|
|
|
struct bio_vec *bvec;
|
2019-02-15 19:13:19 +08:00
|
|
|
struct bvec_iter_all iter_all;
|
Btrfs: fix write corruption due to bio cloning on raid5/6
The recent changes to make bio cloning faster (added in the 4.13 merge
window) by using the bio_clone_fast() API introduced a regression on
raid5/6 modes, because cloned bios have an invalid bi_vcnt field
(therefore it can not be used) and the raid5/6 code uses the
bio_for_each_segment_all() API to iterate the segments of a bio, and this
API uses a bio's bi_vcnt field.
The issue is very simple to trigger by doing for example a direct IO write
against a raid5 or raid6 filesystem and then attempting to read what we
wrote before:
$ mkfs.btrfs -m raid5 -d raid5 -f /dev/sdc /dev/sdd /dev/sde /dev/sdf
$ mount /dev/sdc /mnt
$ xfs_io -f -d -c "pwrite -S 0xab 0 1M" /mnt/foobar
$ od -t x1 /mnt/foobar
od: /mnt/foobar: read error: Input/output error
For that example, the following is also reported in dmesg/syslog:
[18274.985557] btrfs_print_data_csum_error: 18 callbacks suppressed
[18274.995277] BTRFS warning (device sdf): csum failed root 5 ino 257 off 0 csum 0x98f94189 expected csum 0x94374193 mirror 1
[18274.997205] BTRFS warning (device sdf): csum failed root 5 ino 257 off 4096 csum 0x98f94189 expected csum 0x94374193 mirror 1
[18275.025221] BTRFS warning (device sdf): csum failed root 5 ino 257 off 8192 csum 0x98f94189 expected csum 0x94374193 mirror 1
[18275.047422] BTRFS warning (device sdf): csum failed root 5 ino 257 off 12288 csum 0x98f94189 expected csum 0x94374193 mirror 1
[18275.054818] BTRFS warning (device sdf): csum failed root 5 ino 257 off 4096 csum 0x98f94189 expected csum 0x94374193 mirror 1
[18275.054834] BTRFS warning (device sdf): csum failed root 5 ino 257 off 8192 csum 0x98f94189 expected csum 0x94374193 mirror 1
[18275.054943] BTRFS warning (device sdf): csum failed root 5 ino 257 off 8192 csum 0x98f94189 expected csum 0x94374193 mirror 2
[18275.055207] BTRFS warning (device sdf): csum failed root 5 ino 257 off 8192 csum 0x98f94189 expected csum 0x94374193 mirror 3
[18275.055571] BTRFS warning (device sdf): csum failed root 5 ino 257 off 0 csum 0x98f94189 expected csum 0x94374193 mirror 1
[18275.062171] BTRFS warning (device sdf): csum failed root 5 ino 257 off 12288 csum 0x98f94189 expected csum 0x94374193 mirror 1
A scrub will also fail correcting bad copies, mentioning the following in
dmesg/syslog:
[18276.128696] scrub_handle_errored_block: 498 callbacks suppressed
[18276.129617] BTRFS warning (device sdf): checksum error at logical 2186346496 on dev /dev/sde, sector 2116608, root 5, inode 257, offset 65536, length 4096, links $
[18276.149235] btrfs_dev_stat_print_on_error: 498 callbacks suppressed
[18276.157897] BTRFS error (device sdf): bdev /dev/sde errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[18276.206059] BTRFS warning (device sdf): checksum error at logical 2186477568 on dev /dev/sdd, sector 2116736, root 5, inode 257, offset 196608, length 4096, links$
[18276.206059] BTRFS error (device sdf): bdev /dev/sdd errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[18276.306552] BTRFS warning (device sdf): checksum error at logical 2186543104 on dev /dev/sdd, sector 2116864, root 5, inode 257, offset 262144, length 4096, links$
[18276.319152] BTRFS error (device sdf): bdev /dev/sdd errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[18276.394316] BTRFS warning (device sdf): checksum error at logical 2186739712 on dev /dev/sdf, sector 2116992, root 5, inode 257, offset 458752, length 4096, links$
[18276.396348] BTRFS error (device sdf): bdev /dev/sdf errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[18276.434127] BTRFS warning (device sdf): checksum error at logical 2186870784 on dev /dev/sde, sector 2117120, root 5, inode 257, offset 589824, length 4096, links$
[18276.434127] BTRFS error (device sdf): bdev /dev/sde errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[18276.500504] BTRFS error (device sdf): unable to fixup (regular) error at logical 2186477568 on dev /dev/sdd
[18276.538400] BTRFS warning (device sdf): checksum error at logical 2186481664 on dev /dev/sdd, sector 2116744, root 5, inode 257, offset 200704, length 4096, links$
[18276.540452] BTRFS error (device sdf): bdev /dev/sdd errs: wr 0, rd 0, flush 0, corrupt 3, gen 0
[18276.542012] BTRFS error (device sdf): unable to fixup (regular) error at logical 2186481664 on dev /dev/sdd
[18276.585030] BTRFS error (device sdf): unable to fixup (regular) error at logical 2186346496 on dev /dev/sde
[18276.598306] BTRFS warning (device sdf): checksum error at logical 2186412032 on dev /dev/sde, sector 2116736, root 5, inode 257, offset 131072, length 4096, links$
[18276.598310] BTRFS error (device sdf): bdev /dev/sde errs: wr 0, rd 0, flush 0, corrupt 3, gen 0
[18276.598582] BTRFS error (device sdf): unable to fixup (regular) error at logical 2186350592 on dev /dev/sde
[18276.603455] BTRFS error (device sdf): bdev /dev/sde errs: wr 0, rd 0, flush 0, corrupt 4, gen 0
[18276.638362] BTRFS warning (device sdf): checksum error at logical 2186354688 on dev /dev/sde, sector 2116624, root 5, inode 257, offset 73728, length 4096, links $
[18276.640445] BTRFS error (device sdf): bdev /dev/sde errs: wr 0, rd 0, flush 0, corrupt 5, gen 0
[18276.645942] BTRFS error (device sdf): unable to fixup (regular) error at logical 2186354688 on dev /dev/sde
[18276.657204] BTRFS error (device sdf): unable to fixup (regular) error at logical 2186412032 on dev /dev/sde
[18276.660563] BTRFS warning (device sdf): checksum error at logical 2186416128 on dev /dev/sde, sector 2116744, root 5, inode 257, offset 135168, length 4096, links$
[18276.664609] BTRFS error (device sdf): bdev /dev/sde errs: wr 0, rd 0, flush 0, corrupt 6, gen 0
[18276.664609] BTRFS error (device sdf): unable to fixup (regular) error at logical 2186358784 on dev /dev/sde
So fix this by using the bio_for_each_segment() API and setting before
the bio's bi_iter field to the value of the corresponding btrfs bio
container's saved iterator if we are processing a cloned bio in the
raid5/6 code (the same code processes both cloned and non-cloned bios).
This incorrect iteration of cloned bios was also causing some occasional
BUG_ONs when running fstest btrfs/064, which have a trace like the
following:
[ 6674.416156] ------------[ cut here ]------------
[ 6674.416157] kernel BUG at fs/btrfs/raid56.c:1897!
[ 6674.416159] invalid opcode: 0000 [#1] PREEMPT SMP
[ 6674.416160] Modules linked in: dm_flakey dm_mod dax ppdev tpm_tis parport_pc tpm_tis_core evdev tpm psmouse sg i2c_piix4 pcspkr parport i2c_core serio_raw button s
[ 6674.416184] CPU: 3 PID: 19236 Comm: kworker/u32:10 Not tainted 4.12.0-rc6-btrfs-next-44+ #1
[ 6674.416185] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 6674.416210] Workqueue: btrfs-endio btrfs_endio_helper [btrfs]
[ 6674.416211] task: ffff880147f6c740 task.stack: ffffc90001fb8000
[ 6674.416229] RIP: 0010:__raid_recover_end_io+0x1ac/0x370 [btrfs]
[ 6674.416230] RSP: 0018:ffffc90001fbbb90 EFLAGS: 00010217
[ 6674.416231] RAX: ffff8801ff4b4f00 RBX: 0000000000000002 RCX: 0000000000000001
[ 6674.416232] RDX: ffff880099b045d8 RSI: ffffffff81a5f6e0 RDI: 0000000000000004
[ 6674.416232] RBP: ffffc90001fbbbc8 R08: 0000000000000001 R09: 0000000000000001
[ 6674.416233] R10: ffffc90001fbbac8 R11: 0000000000001000 R12: 0000000000000002
[ 6674.416234] R13: ffff880099b045c0 R14: 0000000000000004 R15: ffff88012bff2000
[ 6674.416235] FS: 0000000000000000(0000) GS:ffff88023f2c0000(0000) knlGS:0000000000000000
[ 6674.416235] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6674.416236] CR2: 00007f28cf282000 CR3: 00000001000c6000 CR4: 00000000000006e0
[ 6674.416239] Call Trace:
[ 6674.416259] __raid56_parity_recover+0xfc/0x16e [btrfs]
[ 6674.416276] raid56_parity_recover+0x157/0x16b [btrfs]
[ 6674.416293] btrfs_map_bio+0xe0/0x259 [btrfs]
[ 6674.416310] btrfs_submit_bio_hook+0xbf/0x147 [btrfs]
[ 6674.416327] end_bio_extent_readpage+0x27b/0x4a0 [btrfs]
[ 6674.416331] bio_endio+0x17d/0x1b3
[ 6674.416346] end_workqueue_fn+0x3c/0x3f [btrfs]
[ 6674.416362] btrfs_scrubparity_helper+0x1aa/0x3b8 [btrfs]
[ 6674.416379] btrfs_endio_helper+0xe/0x10 [btrfs]
[ 6674.416381] process_one_work+0x276/0x4b6
[ 6674.416384] worker_thread+0x1ac/0x266
[ 6674.416386] ? rescuer_thread+0x278/0x278
[ 6674.416387] kthread+0x106/0x10e
[ 6674.416389] ? __list_del_entry+0x22/0x22
[ 6674.416391] ret_from_fork+0x27/0x40
[ 6674.416395] Code: 44 89 e2 be 00 10 00 00 ff 15 b0 ab ef ff eb 72 4d 89 e8 89 d9 44 89 e2 be 00 10 00 00 ff 15 a3 ab ef ff eb 5d 41 83 fc ff 74 02 <0f> 0b 49 63 97
[ 6674.416432] RIP: __raid_recover_end_io+0x1ac/0x370 [btrfs] RSP: ffffc90001fbbb90
[ 6674.416434] ---[ end trace 74d56ebe7489dd6a ]---
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
2017-07-13 06:36:02 +08:00
|
|
|
|
2018-01-13 09:07:01 +08:00
|
|
|
ASSERT(!bio_flagged(bio, BIO_CLONED));
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-04-01 19:23:28 +08:00
|
|
|
bio_for_each_segment_all(bvec, bio, iter_all) {
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
int pgoff;
|
|
|
|
|
|
|
|
for (pgoff = bvec->bv_offset; pgoff - bvec->bv_offset < bvec->bv_len;
|
|
|
|
pgoff += sectorsize) {
|
|
|
|
sector = find_stripe_sector(rbio, bvec->bv_page, pgoff);
|
|
|
|
ASSERT(sector);
|
|
|
|
if (sector)
|
|
|
|
sector->uptodate = 1;
|
|
|
|
}
|
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
static int get_bio_sector_nr(struct btrfs_raid_bio *rbio, struct bio *bio)
|
|
|
|
{
|
|
|
|
struct bio_vec *bv = bio_first_bvec_all(bio);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < rbio->nr_sectors; i++) {
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
|
|
|
|
sector = &rbio->stripe_sectors[i];
|
|
|
|
if (sector->page == bv->bv_page && sector->pgoff == bv->bv_offset)
|
|
|
|
break;
|
|
|
|
sector = &rbio->bio_sectors[i];
|
|
|
|
if (sector->page == bv->bv_page && sector->pgoff == bv->bv_offset)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ASSERT(i < rbio->nr_sectors);
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rbio_update_error_bitmap(struct btrfs_raid_bio *rbio, struct bio *bio)
|
|
|
|
{
|
|
|
|
int total_sector_nr = get_bio_sector_nr(rbio, bio);
|
|
|
|
u32 bio_size = 0;
|
|
|
|
struct bio_vec *bvec;
|
2023-01-21 16:06:11 +08:00
|
|
|
int i;
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
|
2023-01-21 16:06:12 +08:00
|
|
|
bio_for_each_bvec_all(bvec, bio, i)
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
bio_size += bvec->bv_len;
|
|
|
|
|
2023-01-21 16:06:11 +08:00
|
|
|
/*
|
|
|
|
* Since we can have multiple bios touching the error_bitmap, we cannot
|
|
|
|
* call bitmap_set() without protection.
|
|
|
|
*
|
|
|
|
* Instead use set_bit() for each bit, as set_bit() itself is atomic.
|
|
|
|
*/
|
|
|
|
for (i = total_sector_nr; i < total_sector_nr +
|
|
|
|
(bio_size >> rbio->bioc->fs_info->sectorsize_bits); i++)
|
|
|
|
set_bit(i, rbio->error_bitmap);
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
}
|
|
|
|
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
/* Verify the data sectors at read time. */
|
|
|
|
static void verify_bio_data_sectors(struct btrfs_raid_bio *rbio,
|
|
|
|
struct bio *bio)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = rbio->bioc->fs_info;
|
|
|
|
int total_sector_nr = get_bio_sector_nr(rbio, bio);
|
|
|
|
struct bio_vec *bvec;
|
|
|
|
struct bvec_iter_all iter_all;
|
|
|
|
|
|
|
|
/* No data csum for the whole stripe, no need to verify. */
|
|
|
|
if (!rbio->csum_bitmap || !rbio->csum_buf)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* P/Q stripes, they have no data csum to verify against. */
|
|
|
|
if (total_sector_nr >= rbio->nr_data * rbio->stripe_nsectors)
|
|
|
|
return;
|
|
|
|
|
|
|
|
bio_for_each_segment_all(bvec, bio, iter_all) {
|
|
|
|
int bv_offset;
|
|
|
|
|
|
|
|
for (bv_offset = bvec->bv_offset;
|
|
|
|
bv_offset < bvec->bv_offset + bvec->bv_len;
|
|
|
|
bv_offset += fs_info->sectorsize, total_sector_nr++) {
|
|
|
|
u8 csum_buf[BTRFS_CSUM_SIZE];
|
|
|
|
u8 *expected_csum = rbio->csum_buf +
|
|
|
|
total_sector_nr * fs_info->csum_size;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* No csum for this sector, skip to the next sector. */
|
|
|
|
if (!test_bit(total_sector_nr, rbio->csum_bitmap))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = btrfs_check_sector_csum(fs_info, bvec->bv_page,
|
|
|
|
bv_offset, csum_buf, expected_csum);
|
|
|
|
if (ret < 0)
|
|
|
|
set_bit(total_sector_nr, rbio->error_bitmap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:05 +08:00
|
|
|
static void raid_wait_read_end_io(struct bio *bio)
|
|
|
|
{
|
|
|
|
struct btrfs_raid_bio *rbio = bio->bi_private;
|
|
|
|
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
if (bio->bi_status) {
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
rbio_update_error_bitmap(rbio, bio);
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
} else {
|
2022-11-01 19:16:05 +08:00
|
|
|
set_bio_pages_uptodate(rbio, bio);
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
verify_bio_data_sectors(rbio, bio);
|
|
|
|
}
|
2022-11-01 19:16:05 +08:00
|
|
|
|
|
|
|
bio_put(bio);
|
|
|
|
if (atomic_dec_and_test(&rbio->stripes_pending))
|
|
|
|
wake_up(&rbio->io_wait);
|
|
|
|
}
|
|
|
|
|
2023-01-11 14:23:27 +08:00
|
|
|
static void submit_read_wait_bio_list(struct btrfs_raid_bio *rbio,
|
2022-11-01 19:16:05 +08:00
|
|
|
struct bio_list *bio_list)
|
|
|
|
{
|
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
atomic_set(&rbio->stripes_pending, bio_list_size(bio_list));
|
|
|
|
while ((bio = bio_list_pop(bio_list))) {
|
|
|
|
bio->bi_end_io = raid_wait_read_end_io;
|
|
|
|
|
|
|
|
if (trace_raid56_scrub_read_recover_enabled()) {
|
|
|
|
struct raid56_bio_trace_info trace_info = { 0 };
|
|
|
|
|
|
|
|
bio_get_trace_info(rbio, bio, &trace_info);
|
|
|
|
trace_raid56_scrub_read_recover(rbio, bio, &trace_info);
|
|
|
|
}
|
|
|
|
submit_bio(bio);
|
|
|
|
}
|
2023-01-11 14:23:27 +08:00
|
|
|
|
|
|
|
wait_event(rbio->io_wait, atomic_read(&rbio->stripes_pending) == 0);
|
2022-11-01 19:16:05 +08:00
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:08 +08:00
|
|
|
static int alloc_rbio_data_pages(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
const int data_pages = rbio->nr_data * rbio->stripe_npages;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = btrfs_alloc_page_array(data_pages, rbio->stripe_pages);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
index_stripe_sectors(rbio);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-02-01 03:42:28 +08:00
|
|
|
/*
|
|
|
|
* We use plugging call backs to collect full stripes.
|
|
|
|
* Any time we get a partial stripe write while plugged
|
|
|
|
* we collect it into a list. When the unplug comes down,
|
|
|
|
* we sort the list by logical block number and merge
|
|
|
|
* everything we can into the same rbios
|
|
|
|
*/
|
|
|
|
struct btrfs_plug_cb {
|
|
|
|
struct blk_plug_cb cb;
|
|
|
|
struct btrfs_fs_info *info;
|
|
|
|
struct list_head rbio_list;
|
2022-04-18 12:43:11 +08:00
|
|
|
struct work_struct work;
|
2013-02-01 03:42:28 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* rbios on the plug list are sorted for easier merging.
|
|
|
|
*/
|
2021-04-09 02:28:34 +08:00
|
|
|
static int plug_cmp(void *priv, const struct list_head *a,
|
|
|
|
const struct list_head *b)
|
2013-02-01 03:42:28 +08:00
|
|
|
{
|
2021-07-26 20:15:26 +08:00
|
|
|
const struct btrfs_raid_bio *ra = container_of(a, struct btrfs_raid_bio,
|
|
|
|
plug_list);
|
|
|
|
const struct btrfs_raid_bio *rb = container_of(b, struct btrfs_raid_bio,
|
|
|
|
plug_list);
|
2013-10-12 06:44:27 +08:00
|
|
|
u64 a_sector = ra->bio_list.head->bi_iter.bi_sector;
|
|
|
|
u64 b_sector = rb->bio_list.head->bi_iter.bi_sector;
|
2013-02-01 03:42:28 +08:00
|
|
|
|
|
|
|
if (a_sector < b_sector)
|
|
|
|
return -1;
|
|
|
|
if (a_sector > b_sector)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:09 +08:00
|
|
|
static void raid_unplug(struct blk_plug_cb *cb, bool from_schedule)
|
2013-02-01 03:42:28 +08:00
|
|
|
{
|
2022-11-01 19:16:09 +08:00
|
|
|
struct btrfs_plug_cb *plug = container_of(cb, struct btrfs_plug_cb, cb);
|
2013-02-01 03:42:28 +08:00
|
|
|
struct btrfs_raid_bio *cur;
|
|
|
|
struct btrfs_raid_bio *last = NULL;
|
|
|
|
|
|
|
|
list_sort(NULL, &plug->rbio_list, plug_cmp);
|
2022-11-01 19:16:09 +08:00
|
|
|
|
2013-02-01 03:42:28 +08:00
|
|
|
while (!list_empty(&plug->rbio_list)) {
|
|
|
|
cur = list_entry(plug->rbio_list.next,
|
|
|
|
struct btrfs_raid_bio, plug_list);
|
|
|
|
list_del_init(&cur->plug_list);
|
|
|
|
|
|
|
|
if (rbio_is_full(cur)) {
|
2022-11-01 19:16:09 +08:00
|
|
|
/* We have a full stripe, queue it down. */
|
|
|
|
start_async_work(cur, rmw_rbio_work);
|
2013-02-01 03:42:28 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (last) {
|
|
|
|
if (rbio_can_merge(last, cur)) {
|
|
|
|
merge_rbio(last, cur);
|
2022-10-10 18:36:08 +08:00
|
|
|
free_raid_bio(cur);
|
2013-02-01 03:42:28 +08:00
|
|
|
continue;
|
|
|
|
}
|
2022-11-01 19:16:09 +08:00
|
|
|
start_async_work(last, rmw_rbio_work);
|
2013-02-01 03:42:28 +08:00
|
|
|
}
|
|
|
|
last = cur;
|
|
|
|
}
|
2022-11-01 19:16:09 +08:00
|
|
|
if (last)
|
|
|
|
start_async_work(last, rmw_rbio_work);
|
2013-02-01 03:42:28 +08:00
|
|
|
kfree(plug);
|
|
|
|
}
|
|
|
|
|
2022-05-27 15:28:19 +08:00
|
|
|
/* Add the original bio into rbio->bio_list, and update rbio::dbitmap. */
|
|
|
|
static void rbio_add_bio(struct btrfs_raid_bio *rbio, struct bio *orig_bio)
|
|
|
|
{
|
|
|
|
const struct btrfs_fs_info *fs_info = rbio->bioc->fs_info;
|
|
|
|
const u64 orig_logical = orig_bio->bi_iter.bi_sector << SECTOR_SHIFT;
|
2023-02-17 13:37:03 +08:00
|
|
|
const u64 full_stripe_start = rbio->bioc->full_stripe_logical;
|
2022-05-27 15:28:19 +08:00
|
|
|
const u32 orig_len = orig_bio->bi_iter.bi_size;
|
|
|
|
const u32 sectorsize = fs_info->sectorsize;
|
|
|
|
u64 cur_logical;
|
|
|
|
|
|
|
|
ASSERT(orig_logical >= full_stripe_start &&
|
|
|
|
orig_logical + orig_len <= full_stripe_start +
|
2022-06-17 18:04:05 +08:00
|
|
|
rbio->nr_data * BTRFS_STRIPE_LEN);
|
2022-05-27 15:28:19 +08:00
|
|
|
|
|
|
|
bio_list_add(&rbio->bio_list, orig_bio);
|
|
|
|
rbio->bio_list_bytes += orig_bio->bi_iter.bi_size;
|
|
|
|
|
|
|
|
/* Update the dbitmap. */
|
|
|
|
for (cur_logical = orig_logical; cur_logical < orig_logical + orig_len;
|
|
|
|
cur_logical += sectorsize) {
|
|
|
|
int bit = ((u32)(cur_logical - full_stripe_start) >>
|
|
|
|
fs_info->sectorsize_bits) % rbio->stripe_nsectors;
|
|
|
|
|
|
|
|
set_bit(bit, &rbio->dbitmap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* our main entry point for writes from the rest of the FS.
|
|
|
|
*/
|
2022-06-17 18:04:08 +08:00
|
|
|
void raid56_parity_write(struct bio *bio, struct btrfs_io_context *bioc)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2021-09-23 14:00:09 +08:00
|
|
|
struct btrfs_fs_info *fs_info = bioc->fs_info;
|
2013-01-30 07:40:14 +08:00
|
|
|
struct btrfs_raid_bio *rbio;
|
2013-02-01 03:42:28 +08:00
|
|
|
struct btrfs_plug_cb *plug = NULL;
|
|
|
|
struct blk_plug_cb *cb;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-06-17 18:04:05 +08:00
|
|
|
rbio = alloc_rbio(fs_info, bioc);
|
2014-10-23 14:42:50 +08:00
|
|
|
if (IS_ERR(rbio)) {
|
2023-01-11 14:23:25 +08:00
|
|
|
bio->bi_status = errno_to_blk_status(PTR_ERR(rbio));
|
|
|
|
bio_endio(bio);
|
|
|
|
return;
|
2014-10-23 14:42:50 +08:00
|
|
|
}
|
2014-11-06 16:14:21 +08:00
|
|
|
rbio->operation = BTRFS_RBIO_WRITE;
|
2022-05-27 15:28:19 +08:00
|
|
|
rbio_add_bio(rbio, bio);
|
2013-02-01 03:42:28 +08:00
|
|
|
|
|
|
|
/*
|
2022-11-01 19:16:09 +08:00
|
|
|
* Don't plug on full rbios, just get them out the door
|
2013-02-01 03:42:28 +08:00
|
|
|
* as quickly as we can
|
|
|
|
*/
|
2023-01-11 14:23:25 +08:00
|
|
|
if (!rbio_is_full(rbio)) {
|
|
|
|
cb = blk_check_plugged(raid_unplug, fs_info, sizeof(*plug));
|
|
|
|
if (cb) {
|
|
|
|
plug = container_of(cb, struct btrfs_plug_cb, cb);
|
|
|
|
if (!plug->info) {
|
|
|
|
plug->info = fs_info;
|
|
|
|
INIT_LIST_HEAD(&plug->rbio_list);
|
|
|
|
}
|
|
|
|
list_add_tail(&rbio->plug_list, &plug->rbio_list);
|
|
|
|
return;
|
2013-02-01 03:42:28 +08:00
|
|
|
}
|
|
|
|
}
|
2023-01-11 14:23:25 +08:00
|
|
|
|
2022-11-01 19:16:09 +08:00
|
|
|
/*
|
|
|
|
* Either we don't have any existing plug, or we're doing a full stripe,
|
2023-01-11 14:23:25 +08:00
|
|
|
* queue the rmw work now.
|
2022-11-01 19:16:09 +08:00
|
|
|
*/
|
|
|
|
start_async_work(rbio, rmw_rbio_work);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
static int verify_one_sector(struct btrfs_raid_bio *rbio,
|
|
|
|
int stripe_nr, int sector_nr)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = rbio->bioc->fs_info;
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
u8 csum_buf[BTRFS_CSUM_SIZE];
|
|
|
|
u8 *csum_expected;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!rbio->csum_bitmap || !rbio->csum_buf)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* No way to verify P/Q as they are not covered by data csum. */
|
|
|
|
if (stripe_nr >= rbio->nr_data)
|
|
|
|
return 0;
|
|
|
|
/*
|
|
|
|
* If we're rebuilding a read, we have to use pages from the
|
|
|
|
* bio list if possible.
|
|
|
|
*/
|
|
|
|
if ((rbio->operation == BTRFS_RBIO_READ_REBUILD ||
|
|
|
|
rbio->operation == BTRFS_RBIO_REBUILD_MISSING)) {
|
|
|
|
sector = sector_in_rbio(rbio, stripe_nr, sector_nr, 0);
|
|
|
|
} else {
|
|
|
|
sector = rbio_stripe_sector(rbio, stripe_nr, sector_nr);
|
|
|
|
}
|
|
|
|
|
|
|
|
ASSERT(sector->page);
|
|
|
|
|
|
|
|
csum_expected = rbio->csum_buf +
|
|
|
|
(stripe_nr * rbio->stripe_nsectors + sector_nr) *
|
|
|
|
fs_info->csum_size;
|
|
|
|
ret = btrfs_check_sector_csum(fs_info, sector->page, sector->pgoff,
|
|
|
|
csum_buf, csum_expected);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:01 +08:00
|
|
|
/*
|
|
|
|
* Recover a vertical stripe specified by @sector_nr.
|
|
|
|
* @*pointers are the pre-allocated pointers by the caller, so we don't
|
|
|
|
* need to allocate/free the pointers again and again.
|
|
|
|
*/
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
static int recover_vertical(struct btrfs_raid_bio *rbio, int sector_nr,
|
|
|
|
void **pointers, void **unmap_array)
|
2022-11-01 19:16:01 +08:00
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = rbio->bioc->fs_info;
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
const u32 sectorsize = fs_info->sectorsize;
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
int found_errors;
|
|
|
|
int faila;
|
|
|
|
int failb;
|
2022-11-01 19:16:01 +08:00
|
|
|
int stripe_nr;
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
int ret = 0;
|
2022-11-01 19:16:01 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we just use bitmap to mark the horizontal stripes in
|
|
|
|
* which we have data when doing parity scrub.
|
|
|
|
*/
|
|
|
|
if (rbio->operation == BTRFS_RBIO_PARITY_SCRUB &&
|
|
|
|
!test_bit(sector_nr, &rbio->dbitmap))
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
found_errors = get_rbio_veritical_errors(rbio, sector_nr, &faila,
|
|
|
|
&failb);
|
|
|
|
/*
|
2023-01-17 18:03:21 +08:00
|
|
|
* No errors in the vertical stripe, skip it. Can happen for recovery
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
* which only part of a stripe failed csum check.
|
|
|
|
*/
|
|
|
|
if (!found_errors)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (found_errors > rbio->bioc->max_errors)
|
|
|
|
return -EIO;
|
2022-11-01 19:16:01 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Setup our array of pointers with sectors from each stripe
|
|
|
|
*
|
|
|
|
* NOTE: store a duplicate array of pointers to preserve the
|
|
|
|
* pointer order.
|
|
|
|
*/
|
|
|
|
for (stripe_nr = 0; stripe_nr < rbio->real_stripes; stripe_nr++) {
|
|
|
|
/*
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
* If we're rebuilding a read, we have to use pages from the
|
|
|
|
* bio list if possible.
|
2022-11-01 19:16:01 +08:00
|
|
|
*/
|
|
|
|
if ((rbio->operation == BTRFS_RBIO_READ_REBUILD ||
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
rbio->operation == BTRFS_RBIO_REBUILD_MISSING)) {
|
2022-11-01 19:16:01 +08:00
|
|
|
sector = sector_in_rbio(rbio, stripe_nr, sector_nr, 0);
|
|
|
|
} else {
|
|
|
|
sector = rbio_stripe_sector(rbio, stripe_nr, sector_nr);
|
|
|
|
}
|
|
|
|
ASSERT(sector->page);
|
|
|
|
pointers[stripe_nr] = kmap_local_page(sector->page) +
|
|
|
|
sector->pgoff;
|
|
|
|
unmap_array[stripe_nr] = pointers[stripe_nr];
|
|
|
|
}
|
|
|
|
|
|
|
|
/* All raid6 handling here */
|
|
|
|
if (rbio->bioc->map_type & BTRFS_BLOCK_GROUP_RAID6) {
|
|
|
|
/* Single failure, rebuild from parity raid5 style */
|
|
|
|
if (failb < 0) {
|
|
|
|
if (faila == rbio->nr_data)
|
|
|
|
/*
|
|
|
|
* Just the P stripe has failed, without
|
|
|
|
* a bad data or Q stripe.
|
|
|
|
* We have nothing to do, just skip the
|
|
|
|
* recovery for this stripe.
|
|
|
|
*/
|
|
|
|
goto cleanup;
|
|
|
|
/*
|
|
|
|
* a single failure in raid6 is rebuilt
|
|
|
|
* in the pstripe code below
|
|
|
|
*/
|
|
|
|
goto pstripe;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the q stripe is failed, do a pstripe reconstruction from
|
|
|
|
* the xors.
|
|
|
|
* If both the q stripe and the P stripe are failed, we're
|
|
|
|
* here due to a crc mismatch and we can't give them the
|
|
|
|
* data they want.
|
|
|
|
*/
|
2023-02-17 13:37:03 +08:00
|
|
|
if (failb == rbio->real_stripes - 1) {
|
|
|
|
if (faila == rbio->real_stripes - 2)
|
2022-11-01 19:16:01 +08:00
|
|
|
/*
|
|
|
|
* Only P and Q are corrupted.
|
|
|
|
* We only care about data stripes recovery,
|
|
|
|
* can skip this vertical stripe.
|
|
|
|
*/
|
|
|
|
goto cleanup;
|
|
|
|
/*
|
|
|
|
* Otherwise we have one bad data stripe and
|
|
|
|
* a good P stripe. raid5!
|
|
|
|
*/
|
|
|
|
goto pstripe;
|
|
|
|
}
|
|
|
|
|
2023-02-17 13:37:03 +08:00
|
|
|
if (failb == rbio->real_stripes - 2) {
|
2022-11-01 19:16:01 +08:00
|
|
|
raid6_datap_recov(rbio->real_stripes, sectorsize,
|
|
|
|
faila, pointers);
|
|
|
|
} else {
|
|
|
|
raid6_2data_recov(rbio->real_stripes, sectorsize,
|
|
|
|
faila, failb, pointers);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
void *p;
|
|
|
|
|
|
|
|
/* Rebuild from P stripe here (raid5 or raid6). */
|
|
|
|
ASSERT(failb == -1);
|
|
|
|
pstripe:
|
|
|
|
/* Copy parity block into failed block to start with */
|
|
|
|
memcpy(pointers[faila], pointers[rbio->nr_data], sectorsize);
|
|
|
|
|
|
|
|
/* Rearrange the pointer array */
|
|
|
|
p = pointers[faila];
|
|
|
|
for (stripe_nr = faila; stripe_nr < rbio->nr_data - 1;
|
|
|
|
stripe_nr++)
|
|
|
|
pointers[stripe_nr] = pointers[stripe_nr + 1];
|
|
|
|
pointers[rbio->nr_data - 1] = p;
|
|
|
|
|
|
|
|
/* Xor in the rest */
|
|
|
|
run_xor(pointers, rbio->nr_data - 1, sectorsize);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No matter if this is a RMW or recovery, we should have all
|
|
|
|
* failed sectors repaired in the vertical stripe, thus they are now
|
|
|
|
* uptodate.
|
|
|
|
* Especially if we determine to cache the rbio, we need to
|
|
|
|
* have at least all data sectors uptodate.
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
*
|
|
|
|
* If possible, also check if the repaired sector matches its data
|
|
|
|
* checksum.
|
2022-11-01 19:16:01 +08:00
|
|
|
*/
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
if (faila >= 0) {
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
ret = verify_one_sector(rbio, faila, sector_nr);
|
|
|
|
if (ret < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
sector = rbio_stripe_sector(rbio, faila, sector_nr);
|
2022-11-01 19:16:01 +08:00
|
|
|
sector->uptodate = 1;
|
|
|
|
}
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
if (failb >= 0) {
|
2023-01-16 04:32:15 +08:00
|
|
|
ret = verify_one_sector(rbio, failb, sector_nr);
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
sector = rbio_stripe_sector(rbio, failb, sector_nr);
|
2022-11-01 19:16:01 +08:00
|
|
|
sector->uptodate = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
for (stripe_nr = rbio->real_stripes - 1; stripe_nr >= 0; stripe_nr--)
|
|
|
|
kunmap_local(unmap_array[stripe_nr]);
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
return ret;
|
2022-11-01 19:16:01 +08:00
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:04 +08:00
|
|
|
static int recover_sectors(struct btrfs_raid_bio *rbio)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2022-11-01 19:16:01 +08:00
|
|
|
void **pointers = NULL;
|
|
|
|
void **unmap_array = NULL;
|
2022-11-01 19:16:04 +08:00
|
|
|
int sectornr;
|
|
|
|
int ret = 0;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-04-01 19:23:23 +08:00
|
|
|
/*
|
2022-11-01 19:16:04 +08:00
|
|
|
* @pointers array stores the pointer for each sector.
|
|
|
|
*
|
|
|
|
* @unmap_array stores copy of pointers that does not get reordered
|
|
|
|
* during reconstruction so that kunmap_local works.
|
2022-04-01 19:23:23 +08:00
|
|
|
*/
|
2015-02-21 01:00:26 +08:00
|
|
|
pointers = kcalloc(rbio->real_stripes, sizeof(void *), GFP_NOFS);
|
2021-02-17 10:48:24 +08:00
|
|
|
unmap_array = kcalloc(rbio->real_stripes, sizeof(void *), GFP_NOFS);
|
2022-11-01 19:16:04 +08:00
|
|
|
if (!pointers || !unmap_array) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
2021-02-17 10:48:24 +08:00
|
|
|
}
|
|
|
|
|
2015-06-20 02:52:50 +08:00
|
|
|
if (rbio->operation == BTRFS_RBIO_READ_REBUILD ||
|
|
|
|
rbio->operation == BTRFS_RBIO_REBUILD_MISSING) {
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&rbio->bio_list_lock);
|
2013-01-30 07:40:14 +08:00
|
|
|
set_bit(RBIO_RMW_LOCKED_BIT, &rbio->flags);
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
index_rbio_pages(rbio);
|
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
for (sectornr = 0; sectornr < rbio->stripe_nsectors; sectornr++) {
|
|
|
|
ret = recover_vertical(rbio, sectornr, pointers, unmap_array);
|
|
|
|
if (ret < 0)
|
|
|
|
break;
|
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-11-01 19:16:04 +08:00
|
|
|
out:
|
2013-01-30 07:40:14 +08:00
|
|
|
kfree(pointers);
|
2022-11-01 19:16:04 +08:00
|
|
|
kfree(unmap_array);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-01-11 14:23:33 +08:00
|
|
|
static void recover_rbio(struct btrfs_raid_bio *rbio)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2023-01-11 14:23:29 +08:00
|
|
|
struct bio_list bio_list = BIO_EMPTY_LIST;
|
2022-11-01 19:16:03 +08:00
|
|
|
int total_sector_nr;
|
|
|
|
int ret = 0;
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2023-01-11 14:23:29 +08:00
|
|
|
/*
|
|
|
|
* Either we're doing recover for a read failure or degraded write,
|
|
|
|
* caller should have set error bitmap correctly.
|
|
|
|
*/
|
|
|
|
ASSERT(bitmap_weight(rbio->error_bitmap, rbio->nr_sectors));
|
|
|
|
|
|
|
|
/* For recovery, we need to read all sectors including P/Q. */
|
|
|
|
ret = alloc_rbio_pages(rbio);
|
|
|
|
if (ret < 0)
|
2023-01-11 14:23:33 +08:00
|
|
|
goto out;
|
2023-01-11 14:23:29 +08:00
|
|
|
|
|
|
|
index_rbio_pages(rbio);
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
btrfs: raid56: don't trust any cached sector in __raid56_parity_recover()
[BUG]
There is a small workload which will always fail with recent kernel:
(A simplified version from btrfs/125 test case)
mkfs.btrfs -f -m raid5 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xee 0 1M" $mnt/file1
sync
umount $mnt
btrfs dev scan -u $dev3
mount -o degraded $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 128M" $mnt/file2
umount $mnt
btrfs dev scan
mount $dev1 $mnt
btrfs balance start --full-balance $mnt
umount $mnt
The failure is always failed to read some tree blocks:
BTRFS info (device dm-4): relocating block group 217710592 flags data|raid5
BTRFS error (device dm-4): parent transid verify failed on 38993920 wanted 9 found 7
BTRFS error (device dm-4): parent transid verify failed on 38993920 wanted 9 found 7
...
[CAUSE]
With the recently added debug output, we can see all RAID56 operations
related to full stripe 38928384:
56.1183: raid56_read_partial: full_stripe=38928384 devid=2 type=DATA1 offset=0 opf=0x0 physical=9502720 len=65536
56.1185: raid56_read_partial: full_stripe=38928384 devid=3 type=DATA2 offset=16384 opf=0x0 physical=9519104 len=16384
56.1185: raid56_read_partial: full_stripe=38928384 devid=3 type=DATA2 offset=49152 opf=0x0 physical=9551872 len=16384
56.1187: raid56_write_stripe: full_stripe=38928384 devid=3 type=DATA2 offset=0 opf=0x1 physical=9502720 len=16384
56.1188: raid56_write_stripe: full_stripe=38928384 devid=3 type=DATA2 offset=32768 opf=0x1 physical=9535488 len=16384
56.1188: raid56_write_stripe: full_stripe=38928384 devid=1 type=PQ1 offset=0 opf=0x1 physical=30474240 len=16384
56.1189: raid56_write_stripe: full_stripe=38928384 devid=1 type=PQ1 offset=32768 opf=0x1 physical=30507008 len=16384
56.1218: raid56_write_stripe: full_stripe=38928384 devid=3 type=DATA2 offset=49152 opf=0x1 physical=9551872 len=16384
56.1219: raid56_write_stripe: full_stripe=38928384 devid=1 type=PQ1 offset=49152 opf=0x1 physical=30523392 len=16384
56.2721: raid56_parity_recover: full stripe=38928384 eb=39010304 mirror=2
56.2723: raid56_parity_recover: full stripe=38928384 eb=39010304 mirror=2
56.2724: raid56_parity_recover: full stripe=38928384 eb=39010304 mirror=2
Before we enter raid56_parity_recover(), we have triggered some metadata
write for the full stripe 38928384, this leads to us to read all the
sectors from disk.
Furthermore, btrfs raid56 write will cache its calculated P/Q sectors to
avoid unnecessary read.
This means, for that full stripe, after any partial write, we will have
stale data, along with P/Q calculated using that stale data.
Thankfully due to patch "btrfs: only write the sectors in the vertical stripe
which has data stripes" we haven't submitted all the corrupted P/Q to disk.
When we really need to recover certain range, aka in
raid56_parity_recover(), we will use the cached rbio, along with its
cached sectors (the full stripe is all cached).
This explains why we have no event raid56_scrub_read_recover()
triggered.
Since we have the cached P/Q which is calculated using the stale data,
the recovered one will just be stale.
In our particular test case, it will always return the same incorrect
metadata, thus causing the same error message "parent transid verify
failed on 39010304 wanted 9 found 7" again and again.
[BTRFS DESTRUCTIVE RMW PROBLEM]
Test case btrfs/125 (and above workload) always has its trouble with
the destructive read-modify-write (RMW) cycle:
0 32K 64K
Data1: | Good | Good |
Data2: | Bad | Bad |
Parity: | Good | Good |
In above case, if we trigger any write into Data1, we will use the bad
data in Data2 to re-generate parity, killing the only chance to recovery
Data2, thus Data2 is lost forever.
This destructive RMW cycle is not specific to btrfs RAID56, but there
are some btrfs specific behaviors making the case even worse:
- Btrfs will cache sectors for unrelated vertical stripes.
In above example, if we're only writing into 0~32K range, btrfs will
still read data range (32K ~ 64K) of Data1, and (64K~128K) of Data2.
This behavior is to cache sectors for later update.
Incidentally commit d4e28d9b5f04 ("btrfs: raid56: make steal_rbio()
subpage compatible") has a bug which makes RAID56 to never trust the
cached sectors, thus slightly improve the situation for recovery.
Unfortunately, follow up fix "btrfs: update stripe_sectors::uptodate in
steal_rbio" will revert the behavior back to the old one.
- Btrfs raid56 partial write will update all P/Q sectors and cache them
This means, even if data at (64K ~ 96K) of Data2 is free space, and
only (96K ~ 128K) of Data2 is really stale data.
And we write into that (96K ~ 128K), we will update all the parity
sectors for the full stripe.
This unnecessary behavior will completely kill the chance of recovery.
Thankfully, an unrelated optimization "btrfs: only write the sectors
in the vertical stripe which has data stripes" will prevent
submitting the write bio for untouched vertical sectors.
That optimization will keep the on-disk P/Q untouched for a chance for
later recovery.
[FIX]
Although we have no good way to completely fix the destructive RMW
(unless we go full scrub for each partial write), we can still limit the
damage.
With patch "btrfs: only write the sectors in the vertical stripe which
has data stripes" now we won't really submit the P/Q of unrelated
vertical stripes, so the on-disk P/Q should still be fine.
Now we really need to do is just drop all the cached sectors when doing
recovery.
By this, we have a chance to read the original P/Q from disk, and have a
chance to recover the stale data, while still keep the cache to speed up
regular write path.
In fact, just dropping all the cache for recovery path is good enough to
allow the test case btrfs/125 along with the small script to pass
reliably.
The lack of metadata write after the degraded mount, and forced metadata
COW is saving us this time.
So this patch will fix the behavior by not trust any cache in
__raid56_parity_recover(), to solve the problem while still keep the
cache useful.
But please note that this test pass DOES NOT mean we have solved the
destructive RMW problem, we just do better damage control a little
better.
Related patches:
- btrfs: only write the sectors in the vertical stripe
- d4e28d9b5f04 ("btrfs: raid56: make steal_rbio() subpage compatible")
- btrfs: update stripe_sectors::uptodate in steal_rbio
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-06-09 13:18:44 +08:00
|
|
|
* Read everything that hasn't failed. However this time we will
|
|
|
|
* not trust any cached sector.
|
|
|
|
* As we may read out some stale data but higher layer is not reading
|
|
|
|
* that stale part.
|
|
|
|
*
|
|
|
|
* So here we always re-read everything in recovery path.
|
2013-01-30 07:40:14 +08:00
|
|
|
*/
|
2022-06-02 15:51:19 +08:00
|
|
|
for (total_sector_nr = 0; total_sector_nr < rbio->nr_sectors;
|
|
|
|
total_sector_nr++) {
|
|
|
|
int stripe = total_sector_nr / rbio->stripe_nsectors;
|
|
|
|
int sectornr = total_sector_nr % rbio->stripe_nsectors;
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
/*
|
|
|
|
* Skip the range which has error. It can be a range which is
|
|
|
|
* marked error (for csum mismatch), or it can be a missing
|
|
|
|
* device.
|
|
|
|
*/
|
|
|
|
if (!rbio->bioc->stripes[stripe].dev->bdev ||
|
|
|
|
test_bit(total_sector_nr, rbio->error_bitmap)) {
|
|
|
|
/*
|
|
|
|
* Also set the error bit for missing device, which
|
|
|
|
* may not yet have its error bit set.
|
|
|
|
*/
|
|
|
|
set_bit(total_sector_nr, rbio->error_bitmap);
|
2013-01-30 07:40:14 +08:00
|
|
|
continue;
|
2014-06-24 15:39:16 +08:00
|
|
|
}
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
|
2022-06-02 15:51:19 +08:00
|
|
|
sector = rbio_stripe_sector(rbio, stripe, sectornr);
|
2023-01-11 14:23:29 +08:00
|
|
|
ret = rbio_add_io_sector(rbio, &bio_list, sector, stripe,
|
2022-06-17 18:04:05 +08:00
|
|
|
sectornr, REQ_OP_READ);
|
2023-01-11 14:23:29 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
bio_list_put(&bio_list);
|
2023-01-11 14:23:33 +08:00
|
|
|
goto out;
|
2023-01-11 14:23:29 +08:00
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
2022-11-01 19:16:05 +08:00
|
|
|
|
2023-01-11 14:23:27 +08:00
|
|
|
submit_read_wait_bio_list(rbio, &bio_list);
|
2023-01-11 14:23:33 +08:00
|
|
|
ret = recover_sectors(rbio);
|
|
|
|
out:
|
|
|
|
rbio_orig_end_io(rbio, errno_to_blk_status(ret));
|
2022-11-01 19:16:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void recover_rbio_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct btrfs_raid_bio *rbio;
|
|
|
|
|
|
|
|
rbio = container_of(work, struct btrfs_raid_bio, work);
|
2023-01-11 14:23:33 +08:00
|
|
|
if (!lock_stripe_add(rbio))
|
|
|
|
recover_rbio(rbio);
|
2022-11-01 19:16:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void recover_rbio_work_locked(struct work_struct *work)
|
|
|
|
{
|
2023-01-11 14:23:33 +08:00
|
|
|
recover_rbio(container_of(work, struct btrfs_raid_bio, work));
|
2022-11-01 19:16:05 +08:00
|
|
|
}
|
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
static void set_rbio_raid6_extra_error(struct btrfs_raid_bio *rbio, int mirror_num)
|
|
|
|
{
|
|
|
|
bool found = false;
|
|
|
|
int sector_nr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is for RAID6 extra recovery tries, thus mirror number should
|
|
|
|
* be large than 2.
|
|
|
|
* Mirror 1 means read from data stripes. Mirror 2 means rebuild using
|
|
|
|
* RAID5 methods.
|
|
|
|
*/
|
|
|
|
ASSERT(mirror_num > 2);
|
|
|
|
for (sector_nr = 0; sector_nr < rbio->stripe_nsectors; sector_nr++) {
|
|
|
|
int found_errors;
|
|
|
|
int faila;
|
|
|
|
int failb;
|
|
|
|
|
|
|
|
found_errors = get_rbio_veritical_errors(rbio, sector_nr,
|
|
|
|
&faila, &failb);
|
|
|
|
/* This vertical stripe doesn't have errors. */
|
|
|
|
if (!found_errors)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we found errors, there should be only one error marked
|
|
|
|
* by previous set_rbio_range_error().
|
|
|
|
*/
|
|
|
|
ASSERT(found_errors == 1);
|
|
|
|
found = true;
|
|
|
|
|
|
|
|
/* Now select another stripe to mark as error. */
|
|
|
|
failb = rbio->real_stripes - (mirror_num - 1);
|
|
|
|
if (failb <= faila)
|
|
|
|
failb--;
|
|
|
|
|
|
|
|
/* Set the extra bit in error bitmap. */
|
|
|
|
if (failb >= 0)
|
|
|
|
set_bit(failb * rbio->stripe_nsectors + sector_nr,
|
|
|
|
rbio->error_bitmap);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We should found at least one vertical stripe with error.*/
|
|
|
|
ASSERT(found);
|
|
|
|
}
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
|
|
|
* the main entry point for reads from the higher layers. This
|
|
|
|
* is really only called when the normal read path had a failure,
|
|
|
|
* so we assume the bio they send down corresponds to a failed part
|
|
|
|
* of the drive.
|
|
|
|
*/
|
2022-06-17 18:04:09 +08:00
|
|
|
void raid56_parity_recover(struct bio *bio, struct btrfs_io_context *bioc,
|
2022-08-06 16:03:25 +08:00
|
|
|
int mirror_num)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2021-09-23 14:00:09 +08:00
|
|
|
struct btrfs_fs_info *fs_info = bioc->fs_info;
|
2013-01-30 07:40:14 +08:00
|
|
|
struct btrfs_raid_bio *rbio;
|
|
|
|
|
2022-06-17 18:04:05 +08:00
|
|
|
rbio = alloc_rbio(fs_info, bioc);
|
2014-10-23 14:42:50 +08:00
|
|
|
if (IS_ERR(rbio)) {
|
2022-06-17 18:04:09 +08:00
|
|
|
bio->bi_status = errno_to_blk_status(PTR_ERR(rbio));
|
2022-11-01 19:16:05 +08:00
|
|
|
bio_endio(bio);
|
|
|
|
return;
|
2014-10-23 14:42:50 +08:00
|
|
|
}
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2014-11-06 16:14:21 +08:00
|
|
|
rbio->operation = BTRFS_RBIO_READ_REBUILD;
|
2022-05-27 15:28:19 +08:00
|
|
|
rbio_add_bio(rbio, bio);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
set_rbio_range_error(rbio, bio);
|
|
|
|
|
2013-01-30 07:40:14 +08:00
|
|
|
/*
|
Btrfs: make raid6 rebuild retry more
There is a scenario that can end up with rebuild process failing to
return good content, i.e.
suppose that all disks can be read without problems and if the content
that was read out doesn't match its checksum, currently for raid6
btrfs at most retries twice,
- the 1st retry is to rebuild with all other stripes, it'll eventually
be a raid5 xor rebuild,
- if the 1st fails, the 2nd retry will deliberately fail parity p so
that it will do raid6 style rebuild,
however, the chances are that another non-parity stripe content also
has something corrupted, so that the above retries are not able to
return correct content, and users will think of this as data loss.
More seriouly, if the loss happens on some important internal btree
roots, it could refuse to mount.
This extends btrfs to do more retries and each retry fails only one
stripe. Since raid6 can tolerate 2 disk failures, if there is one
more failure besides the failure on which we're recovering, this can
always work.
The worst case is to retry as many times as the number of raid6 disks,
but given the fact that such a scenario is really rare in practice,
it's still acceptable.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2018-01-03 04:36:41 +08:00
|
|
|
* Loop retry:
|
|
|
|
* for 'mirror == 2', reconstruct from all other stripes.
|
|
|
|
* for 'mirror_num > 2', select a stripe to fail on every retry.
|
2013-01-30 07:40:14 +08:00
|
|
|
*/
|
2022-11-07 15:32:31 +08:00
|
|
|
if (mirror_num > 2)
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
set_rbio_raid6_extra_error(rbio, mirror_num);
|
2013-01-30 07:40:14 +08:00
|
|
|
|
2022-11-01 19:16:05 +08:00
|
|
|
start_async_work(rbio, recover_rbio_work);
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
2022-11-14 08:26:33 +08:00
|
|
|
static void fill_data_csums(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
struct btrfs_fs_info *fs_info = rbio->bioc->fs_info;
|
|
|
|
struct btrfs_root *csum_root = btrfs_csum_root(fs_info,
|
2023-02-17 13:37:03 +08:00
|
|
|
rbio->bioc->full_stripe_logical);
|
|
|
|
const u64 start = rbio->bioc->full_stripe_logical;
|
2022-11-14 08:26:33 +08:00
|
|
|
const u32 len = (rbio->nr_data * rbio->stripe_nsectors) <<
|
|
|
|
fs_info->sectorsize_bits;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* The rbio should not have its csum buffer initialized. */
|
|
|
|
ASSERT(!rbio->csum_buf && !rbio->csum_bitmap);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip the csum search if:
|
|
|
|
*
|
|
|
|
* - The rbio doesn't belong to data block groups
|
|
|
|
* Then we are doing IO for tree blocks, no need to search csums.
|
|
|
|
*
|
|
|
|
* - The rbio belongs to mixed block groups
|
|
|
|
* This is to avoid deadlock, as we're already holding the full
|
|
|
|
* stripe lock, if we trigger a metadata read, and it needs to do
|
|
|
|
* raid56 recovery, we will deadlock.
|
|
|
|
*/
|
|
|
|
if (!(rbio->bioc->map_type & BTRFS_BLOCK_GROUP_DATA) ||
|
|
|
|
rbio->bioc->map_type & BTRFS_BLOCK_GROUP_METADATA)
|
|
|
|
return;
|
|
|
|
|
|
|
|
rbio->csum_buf = kzalloc(rbio->nr_data * rbio->stripe_nsectors *
|
|
|
|
fs_info->csum_size, GFP_NOFS);
|
|
|
|
rbio->csum_bitmap = bitmap_zalloc(rbio->nr_data * rbio->stripe_nsectors,
|
|
|
|
GFP_NOFS);
|
|
|
|
if (!rbio->csum_buf || !rbio->csum_bitmap) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = btrfs_lookup_csums_bitmap(csum_root, start, start + len - 1,
|
2023-03-20 10:12:51 +08:00
|
|
|
rbio->csum_buf, rbio->csum_bitmap, false);
|
2022-11-14 08:26:33 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
|
|
|
if (bitmap_empty(rbio->csum_bitmap, len >> fs_info->sectorsize_bits))
|
|
|
|
goto no_csum;
|
|
|
|
return;
|
|
|
|
|
|
|
|
error:
|
|
|
|
/*
|
|
|
|
* We failed to allocate memory or grab the csum, but it's not fatal,
|
|
|
|
* we can still continue. But better to warn users that RMW is no
|
|
|
|
* longer safe for this particular sub-stripe write.
|
|
|
|
*/
|
|
|
|
btrfs_warn_rl(fs_info,
|
|
|
|
"sub-stripe write for full stripe %llu is not safe, failed to get csum: %d",
|
2023-02-17 13:37:03 +08:00
|
|
|
rbio->bioc->full_stripe_logical, ret);
|
2022-11-14 08:26:33 +08:00
|
|
|
no_csum:
|
|
|
|
kfree(rbio->csum_buf);
|
|
|
|
bitmap_free(rbio->csum_bitmap);
|
|
|
|
rbio->csum_buf = NULL;
|
|
|
|
rbio->csum_bitmap = NULL;
|
|
|
|
}
|
|
|
|
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
static int rmw_read_wait_recover(struct btrfs_raid_bio *rbio)
|
2022-11-01 19:16:08 +08:00
|
|
|
{
|
2023-01-11 14:23:30 +08:00
|
|
|
struct bio_list bio_list = BIO_EMPTY_LIST;
|
|
|
|
int total_sector_nr;
|
|
|
|
int ret = 0;
|
2022-11-01 19:16:08 +08:00
|
|
|
|
2022-11-14 08:26:33 +08:00
|
|
|
/*
|
|
|
|
* Fill the data csums we need for data verification. We need to fill
|
|
|
|
* the csum_bitmap/csum_buf first, as our endio function will try to
|
|
|
|
* verify the data sectors.
|
|
|
|
*/
|
|
|
|
fill_data_csums(rbio);
|
|
|
|
|
2023-01-11 14:23:30 +08:00
|
|
|
/*
|
|
|
|
* Build a list of bios to read all sectors (including data and P/Q).
|
|
|
|
*
|
|
|
|
* This behavior is to compensate the later csum verification and recovery.
|
|
|
|
*/
|
|
|
|
for (total_sector_nr = 0; total_sector_nr < rbio->nr_sectors;
|
|
|
|
total_sector_nr++) {
|
|
|
|
struct sector_ptr *sector;
|
|
|
|
int stripe = total_sector_nr / rbio->stripe_nsectors;
|
|
|
|
int sectornr = total_sector_nr % rbio->stripe_nsectors;
|
2022-11-01 19:16:08 +08:00
|
|
|
|
2023-01-11 14:23:30 +08:00
|
|
|
sector = rbio_stripe_sector(rbio, stripe, sectornr);
|
|
|
|
ret = rbio_add_io_sector(rbio, &bio_list, sector,
|
|
|
|
stripe, sectornr, REQ_OP_READ);
|
|
|
|
if (ret) {
|
|
|
|
bio_list_put(&bio_list);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We may or may not have any corrupted sectors (including missing dev
|
|
|
|
* and csum mismatch), just let recover_sectors() to handle them all.
|
|
|
|
*/
|
2023-01-11 14:23:30 +08:00
|
|
|
submit_read_wait_bio_list(rbio, &bio_list);
|
|
|
|
return recover_sectors(rbio);
|
2022-11-01 19:16:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void raid_wait_write_end_io(struct bio *bio)
|
|
|
|
{
|
|
|
|
struct btrfs_raid_bio *rbio = bio->bi_private;
|
|
|
|
blk_status_t err = bio->bi_status;
|
|
|
|
|
2022-11-07 15:32:31 +08:00
|
|
|
if (err)
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
rbio_update_error_bitmap(rbio, bio);
|
2022-11-01 19:16:08 +08:00
|
|
|
bio_put(bio);
|
|
|
|
if (atomic_dec_and_test(&rbio->stripes_pending))
|
|
|
|
wake_up(&rbio->io_wait);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void submit_write_bios(struct btrfs_raid_bio *rbio,
|
|
|
|
struct bio_list *bio_list)
|
|
|
|
{
|
|
|
|
struct bio *bio;
|
|
|
|
|
|
|
|
atomic_set(&rbio->stripes_pending, bio_list_size(bio_list));
|
|
|
|
while ((bio = bio_list_pop(bio_list))) {
|
|
|
|
bio->bi_end_io = raid_wait_write_end_io;
|
|
|
|
|
|
|
|
if (trace_raid56_write_stripe_enabled()) {
|
|
|
|
struct raid56_bio_trace_info trace_info = { 0 };
|
|
|
|
|
|
|
|
bio_get_trace_info(rbio, bio, &trace_info);
|
|
|
|
trace_raid56_write_stripe(rbio, bio, &trace_info);
|
|
|
|
}
|
|
|
|
submit_bio(bio);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
/*
|
|
|
|
* To determine if we need to read any sector from the disk.
|
|
|
|
* Should only be utilized in RMW path, to skip cached rbio.
|
|
|
|
*/
|
|
|
|
static bool need_read_stripe_sectors(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < rbio->nr_data * rbio->stripe_nsectors; i++) {
|
|
|
|
struct sector_ptr *sector = &rbio->stripe_sectors[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have a sector which doesn't have page nor uptodate,
|
|
|
|
* thus this rbio can not be cached one, as cached one must
|
|
|
|
* have all its data sectors present and uptodate.
|
|
|
|
*/
|
|
|
|
if (!sector->page || !sector->uptodate)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2023-01-11 14:23:32 +08:00
|
|
|
static void rmw_rbio(struct btrfs_raid_bio *rbio)
|
2022-11-01 19:16:08 +08:00
|
|
|
{
|
|
|
|
struct bio_list bio_list;
|
|
|
|
int sectornr;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate the pages for parity first, as P/Q pages will always be
|
|
|
|
* needed for both full-stripe and sub-stripe writes.
|
|
|
|
*/
|
|
|
|
ret = alloc_rbio_parity_pages(rbio);
|
|
|
|
if (ret < 0)
|
2023-01-11 14:23:32 +08:00
|
|
|
goto out;
|
2022-11-01 19:16:08 +08:00
|
|
|
|
btrfs: raid56: do data csum verification during RMW cycle
[BUG]
For the following small script, btrfs will be unable to recover the
content of file1:
mkfs.btrfs -f -m raid1 -d raid5 -b 1G $dev1 $dev2 $dev3
mount $dev1 $mnt
xfs_io -f -c "pwrite -S 0xff 0 64k" -c sync $mnt/file1
md5sum $mnt/file1
umount $mnt
# Corrupt the above 64K data stripe.
xfs_io -f -c "pwrite -S 0x00 323026944 64K" -c sync $dev3
mount $dev1 $mnt
# Write a new 64K, which should be in the other data stripe
# And this is a sub-stripe write, which will cause RMW
xfs_io -f -c "pwrite 0 64k" -c sync $mnt/file2
md5sum $mnt/file1
umount $mnt
Above md5sum would fail.
[CAUSE]
There is a long existing problem for raid56 (not limited to btrfs
raid56) that, if we already have some corrupted on-disk data, and then
trigger a sub-stripe write (which needs RMW cycle), it can cause further
damage into P/Q stripe.
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000|
Disk 2: parity |0xffffffffffff|
In above case, data 1 is already corrupted, the original data should be
64KiB of 0xff.
At this stage, if we read data 1, and it has data checksum, we can still
recovery going via the regular RAID56 recovery path.
But if now we decide to write some data into data 2, then we need to go
RMW.
Let's say we want to write 64KiB of '0x00' into data 2, then we read the
on-disk data of data 1, calculate the new parity, resulting the
following layout:
Disk 1: data 1 |0x000000000000| <- Corrupted
Disk 2: data 2 |0x000000000000| <- New '0x00' writes
Disk 2: parity |0x000000000000| <- New Parity.
But the new parity is calculated using the *corrupted* data 1, we can
no longer recover the correct data of data1. Thus the corruption is
forever there.
[FIX]
To solve above problem, this patch will do a full stripe data checksum
verification at RMW time.
This involves the following changes:
- Always read the full stripe (including data/P/Q) when doing RMW
Before we only read the missing data sectors, but since we may do a
data csum verification and recovery, we need to read everything out.
Please note that, if we have a cached rbio, we don't need to read
anything, and can treat it the same as full stripe write.
As only stripe with all its csum matches can be cached.
- Verify the data csum during read.
The goal is only the rbio stripe sectors, and only if the rbio
already has csum_buf/csum_bitmap filled.
And sectors which cannot pass csum verification will have their bit
set in error_bitmap.
- Always call recovery_sectors() after we read out all the sectors
Since error_bitmap will be updated during read, recover_sectors()
can easily find out all the bad sectors and try to recover (if still
under tolerance).
And since recovery_sectors() is already migrated to use error_bitmap,
it can skip vertical stripes which don't have any error.
- Verify the repaired sectors against its csum in recover_vertical()
- Rename rmw_read_and_wait() to rmw_read_wait_recover()
Since we will always recover the sectors, the old name is no longer
accurate.
Furthermore since recovery is already done in rmw_read_wait_recover(),
we no longer need to call recovery_sectors() inside rmw_rbio().
Obviously this will have a performance impact, as we are doing more
work during RMW cycle:
- Fetch the data checksums
- Do checksum verification for all data stripes
- Do checksum verification again after repair
But for full stripe write or cached rbio we won't have the overhead all,
thus for fully optimized RAID56 workload (always full stripe write),
there should be no extra overhead.
To me, the extra overhead looks reasonable, as data consistency is way
more important than performance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-14 08:26:34 +08:00
|
|
|
/*
|
|
|
|
* Either full stripe write, or we have every data sector already
|
|
|
|
* cached, can go to write path immediately.
|
|
|
|
*/
|
2023-01-11 14:23:26 +08:00
|
|
|
if (!rbio_is_full(rbio) && need_read_stripe_sectors(rbio)) {
|
|
|
|
/*
|
|
|
|
* Now we're doing sub-stripe write, also need all data stripes
|
|
|
|
* to do the full RMW.
|
|
|
|
*/
|
|
|
|
ret = alloc_rbio_data_pages(rbio);
|
|
|
|
if (ret < 0)
|
2023-01-11 14:23:32 +08:00
|
|
|
goto out;
|
2022-11-01 19:16:08 +08:00
|
|
|
|
2023-01-11 14:23:26 +08:00
|
|
|
index_rbio_pages(rbio);
|
2022-11-01 19:16:08 +08:00
|
|
|
|
2023-01-11 14:23:26 +08:00
|
|
|
ret = rmw_read_wait_recover(rbio);
|
|
|
|
if (ret < 0)
|
2023-01-11 14:23:32 +08:00
|
|
|
goto out;
|
2023-01-11 14:23:26 +08:00
|
|
|
}
|
2022-11-01 19:16:08 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* At this stage we're not allowed to add any new bios to the
|
|
|
|
* bio list any more, anyone else that wants to change this stripe
|
|
|
|
* needs to do their own rmw.
|
|
|
|
*/
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_lock(&rbio->bio_list_lock);
|
2022-11-01 19:16:08 +08:00
|
|
|
set_bit(RBIO_RMW_LOCKED_BIT, &rbio->flags);
|
2023-01-20 15:46:57 +08:00
|
|
|
spin_unlock(&rbio->bio_list_lock);
|
2022-11-01 19:16:08 +08:00
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
bitmap_clear(rbio->error_bitmap, 0, rbio->nr_sectors);
|
2022-11-01 19:16:08 +08:00
|
|
|
|
|
|
|
index_rbio_pages(rbio);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't cache full rbios because we're assuming
|
|
|
|
* the higher layers are unlikely to use this area of
|
|
|
|
* the disk again soon. If they do use it again,
|
|
|
|
* hopefully they will send another full bio.
|
|
|
|
*/
|
|
|
|
if (!rbio_is_full(rbio))
|
|
|
|
cache_rbio_pages(rbio);
|
|
|
|
else
|
|
|
|
clear_bit(RBIO_CACHE_READY_BIT, &rbio->flags);
|
|
|
|
|
|
|
|
for (sectornr = 0; sectornr < rbio->stripe_nsectors; sectornr++)
|
|
|
|
generate_pq_vertical(rbio, sectornr);
|
|
|
|
|
|
|
|
bio_list_init(&bio_list);
|
|
|
|
ret = rmw_assemble_write_bios(rbio, &bio_list);
|
|
|
|
if (ret < 0)
|
2023-01-11 14:23:32 +08:00
|
|
|
goto out;
|
2022-11-01 19:16:08 +08:00
|
|
|
|
|
|
|
/* We should have at least one bio assembled. */
|
|
|
|
ASSERT(bio_list_size(&bio_list));
|
|
|
|
submit_write_bios(rbio, &bio_list);
|
|
|
|
wait_event(rbio->io_wait, atomic_read(&rbio->stripes_pending) == 0);
|
|
|
|
|
2022-11-07 15:32:31 +08:00
|
|
|
/* We may have more errors than our tolerance during the read. */
|
|
|
|
for (sectornr = 0; sectornr < rbio->stripe_nsectors; sectornr++) {
|
|
|
|
int found_errors;
|
|
|
|
|
|
|
|
found_errors = get_rbio_veritical_errors(rbio, sectornr, NULL, NULL);
|
|
|
|
if (found_errors > rbio->bioc->max_errors) {
|
|
|
|
ret = -EIO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2023-01-11 14:23:32 +08:00
|
|
|
out:
|
|
|
|
rbio_orig_end_io(rbio, errno_to_blk_status(ret));
|
2022-11-01 19:16:08 +08:00
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:09 +08:00
|
|
|
static void rmw_rbio_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct btrfs_raid_bio *rbio;
|
|
|
|
|
|
|
|
rbio = container_of(work, struct btrfs_raid_bio, work);
|
2023-01-11 14:23:32 +08:00
|
|
|
if (lock_stripe_add(rbio) == 0)
|
|
|
|
rmw_rbio(rbio);
|
2022-11-01 19:16:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rmw_rbio_work_locked(struct work_struct *work)
|
2013-01-30 07:40:14 +08:00
|
|
|
{
|
2023-01-11 14:23:32 +08:00
|
|
|
rmw_rbio(container_of(work, struct btrfs_raid_bio, work));
|
2013-01-30 07:40:14 +08:00
|
|
|
}
|
|
|
|
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
/*
|
|
|
|
* The following code is used to scrub/replace the parity stripe
|
|
|
|
*
|
2021-09-15 15:17:16 +08:00
|
|
|
* Caller must have already increased bio_counter for getting @bioc.
|
btrfs: Wait for in-flight bios before freeing target device for raid56
When raid56 dev-replace is cancelled by running scrub, we will free
target device without waiting for in-flight bios, causing the following
NULL pointer deference or general protection failure.
BUG: unable to handle kernel NULL pointer dereference at 00000000000005e0
IP: generic_make_request_checks+0x4d/0x610
CPU: 1 PID: 11676 Comm: kworker/u4:14 Tainted: G O 4.11.0-rc2 #72
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
Workqueue: btrfs-endio-raid56 btrfs_endio_raid56_helper [btrfs]
task: ffff88002875b4c0 task.stack: ffffc90001334000
RIP: 0010:generic_make_request_checks+0x4d/0x610
Call Trace:
? generic_make_request+0xc7/0x360
generic_make_request+0x24/0x360
? generic_make_request+0xc7/0x360
submit_bio+0x64/0x120
? page_in_rbio+0x4d/0x80 [btrfs]
? rbio_orig_end_io+0x80/0x80 [btrfs]
finish_rmw+0x3f4/0x540 [btrfs]
validate_rbio_for_rmw+0x36/0x40 [btrfs]
raid_rmw_end_io+0x7a/0x90 [btrfs]
bio_endio+0x56/0x60
end_workqueue_fn+0x3c/0x40 [btrfs]
btrfs_scrubparity_helper+0xef/0x620 [btrfs]
btrfs_endio_raid56_helper+0xe/0x10 [btrfs]
process_one_work+0x2af/0x720
? process_one_work+0x22b/0x720
worker_thread+0x4b/0x4f0
kthread+0x10f/0x150
? process_one_work+0x720/0x720
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x2e/0x40
RIP: generic_make_request_checks+0x4d/0x610 RSP: ffffc90001337bb8
In btrfs_dev_replace_finishing(), we will call
btrfs_rm_dev_replace_blocked() to wait bios before destroying the target
device when scrub is finished normally.
However when dev-replace is aborted, either due to error or cancelled by
scrub, we didn't wait for bios, this can lead to use-after-free if there
are bios holding the target device.
Furthermore, for raid56 scrub, at least 2 places are calling
btrfs_map_sblock() without protection of bio_counter, leading to the
problem.
This patch fixes the problem:
1) Wait for bio_counter before freeing target device when canceling
replace
2) When calling btrfs_map_sblock() for raid56, use bio_counter to
protect the call.
Cc: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2017-03-29 09:33:21 +08:00
|
|
|
*
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
* Note: We need make sure all the pages that add into the scrub/replace
|
|
|
|
* raid bio are correct and not be changed during the scrub/replace. That
|
|
|
|
* is those pages just hold metadata or file data with checksum.
|
|
|
|
*/
|
|
|
|
|
2021-09-23 14:00:09 +08:00
|
|
|
struct btrfs_raid_bio *raid56_parity_alloc_scrub_rbio(struct bio *bio,
|
|
|
|
struct btrfs_io_context *bioc,
|
2022-06-17 18:04:05 +08:00
|
|
|
struct btrfs_device *scrub_dev,
|
2021-09-23 14:00:09 +08:00
|
|
|
unsigned long *dbitmap, int stripe_nsectors)
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
{
|
2021-09-23 14:00:09 +08:00
|
|
|
struct btrfs_fs_info *fs_info = bioc->fs_info;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
struct btrfs_raid_bio *rbio;
|
|
|
|
int i;
|
|
|
|
|
2022-06-17 18:04:05 +08:00
|
|
|
rbio = alloc_rbio(fs_info, bioc);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
if (IS_ERR(rbio))
|
|
|
|
return NULL;
|
|
|
|
bio_list_add(&rbio->bio_list, bio);
|
|
|
|
/*
|
|
|
|
* This is a special bio which is used to hold the completion handler
|
|
|
|
* and make the scrub rbio is similar to the other types
|
|
|
|
*/
|
|
|
|
ASSERT(!bio->bi_iter.bi_size);
|
|
|
|
rbio->operation = BTRFS_RBIO_PARITY_SCRUB;
|
|
|
|
|
2017-08-04 03:53:31 +08:00
|
|
|
/*
|
2021-09-15 15:17:16 +08:00
|
|
|
* After mapping bioc with BTRFS_MAP_WRITE, parities have been sorted
|
2017-08-04 03:53:31 +08:00
|
|
|
* to the end position, so this search can start from the first parity
|
|
|
|
* stripe.
|
|
|
|
*/
|
|
|
|
for (i = rbio->nr_data; i < rbio->real_stripes; i++) {
|
2021-09-15 15:17:16 +08:00
|
|
|
if (bioc->stripes[i].dev == scrub_dev) {
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
rbio->scrubp = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2017-08-04 03:53:31 +08:00
|
|
|
ASSERT(i < rbio->real_stripes);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-05-27 15:28:17 +08:00
|
|
|
bitmap_copy(&rbio->dbitmap, dbitmap, stripe_nsectors);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
return rbio;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We just scrub the parity that we have correct data on the same horizontal,
|
|
|
|
* so we needn't allocate all pages for all the stripes.
|
|
|
|
*/
|
|
|
|
static int alloc_rbio_essential_pages(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
2022-04-01 19:23:30 +08:00
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
2022-06-08 08:34:34 +08:00
|
|
|
int total_sector_nr;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-06-08 08:34:34 +08:00
|
|
|
for (total_sector_nr = 0; total_sector_nr < rbio->nr_sectors;
|
|
|
|
total_sector_nr++) {
|
|
|
|
struct page *page;
|
|
|
|
int sectornr = total_sector_nr % rbio->stripe_nsectors;
|
|
|
|
int index = (total_sector_nr * sectorsize) >> PAGE_SHIFT;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-06-08 08:34:34 +08:00
|
|
|
if (!test_bit(sectornr, &rbio->dbitmap))
|
|
|
|
continue;
|
|
|
|
if (rbio->stripe_pages[index])
|
|
|
|
continue;
|
|
|
|
page = alloc_page(GFP_NOFS);
|
|
|
|
if (!page)
|
|
|
|
return -ENOMEM;
|
|
|
|
rbio->stripe_pages[index] = page;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
btrfs: raid56: introduce btrfs_raid_bio::stripe_sectors
The new member is an array of sector_ptr pointers, they will represent
all sectors inside a full stripe (including P/Q).
They co-operate with btrfs_raid_bio::stripe_pages:
stripe_pages: | Page 0, range [0, 64K) | Page 1 ...
stripe_sectors: | | | ... | |
| | \- sector 15, page 0, pgoff=60K
| \- sector 1, page 0, pgoff=4K
\---- sector 0, page 0, pfoff=0
With such structure, we can represent subpage sectors without using
extra pages.
Here we introduce a new helper, index_stripe_sectors(), to update
stripe_sectors[] to point to correct page and pgoff.
So every time rbio::stripe_pages[] pointer gets updated, the new helper
should be called.
The following functions have to call the new helper:
- steal_rbio()
- alloc_rbio_pages()
- alloc_rbio_parity_pages()
- alloc_rbio_essential_pages()
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-01 19:23:19 +08:00
|
|
|
index_stripe_sectors(rbio);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:11 +08:00
|
|
|
static int finish_parity_scrub(struct btrfs_raid_bio *rbio, int need_check)
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
{
|
2021-09-15 15:17:16 +08:00
|
|
|
struct btrfs_io_context *bioc = rbio->bioc;
|
2022-04-01 19:23:22 +08:00
|
|
|
const u32 sectorsize = bioc->fs_info->sectorsize;
|
2018-05-30 07:44:59 +08:00
|
|
|
void **pointers = rbio->finish_pointers;
|
2022-05-27 15:28:17 +08:00
|
|
|
unsigned long *pbitmap = &rbio->finish_pbitmap;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
int nr_data = rbio->nr_data;
|
|
|
|
int stripe;
|
2022-04-01 19:23:21 +08:00
|
|
|
int sectornr;
|
2020-02-19 22:17:20 +08:00
|
|
|
bool has_qstripe;
|
2022-04-01 19:23:22 +08:00
|
|
|
struct sector_ptr p_sector = { 0 };
|
|
|
|
struct sector_ptr q_sector = { 0 };
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
struct bio_list bio_list;
|
2014-11-14 17:45:42 +08:00
|
|
|
int is_replace = 0;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
bio_list_init(&bio_list);
|
|
|
|
|
2020-02-19 22:17:20 +08:00
|
|
|
if (rbio->real_stripes - rbio->nr_data == 1)
|
|
|
|
has_qstripe = false;
|
|
|
|
else if (rbio->real_stripes - rbio->nr_data == 2)
|
|
|
|
has_qstripe = true;
|
|
|
|
else
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
BUG();
|
|
|
|
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
/*
|
|
|
|
* Replace is running and our P/Q stripe is being replaced, then we
|
|
|
|
* need to duplicate the final write to replace target.
|
|
|
|
*/
|
|
|
|
if (bioc->replace_nr_stripes && bioc->replace_stripe_src == rbio->scrubp) {
|
2014-11-14 17:45:42 +08:00
|
|
|
is_replace = 1;
|
2022-05-27 15:28:17 +08:00
|
|
|
bitmap_copy(pbitmap, &rbio->dbitmap, rbio->stripe_nsectors);
|
2014-11-14 17:45:42 +08:00
|
|
|
}
|
|
|
|
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
/*
|
|
|
|
* Because the higher layers(scrubber) are unlikely to
|
|
|
|
* use this area of the disk again soon, so don't cache
|
|
|
|
* it.
|
|
|
|
*/
|
|
|
|
clear_bit(RBIO_CACHE_READY_BIT, &rbio->flags);
|
|
|
|
|
|
|
|
if (!need_check)
|
|
|
|
goto writeback;
|
|
|
|
|
2022-04-01 19:23:22 +08:00
|
|
|
p_sector.page = alloc_page(GFP_NOFS);
|
|
|
|
if (!p_sector.page)
|
2022-11-01 19:16:11 +08:00
|
|
|
return -ENOMEM;
|
2022-04-01 19:23:22 +08:00
|
|
|
p_sector.pgoff = 0;
|
|
|
|
p_sector.uptodate = 1;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2020-02-19 22:17:20 +08:00
|
|
|
if (has_qstripe) {
|
2021-01-28 14:15:03 +08:00
|
|
|
/* RAID6, allocate and map temp space for the Q stripe */
|
2022-04-01 19:23:22 +08:00
|
|
|
q_sector.page = alloc_page(GFP_NOFS);
|
|
|
|
if (!q_sector.page) {
|
|
|
|
__free_page(p_sector.page);
|
|
|
|
p_sector.page = NULL;
|
2022-11-01 19:16:11 +08:00
|
|
|
return -ENOMEM;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
2022-04-01 19:23:22 +08:00
|
|
|
q_sector.pgoff = 0;
|
|
|
|
q_sector.uptodate = 1;
|
|
|
|
pointers[rbio->real_stripes - 1] = kmap_local_page(q_sector.page);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
bitmap_clear(rbio->error_bitmap, 0, rbio->nr_sectors);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2021-01-28 14:15:03 +08:00
|
|
|
/* Map the parity stripe just once */
|
2022-04-01 19:23:22 +08:00
|
|
|
pointers[nr_data] = kmap_local_page(p_sector.page);
|
2021-01-28 14:15:03 +08:00
|
|
|
|
2022-05-27 15:28:17 +08:00
|
|
|
for_each_set_bit(sectornr, &rbio->dbitmap, rbio->stripe_nsectors) {
|
2022-04-01 19:23:22 +08:00
|
|
|
struct sector_ptr *sector;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
void *parity;
|
2022-04-01 19:23:22 +08:00
|
|
|
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
/* first collect one page from each data stripe */
|
|
|
|
for (stripe = 0; stripe < nr_data; stripe++) {
|
2022-04-01 19:23:22 +08:00
|
|
|
sector = sector_in_rbio(rbio, stripe, sectornr, 0);
|
|
|
|
pointers[stripe] = kmap_local_page(sector->page) +
|
|
|
|
sector->pgoff;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
2020-02-19 22:17:20 +08:00
|
|
|
if (has_qstripe) {
|
2021-01-28 14:15:03 +08:00
|
|
|
/* RAID6, call the library function to fill in our P/Q */
|
2022-04-01 19:23:22 +08:00
|
|
|
raid6_call.gen_syndrome(rbio->real_stripes, sectorsize,
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
pointers);
|
|
|
|
} else {
|
|
|
|
/* raid5 */
|
2022-04-01 19:23:22 +08:00
|
|
|
memcpy(pointers[nr_data], pointers[0], sectorsize);
|
|
|
|
run_xor(pointers + 1, nr_data - 1, sectorsize);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 09:18:45 +08:00
|
|
|
/* Check scrubbing parity and repair it */
|
2022-04-01 19:23:22 +08:00
|
|
|
sector = rbio_stripe_sector(rbio, rbio->scrubp, sectornr);
|
|
|
|
parity = kmap_local_page(sector->page) + sector->pgoff;
|
|
|
|
if (memcmp(parity, pointers[rbio->scrubp], sectorsize) != 0)
|
|
|
|
memcpy(parity, pointers[rbio->scrubp], sectorsize);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
else
|
|
|
|
/* Parity is right, needn't writeback */
|
2022-05-27 15:28:17 +08:00
|
|
|
bitmap_clear(&rbio->dbitmap, sectornr, 1);
|
2021-02-17 10:48:23 +08:00
|
|
|
kunmap_local(parity);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2021-02-17 10:48:24 +08:00
|
|
|
for (stripe = nr_data - 1; stripe >= 0; stripe--)
|
|
|
|
kunmap_local(pointers[stripe]);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
2021-02-17 10:48:24 +08:00
|
|
|
kunmap_local(pointers[nr_data]);
|
2022-04-01 19:23:22 +08:00
|
|
|
__free_page(p_sector.page);
|
|
|
|
p_sector.page = NULL;
|
|
|
|
if (q_sector.page) {
|
2021-02-17 10:48:24 +08:00
|
|
|
kunmap_local(pointers[rbio->real_stripes - 1]);
|
2022-04-01 19:23:22 +08:00
|
|
|
__free_page(q_sector.page);
|
|
|
|
q_sector.page = NULL;
|
2021-01-28 14:15:03 +08:00
|
|
|
}
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
|
|
|
writeback:
|
|
|
|
/*
|
|
|
|
* time to start writing. Make bios for everything from the
|
|
|
|
* higher layers (the bio_list in our rbio) and our p/q. Ignore
|
|
|
|
* everything else.
|
|
|
|
*/
|
2022-05-27 15:28:17 +08:00
|
|
|
for_each_set_bit(sectornr, &rbio->dbitmap, rbio->stripe_nsectors) {
|
2022-04-01 19:23:21 +08:00
|
|
|
struct sector_ptr *sector;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-04-01 19:23:21 +08:00
|
|
|
sector = rbio_stripe_sector(rbio, rbio->scrubp, sectornr);
|
|
|
|
ret = rbio_add_io_sector(rbio, &bio_list, sector, rbio->scrubp,
|
2022-06-17 18:04:05 +08:00
|
|
|
sectornr, REQ_OP_WRITE);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
if (ret)
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2014-11-14 17:45:42 +08:00
|
|
|
if (!is_replace)
|
|
|
|
goto submit_write;
|
|
|
|
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
/*
|
|
|
|
* Replace is running and our parity stripe needs to be duplicated to
|
|
|
|
* the target device. Check we have a valid source stripe number.
|
|
|
|
*/
|
|
|
|
ASSERT(rbio->bioc->replace_stripe_src >= 0);
|
2022-04-01 19:23:21 +08:00
|
|
|
for_each_set_bit(sectornr, pbitmap, rbio->stripe_nsectors) {
|
|
|
|
struct sector_ptr *sector;
|
2014-11-14 17:45:42 +08:00
|
|
|
|
2022-04-01 19:23:21 +08:00
|
|
|
sector = rbio_stripe_sector(rbio, rbio->scrubp, sectornr);
|
|
|
|
ret = rbio_add_io_sector(rbio, &bio_list, sector,
|
btrfs: use an efficient way to represent source of duplicated stripes
For btrfs dev-replace, we have to duplicate writes to the source
device into the target device.
For non-RAID56, all writes into the same mapped ranges are sharing the
same content, thus they don't really need to bother anything.
(E.g. in btrfs_submit_bio() for non-RAID56 range we just submit the
same write to all involved devices).
But for RAID56, all stripes contain different content, thus we must
have a clear mapping of which stripe is duplicated from which original
stripe.
Currently we use a complex way using tgtdev_map[] array, e.g:
num_tgtdevs = 1
tgtdev_map[0] = 0 <- Means stripes[0] is not involved in replace.
tgtdev_map[1] = 3 <- Means stripes[1] is involved in replace,
and it's duplicated to stripes[3].
tgtdev_map[2] = 0 <- Means stripes[2] is not involved in replace.
But this is wasting some space, and ignores one important thing for
dev-replace, there is at most one running replace.
Thus we can change it to a fixed array to represent the mapping:
replace_nr_stripes = 1
replace_stripe_src = 1 <- Means stripes[1] is involved in replace.
thus the extra stripe is a copy of
stripes[1]
By this we can save some space for bioc on RAID56 chunks with many
devices. And we get rid of one variable sized array from bioc.
Thus the patch involves the following changes:
- Replace @num_tgtdevs and @tgtdev_map[] with @replace_nr_stripes
and @replace_stripe_src.
@num_tgtdevs is just renamed to @replace_nr_stripes.
While the mapping is completely changed.
- Add extra ASSERT()s for RAID56 code
- Only add two more extra stripes for dev-replace cases.
As we have an upper limit on how many dev-replace stripes we can have.
- Unify the behavior of handle_ops_on_dev_replace()
Previously handle_ops_on_dev_replace() go two different paths for
WRITE and GET_READ_MIRRORS.
Now unify them by always going the WRITE path first (with at most 2
replace stripes), then if we're doing GET_READ_MIRRORS and we have 2
extra stripes, just drop one stripe.
- Remove the @real_stripes argument from alloc_btrfs_io_context()
As we don't need the old variable length array any more.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-02-07 12:26:14 +08:00
|
|
|
rbio->real_stripes,
|
|
|
|
sectornr, REQ_OP_WRITE);
|
2014-11-14 17:45:42 +08:00
|
|
|
if (ret)
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
submit_write:
|
2022-11-01 19:16:11 +08:00
|
|
|
submit_write_bios(rbio, &bio_list);
|
|
|
|
return 0;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
|
|
|
cleanup:
|
2023-01-11 14:23:28 +08:00
|
|
|
bio_list_put(&bio_list);
|
2022-11-01 19:16:11 +08:00
|
|
|
return ret;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int is_data_stripe(struct btrfs_raid_bio *rbio, int stripe)
|
|
|
|
{
|
|
|
|
if (stripe >= 0 && stripe < rbio->nr_data)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:11 +08:00
|
|
|
static int recover_scrub_rbio(struct btrfs_raid_bio *rbio)
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
{
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
void **pointers = NULL;
|
|
|
|
void **unmap_array = NULL;
|
|
|
|
int sector_nr;
|
2022-12-17 00:48:00 +08:00
|
|
|
int ret = 0;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
/*
|
|
|
|
* @pointers array stores the pointer for each sector.
|
|
|
|
*
|
|
|
|
* @unmap_array stores copy of pointers that does not get reordered
|
|
|
|
* during reconstruction so that kunmap_local works.
|
|
|
|
*/
|
|
|
|
pointers = kcalloc(rbio->real_stripes, sizeof(void *), GFP_NOFS);
|
|
|
|
unmap_array = kcalloc(rbio->real_stripes, sizeof(void *), GFP_NOFS);
|
|
|
|
if (!pointers || !unmap_array) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
for (sector_nr = 0; sector_nr < rbio->stripe_nsectors; sector_nr++) {
|
|
|
|
int dfail = 0, failp = -1;
|
|
|
|
int faila;
|
|
|
|
int failb;
|
|
|
|
int found_errors;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
found_errors = get_rbio_veritical_errors(rbio, sector_nr,
|
|
|
|
&faila, &failb);
|
|
|
|
if (found_errors > rbio->bioc->max_errors) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
if (found_errors == 0)
|
|
|
|
continue;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
/* We should have at least one error here. */
|
|
|
|
ASSERT(faila >= 0 || failb >= 0);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
if (is_data_stripe(rbio, faila))
|
|
|
|
dfail++;
|
|
|
|
else if (is_parity_stripe(faila))
|
|
|
|
failp = faila;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
if (is_data_stripe(rbio, failb))
|
|
|
|
dfail++;
|
|
|
|
else if (is_parity_stripe(failb))
|
|
|
|
failp = failb;
|
|
|
|
/*
|
|
|
|
* Because we can not use a scrubbing parity to repair the
|
|
|
|
* data, so the capability of the repair is declined. (In the
|
|
|
|
* case of RAID5, we can not repair anything.)
|
|
|
|
*/
|
|
|
|
if (dfail > rbio->bioc->max_errors - 1) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* If all data is good, only parity is correctly, just repair
|
|
|
|
* the parity, no need to recover data stripes.
|
|
|
|
*/
|
|
|
|
if (dfail == 0)
|
|
|
|
continue;
|
2022-11-01 19:16:11 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
/*
|
|
|
|
* Here means we got one corrupted data stripe and one
|
|
|
|
* corrupted parity on RAID6, if the corrupted parity is
|
|
|
|
* scrubbing parity, luckily, use the other one to repair the
|
|
|
|
* data, or we can not repair the data stripe.
|
|
|
|
*/
|
|
|
|
if (failp != rbio->scrubp) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = recover_vertical(rbio, sector_nr, pointers, unmap_array);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
kfree(pointers);
|
|
|
|
kfree(unmap_array);
|
2022-11-01 19:16:11 +08:00
|
|
|
return ret;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
2023-01-11 14:23:31 +08:00
|
|
|
static int scrub_assemble_read_bios(struct btrfs_raid_bio *rbio)
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
{
|
2023-01-11 14:23:31 +08:00
|
|
|
struct bio_list bio_list = BIO_EMPTY_LIST;
|
2022-11-01 19:16:10 +08:00
|
|
|
int total_sector_nr;
|
|
|
|
int ret = 0;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-06-08 08:34:36 +08:00
|
|
|
/* Build a list of bios to read all the missing parts. */
|
|
|
|
for (total_sector_nr = 0; total_sector_nr < rbio->nr_sectors;
|
|
|
|
total_sector_nr++) {
|
|
|
|
int sectornr = total_sector_nr % rbio->stripe_nsectors;
|
|
|
|
int stripe = total_sector_nr / rbio->stripe_nsectors;
|
|
|
|
struct sector_ptr *sector;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-06-08 08:34:36 +08:00
|
|
|
/* No data in the vertical stripe, no need to read. */
|
|
|
|
if (!test_bit(sectornr, &rbio->dbitmap))
|
|
|
|
continue;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-06-08 08:34:36 +08:00
|
|
|
/*
|
|
|
|
* We want to find all the sectors missing from the rbio and
|
|
|
|
* read them from the disk. If sector_in_rbio() finds a sector
|
|
|
|
* in the bio list we don't need to read it off the stripe.
|
|
|
|
*/
|
|
|
|
sector = sector_in_rbio(rbio, stripe, sectornr, 1);
|
|
|
|
if (sector)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
sector = rbio_stripe_sector(rbio, stripe, sectornr);
|
|
|
|
/*
|
|
|
|
* The bio cache may have handed us an uptodate sector. If so,
|
|
|
|
* use it.
|
|
|
|
*/
|
|
|
|
if (sector->uptodate)
|
|
|
|
continue;
|
|
|
|
|
2023-01-11 14:23:31 +08:00
|
|
|
ret = rbio_add_io_sector(rbio, &bio_list, sector, stripe,
|
2022-06-17 18:04:05 +08:00
|
|
|
sectornr, REQ_OP_READ);
|
2023-01-11 14:23:31 +08:00
|
|
|
if (ret) {
|
|
|
|
bio_list_put(&bio_list);
|
|
|
|
return ret;
|
|
|
|
}
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
2023-01-11 14:23:31 +08:00
|
|
|
|
|
|
|
submit_read_wait_bio_list(rbio, &bio_list);
|
2022-11-01 19:16:10 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-01-11 14:23:34 +08:00
|
|
|
static void scrub_rbio(struct btrfs_raid_bio *rbio)
|
2022-11-01 19:16:10 +08:00
|
|
|
{
|
2022-11-01 19:16:11 +08:00
|
|
|
bool need_check = false;
|
2022-11-07 15:32:31 +08:00
|
|
|
int sector_nr;
|
2022-11-01 19:16:10 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = alloc_rbio_essential_pages(rbio);
|
|
|
|
if (ret)
|
2023-01-11 14:23:34 +08:00
|
|
|
goto out;
|
2022-11-01 19:16:10 +08:00
|
|
|
|
btrfs: raid56: introduce btrfs_raid_bio::error_bitmap
Currently btrfs raid56 uses btrfs_raid_bio::faila and failb to indicate
which stripe(s) had IO errors.
But that has some problems:
- If one sector failed csum check, the whole stripe where the corruption
is will be marked error.
This can reduce the chance we do recover, like this:
0 4K 8K
Data 1 |XX| |
Data 2 | |XX|
Parity | | |
In above case, 0~4K in data 1 should be recovered using data 2 and
parity, while 4K~8K in data 2 should be recovered using data 1 and
parity.
Currently if we trigger read on 0~4K of data 1, we will also recover
4K~8K of data 1 using corrupted data 2 and parity, causing wrong
result in rbio cache.
- Harder to expand for future M-N scheme
As we're limited to just faila/b, two corruptions.
- Harder to expand to handle extra csum errors
This can be problematic if we start to do csum verification.
This patch will introduce an extra @error_bitmap, where one bit
represents error that happened for that sector.
The choice to introduce a new error bitmap other than reusing
sector_ptr, is to avoid extra search between rbio::stripe_sectors[] and
rbio::bio_sectors[].
Since we can submit bio using sectors from both sectors, doing proper
search on both array will more complex.
Although the new bitmap will take extra memory, later we can remove
things like @error and faila/b to save some memory.
Currently the new error bitmap and failab mechanism coexists, the error
bitmap is only updated at endio time and recover entrance.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:29 +08:00
|
|
|
bitmap_clear(rbio->error_bitmap, 0, rbio->nr_sectors);
|
|
|
|
|
2023-01-11 14:23:31 +08:00
|
|
|
ret = scrub_assemble_read_bios(rbio);
|
2022-11-01 19:16:10 +08:00
|
|
|
if (ret < 0)
|
2023-01-11 14:23:34 +08:00
|
|
|
goto out;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
btrfs: raid56: migrate recovery and scrub recovery path to use error_bitmap
Since we have rbio::error_bitmap to indicate exactly where the errors
are (including read error and csum mismatch error), we can make recovery
path more accurate.
For example:
0 32K 64K
Data 1 |XXXXXXXX| |
Data 2 | |XXXXXXXXX|
Parity | | |
1) Get csum mismatch when reading data 1 [0, 32K)
2) Mark corresponding range error
The old code will mark the whole data 1 stripe as error.
While the new code will only mark data 1 [0, 32K) as error.
3) Recovery path
The old code will recover data 1 [0, 64K), all using Data 2 and
parity.
This means, Data 1 [32K, 64K) will be corrupted data, as data 2
[32K, 64K) is already corrupted.
While the new code will only recover data 1 [0, 32K), as only
that range has error so far.
This new behavior can avoid populating rbio cache with incorrect data.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2022-11-07 15:32:30 +08:00
|
|
|
/* We may have some failures, recover the failed sectors first. */
|
2022-11-01 19:16:11 +08:00
|
|
|
ret = recover_scrub_rbio(rbio);
|
|
|
|
if (ret < 0)
|
2023-01-11 14:23:34 +08:00
|
|
|
goto out;
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
|
2022-11-01 19:16:11 +08:00
|
|
|
/*
|
|
|
|
* We have every sector properly prepared. Can finish the scrub
|
|
|
|
* and writeback the good content.
|
|
|
|
*/
|
|
|
|
ret = finish_parity_scrub(rbio, need_check);
|
|
|
|
wait_event(rbio->io_wait, atomic_read(&rbio->stripes_pending) == 0);
|
2022-11-07 15:32:31 +08:00
|
|
|
for (sector_nr = 0; sector_nr < rbio->stripe_nsectors; sector_nr++) {
|
|
|
|
int found_errors;
|
|
|
|
|
|
|
|
found_errors = get_rbio_veritical_errors(rbio, sector_nr, NULL, NULL);
|
|
|
|
if (found_errors > rbio->bioc->max_errors) {
|
|
|
|
ret = -EIO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2023-01-11 14:23:34 +08:00
|
|
|
out:
|
|
|
|
rbio_orig_end_io(rbio, errno_to_blk_status(ret));
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
2022-11-01 19:16:11 +08:00
|
|
|
static void scrub_rbio_work_locked(struct work_struct *work)
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
{
|
2023-01-11 14:23:34 +08:00
|
|
|
scrub_rbio(container_of(work, struct btrfs_raid_bio, work));
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void raid56_parity_submit_scrub_rbio(struct btrfs_raid_bio *rbio)
|
|
|
|
{
|
|
|
|
if (!lock_stripe_add(rbio))
|
2022-11-01 19:16:11 +08:00
|
|
|
start_async_work(rbio, scrub_rbio_work_locked);
|
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>
2014-11-06 17:20:58 +08:00
|
|
|
}
|
btrfs: scrub: use recovered data stripes as cache to avoid unnecessary read
For P/Q stripe scrub, we have quite some duplicated read IO:
- Data stripes read for verification
This is triggered by the scrub_submit_initial_read() inside
scrub_raid56_parity_stripe().
- Data stripes read (again) for P/Q stripe verification
This is triggered by scrub_assemble_read_bios() from scrub_rbio().
Although we can have hit rbio cache and avoid unnecessary read, the
chance is very low, as scrub would easily flush the whole rbio cache.
This means, even we're just scrubbing a single P/Q stripe, we would read
the data stripes twice for the best case scenario. If we need to
recover some data stripes, it would cause more reads on the same data
stripes, again and again.
However before we call raid56_parity_submit_scrub_rbio() we already
have all data stripes repaired and their contents ready to use.
But RAID56 cache is unaware about the scrub cache, thus RAID56 layer
itself still needs to re-read the data stripes.
To avoid such cache miss, this patch would:
- Introduce a new helper, raid56_parity_cache_data_pages()
This function would grab the pages from an array, and copy the content
to the rbio, marking all the involved sectors uptodate.
The page copy is unavoidable because of the cache pages of rbio are all
self managed, thus can not utilize outside pages without screwing up
the lifespan.
- Use the repaired data stripes as cache inside
scrub_raid56_parity_stripe()
By this, we ensure all the data sectors of the scrub rbio are already
uptodate, and no need to read them again from disk.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-04-13 13:57:18 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This is for scrub call sites where we already have correct data contents.
|
|
|
|
* This allows us to avoid reading data stripes again.
|
|
|
|
*
|
|
|
|
* Unfortunately here we have to do page copy, other than reusing the pages.
|
|
|
|
* This is due to the fact rbio has its own page management for its cache.
|
|
|
|
*/
|
|
|
|
void raid56_parity_cache_data_pages(struct btrfs_raid_bio *rbio,
|
|
|
|
struct page **data_pages, u64 data_logical)
|
|
|
|
{
|
|
|
|
const u64 offset_in_full_stripe = data_logical -
|
|
|
|
rbio->bioc->full_stripe_logical;
|
|
|
|
const int page_index = offset_in_full_stripe >> PAGE_SHIFT;
|
|
|
|
const u32 sectorsize = rbio->bioc->fs_info->sectorsize;
|
|
|
|
const u32 sectors_per_page = PAGE_SIZE / sectorsize;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we hit ENOMEM temporarily, but later at
|
|
|
|
* raid56_parity_submit_scrub_rbio() time it succeeded, we just do
|
|
|
|
* the extra read, not a big deal.
|
|
|
|
*
|
|
|
|
* If we hit ENOMEM later at raid56_parity_submit_scrub_rbio() time,
|
|
|
|
* the bio would got proper error number set.
|
|
|
|
*/
|
|
|
|
ret = alloc_rbio_data_pages(rbio);
|
|
|
|
if (ret < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* data_logical must be at stripe boundary and inside the full stripe. */
|
|
|
|
ASSERT(IS_ALIGNED(offset_in_full_stripe, BTRFS_STRIPE_LEN));
|
|
|
|
ASSERT(offset_in_full_stripe < (rbio->nr_data << BTRFS_STRIPE_LEN_SHIFT));
|
|
|
|
|
|
|
|
for (int page_nr = 0; page_nr < (BTRFS_STRIPE_LEN >> PAGE_SHIFT); page_nr++) {
|
|
|
|
struct page *dst = rbio->stripe_pages[page_nr + page_index];
|
|
|
|
struct page *src = data_pages[page_nr];
|
|
|
|
|
|
|
|
memcpy_page(dst, 0, src, 0, PAGE_SIZE);
|
|
|
|
for (int sector_nr = sectors_per_page * page_index;
|
|
|
|
sector_nr < sectors_per_page * (page_index + 1);
|
|
|
|
sector_nr++)
|
|
|
|
rbio->stripe_sectors[sector_nr].uptodate = true;
|
|
|
|
}
|
|
|
|
}
|