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
On Sat, Oct 15, 2016 at 10:03:03AM -0700, Christoph Hellwig wrote:
> The poster child would be btrfs, and I would have added some output
> here if btrfs support in xfstests wasn't completely broken at this
> point.
>
> Well, added Ccs and some output anyway in this case..
Turns out the btrfs
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.
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
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 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.
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
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
***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
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
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
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
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
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
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
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: |
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
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
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
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
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
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
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
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
25 matches
Mail list logo