Re: [PATCH 6/7] Btrfs: helper for ops that requires full stripe

At 02/18/2017 09:28 AM, Liu Bo wrote: This adds a helper to show directly whether ops require full stripe. Signed-off-by: Liu Bo Looks good to me. Reviewed-by: Qu Wenruo Thanks, Qu --- fs/btrfs/volumes.c | 18 ++ 1 file

Re: [PATCH 7/7] Btrfs: convert BUG_ON to WARN_ON

At 02/18/2017 09:28 AM, Liu Bo wrote: These two BUG_ON()s would never be true, ensured by callers' logic. Never a bad idea to remove BUG_ON. Reviewed-by: Qu Wenruo Thanks, Qu Signed-off-by: Liu Bo --- fs/btrfs/volumes.c | 4 ++-- 1 file

Re: [PATCH 5/7] Btrfs: do not add extra mirror when dev_replace target dev is not available

At 02/18/2017 09:28 AM, Liu Bo wrote: With this, we can avoid allocating memory for dev replace copies if the target dev is not available. The patch itself looks good. Reviewed-by: Qu Wenruo However I'm just curious about in which case we can have

Re: [PATCH 4/7] Btrfs: handle operations for device replace separately

At 02/18/2017 09:28 AM, Liu Bo wrote: Since this part is mostly self-independent, this moves it to a separate function. Just code move and modified part looks good to me. Reviewed-by: Qu Wenruo Thanks, Qu Signed-off-by: Liu Bo ---

Re: [PATCH 3/7] Btrfs: introduce a function to get extra mirror from replace

At 02/18/2017 09:28 AM, Liu Bo wrote: As the part of getting extra mirror in __btrfs_map_block is self-independent, this puts it into a separate function. Signed-off-by: Liu Bo Looks good to me. Reviewed-by: Qu Wenruo Thanks, Qu ---

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

At 02/20/2017 12:35 PM, Goldwyn Rodrigues wrote: Hi Qu, On 02/19/2017 09:07 PM, Qu Wenruo wrote: At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: From: Goldwyn Rodrigues We are facing the same problem with EDQUOT which was experienced with ENOSPC. Not sure if we

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

Hi Qu, On 02/19/2017 09:07 PM, Qu Wenruo wrote: > > > At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues >> >> We are facing the same problem with EDQUOT which was experienced with >> ENOSPC. Not sure if we require a full ticketing system such as

Re: [PATCH 2/7] Btrfs: separate DISCARD from __btrfs_map_block

At 02/18/2017 09:28 AM, Liu Bo wrote: Since DISCARD is not as important as an operation like write, we don't copy it to target device during replace, and it makes __btrfs_map_block less complex. Makes sense to me. Signed-off-by: Liu Bo --- fs/btrfs/volumes.c | 306

Re: [PATCH 1/7] Btrfs: create a helper for getting chunk map

At 02/18/2017 09:28 AM, Liu Bo wrote: We have similar code here and there, this merges them into a helper. Signed-off-by: Liu Bo Looks good overall. Although small nitpick inlined below. --- fs/btrfs/extent_io.c | 3 +- fs/btrfs/volumes.c | 163

Re: [PATCH 0/7] cleanup __btrfs_map_block

At 02/18/2017 09:28 AM, Liu Bo wrote: This is attempting to make __btrfs_map_block less scary :) Great!! That's also what I want to do in btrfs-progs. And it would be better if we can take a step further to have a better API for both pure mirrored/striped profile and parity profile. I

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: From: Goldwyn Rodrigues We are facing the same problem with EDQUOT which was experienced with ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but here is a fix. Let me know if it is too big a hammer.

Re: [PATCH] qgroup: Add trace events for reserve and free_ref_root

At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: From: Goldwyn Rodrigues These commits show the current value of qg->reserved and the amount modified. Though these are frequently called function, we may require to monitor qg->reserved for some operations. I have submitted

Re: [PULL] Btrfs patches for 4.11, part 1

At 02/17/2017 08:12 PM, David Sterba wrote: Hi, here's the first batch of patches for 4.11, I'd like to get it off my table. Apart from the few top patches, the rest has been in next. This branch does not conflict with Filipe's pull. Good portion of the patches are cleanups,

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

At 02/17/2017 11:25 PM, Filipe Manana wrote: On Fri, Feb 17, 2017 at 12:37 AM, Qu Wenruo wrote: At 02/16/2017 06:03 PM, Filipe Manana wrote: On Thu, Feb 16, 2017 at 12:39 AM, Qu Wenruo wrote: At 02/15/2017 11:59 PM, Filipe Manana

Re: Btrfs Heatmap - v5 ... snake, linear ... the virtual address space

On 02/19/2017 11:25 AM, Adam Borowski wrote: > On Sun, Feb 19, 2017 at 01:01:29AM +0100, Hans van Kranenburg wrote: >> I just tagged v5 of the Btrfs Heatmap utility, which visualizes the >> usage of your btrfs filesystem > >> Since I got tired of cloning and updating the thing all over the place,

[PATCH] qgroup: Add trace events for reserve and free_ref_root

From: Goldwyn Rodrigues These commits show the current value of qg->reserved and the amount modified. Though these are frequently called function, we may require to monitor qg->reserved for some operations. Signed-off-by: Goldwyn Rodrigues ---

[PATCH] qgroup: Retry after commit on getting EDQUOT

From: Goldwyn Rodrigues We are facing the same problem with EDQUOT which was experienced with ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but here is a fix. Let me know if it is too big a hammer. Quotas are reserved during the start of an operation,

Personal View

Hello, I work with a private security vault firm company. I will be happy to discuss a very important proposal with you if you are interested. Thanks Darren -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More

Re: Btrfs Heatmap - v5 ... snake, linear ... the virtual address space

On Sun, Feb 19, 2017 at 01:01:29AM +0100, Hans van Kranenburg wrote: > I just tagged v5 of the Btrfs Heatmap utility, which visualizes the > usage of your btrfs filesystem > Since I got tired of cloning and updating the thing all over the place, > I added debian packaging. I'm planning to get all