[PATCH V2] Btrfs-progs: subvol_uuid_search: Return error code on memory allocation failure

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

Re: Copy BTRFS volume to another BTRFS volume including subvolumes and snapshots

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

[PATCH] btrfs: assign error values to the correct bio structs

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

Re: speed up cp --reflink=always

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

[RFC PATCH v0.8 08/14] btrfs-progs: check/scrub: Introduce function to scrub one data stripe

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

[RFC PATCH v0.8 01/14] btrfs-progs: Introduce new btrfs_map_block function which returns more unified result.

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

[RFC PATCH v0.8 05/14] btrfs-progs: check/scrub: Introduce function to scrub mirror based tree block

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

[RFC PATCH v0.8 14/14] btrfs-progs: fsck: Introduce offline scrub function

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

[RFC PATCH v0.8 13/14] btrfs-progs: check/scrub: Introduce function to check a whole block group

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

[RFC PATCH v0.8 09/14] btrfs-progs: check/scrub: Introduce function to verify parities

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

[RFC PATCH v0.8 02/14] btrfs-progs: Allow __btrfs_map_block_v2 to remove unrelated stripes

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: |

[RFC PATCH v0.8 10/14] btrfs-progs: extent-tree: Introduce function to check if there is any extent in given range.

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

[RFC PATCH v0.8 04/14] btrfs-progs: check/scrub: Introduce structures to support fsck scrub

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

[RFC PATCH v0.8 07/14] btrfs-progs: check/scrub: Introduce function to scrub one extent

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

[RFC PATCH v0.8 03/14] btrfs-progs: check/csum: Introduce function to read out one data csum

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

[RFC PATCH v0.8 11/14] btrfs-progs: check/scrub: Introduce function to recover data parity

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

[RFC PATCH v0.8 12/14] btrfs-progs: check/scrub: Introduce a function to scrub one full stripe

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

[RFC PATCH v0.8 06/14] btrfs-progs: check/scrub: Introduce function to scrub mirror based data blocks

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

[RFC PATCH v0.8 00/14] Offline scrub support, and hint to solve kernel scrub data silent corruption

***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

Re: speed up cp --reflink=always

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.

Re: speed up cp --reflink=always

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.

Re: speed up cp --reflink=always

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: >>>

Re: speed up cp --reflink=always

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

Re: Incremental send robustness question

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

Re: [PATCH 2/3] misc: fix fallocate commands that need the unshare switch

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