Am 17.10.2016 um 03:50 schrieb Qu Wenruo:
> At 10/17/2016 02:54 AM, Stefan Priebe - Profihost AG wrote:
>> Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:
>>> Hi,
>>>
>>> On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:
cp --reflink=always takes sometimes very long. (i.e. 2
From: Prasanth K S R
This commit fixes coverity defect CID 1328695.
Signed-off-by: Prasanth K S R
---
cmds-receive.c | 10 +-
cmds-send.c| 18 +-
send-utils.c | 22 ++
3 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/cmds-receiv
15.10.2016 01:58, Alberto Bursi пишет:
>
>
> On 10/15/2016 12:17 AM, Chris Murphy wrote:
>> It should be -e can accept a listing of all the subvolumes you want to
>> send at once. And possibly an -r flag, if it existed, could
>> automatically populate -e. But the last time I tested -e I just got
Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
Signed-off-by: Junjie Mao
---
fs/btrfs/compression.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index ccc70d96958d..d4d8b7e36b2f 100644
--- a/fs/btrfs/co
At 10/17/2016 02:54 AM, Stefan Priebe - Profihost AG wrote:
Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:
Hi,
On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:
cp --reflink=always takes sometimes very long. (i.e. 25-35 minutes)
An example:
source file:
# ls -la vm-279-disk
Introduce new function, scrub_one_data_stripe(), to check all data and
tree blocks inside the data stripe.
Signed-off-by: Qu Wenruo
---
check/scrub.c | 111 ++
1 file changed, 111 insertions(+)
diff --git a/check/scrub.c b/check/scrub.c
in
Introduce a new function, __btrfs_map_block_v2().
Unlike old btrfs_map_block(), which needs different parameter to handle
different RAID profile, this new function uses unified btrfs_map_block
structure to handle all RAID profile in a more meaningful method:
Return physical address along with log
Introduce a new function, scrub_tree_mirror(), to scrub mirror based
tree blocks (Single/DUP/RAID0/1/10)
This function can be used on in-memory tree blocks using @data parameter
for RAID5/6 full stripe, or just by @bytenr, for other profiles.
Signed-off-by: Qu Wenruo
---
check/scrub.c | 59
Now, btrfs check has a kernel scrub equivalent.
And even more, it's has stronger csum check against reconstructed data
and existing data stripes.
It will avoid any possible silent data corruption in kernel scrub.
Now it only supports to do read-only check, but is already able to
provide info on t
Introduce new function, scrub_one_block_group(), to scrub a block group.
For Single/DUP/RAID0/RAID1/RAID10, we use old mirror number based
map_block, and check extent by extent.
For parity based profile (RAID5/6), we use new map_block_v2() and check
full stripe by full stripe.
Signed-off-by: Qu
Introduce new function, verify_parities(), to check if parities matches
for full stripe which all data stripes matches with their csum.
Signed-off-by: Qu Wenruo
---
check/scrub.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/chec
For READ, caller normally hopes to get what they request, other than
full stripe map.
In this case, we should remove unrelated stripe map, just like the
following case:
32K 96K
|<-request range->|
0 64k 128K
RAID0: |
Will be used for later scrub usage.
Signed-off-by: Qu Wenruo
---
ctree.h | 2 ++
extent-tree.c | 52
2 files changed, 54 insertions(+)
diff --git a/ctree.h b/ctree.h
index c76b1f1..d22e520 100644
--- a/ctree.h
+++ b/ctree.h
@@ -2372,6
Introuduce new local structures, scrub_full_stripe and scrub_stripe, for
incoming offline scrub support.
Signed-off-by: Qu Wenruo
---
Makefile.in | 2 +-
check/scrub.c | 100 ++
2 files changed, 101 insertions(+), 1 deletion(-)
create
Introduce a new function, scrub_one_extent(), as a wrapper to check one
extent.
Signed-off-by: Qu Wenruo
---
check/scrub.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/check/scrub.c b/check/scrub.c
index 5cd8bc4..cdba469 100644
Introduce a new function, btrfs_read_one_data_csum(), to read just one
data csum for check usage.
Unlike original implement in cmds-check.c which checks csum by one
CSUM_EXTENT, this just read out one csum(4 bytes).
It is not fast but makes code easier to read.
And will be used in later fsck scru
Introduce function, recover_from_parities(), to recover data stripes.
However this function only support RAID5 yet, but should be good enough
for the scrub framework.
Signed-off-by: Qu Wenruo
---
check/scrub.c | 49 +
1 file changed, 49 insertions
Introduce a new function, scrub_one_full_stripe(), to check a full
stripe.
It can handle the following case:
1) Device missing
Will try to recover, then check against csum
2) Csum mismatch
Will try to recover, then check against csum
3) All csum match
Will check against parity, to ensur
Introduce a new function, scrub_data_mirror(), to check mirror based
data blocks.
Signed-off-by: Qu Wenruo
---
check/scrub.c | 67 +++
1 file changed, 67 insertions(+)
diff --git a/check/scrub.c b/check/scrub.c
index ce8d5e5..5cd8bc4 10064
***Just RFC patch for early evaluation, please don't merge it***
For any one who wants to try it, it can be get from my repo:
https://github.com/adam900710/btrfs-progs/tree/fsck_scrub
Currently, I only tested it on SINGLE/DUP/RAID1/RAID5 filesystems, with
mirror or parity or data corrupted.
The t
On 10/16/2016 09:48 PM, Hans van Kranenburg wrote:
> On 10/16/2016 08:54 PM, Stefan Priebe - Profihost AG wrote:
>> Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:
>>> On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:
cp --reflink=always takes sometimes very long. (i.e. 25-3
Am 16.10.2016 um 21:48 schrieb Hans van Kranenburg:
> On 10/16/2016 08:54 PM, Stefan Priebe - Profihost AG wrote:
>> Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:
>>> On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:
cp --reflink=always takes sometimes very long. (i.e. 25-
On 10/16/2016 08:54 PM, Stefan Priebe - Profihost AG wrote:
> Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:
>> On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:
>>>
>>> cp --reflink=always takes sometimes very long. (i.e. 25-35 minutes)
>>>
>>> An example:
>>>
>>> source file:
>>> #
Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg:
> Hi,
>
> On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote:
>>
>> cp --reflink=always takes sometimes very long. (i.e. 25-35 minutes)
>>
>> An example:
>>
>> source file:
>> # ls -la vm-279-disk-1.img
>> -rw-r--r-- 1 root root 204010946
On October 14, 2016 12:43:03 AM EDT, Duncan <1i5t5.dun...@cox.net> wrote:
>I see the specific questions have been answered, and alternatives
>explored in one direction, but I've another alternative, in a different
>
>direction, to suggest.
>
>First a disclaimer. I'm a btrfs user/sysadmin and regu
25 matches
Mail list logo
