TL;DR: RAID1 does not recover, I guess the interesting part in the stack
trace is:
Call Trace:
[] __del_reloc_root+0x30/0x100 [btrfs]
[] free_reloc_roots+0x25/0x40 [btrfs]
[] merge_reloc_roots+0x18e/0x240 [btrfs]
[] btrfs_recover_relocation+0x374/0x420 [btrfs]
[] open_ctree+0x1b7d/0x
When rebasing my patchset, I forgot to pick up a cleanup patch to remove
old hotfix in 4.2 release.
Witouth the cleanup, it will screw up new qgroup reserve framework and
always cause minus reserved number.
Signed-off-by: Qu Wenruo
---
fs/btrfs/qgroup.c | 4
1 file changed, 4 deletions(-)
No_quota parameter for delayed_ref related function are meaningless
after 4.2-rc1, as any new delayed_ref_head will cause qgroup to scan
extent for its rfer/excl change without checking no_quota flag.
So this patch will clean them up.
Signed-off-by: Qu Wenruo
---
fs/btrfs/ctree.h | 4 ++-
Between btrfs_allocerved_file_extent() and
btrfs_add_delayed_qgroup_reserve(), there is a window that delayed_refs
are run and delayed ref head maybe freed before
btrfs_add_delayed_qgroup_reserve().
This will cause btrfs_dad_delayed_qgroup_reserve() to return -ENOENT,
and cause transaction to be a
This patchset fixes 2 bugs:
1. Race condition leading to abort transaction
Reported by Filipe, fixed by 2nd patch.
2. Qgroup low level double free leading to EDQUOT
In fact, I hit such bug several times during internal rebase, but I'm so
stupid to forgot to include it in v3 patchset.
Fixed in 3rd
This patchset fixes 2 bugs:
1. Race condition leading to abort transaction
Reported by Filipe, fixed by 2nd patch.
2. Qgroup low level double free leading to EDQUOT
In fact, I hit such bug several times during internal rebase, but I'm so
stupid to forgot to include it in v3 patchset.
Fixed in 3rd
From: Jiri Kosina
cleaner_kthread() kthread calls try_to_freeze() at the beginning of every
cleanup attempt. This operation can't ever succeed though, as the kthread
hasn't marked itself as freezable.
Before (hopefully eventually) kthread freezing gets converted to fileystem
freezing, we'd ra
On Sat, Oct 24, 2015 at 11:52:37AM -0500, Eric Biggers wrote:
> A few comments:
>
> > if (!(file_in->f_mode & FMODE_READ) ||
> > !(file_out->f_mode & FMODE_WRITE) ||
> > (file_out->f_flags & O_APPEND) ||
> > !file_out->f_op)
> > return -EBADF;
>
>
On Sat, Oct 24, 2015 at 01:02:21PM +0100, P??draig Brady wrote:
> I'm a bit worried about the sparse expansion and default reflinking
> which might preclude cp(1) from using this call in most cases, but I will
> test and try to use it. coreutils has heuristics for determining if files
> are remote,
Filipe Manana wrote on 2015/10/25 14:39 +:
On Tue, Oct 13, 2015 at 3:20 AM, Qu Wenruo wrote:
Add new function btrfs_add_delayed_qgroup_reserve() function to record
how much space is reserved for that extent.
As btrfs only accounts qgroup at run_delayed_refs() time, so newly
allocated ext
Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
iteration.
As extent buffer contains lock, pointers to pages, it's never sane to do
such copy.
The following bug may be caused by this insane operation:
[92098.841309] general protection fault: [#1] SMP
[92098.841338] M
On Sun, Oct 25, 2015 at 01:33:45PM -0400, Jeff Mahoney wrote:
>
> On Oct 25, 2015, at 3:50 PM, Alexandru Moise <00moses.alexande...@gmail.com>
> wrote:
>
> >>> This allows us to trim out half of btrfs_init_delayed_node() which
> >>> is now reduntant.
> >>
> >> It's redundant if kmem_cache_zallo
On Oct 25, 2015, at 3:50 PM, Alexandru Moise <00moses.alexande...@gmail.com>
wrote:
>>> This allows us to trim out half of btrfs_init_delayed_node() which
>>> is now reduntant.
>>
>> It's redundant if kmem_cache_zalloc is used, but you haven't
>> documented that doing so is now required. For a
It's slightly cleaner to zero-out the delayed node upon allocation
than to do it by hand in btrfs_init_delayed_node() for a few members
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
v2: Thanks Jeff Mahoney for pointing out the mistake of removing
the atomic_set in v1 of the pa
> > This allows us to trim out half of btrfs_init_delayed_node() which
> > is now reduntant.
>
> It's redundant if kmem_cache_zalloc is used, but you haven't
> documented that doing so is now required. For all of these changes
> you've posted, if they're to be accepted, I'd really prefer to set u
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
fs/btrfs/transaction.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index a5b0644..cb50f53 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/25/15 1:48 PM, Alexandru Moise wrote:
> This allows us to trim out half of btrfs_init_delayed_node() which
> is now reduntant.
It's redundant if kmem_cache_zalloc is used, but you haven't
documented that doing so is now required. For all of t
This allows us to trim out half of btrfs_init_delayed_node()
which is now reduntant.
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
fs/btrfs/delayed-inode.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-i
On Tue, Oct 13, 2015 at 3:20 AM, Qu Wenruo wrote:
> Add new function btrfs_add_delayed_qgroup_reserve() function to record
> how much space is reserved for that extent.
>
> As btrfs only accounts qgroup at run_delayed_refs() time, so newly
> allocated extent should keep the reserved space until th
On Sun, Oct 25, 2015 at 2:10 PM, Ed Tomlinson wrote:
> Filipe,
>
> I realize its another bug. Two additional pieces of info that might help.
> One, btrfs-progs was at 4.1.2 (I missed a tag= in my git pull).
Btrfs-progs' version is irrelevant. The problem is the send side
generating incorrect pat
Filipe,
I realize its another bug. Two additional pieces of info that might help.
One, btrfs-progs was at 4.1.2 (I missed a tag= in my git pull). Second
is that I have been able to recreate this issue three times over a period
of
two to three days (tring again with 4.2.3). My fs is probably a
On Sun, Oct 25, 2015 at 1:38 PM, Ed Tomlinson wrote:
> Filipe,
>
> Its still not perfect. Here I can do sequential sends a few times then I
> get something like this:
>
> [root@grover snap]# sh -x brh
> + base=/snap/shot
> ++ date +%Y-%V-%u_%m-%d_%H:%M
> + stamp=2015-43-6_10-24_10:24
> + btrfs su
Filipe,
Its still not perfect. Here I can do sequential sends a few times then I
get something like this:
[root@grover snap]# sh -x brh
+ base=/snap/shot
++ date +%Y-%V-%u_%m-%d_%H:%M
+ stamp=2015-43-6_10-24_10:24
+ btrfs subv snapshot -r /snap/homevol /snap/shot.2015-43-6_10-24_10:24
Create
在 2015年10月25日 19:10, Johannes Henninger 写道:
On 25.10.2015 02:44, Qu Wenruo wrote:
在 2015年10月23日 23:05, Johannes Henninger 写道:
On 23.10.2015 01:47, Qu Wenruo wrote:
在 2015年10月23日 04:38, Johannes Henninger 写道:
I'm having a weird problem with snapshots and exclusive quotas. After
creating a
On 25.10.2015 02:44, Qu Wenruo wrote:
>
>
> 在 2015年10月23日 23:05, Johannes Henninger 写道:
>> On 23.10.2015 01:47, Qu Wenruo wrote:
>>> 在 2015年10月23日 04:38, Johannes Henninger 写道:
I'm having a weird problem with snapshots and exclusive quotas. After
creating a snapshot of a subvolume and set
From: Filipe Manana
In the kernel 4.2 merge window we had a big changes to the implementation
of delayed references and qgroups which made the no_quota field of delayed
references not used anymore. More specifically the no_quota field is not
used anymore as of:
commit 0ed4792af0e8 ("btrfs: qgr
From: Filipe Manana
In the kernel 4.2 merge window we had a refactoring/rework of the delayed
references implementation in order to fix certain problems with qgroups.
However that rework introduced one more regression that leads to the
following trace when running delayed references for metadata:
27 matches
Mail list logo
