Re: [PATCH 4/9] btrfs-progs: Fix Wempty-body warning

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 9:54 ч., Qu Wenruo wrote: > messages.h:49:24: warning: suggest braces around empty body in an 'if' > statement [-Wempty-body] > PRINT_TRACE_ON_ERROR;\ > > Just extra braces would solve the problem. > > Signed-off-by: Qu Wenruo Reviewed-by: Nikolay Borisov > --- >

Re: [PATCH 8/9] btrfs-progs: Fix Wtype-limits warning

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 9:54 ч., Qu Wenruo wrote: > The only hit is the following code: > > tlv_len = le16_to_cpu(tlv_hdr->tlv_len); > > if (tlv_type == 0 || tlv_type > BTRFS_SEND_A_MAX > || tlv_len > BTRFS_SEND_BUF_SIZE) { >

Re: [PATCH 7/9] btrfs-progs: Fix Wmaybe-uninitialized warning

2018-11-16 Thread Qu Wenruo
On 2018/11/16 下午4:13, Nikolay Borisov wrote: > > > On 16.11.18 г. 9:54 ч., Qu Wenruo wrote: >> The only location is the following code: >> >> int level = path->lowest_level + 1; >> BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL); >> while(level < BTRFS_MAX_LEVEL) { >>

Re: [PATCH 0/9 v2] fix replace-start and replace-cancel racing

2018-11-16 Thread Anand Jain
On 11/15/2018 11:41 PM, David Sterba wrote: On Sun, Nov 11, 2018 at 10:22:15PM +0800, Anand Jain wrote: v1->v2: 2/9: Drop writeback required 3/9: Drop writeback required 7/9: Use the condition within the WARN_ON() 6/9: Use the condition within the ASSERT() Replace-start and

Re: [PATCH 5/9] btrfs-progs: Fix Wimplicit-fallthrough warning

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 9:54 ч., Qu Wenruo wrote: > Although most fallthrough case is pretty obvious, we still need to teach > the dumb compiler that it's an explicit fallthrough. > > Also reformat the code to use common indent. > > Signed-off-by: Qu Wenruo Reviewed-by: Nikolay Borisov Is this

[PATCH v1.1 9/9] btrfs-progs: Cleanup warning reported by -Wmissing-prototypes

2018-11-16 Thread Qu Wenruo
The following missing prototypes will be fixed: 1) btrfs.c::handle_special_globals() 2) check/mode-lowmem.c::repair_ternary_lowmem() 3) extent-tree.c::btrfs_search_overlap_extent() Above 3 can be fixed by making them static 4) utils.c::btrfs_check_nodesize() Fixed by moving it to

Re: [PATCH v1.1 7/9] btrfs-progs: Fix Wmaybe-uninitialized warning

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 10:22 ч., Qu Wenruo wrote: > GCC 8.2.1 will report the following warning with "make W=1": > > ctree.c: In function 'btrfs_next_sibling_tree_block': > ctree.c:2990:21: warning: 'slot' may be used uninitialized in this function > [-Wmaybe-uninitialized] >

Re: [PATCH 6/9] btrfs-progs: Fix Wsuggest-attribute=format warning

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 9:54 ч., Qu Wenruo wrote: > Add __attribute__ ((format (printf, 4, 0))) to fix the vprintf calling > function. > > Signed-off-by: Qu Wenruo Reviewed-by: Nikolay Borisov > --- > string-table.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/string-table.c

Re: [PATCH v1.1 9/9] btrfs-progs: Cleanup warning reported by -Wmissing-prototypes

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 10:04 ч., Qu Wenruo wrote: > The following missing prototypes will be fixed: > 1) btrfs.c::handle_special_globals() > 2) check/mode-lowmem.c::repair_ternary_lowmem() > 3) extent-tree.c::btrfs_search_overlap_extent() > Above 3 can be fixed by making them static > > 4)

Re: [PATCH 7/9] btrfs-progs: Fix Wmaybe-uninitialized warning

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 9:54 ч., Qu Wenruo wrote: > The only location is the following code: > > int level = path->lowest_level + 1; > BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL); > while(level < BTRFS_MAX_LEVEL) { > slot = path->slots[level] + 1; >

Re: [PATCH 8/9] btrfs: user requsted replace cancel is not an error

2018-11-16 Thread Anand Jain
On 11/16/2018 06:29 PM, Anand Jain wrote: On 11/15/2018 11:31 PM, David Sterba wrote: On Sun, Nov 11, 2018 at 10:22:23PM +0800, Anand Jain wrote: As of now only user requested replace cancel can cancel the replace-scrub so no need to log error for it. This has probably some user

[PATCH v1.1 3/9] btrfs-progs: Makefile.extrawarn: Don't warn on sign compare

2018-11-16 Thread Qu Wenruo
Under most case, we are just using 'int' for 'unsigned int', and doesn't care about the sign. The Wsign-compare is causing tons of false alerts. Suppressing it would make W=1 less noisy. Signed-off-by: Qu Wenruo --- changelog: v1.1: Use cc-disable-warning to provide much better compatibility

Re: [PATCH 5/9] btrfs-progs: Fix Wimplicit-fallthrough warning

2018-11-16 Thread Qu Wenruo
On 2018/11/16 下午4:04, Nikolay Borisov wrote: > > > On 16.11.18 г. 9:54 ч., Qu Wenruo wrote: >> Although most fallthrough case is pretty obvious, we still need to teach >> the dumb compiler that it's an explicit fallthrough. >> >> Also reformat the code to use common indent. >> >>

[PATCH v1.1 7/9] btrfs-progs: Fix Wmaybe-uninitialized warning

2018-11-16 Thread Qu Wenruo
GCC 8.2.1 will report the following warning with "make W=1": ctree.c: In function 'btrfs_next_sibling_tree_block': ctree.c:2990:21: warning: 'slot' may be used uninitialized in this function [-Wmaybe-uninitialized] path->slots[level] = slot; ~~~^~ The culprit is

Re: BTRFS on production: NVR 16+ IP Cameras

2018-11-16 Thread Anand Jain
On 11/16/2018 03:51 AM, Nikolay Borisov wrote: On 15.11.18 г. 20:39 ч., Juan Alberto Cirez wrote: Is BTRFS mature enough to be deployed on a production system to underpin the storage layer of a 16+ ipcameras-based NVR (or VMS if you prefer)? Based on our limited experience with BTRFS (1+

Re: [PATCH 8/9] btrfs: user requsted replace cancel is not an error

2018-11-16 Thread Anand Jain
On 11/15/2018 11:31 PM, David Sterba wrote: On Sun, Nov 11, 2018 at 10:22:23PM +0800, Anand Jain wrote: As of now only user requested replace cancel can cancel the replace-scrub so no need to log error for it. This has probably some user visible effect or threre are steps to reproduce the

[PATCH] Btrfs: bring back key search optimization to btrfs_search_old_slot()

2018-11-16 Thread fdmanana
From: Filipe Manana Commit d7396f07358a ("Btrfs: optimize key searches in btrfs_search_slot"), dated from August 2013, introduced an optimization to search for keys in a node/leaf to both btrfs_search_slot() and btrfs_search_old_slot(). For the later, it ended up being reverted in commit

Re: [PATCH 7/9] btrfs: quiten warn if the replace is canceled at finish

2018-11-16 Thread Anand Jain
On 11/15/2018 11:35 PM, David Sterba wrote: On Sun, Nov 11, 2018 at 10:22:22PM +0800, Anand Jain wrote: When we successfully cancel the replace its scrub returns -ECANCELED, which then passed to btrfs_dev_replace_finishing(), it cleans up based on the scrub returned status and propagates the

Re: BTRFS on production: NVR 16+ IP Cameras

2018-11-16 Thread Austin S. Hemmelgarn
On 2018-11-15 13:39, Juan Alberto Cirez wrote: Is BTRFS mature enough to be deployed on a production system to underpin the storage layer of a 16+ ipcameras-based NVR (or VMS if you prefer)? For NVR, I'd say no. BTRFS does pretty horribly with append-only workloads, even if they are WORM

[PATCH] Btrfs: allow clear_extent_dirty() to receive a cached extent state record

2018-11-16 Thread fdmanana
From: Filipe Manana We can have a lot freed extents during the life span of transaction, so the red black tree that keeps track of the ranges of each freed extent (fs_info->freed_extents[]) can get quite big. When finishing a transaction commit we find each range, process it (discard the

Re: [PATCH] Btrfs: allow clear_extent_dirty() to receive a cached extent state record

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 15:04 ч., fdman...@kernel.org wrote: > From: Filipe Manana > > We can have a lot freed extents during the life span of transaction, so > the red black tree that keeps track of the ranges of each freed extent > (fs_info->freed_extents[]) can get quite big. When finishing a

Re: [PATCH 0/5] Misc cleanups in balance code

2018-11-16 Thread David Sterba
On Fri, Oct 26, 2018 at 02:43:16PM +0300, Nikolay Borisov wrote: > While investigating the balance hang I came across various inconsistencies in > the source. This series aims to fix those. > > The first patch is (I believe) a fix to a longstanding bug that could cause > balance to fail due to

Re: [PATCH 7/9] btrfs: quiten warn if the replace is canceled at finish

2018-11-16 Thread David Sterba
On Fri, Nov 16, 2018 at 08:06:36PM +0800, Anand Jain wrote: > > > On 11/15/2018 11:35 PM, David Sterba wrote: > > On Sun, Nov 11, 2018 at 10:22:22PM +0800, Anand Jain wrote: > >> When we successfully cancel the replace its scrub returns -ECANCELED, > >> which then passed to

Re: [PATCH 0/5] Misc cleanups in balance code

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 17:18 ч., David Sterba wrote: > On Fri, Oct 26, 2018 at 02:43:16PM +0300, Nikolay Borisov wrote: >> While investigating the balance hang I came across various inconsistencies >> in >> the source. This series aims to fix those. >> >> The first patch is (I believe) a fix to a

bad tree block start, want 705757184 have 82362368

2018-11-16 Thread Stephan Olbrich
Hi, a few days ago my root file system (simple btrfs on a SSD, no RAID or anything) suddenly became read only. Looking at dmsg, I found this: [ 19.285020] BTRFS error (device sda2): bad tree block start, want 705757184 have 82362368 [ 19.285042] BTRFS: error (device sda2) in

Re: bad tree block start, want 705757184 have 82362368

2018-11-16 Thread Nikolay Borisov
On 16.11.18 г. 18:17 ч., Stephan Olbrich wrote: > Hi, > > a few days ago my root file system (simple btrfs on a SSD, no RAID or > anything) suddenly became read only. > Looking at dmsg, I found this: > > [ 19.285020] BTRFS error (device sda2): bad tree block start, want > 705757184 have

Re: BTRFS on production: NVR 16+ IP Cameras

2018-11-16 Thread Chris Murphy
On Thu, Nov 15, 2018 at 10:39 AM Juan Alberto Cirez wrote: > > Is BTRFS mature enough to be deployed on a production system to underpin > the storage layer of a 16+ ipcameras-based NVR (or VMS if you prefer)? > > Based on our limited experience with BTRFS (1+ year) under the above > scenario the

Re: [PATCH 2/5] btrfs: Refactor btrfs_can_relocate

2018-11-16 Thread Anand Jain
On 10/26/2018 07:43 PM, Nikolay Borisov wrote: btrfs_can_relocate returns 0 when it concludes the given chunk can be relocated and -1 otherwise. Since this function is used as a predicated and it return a binary value it makes no sense to have it's return value as an int so change it to bool.

Re: [PATCH 3/5] btrfs: Remove superfluous check form btrfs_remove_chunk

2018-11-16 Thread Anand Jain
On 10/26/2018 07:43 PM, Nikolay Borisov wrote: It's unnecessary to check map->stripes[i].dev for NULL given its value is already set and dereferenced above the the check. No functional changes. Signed-off-by: Nikolay Borisov Reviewed-by: Anand Jain Thanks, Anand ---

Re: [PATCH 5/5] btrfs: Replace BUG_ON with ASSERT in find_lock_delalloc_range

2018-11-16 Thread Anand Jain
On 10/26/2018 07:43 PM, Nikolay Borisov wrote: lock_delalloc_pages should only return 2 values - 0 in case of success and -EAGAIN if the range of pages to be locked should be shrunk due to some of gone. Manual inspections confirms that this is indeed the case since __process_pages_contig is

Re: [PATCH 4/5] btrfs: Sink find_lock_delalloc_range's 'max_bytes' argument

2018-11-16 Thread Anand Jain
On 10/26/2018 07:43 PM, Nikolay Borisov wrote: All callers of this function pass BTRFS_MAX_EXTENT_SIZE (128M) so let's reduce the argument count and make that a local variable. No functional changes. Signed-off-by: Nikolay Borisov Reviewed-by: Anand Jain Thanks, Anand ---