Re: [PATCH] btrfs-progs: check: skip shared node or leaf check for low_memory mode

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

[PATCH 1/3] btrfs-progs: check: remove unused found_key variable in walk_down_tree()

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

[PATCH 2/3] btrfs-progs: check: make low memory mode support partially dropped snapshots

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

[PATCH 3/3] btrfs-progs: tests: add 021-partially-dropped-snapshot-case

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

WARNING: CPU: 7 PID: 23122 at /home/kernel/COD/linux/lib/list_debug.c:59 btrfs_clear_bit_hook+0x2b9/0x350 [btrfs]

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

Re: btrfs partition fails to mount - kernel BUG at ../fs/btrfs/extent-tree.c:1872

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 >

Re: [PATCH] Btrfs: fix memory leak in reading btree blocks

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)

Re: kernel BUG at fs/btrfs/delayed-inode.c:1579!

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,

Re: Will Btrfs have an official command to "uncow" existing files?

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

btrfs partition fails to mount - kernel BUG at ../fs/btrfs/extent-tree.c:1872

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.

Re: [PULL] Btrfs fixes, part 3

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:

Re: kernel BUG at fs/btrfs/delayed-inode.c:1579!

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 > [

kernel BUG at fs/btrfs/delayed-inode.c:1579!

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

Re: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

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

Re: Will Btrfs have an official command to "uncow" existing files?

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

Re: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[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

Re: [PATCH] btrfs: Fix extent map leak in find_first_block_group

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 > >

Re: [PATCH] Btrfs: fix em leak in find_first_block_group

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

Re: [PATCH] Btrfs: handle pending renames with recycled inodes properly

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

Re: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

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

Re: btrfs-progs 4.7, check reports many "incorrect local backref count" messages

[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

btrfs-progs 4.7, check reports many "incorrect local backref count" messages

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

[PATCH][v2] Btrfs: kill invalid ASSERT() in process_all_refs()

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

[PULL] Btrfs fixes, part 3

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

Re: [PATCH 1/3] btrfs-progs: Introduce new send-dump object

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

Re: [PATCH] btrfs-progs: check: skip shared node or leaf check for low_memory mode

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

Re: [PATCH v4] Btrfs: remove BUG() in raid56

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

Re: [PATCH v2] Btrfs: check btree node's nritems

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] +

Re: [PATCH 1/2] btrfs: Fix warning "variable ‘gen’ set but not used"

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

Re: [PATCH] btrfs: Fix warning "variable ‘blocksize’ set but not used"

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

Re: [PATCH v2] Btrfs: detect corruption when non-root leaf has zero item

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

Re: [PATCH 05/13] btrfs-progs: two staged filesystem creation

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

Re: [PATCH 01/13] btrfs-progs: pass OPEN_CTREE flags as unsigned

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 +-

Re: [PATCH] Btrfs: handle pending renames with recycled inodes properly

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: [PATCH] btrfs: Fix extent map leak in find_first_block_group

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

[PATCH] fstests: generic test for fsync after file rename

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

[PATCH] Btrfs: fix lockdep warning on deadlock against an inode's log mutex

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:

Re: Btrfs send to send out metadata and data separately

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