Re: Full filesystem btrfs rebalance kernel panic to read-only lock

2018-11-08 Thread Qu Wenruo
On 2018/11/9 上午6:40, Pieter Maes wrote: > Hello, > > So, I've had the full disk issue, so when I tried re-balancing, > I got a panic, that pushed filesystem read-only and I'm unable to > balance or grow the filesystem now. > > fs info: > btrfs fi show / > Label: none  uuid:

Re: [PATCH] Btrfs: incremental send, fix infinite loop when apply children dir moves

2018-11-08 Thread robbieko
robbieko 於 2018-11-06 20:23 寫到: Hi, I can reproduce the infinite loop, the following will describe the reason and example. Example: tree --inodes parent/ send/ parent/ `-- [261] 261 `-- [271] 271 `-- [266] 266 |-- [259] 259 |-- [260]

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

2018-11-08 Thread Qu Wenruo
On 2018/11/8 下午10:48, Filipe Manana wrote: > On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana wrote: >> >> On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote: >>> >>> >>> >>> On 2018/11/8 下午9:17, fdman...@kernel.org wrote: From: Filipe Manana When creating a block group we don't need

Full filesystem btrfs rebalance kernel panic to read-only lock

2018-11-08 Thread Pieter Maes
Hello, So, I've had the full disk issue, so when I tried re-balancing, I got a panic, that pushed filesystem read-only and I'm unable to balance or grow the filesystem now. fs info: btrfs fi show / Label: none  uuid: 9b591b6b-6040-437e-9398-6883ca3bf1bb     Total devices 1 FS bytes used

Re: [PATCH v15.1 03/13] btrfs: dedupe: Introduce function to add hash into in-memory tree

2018-11-08 Thread Timofey Titovets
вт, 6 нояб. 2018 г. в 9:41, Lu Fengqi : > > From: Wang Xiaoguang > > Introduce static function inmem_add() to add hash into in-memory tree. > And now we can implement the btrfs_dedupe_add() interface. > > Signed-off-by: Qu Wenruo > Signed-off-by: Wang Xiaoguang > Reviewed-by: Josef Bacik >

Re: Where is my disk space ?

2018-11-08 Thread Chris Murphy
On Thu, Nov 8, 2018 at 2:27 AM, Barbet Alain wrote: > Hi ! > Just to give you end of the story: > I move my /var/lib/docker to my home (other partition), and my space > come back ... I'm not sure why that would matter. Both btrfs du and regular du showed only ~350M used in /var which is about

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

2018-11-08 Thread Filipe Manana
On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana wrote: > > On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote: > > > > > > > > On 2018/11/8 下午9:17, fdman...@kernel.org wrote: > > > From: Filipe Manana > > > > > > When creating a block group we don't need to set the log for full commit > > > if the new

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

2018-11-08 Thread Filipe Manana
On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote: > > > > On 2018/11/8 下午9:17, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > When creating a block group we don't need to set the log for full commit > > if the new block group is not used for data. Logged items can only point > > to

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

2018-11-08 Thread Qu Wenruo
On 2018/11/8 下午9:17, fdman...@kernel.org wrote: > From: Filipe Manana > > When creating a block group we don't need to set the log for full commit > if the new block group is not used for data. Logged items can only point > to logical addresses of data block groups (through file extent items)

[PATCH] btrfs: Check for missing device before bio submission in btrfs_map_bio

2018-11-08 Thread Nikolay Borisov
Before btrfs_map_bio submits all stripe bio it does a number of checks to ensure the device for every stripe is present. However, it doesn't do a DEV_STATE_MISSING check, instead this is relegated to the lower level btrfs_schedule_bio (in the async submission case, sync submission doesn't check

[PATCH] Btrfs: do not set log for full commit when creating non-data block groups

2018-11-08 Thread fdmanana
From: Filipe Manana When creating a block group we don't need to set the log for full commit if the new block group is not used for data. Logged items can only point to logical addresses of data block groups (through file extent items) so there is no need to for the next fsync to fallback to a

Re: [PATCH v15.1 02/13] btrfs: dedupe: Introduce function to initialize dedupe info

2018-11-08 Thread Timofey Titovets
вт, 6 нояб. 2018 г. в 9:41, Lu Fengqi : > > From: Wang Xiaoguang > > Add generic function to initialize dedupe info. > > Signed-off-by: Qu Wenruo > Signed-off-by: Wang Xiaoguang > Reviewed-by: Josef Bacik > Signed-off-by: Lu Fengqi > --- > fs/btrfs/Makefile | 2 +- >

Re: [PATCH -next] btrfs: remove set but not used variable 'tree'

2018-11-08 Thread David Sterba
On Thu, Nov 08, 2018 at 02:14:43AM +, YueHaibing wrote: > Fixes gcc '-Wunused-but-set-variable' warning: > > fs/btrfs/extent_io.c: In function 'end_extent_writepage': > fs/btrfs/extent_io.c:2406:25: warning: > variable 'tree' set but not used [-Wunused-but-set-variable] > > It not used any

Re: [PATCH v15.1 01/13] btrfs: dedupe: Introduce dedupe framework and its header

2018-11-08 Thread Timofey Titovets
вт, 6 нояб. 2018 г. в 9:41, Lu Fengqi : > > From: Wang Xiaoguang > > Introduce the header for btrfs in-band(write time) de-duplication > framework and needed header. > > The new de-duplication framework is going to support 2 different dedupe > methods and 1 dedupe hash. > > Signed-off-by: Qu

Re: Where is my disk space ?

2018-11-08 Thread Barbet Alain
Hi ! Just to give you end of the story: I move my /var/lib/docker to my home (other partition), and my space come back ... I let docker here & don't try to put it again on / to see if problem come back. Le mer. 31 oct. 2018 à 08:34, Barbet Alain a écrit : > > > Also, since you don't have any

Re: [PATCH 6/9] btrfs: replace's scrub must not be running in replace suspended state

2018-11-08 Thread Anand Jain
On 11/08/2018 04:52 PM, Nikolay Borisov wrote: On 8.11.18 г. 10:33 ч., Anand Jain wrote: On 11/07/2018 08:19 PM, Nikolay Borisov wrote: On 7.11.18 г. 13:43 ч., Anand Jain wrote: +    /* scrub for replace must not be running in suspended state */ +    if

Re: [PATCH 6/9] btrfs: replace's scrub must not be running in replace suspended state

2018-11-08 Thread Nikolay Borisov
On 8.11.18 г. 10:33 ч., Anand Jain wrote: > > > On 11/07/2018 08:19 PM, Nikolay Borisov wrote: >> >> >> On 7.11.18 г. 13:43 ч., Anand Jain wrote: >>> +    /* scrub for replace must not be running in suspended state */ >>> +    if (btrfs_scrub_cancel(fs_info) != -ENOTCONN) >>> +

Re: [PATCH 6/9] btrfs: replace's scrub must not be running in replace suspended state

2018-11-08 Thread Anand Jain
On 11/07/2018 08:19 PM, Nikolay Borisov wrote: On 7.11.18 г. 13:43 ч., Anand Jain wrote: + /* scrub for replace must not be running in suspended state */ + if (btrfs_scrub_cancel(fs_info) != -ENOTCONN) + ASSERT(0);

[PATCH 0/3] Cleanups following optional extent_io_ops callbacks removal

2018-11-08 Thread Nikolay Borisov
Here are 3 minor patches that further clean up writepage_delalloc. The first one moves the extent locked check in the caller of writepage_delalloc since this seems more natural. This paves the way for the second patch which removes epd as an argument to writepage_delalloc. The final patch was

[PATCH 3/3] btrfs: Remove unused extent_state argument from btrfs_writepage_endio_finish_ordered

2018-11-08 Thread Nikolay Borisov
This parameter was never used, yet was part of the interface of the function ever since its introduction as extent_io_ops::writepage_end_io_hook in e6dcd2dc9c48 ("Btrfs: New data=ordered implementation"). Now that NULL is passed everywhere as a value for this parameter let's remove it for good. No

[PATCH 1/3] btrfs: Move epd::extent_locked check to writepage_delalloc's caller

2018-11-08 Thread Nikolay Borisov
If epd::extent_locked is set then writepage_delalloc terminates. Make this a bit more apparent in the caller by simply bubbling the check up. This enables to remove epd as an argument to writepage_delalloc in a future patch. No functional change. Signed-off-by: Nikolay Borisov ---

[PATCH 2/3] btrfs: Remove extent_page_data argument from writepage_delalloc

2018-11-08 Thread Nikolay Borisov
The only remaining use of the 'epd' argument in writepage_delalloc is to reference the extent_io_tree which was set in extent_writepages. Since it is guaranteed that page->mapping of any page passed to writepage_delalloc (and __extent_writepage as the sole caller) to be equal to that passed in

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

2018-11-08 Thread Anand Jain
On 11/07/2018 08:17 PM, Nikolay Borisov wrote: On 7.11.18 г. 13:43 ч., Anand Jain wrote: - WARN_ON(ret); + if (ret != -ECANCELED) + WARN_ON(ret); WARN_ON(ret && ret != -ECANCELED) Will fix. Thanks, Anand