(Replying to myself as I'm not subscribed and can't reply to Duncan's message)
Hi Duncan,
Good catch, mounting with -o skip_balance does allow me to mount the
disk properly.
Scrubbing the partition once mounted results in 0 errors.
I'm still going to keep this untouched for further investigatio
Hi david and chris,
On 08/24/2016 09:42 PM, David Sterba wrote:
Hi,
this pull request contains part 2 and adds more that arrived in the meantime
(new fixes or updated versions of patches). Assorted fixes. Please pull,
thanks.
The
Hi,
On 08/24/2016 08:44 PM, David Sterba wrote:
On Fri, Aug 19, 2016 at 05:59:46PM +0800, Wang Xiaoguang wrote:
The basic idea is simple. Assume a middle tree node A is shared and
its referenceing fs/file tree root ids are 5, 258 and 260, then we
only check node A in the tree who has the smalle
Signed-off-by: Wang Xiaoguang
---
cmds-check.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index 0ddfd24..1cd0421 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -3737,7 +3737,6 @@ static int check_fs_root(struct btrfs_root *root,
path.slots
Signed-off-by: Wang Xiaoguang
---
cmds-check.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/cmds-check.c b/cmds-check.c
index 1cd0421..bce586c 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -9016,9 +9016,10 @@ static int check_tree_block_backref(struct btrfs_fs
Signed-off-by: Wang Xiaoguang
---
.../dropped-snapshot.img | Bin 0 -> 24576 bytes
.../021-partially-dropped-snapshot-case/test.sh | 18 ++
2 files changed, 18 insertions(+)
create mode 100644
tests/fsck-tests/021-partially-dropped-snapshot-ca
This is a brand new btrfs filesystem (few hours of uptime) on 4.7.2
kernel:
1) first, this one repeated in syslog several times:
Aug 24 21:54:15 srv8 kernel: [ 9626.010136] [ cut here
]
Aug 24 21:54:15 srv8 kernel: [ 9626.010162] WARNING: CPU: 2 PID: 71 at
/home/kernel
Robert Munteanu posted on Thu, 25 Aug 2016 01:19:27 +0300 as excerpted:
> Using Kernel 4.7.1 ( openSUSE Tumbleweed x86_64 ), btrfsprogs 4.7 I
> always get a hard lockup when trying to mount my btrfs root partition.
>
> This may be due to some previous errors which only manifested themselves
> now
Hi David,
On Wed, Aug 03, 2016 at 12:33:01PM -0700, Liu Bo wrote:
> So we can read a btree block via readahead or intentional read,
> and we can end up with a memory leak when something happens as
> follows,
> 1) readahead starts to read block A but does not wait for read
>completion,
> 2) btr
pstore to the rescue.
BTRFS error (device dm-1): err add delayed dir index item(index: 3864)
into the deletion tree of the delayed node(root id: 452, inode id:
1299522, errno: -17)
On 24 August 2016 at 23:09, Omar Sandoval wrote:
> On Wed, Aug 24, 2016 at 09:27:16PM +0200, Sverd Johnsen wrote:
>
On Wed, Aug 24, 2016 at 11:34:27AM -0700, Omar Sandoval wrote:
> On Mon, Aug 22, 2016 at 08:43:18PM -0600, Chris Murphy wrote:
> > On Mon, Aug 22, 2016 at 5:06 PM, Darrick J. Wong
> > wrote:
> > > [add Dave and Christoph to cc]
> > >
> > > On Mon, Aug 22, 2016 at 04:14:19PM -0400, Jeff Mahoney wro
Hi,
Using Kernel 4.7.1 ( openSUSE Tumbleweed x86_64 ), btrfsprogs 4.7 I
always get a hard lockup when trying to mount my btrfs root partition.
This may be due to some previous errors which only manifested
themselves now, as it's been converted from an ext4 partition.
Using mount -o ro works. Usi
On Wed, Aug 24, 2016 at 03:42:54PM +0200, David Sterba wrote:
Hi,
this pull request contains part 2 and adds more that arrived in the meantime
(new fixes or updated versions of patches). Assorted fixes. Please pull,
thanks.
Thanks Dave, since this patch got turned into a v2:
Btrfs: handl
On Wed, Aug 24, 2016 at 09:27:16PM +0200, Sverd Johnsen wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=153891
>
> [ 879.935385] [ cut here ]
> [ 879.935400] kernel BUG at fs/btrfs/delayed-inode.c:1579!
> [ 879.935414] invalid opcode: [#1] PREEMPT SMP
> [ 879.
https://bugzilla.kernel.org/show_bug.cgi?id=153891
[ 879.935385] [ cut here ]
[ 879.935400] kernel BUG at fs/btrfs/delayed-inode.c:1579!
[ 879.935414] invalid opcode: [#1] PREEMPT SMP
[ 879.935425] Modules linked in: veth binfmt_misc nft_reject_inet
nf_reject_ipv4
On Wed, Aug 24, 2016 at 11:59 AM, Chris Murphy wrote:
> Plugging in the 'btrfs check' reporte backrefs into btrfs-debug-tree
>
> [chris@f24s ~]$ sudo btrfs-debug-tree -b 16913485824 /dev/mapper/brick1
> btrfs-progs v4.7
> checksum verify failed on 16913485824 found FEAA7A13 wanted 2000
> check
On Mon, Aug 22, 2016 at 08:43:18PM -0600, Chris Murphy wrote:
> On Mon, Aug 22, 2016 at 5:06 PM, Darrick J. Wong
> wrote:
> > [add Dave and Christoph to cc]
> >
> > On Mon, Aug 22, 2016 at 04:14:19PM -0400, Jeff Mahoney wrote:
> >> On 8/21/16 2:59 PM, Tomokhov Alexander wrote:
> >> > Btrfs wiki FA
[chris@f24s ~]$ btrfs --version
btrfs-progs v4.5.3
[chris@f24s ~]$ sudo btrfs check /dev/mapper/brick1
Checking filesystem on /dev/mapper/brick1
UUID: 30f4724a-9a9f-4a5d-a37d-3e53876bf2e1
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 4233021239
On Wed, Aug 24, 2016 at 09:54:16AM +0100, Filipe Manana wrote:
> On Wed, Aug 24, 2016 at 5:13 AM, Qu Wenruo wrote:
> > The following commit introduced the extent map leak:
> > commit 6fb37b756acce6d6e045f79c3764206033f617b4
> > Author: Liu Bo
> > Date: Wed Jun 22 18:31:27 2016 -0700
> >
> >
On Thu, Aug 18, 2016 at 03:30:06PM -0400, Josef Bacik wrote:
> We need to call free_extent_map() on the em we look up.Btrfs: fix em leak in
> find_first_block_group
>
> We need to call free_extent_map() on the em we look up.
Thanks for fixing it.
Reviewed-by: Liu Bo
Thanks,
-liubo
>
> Signe
On 08/24/2016 05:07 AM, Filipe Manana wrote:
On Tue, Aug 23, 2016 at 6:22 PM, Josef Bacik wrote:
Suppose you have the following tree in snap1 on a file system mounted with -o
inode_cache so that inode numbers are recycled
└── [258] a
└── [257] b
and then you remove b, rename a t
Plugging in the 'btrfs check' reporte backrefs into btrfs-debug-tree
[chris@f24s ~]$ sudo btrfs-debug-tree -b 16913485824 /dev/mapper/brick1
btrfs-progs v4.7
checksum verify failed on 16913485824 found FEAA7A13 wanted 2000
checksum verify failed on 16913485824 found FEAA7A13 wanted 2000
by
[chris@f24s ~]$ sudo btrfs dev stats /brick1
[/dev/mapper/brick1].write_io_errs 0
[/dev/mapper/brick1].read_io_errs0
[/dev/mapper/brick1].flush_io_errs 0
[/dev/mapper/brick1].corruption_errs 0
[/dev/mapper/brick1].generation_errs 0
[chris@f24s ~]$ sudo btrfs scrub status /brick1
scrub stat
See attached for 'btrfs check' output.
The last check was about two weeks ago when btrfs-progs 4.7 was
released, and it came up clean. The file system has only been written
to since then with a 4.7.0 kernel, and 4.7.2 kernel for the past ~36
hours.
The workload in those two weeks has only been cu
Suppose you have the following tree in snap1 on a file system mounted with -o
inode_cache so that inode numbers are recycled
└── [258] a
└── [257] b
and then you remove b, rename a to c, and then re-create b in c so you have the
following tree
└── [258] c
└── [257] b
Hi,
this pull request contains part 2 and adds more that arrived in the meantime
(new fixes or updated versions of patches). Assorted fixes. Please pull,
thanks.
The following changes since commit 10838816547a28696ca10e038b3b32f2efe
On Wed, Aug 17, 2016 at 08:42:48AM +0800, Qu Wenruo wrote:
>
>
> At 08/16/2016 10:31 PM, David Sterba wrote:
> > On Mon, Aug 01, 2016 at 02:29:42PM +0800, Qu Wenruo wrote:
> >> Introduce send-dump.[ch] which implements a new btrfs_send_ops to
> >> exam and output all operations inside a send stre
On Fri, Aug 19, 2016 at 05:59:46PM +0800, Wang Xiaoguang wrote:
> The basic idea is simple. Assume a middle tree node A is shared and
> its referenceing fs/file tree root ids are 5, 258 and 260, then we
> only check node A in the tree who has the smallest root id. That means
> in this case, when ch
On Fri, Jul 29, 2016 at 10:57:55AM -0700, Liu Bo wrote:
> This BUG() has been triggered by a fuzz testing image, which contains
> an invalid chunk type, ie. a single stripe chunk has the raid6 type.
>
> Btrfs can handle this gracefully by returning -EIO, so besides using
> btrfs_warn to give us mo
On Tue, Aug 23, 2016 at 05:37:45PM -0700, Liu Bo wrote:
> When btree node (level = 1) has nritems which equals to zero,
> we can end up with panic due to insert_ptr()'s
>
> BUG_ON(slot > nritems);
>
> where slot is 1 and nritems is 0, as copy_for_split() calls
> insert_ptr(.., path->slots[1] + 1,
On Tue, Aug 23, 2016 at 11:23:23PM +0100, Luis Henriques wrote:
> Variable 'gen' in reada_for_search() is not used since commit 58dc4ce43251
> ("btrfs: remove unused parameter from readahead_tree_block"). This patch
> simply removes this variable.
>
> Signed-off-by: Luis Henriques
Reviewed-by:
On Tue, Aug 23, 2016 at 11:23:53PM +0100, Luis Henriques wrote:
> Variable 'blocksize' in reada_walk_down() is not used since commit
> d3e46fea1b1e ("btrfs: sink blocksize parameter to readahead_tree_block").
> This patch simply removes this variable.
>
> Signed-off-by: Luis Henriques
Reviewed-b
On Tue, Aug 23, 2016 at 03:22:58PM -0700, Liu Bo wrote:
> Right now we treat leaf which has zero item as a valid one
> because we could have an empty tree, that is, a root that is
> also a leaf without any item, however, in the same case but
> when the leaf is not a root, we can end up with hitting
On 08/23/2016 06:25 PM, David Sterba wrote:
The filesystem existence on a device is manifested by the signature,
during the mkfs process we write it first and then create other
structures. Such filesystem is not valid and should not be registered
during device scan nor listed among devices from
All patches looks good. nice cleanups.
Reviewed-by: Anand Jain
Thanks.
On 08/23/2016 06:25 PM, David Sterba wrote:
As we're passing a set of flags, the enum type is not appropriate.
Signed-off-by: David Sterba
---
btrfstune.c | 2 +-
cmds-check.c | 2 +-
disk-io.c| 12 ++
On Tue, Aug 23, 2016 at 6:22 PM, Josef Bacik wrote:
> Suppose you have the following tree in snap1 on a file system mounted with -o
> inode_cache so that inode numbers are recycled
>
> └── [258] a
> └── [257] b
>
> and then you remove b, rename a to c, and then re-create b in c so yo
On Wed, Aug 24, 2016 at 5:13 AM, Qu Wenruo wrote:
> The following commit introduced the extent map leak:
> commit 6fb37b756acce6d6e045f79c3764206033f617b4
> Author: Liu Bo
> Date: Wed Jun 22 18:31:27 2016 -0700
>
> Btrfs: check inconsistence between chunk and block group
>
> This leads to s
From: Filipe Manana
Test that if we rename a file, without changing its parent directory,
create a new file that has the old name of the file we renamed, doing an
fsync against the file we renamed works correctly and after a power
failure both files exists.
This is motivated by an issue found in
From: Filipe Manana
Commit 44f714dae50a ("Btrfs: improve performance on fsync against new
inode after rename/unlink"), which landed in 4.8-rc2, introduced a
possibility for a deadlock due to double locking of an inode's log mutex
by the same task, which lockdep reports with:
[23045.433975] =
On Wed, Aug 24, 2016 at 3:36 AM, Qu Wenruo wrote:
>
>
> At 08/04/2016 09:52 AM, Qu Wenruo wrote:
>>
>>
>>
>> At 08/03/2016 05:05 PM, Filipe Manana wrote:
>>>
>>> On Tue, Aug 2, 2016 at 2:20 AM, Qu Wenruo
>>> wrote:
At 08/02/2016 02:00 AM, Filipe Manana wrote:
>
>
>
40 matches
Mail list logo