Re: multi-device btrfs with single data mode and disk failure

Hi, I finally did it : patched the kernel and removed the device. As expected he did not scream since there was nothing at all on the device. Now I'm checking that everything is fine: scrub (in read only) check (in read only) but I think that everything will be OK If not, I will rebuild the array

Re: [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes

On 09/29/16 14:21, Anatoly Pugachev wrote: >> ... >> >> This is fixed by patch >> >> "Btrfs: remove unnecessary btrfs_mark_buffer_dirty in split_leaf" >> >> that's in the 4.9 queue. Other than that, the self-tests seem to pass, >> thanks for the test. Would be good if you can test with the

Re: [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes

On Thu, Sep 29, 2016 at 3:52 PM, Holger Hoffstätte wrote: > On 09/29/16 14:21, Anatoly Pugachev wrote: >>> ... >>> >>> This is fixed by patch >>> >>> "Btrfs: remove unnecessary btrfs_mark_buffer_dirty in split_leaf" >>> >>> that's in the 4.9 queue. Other than

Re: [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes

On Thu, Sep 29, 2016 at 04:02:35PM +0300, Anatoly Pugachev wrote: > > Try to add https://patchwork.kernel.org/patch/9332707/ aka > > "Btrfs: improve check_node to avoid reading corrupted nodes" which should > > return > > -EIO and prevent the BUG(). > > Guys, > > I was wrong with "Btrfs: remove

[RFC][PATCH] btrfs-progs: move sources shared with kernel to own directory

Hi, I've started to reorganize the souces in progs so we can split the files and group them. At the moment there's the kernel library (crc, list, radix, ...) as the files are almost exactly the same as provided by kernel. This patch moves btrfs-specific sources to own directory. As this is a

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

Your original fix is good. Feel free to my tag after enriching the comment in btrfs_invalidatepage(). Reviewed-by: Qu Wenruo Thanks again for your founding and sorry for the extra time reviewing. Thanks Qu At 09/29/2016 07:13 PM, Goldwyn Rodrigues wrote: On

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

At 09/30/2016 10:18 AM, Qu Wenruo wrote: Your original fix is good. Feel free to my tag after enriching the comment in btrfs_invalidatepage(). Feel free to "add" my tag... Reviewed-by: Qu Wenruo Thanks again for your founding and sorry for the extra time

[PATCH v2 3/4] btrfs-progs: raid56: Introduce new function to calculate raid5 parity or data stripe

Introduce new function raid5_gen_result() to calculate parity or data stripe. Signed-off-by: Qu Wenruo --- v2: Patch split Change parameter type from void* to char* for xor_range() Change parameter order for xxor_range() Handle unaligned memory address for

[PATCH v2 2/4] btrfs-progs: volumes: Remove BUG_ON in raid56 write routine

Remove various BUG_ON in raid56 write routine, including: 1) Memory allocation error 2) Write error 3) Validation check Signed-off-by: Qu Wenruo --- v2: Split patch Remove all BUG_ON() in raid56 write routine. --- volumes.c | 84

[PATCH v2 1/4] btrfs-progs: rename raid6.c to raid56.c

This allows us to put raid5 codes into that file other than creating a new raid5.c. Signed-off-by: Qu Wenruo --- v2: Split patch --- Makefile.in | 2 +- disk-io.h | 2 +- raid6.c => raid56.c | 0 3 files changed, 2 insertions(+), 2 deletions(-)

[PATCH v2 4/4] btrfs-progs: volumes: Use new raid5_gen_result to calculate raid5 parity

Use thew raid5_gen_result() function to calculate raid5 parity. Signed-off-by: Qu Wenruo --- v2: Patch split --- volumes.c | 19 ++- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/volumes.c b/volumes.c index 93ce934..e78d157 100644 ---

Re: [PATCH 1/2] btrfs-progs: raid56: Add support for raid5 to calculate any stripe

On Wed, Sep 28, 2016 at 04:30:03PM +0800, Qu Wenruo wrote: > Add a new function raid5_gen_result() to calculate raid5 parity or > recover data stripe. > > Since now that raid6.c handles both raid5 and raid6, rename it to > raid56.c. Please split changes in this patch to the following: - rename

Re: [PATCH 2/2] btrfs-progs: Remove unnecessary parameter to clear_extent_uptodate

On Wed, Sep 28, 2016 at 04:30:04PM +0800, Qu Wenruo wrote: > Signed-off-by: Qu Wenruo Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] btrfs-progs: qgroup: Fix regression leads to corrupted qgroup status

On Wed, Sep 07, 2016 at 10:54:19AM +0800, Qu Wenruo wrote: > Commit 93dabf211d74daf6e3de642bdd887a90a00f7b49 > Author: Mark Fasheh > Date: Fri Jun 17 13:37:48 2016 -0700 > > btrfs-progs: check: verify qgroups above level 0 > > This commit introduced a new regression which

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi, Am 28.09.2016 um 14:10 schrieb Wang Xiaoguang: > OK, I see. > But given that you often run into enospc errors, can you work out a > reproduce > script according to you work load. That will give us great help. I tried hard to reproduce it but i can't get it to reproduce with a test script.

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi, On 09/29/2016 02:49 PM, Stefan Priebe - Profihost AG wrote: Hi, Am 28.09.2016 um 14:10 schrieb Wang Xiaoguang: OK, I see. But given that you often run into enospc errors, can you work out a reproduce script according to you work load. That will give us great help. You got ENOSPC errors

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: >>> I found that compress sometime report ENOSPC error even in 4.8-rc8, >>> currently >> I cannot confirm that as i do not have anough space to test this without >> compression ;-( But yes i've compression enabled. > I might not get you, my poor

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 29.09.2016 um 08:55 schrieb Wang Xiaoguang: > Hi, > > On 09/29/2016 02:49 PM, Stefan Priebe - Profihost AG wrote: >> Hi, >> >> Am 28.09.2016 um 14:10 schrieb Wang Xiaoguang: >>> OK, I see. >>> But given that you often run into enospc errors, can you work out a >>> reproduce >>> script

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi, On 09/29/2016 03:09 PM, Stefan Priebe - Profihost AG wrote: Am 29.09.2016 um 08:55 schrieb Wang Xiaoguang: Hi, On 09/29/2016 02:49 PM, Stefan Priebe - Profihost AG wrote: Hi, Am 28.09.2016 um 14:10 schrieb Wang Xiaoguang: OK, I see. But given that you often run into enospc errors, can

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

Thanks for your test script. I succeeded in pinning down the problem. The problem is, btrfs is invalidate pages that belongs to ordered extent(goes through writeback) The ftrace(with more tracepoints to trace qgroup->reserved change) shows: -- btrfs_qgroup_release_data: root=257,

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi, Am 29.09.2016 um 12:03 schrieb Adam Borowski: > On Thu, Sep 29, 2016 at 09:27:01AM +0200, Stefan Priebe - Profihost AG wrote: >> Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: > I found that compress sometime report ENOSPC error even in 4.8-rc8, > currently I cannot confirm that

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

On 09/29/2016 03:57 AM, Qu Wenruo wrote: > Thanks for your test script. > > I succeeded in pinning down the problem. > > The problem is, btrfs is invalidate pages that belongs to ordered > extent(goes through writeback) No, I don't think invalidated pages are going through writeback. The

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

On Thu, Sep 29, 2016 at 09:27:01AM +0200, Stefan Priebe - Profihost AG wrote: > Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: > >>> I found that compress sometime report ENOSPC error even in 4.8-rc8, > >>> currently > >> I cannot confirm that as i do not have anough space to test this without >

Re: [PULL] Btrfs, for 4.9, part 1

On Thu, Sep 29, 2016 at 01:36:46PM +0200, David Sterba wrote: Hi, I'm sending the first batch for 4.9, mostly fixes, stability improvements and cleanups. There might be a second pull if the patches get reviewed, anything space handling related or qgroups. Please pull, thanks. Thanks Dave,

Re: [PATCH] btrfs-progs: qgroup: Fix regression leads to corrupted qgroup status

At 09/30/2016 01:19 AM, David Sterba wrote: On Wed, Sep 07, 2016 at 10:54:19AM +0800, Qu Wenruo wrote: Commit 93dabf211d74daf6e3de642bdd887a90a00f7b49 Author: Mark Fasheh Date: Fri Jun 17 13:37:48 2016 -0700 btrfs-progs: check: verify qgroups above level 0 This

Re: [PATCH 1/2] btrfs-progs: raid56: Add support for raid5 to calculate any stripe

At 09/30/2016 01:37 AM, David Sterba wrote: On Wed, Sep 28, 2016 at 04:30:03PM +0800, Qu Wenruo wrote: Add a new function raid5_gen_result() to calculate raid5 parity or recover data stripe. Since now that raid6.c handles both raid5 and raid6, rename it to raid56.c. Please split changes in

Re: [RFC][PATCH] btrfs-progs: move sources shared with kernel to own directory

At 09/30/2016 12:38 AM, David Sterba wrote: Hi, I've started to reorganize the souces in progs so we can split the files and group them. At the moment there's the kernel library (crc, list, radix, ...) as the files are almost exactly the same as provided by kernel. This patch moves

[PATCH 2/2] btrfs: Add trace point for qgroup reserved space

Introduce the following trace points: qgroup_update_reserve qgroup_meta_reserve And modify the timing of btrfs_qgroup_free_delayed_ref() and btrfs_qgroup_release_data() events, to work with qgroup_update_reserve() event. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c

[PATCH 1/2] btrfs: Add WARN_ON for qgroup reserved underflow

While the reason why qgroup reserved space may underflow is still under investigation, such WARN_ON will help us to expose the bug more easily, and for end-user we can detect and avoid underflow. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c | 21 -

Re: [PATCH] qgroup: Prevent qgroup->reserved from going subzero

At 09/29/2016 07:13 PM, Goldwyn Rodrigues wrote: On 09/29/2016 03:57 AM, Qu Wenruo wrote: Thanks for your test script. I succeeded in pinning down the problem. The problem is, btrfs is invalidate pages that belongs to ordered extent(goes through writeback) No, I don't think invalidated

Re: [PATCH v2 3/6] Btrfs: catch invalid free space trees

On Mon, Sep 26, 2016 at 04:13:29PM -0700, Omar Sandoval wrote: > > +/* > > + * Older kernels on big-endian systems produced broken free space tree > > bitmaps, > > + * and btrfs-progs also used to corrupt the free space tree. If this bit is > > + * clear, then the free space tree cannot be

Re: [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes

On Mon, Sep 26, 2016 at 07:50:00PM +0200, David Sterba wrote: > On Sun, Sep 25, 2016 at 10:55:24AM +0300, Anatoly Pugachev wrote: > > applied patch to git kernel (v4.8-rc7-172-gbd5dbcb) cleanly. Did not used > > btrfs-progs.git, but debian shipped 4.7.3-1 . > > > > [3184240.135182] BTRFS info

[PULL] Btrfs, for 4.9, part 1

Hi, I'm sending the first batch for 4.9, mostly fixes, stability improvements and cleanups. There might be a second pull if the patches get reviewed, anything space handling related or qgroups. Please pull, thanks. The following

Re: [PATCH v3] btrfs-progs: Return more meaningful value for btrfs_read_deve_super

On Mon, Sep 26, 2016 at 12:54:26PM +0800, Qu Wenruo wrote: > btrfs_read_dev_super() only returns 0 or -1, which doesn't really help, > caller won't know if it's caused by bad superblock or superblock out of > range. > > Return -errno if pread64() return -1, and return -EOF if none or part of >