[PATCH] Btrfs: incremental send, don't rename a directory too soon

$ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt2 $ btrfs receive /mnt2 -f /tmp/1.send $ btrfs receive /mnt2 -f /tmp/2.send ERROR: rename b - a failed. Directory not empty A test case for xfstests follows soon. Reported-by: Ames Cornish a...@cornishes.net Signed-off-by: Filipe Manana fdman

[PATCH v2] Btrfs: incremental send, don't rename a directory too soon

$ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt2 $ btrfs receive /mnt2 -f /tmp/1.send $ btrfs receive /mnt2 -f /tmp/2.send ERROR: rename b - a failed. Directory not empty A test case for xfstests follows soon. Reported-by: Ames Cornish a...@cornishes.net Signed-off-by: Filipe Manana fdman

[PATCH] fstests: btrfs test for incremental send with directory renames

. This issue was fixed by the following linux kernel btrfs patch: Btrfs: incremental send, don't rename a directory too soon Signed-off-by: Filipe Manana fdman...@suse.com --- tests/btrfs/083 | 159 tests/btrfs/083.out | 2 + tests/btrfs/group

[PATCH v2] Btrfs: fix data loss in the fast fsync path

-by: Liu Bo bo.li@oracle.com Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Removed dead assignment of inode-last_trans in btrfs_file_write_iter (and the respective comment) since it's useless now. Added stable to cc because it's a data loss fix. fs/btrfs/file.c | 45

[PATCH v2] Generic test for file fsync after moving files across directories

to be lost (despite fsync returning success to user space). That btrfs bug is fixed by the following linux kernel patch: Btrfs: fix data loss in the fast fsync path Reviewed-by: Lukas Czerner lczer...@redhat.com Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Updated test description

[PATCH 2/2] Btrfs: send, don't leave without decrementing clone root's send_progress

counter if the root is readonly or flagged as dead. Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/send.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index 6ec28f1..571de5a 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c

[PATCH 1/2] Btrfs: send, add missing check for dead clone root

After we locked the root's root item, a concurrent snapshot deletion call might have set the dead flag on it. So check if the dead flag is set and abort if it is, just like we do for the parent root. Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/send.c | 3 ++- 1 file changed, 2

[PATCH] Btrfs: do not ignore errors from btrfs_lookup_xattr in do_setxattr

The return value from btrfs_lookup_xattr() can be a pointer encoding an error, therefore deal with it. This fixes commit 5f5bc6b1e2d5 (Btrfs: make xattr replace operations atomic). Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/xattr.c | 8 ++-- 1 file changed, 6 insertions

[PATCH] fstests: generic test for fsync after removing xattrs

kernel patch: Btrfs: remove deleted xattrs on fsync log replay Signed-off-by: Filipe Manana fdman...@suse.com --- tests/generic/061 | 115 ++ tests/generic/061.out | 10 + tests/generic/group | 1 + 3 files changed, 126 insertions

[PATCH] Btrfs: fix off-by-one logic error in btrfs_realloc_node

- 2'. Fix this and set end_slot to be 'nritems - 1', as it's less confusing since the variable name implies it's inclusive rather then exclusive. Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/ctree.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs

[PATCH] Btrfs: remove deleted xattrs on fsync log replay

. Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/tree-log.c | 123 ++-- 1 file changed, 109 insertions(+), 14 deletions(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 3b8a53f..c0ad094 100644 --- a/fs/btrfs/tree-log.c +++ b/fs

[PATCH v3] Btrfs: fix metadata inconsistencies after directory fsync

. A test case for xfstests follows. Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Speedup search when there's a gap between dentry indexes, and we reached the last slot of a leaf, by using btrfs_next_leaf(). V3: Don't break out of while loop if next_leaf returns 1, there might

[PATCH v2] fstests: generic test for fsync after removing xattrs

kernel patch: Btrfs: remove deleted xattrs on fsync log replay Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Make use of the new function '_require_metadata_journaling' added by Eric. Updated description of the test at the very top of the test file. tests/generic/061 | 121

[PATCH v2] fstests: generic test for directory fsync after adding hard links

that btrfs has the same behaviour as xfs and ext4. The btrfs issue was fixed by the following linux kernel patch: Btrfs: fix metadata inconsistencies after directory fsync Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Make use of the new function '_require_metadata_journaling' added

[PATCH] Generic test for file fsync after moving files across directories

returning success to user space). That btrfs bug is fixed by the following linux kernel patch: Btrfs: fix data loss in the fast fsync path Signed-off-by: Filipe Manana fdman...@suse.com --- tests/generic/067 | 113 ++ tests/generic/067.out

[PATCH] Btrfs: fix data loss in the fast fsync path

aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa * 002 A test case for xfstests will be sent soon. Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/file.c | 63 - 1 file changed, 58 insertions(+), 5 deletions(-) diff --git

[PATCH v4] Btrfs: fix metadata inconsistencies after directory fsync

. Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Speedup search when there's a gap between dentry indexes, and we reached the last slot of a leaf, by using btrfs_next_leaf(). V3: Don't break out of while loop if next_leaf returns 1, there might be other child directory inodes to process

[PATCH v3] fstests: generic test for directory fsync after adding hard links

that btrfs has the same behaviour as xfs and ext4. The btrfs issue was fixed by the following linux kernel patch: Btrfs: fix metadata inconsistencies after directory fsync Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Make use of the new function '_require_metadata_journaling' added

[PATCH v4] fstests: generic test for directory fsync after adding hard links

that btrfs has the same behaviour as xfs and ext4. The btrfs issue was fixed by the following linux kernel patch: Btrfs: fix metadata inconsistencies after directory fsync Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Make use of the new function '_require_metadata_journaling' added

[PATCH] Btrfs: incremental send, don't delay directory renames unnecessarily

of the inode in the send root, which has a delayed rename operation, is not also a descendent of the inode in the parent root. Thanks to Robbie Ko for sending the reproducer example. A test case for xfstests follows soon. Reported-by: Robbie Ko robbi...@synology.com Signed-off-by: Filipe Manana fdman

[PATCH] fstests: test for btrfs send after complex directory hierarchy changes

. This issue was fixed by the following linux kernel btrfs patch: Btrfs: incremental send, don't delay directory renames unnecessarily Signed-off-by: Filipe Manana fdman...@suse.com --- tests/btrfs/085 | 199 tests/btrfs/085.out | 2 + tests

[PATCH v2] Btrfs: incremental send, don't delay directory renames unnecessarily

of the inode in the send root, which has a delayed rename operation, is not also a descendent of the inode in the parent root. Thanks to Robbie Ko for sending the reproducer example. A test case for xfstests follows soon. Reported-by: Robbie Ko robbi...@synology.com Signed-off-by: Filipe Manana fdman

[PATCH RESEND] fstests: test for btrfs send after complex directory hierarchy changes

. This issue was fixed by the following linux kernel btrfs patch: Btrfs: incremental send, don't delay directory renames unnecessarily Signed-off-by: Filipe Manana fdman...@suse.com --- Rebased against latest master branch, which implied changing the test number. No changes otherwise. tests/btrfs

[PATCH v2] fstests: regression test for btrfs file range cloning

range cloning when same inode used as source and destination Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Rebased against latest master, which implied changing the test's number, and added steps to test for the case where different source and destination files are used, just

[PATCH v2] fstests: test for btrfs transaction abortion on device with discard support

read block failed check_tree_block Couldn't read tree root Couldn't open file system (...) Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Added some more comments explaining what's being done and why. Simplified some code (cleanups). tests/btrfs/089 | 125

[PATCH v3] fstests: test for btrfs transaction abortion on device with discard support

SUSE Linux Products GmbH. All Rights Reserved. +# Author: Filipe Manana fdman...@suse.com +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation. +# +# This program

[PATCH] Btrfs: fix race between start dirty bg cache writeout and bg deletion

section in commit) Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/extent-tree.c | 44 +++- 1 file changed, 27 insertions(+), 17 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 5edc7ee..d5f3ef0 100644 --- a/fs/btrfs

[PATCH] Btrfs: fix deadlock when starting writeback of bg caches

] new_sync_write+0x7c/0xa0 [21120.935528] [81153b58] vfs_write+0xb2/0x117 (...) Fixes: 1bbc621ef284 (Btrfs: allow block group cache writeout outside critical section in commit) Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/extent-tree.c | 2 +- 1 file changed, 1

Re: [PATCH] Btrfs: fix race when reusing stale extent buffers that leads to BUG_ON

On 04/23/2015 02:53 PM, Holger Hoffstätte wrote: On Thu, 23 Apr 2015 14:43:40 +0100, Filipe Manana wrote: I don't think a lock followed by unlock without nothing in between (be it a spinlock, mutex, or any other kind of lock) will be seen by the compiler as a nop. Pretty sure I've seen

[PATCH] Btrfs: fix race when reusing stale extent buffers that leads to BUG_ON

Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/extent_io.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 62e8706..46d6e68 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -4768,6 +4768,25

Re: [PATCH] Btrfs: fix race when reusing stale extent buffers that leads to BUG_ON

On 04/23/2015 01:16 PM, Holger Hoffstätte wrote: On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote: There's a race between releasing extent buffers that are flagged as stale and recycling them that makes us it the following BUG_ON at btrfs_release_extent_buffer_page: BUG_ON

Re: [PATCH] Btrfs: fix race when reusing stale extent buffers that leads to BUG_ON

On 04/23/2015 02:22 PM, Holger Hoffstätte wrote: On Thu, 23 Apr 2015 13:34:15 +0100, Filipe Manana wrote: On 04/23/2015 01:16 PM, Holger Hoffstätte wrote: On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote: There's a race between releasing extent buffers that are flagged as stale

[PATCH] Btrfs: fix mutex unlock without prior lock on space cache truncation

section in commit) Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/free-space-cache.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index c1d1e6d..f1ddccf 100644 --- a/fs/btrfs/free-space-cache.c

[PATCH] Btrfs: incremental send, check if orphanized dir inode needs delayed rename

orphanized or not. A test case for fstests follows soon. Thanks to Robbie Ko for providing a reproducer for this problem. Reported-by: Robbie Ko robbi...@synology.com Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/send.c | 56 +--- 1

[PATCH] fstests: test btrfs send after swapping directory names differently

if orphanized dir inode needs delayed rename Signed-off-by: Filipe Manana fdman...@suse.com --- tests/btrfs/090 | 186 tests/btrfs/090.out | 2 + tests/btrfs/group | 1 + 3 files changed, 189 insertions(+) create mode 100755 tests

[PATCH v2] Btrfs: fix data loss after concurrent fsyncs for files in the same subvol

was already committed or we end up waiting for a matching log transaction commit that is ongoing to complete. CC: sta...@vger.kernel.org # 3.18+ Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Add the ordered extents to the transaction even if ctx-log_ret is non-zero, to avoid leaking

[PATCH] Btrfs: don't attach unnecessary extents to transaction on fsync

an asynchronous iput when the ordered extent's reference count drops to 0), preventing the inode from being evictable until the transaction commits. Signed-off-by: Filipe Manana fdman...@suse.com --- This applies on top of my previous patch titled: Btrfs: fix data loss after concurrent fsyncs for files

[PATCH] Btrfs: fix data loss after concurrent fsyncs for files in the same subvol

was already committed or we end up waiting for a matching log transaction commit that is ongoing to complete. CC: sta...@vger.kernel.org # 3.18+ Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/ordered-data.c | 3 ++- fs/btrfs/tree-log.c | 4 2 files changed, 6 insertions(+), 1

[PATCH v2] Btrfs: don't attach unnecessary extents to transaction on fsync

an asynchronous iput when the ordered extent's reference count drops to 0), preventing the inode from being evictable until the transaction commits. Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Made the patch independent of my previous one, since that other one was not correct. fs/btrfs/ordered

[PATCH] fstests: test for btrfs transaction abortion on device with discard support

read block failed check_tree_block Couldn't read tree root Couldn't open file system (...) Signed-off-by: Filipe Manana fdman...@suse.com --- tests/btrfs/089 | 129 tests/btrfs/089.out | 2 + tests/btrfs/group | 1 + 3 files

[PATCH v2] Btrfs: fix range cloning when same inode used as source and destination

soon. Signed-off-by: Filipe Manana fdman...@suse.com --- V2: Fixed a warning about potentially uninitialized variable. David got this warning on a 4.5.1 gcc, but I didn't on a 4.9.2 gcc however. fs/btrfs/ioctl.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs

[PATCH 2/2 RESEND] Btrfs: incremental send, check if orphanized dir inode needs delayed rename

orphanized or not. A test case for fstests follows soon. Thanks to Robbie Ko for providing a reproducer for this problem. Reported-by: Robbie Ko robbi...@synology.com Signed-off-by: Filipe Manana fdman...@suse.com --- fs/btrfs/send.c | 56 +--- 1

[GIT PULL] Send fixes for 4.2

for you to fetch changes up to 8b191a684968e24b34c9894024b37532c68e6ae8: Btrfs: incremental send, check if orphanized dir inode needs delayed rename (2015-06-03 03:10:40 +0100) Filipe Manana (2): Btrfs: incremental send, don't

[PATCH 1/2 RESEND] Btrfs: incremental send, don't delay directory renames unnecessarily

of the inode in the send root, which has a delayed rename operation, is not also a descendent of the inode in the parent root. Thanks to Robbie Ko for sending the reproducer example. A test case for xfstests follows soon. Reported-by: Robbie Ko robbi...@synology.com Signed-off-by: Filipe Manana fdman

Re: [PATCH] Btrfs: fix hang during inode eviction due to concurrent readahead

On Wed, Jun 10, 2015 at 12:05 PM, Liu Bo bo.li@oracle.com wrote: On Wed, Jun 10, 2015 at 11:44:17AM +0100, Filipe Manana wrote: On Wed, Jun 10, 2015 at 11:41 AM, Liu Bo bo.li@oracle.com wrote: On Tue, May 26, 2015 at 12:55:42AM +0100, fdman...@kernel.org wrote: From: Filipe Manana

Re: [PATCH] Btrfs: fix hang during inode eviction due to concurrent readahead

On Wed, Jun 10, 2015 at 11:41 AM, Liu Bo bo.li@oracle.com wrote: On Tue, May 26, 2015 at 12:55:42AM +0100, fdman...@kernel.org wrote: From: Filipe Manana fdman...@suse.com Zygo Blaxell and other users have reported occasional hangs while an inode is being evicted, leading to traces like

Re: [PATCH] Btrfs: fix hang during inode eviction due to concurrent readahead

On Wed, Jun 10, 2015 at 12:27 PM, Liu Bo bo.li@oracle.com wrote: On Wed, Jun 10, 2015 at 12:12:11PM +0100, Filipe Manana wrote: On Wed, Jun 10, 2015 at 12:05 PM, Liu Bo bo.li@oracle.com wrote: On Wed, Jun 10, 2015 at 11:44:17AM +0100, Filipe Manana wrote: On Wed, Jun 10, 2015 at 11

Re: [PATCH] Btrfs: fix fsync after truncate when no_holes feature is enabled

On Thu, Jun 25, 2015 at 3:20 PM, Liu Bo bo.li@oracle.com wrote: On Thu, Jun 25, 2015 at 04:17:46AM +0100, fdman...@kernel.org wrote: From: Filipe Manana fdman...@suse.com When we have the no_holes feature enabled, if a we truncate a file to a smaller size, truncate it again but to a size

Re: [PATCH] Btrfs: fix fsync after truncate when no_holes feature is enabled

On Fri, Jun 26, 2015 at 4:21 AM, Liu Bo bo.li@oracle.com wrote: On Thu, Jun 25, 2015 at 03:23:59PM +0100, Filipe Manana wrote: On Thu, Jun 25, 2015 at 3:20 PM, Liu Bo bo.li@oracle.com wrote: On Thu, Jun 25, 2015 at 04:17:46AM +0100, fdman...@kernel.org wrote: From: Filipe Manana

Re: [PATCH] fstests: generic test for fsync after adding xattr to a file

On Thu, Jun 18, 2015 at 4:48 AM, Eryu Guan eg...@redhat.com wrote: On Wed, Jun 17, 2015 at 12:52:47PM +0100, fdman...@kernel.org wrote: From: Filipe Manana fdman...@suse.com This test is motivated by an issue found in btrfs. It tests that after syncing the filesystem, adding a xattr

Re: [PATCH] Btrfs-progs: add feature to get mininum size for resizing a fs/device

On Mon, Jun 29, 2015 at 4:42 PM, David Sterba dste...@suse.cz wrote: On Wed, Jun 17, 2015 at 12:44:55PM +0100, fdman...@kernel.org wrote: Currently there is not way for a user to know what is the minimum size a device of a btrfs filesystem can be resized to. Sometimes the value of total

Re: [PATCH] Btrfs-progs: add feature to get mininum size for resizing a fs/device

On Tue, Jun 30, 2015 at 4:14 PM, David Sterba dste...@suse.cz wrote: On Mon, Jun 29, 2015 at 05:15:12PM +0100, Filipe Manana wrote: On Mon, Jun 29, 2015 at 4:42 PM, David Sterba dste...@suse.cz wrote: On Wed, Jun 17, 2015 at 12:44:55PM +0100, fdman...@kernel.org wrote: The test fails after I

Re: [PATCH] fstests: generic test for fsync of file with multiple links

On Thu, Aug 6, 2015 at 12:46 PM, Eryu Guan eg...@redhat.com wrote: On Thu, Aug 06, 2015 at 05:11:30AM +0100, fdman...@kernel.org wrote: From: Filipe Manana fdman...@suse.com Test that when we have a file with multiple hard links belonging to different parent directories, if we remove one

Re: [PATCH] Btrfs: fix order by which delayed references are run

: From: Filipe Manana fdman...@suse.com When we have an extent that got N references removed and N new references added in the same transaction, we must run the insertion of the references first because otherwise the last removed reference will remove the extent item from the extent tree, resulting

Re: [PATCH] fstests: btrfs test to exercise shared extent reference accounting

On Fri, Jul 24, 2015 at 10:40 PM, Omar Sandoval osan...@fb.com wrote: On Thu, Jul 09, 2015 at 03:51:13PM +0100, fdman...@kernel.org wrote: From: Filipe Manana fdman...@suse.com Regression test for adding and dropping an equal number of references for file extents. Verify that if we drop N

Re: btrfs double send

On Sat, Oct 24, 2015 at 6:36 PM, wrote: > Hello, > > I would like to do backups based on btrfs send/receive. > > So I though I would do a transfer over portable HDD and then incremental > sends (using -p) over network. > > Initial : > > btrfs send "all" (primary HDD) → btrfs

Re: Linux 4.2.4 kernel panic while balancing

On Fri, Oct 23, 2015 at 4:41 PM, Malte Schröder wrote: > Hi, > kernel 4.2 crashes more or less reliably when running btrfs balance. > The filesystem in question is running in RAID1 mode. This happens quite > reliably. > Btrfs filesystem check doesn't show any problems. > > Dmesg

Re: [PATCH v4] btrfs: qgroup: Don't copy extent buffer to do qgroup rescan

roup_rescan_worker+0x28d is btrfs_disk_key_to_cpu(), > called in reading key from the copied extent_buffer. > > This patch will use btrfs_clone_extent_buffer() to a better copy of > extent buffer to deal such case. > > Reported-by: Stephane Lesimple <stephane_bt...@lesim

Re: [PATCH] Btrfs: fix regression when running delayed references

On Fri, Oct 23, 2015 at 12:03 AM, Filipe Manana <fdman...@kernel.org> wrote: > On Thu, Oct 22, 2015 at 11:38 PM, Stéphane Lesimple > <stephane_bt...@lesimple.fr> wrote: >>>>> [ ... thread cleanup ... ] >>>>> >>>>> Don't h

Re: btrfs double send

end issuing invalid/outdated paths to the send stream. Nothing to do with incorrect uuids in the send stream. > > Please let me know if there is anything you would like me to try. I am > running 4.2 with the 4.3 for-linus tree applied and the 4.2.x patches with > btrfs fixes removed. On top o

Re: BTRFS BUG at insert_inline_extent_backref+0xe3/0xf0 while rebalancing

On Thu, Oct 22, 2015 at 6:32 AM, Erkki Seppala wrote: > Hello, > > Recently I added daily rebalancing to my cron.d (after finding myself in > the no-space-situation), and not long after that, I found my PC had > crashed over night. Having no sign in the logs anywhere (not

Re: Lockup in BTRFS_IOC_CLONE/Kernel 4.2.0-rc5

rfs experience. > > Thank you for reporting this. > > Could you do 'echo w > /proc/sysrq-trigger' to gather the whole hang call > stack? > > Here's a quick patch that may address your problem, can you give it a shot > after > getting sysrq-w output? Hi Liu, Can you please se

Re: [PATCH v3 RESENT 2/2] btrfs: qgroup: Don't copy extent buffer to do qgroup rescan

On Thu, Oct 22, 2015 at 1:42 AM, Qu Wenruo wrote: > 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

Re: [PATCH] Btrfs: fix regression when running delayed references

On Thu, Oct 22, 2015 at 11:38 PM, Stéphane Lesimple wrote: [ ... thread cleanup ... ] Don't hesitate to ask if you need me to debug or even ftrace something. >>> >>> >>> Thanks Stéphane. I haven't seen that crash yet (still running tests >>> for 2

Re: [PATCH] Btrfs: fix regression when running delayed references

On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > wrote on 2015/10/22 09:47 +0100: >> >> From: Filipe Manana <fdman...@suse.com> >> >> In the kernel 4.2 merge window we had a refactoring/rework of the delayed >>

Re: [PATCH] Btrfs: fix regression when running delayed references

On Thu, Oct 22, 2015 at 10:43 AM, Filipe Manana <fdman...@kernel.org> wrote: > On Thu, Oct 22, 2015 at 10:32 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: >> >> >> wrote on 2015/10/22 09:47 +0100: >>> >>> From: Filipe Manana <fdman...@s

Re: [PATCH] Btrfs: fix regression when running delayed references

On Thu, Oct 22, 2015 at 11:05 AM, Koen Kooi <k...@dominion.thruhere.net> wrote: > Op 22-10-15 om 10:47 schreef fdman...@kernel.org: >> From: Filipe Manana <fdman...@suse.com> >> >> In the kernel 4.2 merge window we had a refactoring/rework of the delayed >

Re: [PATCH 1/2 v2] Btrfs: fix regression when running delayed references

On Mon, Oct 26, 2015 at 9:22 AM, Liu Bo <bo.li@oracle.com> wrote: > On 10/25/2015 06:04 PM, fdman...@kernel.org wrote: >> >> From: Filipe Manana <fdman...@suse.com> >> >> In the kernel 4.2 merge window we had a refactoring/rework of the delayed >&

Re: [PATCH v5] btrfs: qgroup: Don't copy extent buffer to do qgroup rescan

roup_rescan_worker+0x28d is btrfs_disk_key_to_cpu(), > called in reading key from the copied extent_buffer. > > This patch will use btrfs_clone_extent_buffer() to a better copy of > extent buffer to deal such case. > > Reported-by: Stephane Lesimple <stephane_bt...@lesim

Re: [PATCH 1/3] btrfs: Cleanup no_quota parameter

On Mon, Oct 26, 2015 at 8:25 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > Filipe Manana wrote on 2015/10/26 08:14 +: >> >> On Mon, Oct 26, 2015 at 6:11 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> No_quota p

Re: [PATCH 1/3] btrfs: Cleanup no_quota parameter

On Mon, Oct 26, 2015 at 6:11 AM, Qu Wenruo wrote: > 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

Re: [PATCH v3 06/21] btrfs: delayed_ref: Add new function to record reserved space into delayed ref

On Tue, Oct 27, 2015 at 4:13 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > Filipe Manana wrote on 2015/10/25 14:39 +: >> >> On Tue, Oct 13, 2015 at 3:20 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> Add new funct

ENOSPC regression in integration-4.4 branch

Hi Josef, Not sure if you are aware or got my report on IRC, but one of the allocator fixes/improvements (Chris' integration-4.4 branch) is causing new ENOSPC failures:

Re: btrfs-balance causes system-freeze on full disk

On Tue, Oct 27, 2015 at 4:05 PM, Jakob Schürz wrote: > Found a new habit... > > I have a lot Snapshots on my drive. (Take every 10 Min a new one, every > houry one, every day one, every system-update, every plugin after > external HD...) > > If there are to much

Re: btrfs double send

Ed > On Sunday, October 25, 2015 9:42:54 AM EDT, Filipe Manana wrote: >> >> On Sun, Oct 25, 2015 at 1:38 PM, Ed Tomlinson <e...@aei.ca> wrote: >>> >>> Filipe, >>> >>> Its still not perfect. Here I can do sequential sends a

Re: [PATCH v3 06/21] btrfs: delayed_ref: Add new function to record reserved space into delayed ref

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

Re: [PATCH] btrfs: Remove code for no-cow in scrub/replace

On Fri, Oct 23, 2015 at 4:11 PM, Jeff Mahoney wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/23/15 4:03 AM, Zhao Lei wrote: >> Since we set source bg to readonly in scrub/replace, we don't need >> to consider confliction of no-cow write in scrub/replace

Re: [PATCH] Btrfs: fix regression when running delayed references

On Thu, Oct 22, 2015 at 3:58 PM, Stéphane Lesimple <stephane_bt...@lesimple.fr> wrote: > Le 2015-10-22 11:47, Filipe Manana a écrit : >> >> On Thu, Oct 22, 2015 at 10:43 AM, Filipe Manana <fdman...@kernel.org> >> wrote: >>> >>> On Thu, Oct 22, 2

Re: [PATCH] btrfs: Continue replace when set_block_ro failed

On Fri, Nov 13, 2015 at 11:38 AM, Zhao Lei wrote: > xfstests/011 failed in node with small_size filesystem. > Can be reproduced by following script: > DEV_LIST="/dev/vdd /dev/vde" > DEV_REPLACE="/dev/vdf" > > do_test() > { > local mkfs_opt="$1" > local

Re: 4.2-rc6: kernel BUG at fs/btrfs/inode.c:3230

On Thu, Aug 13, 2015 at 9:38 AM, Stefan Priebe - Profihost AG wrote: > > Seen today: > > [150110.712196] [ cut here ] > [150110.776995] kernel BUG at fs/btrfs/inode.c:3230! > [150110.841067] invalid opcode: [#1] SMP > [150110.904472] Modules

Re: [PATCH] btrfs: Continue replace when set_block_ro failed

On Mon, Nov 16, 2015 at 10:07 AM, Zhao Lei <zhao...@cn.fujitsu.com> wrote: > Hi, Filipe Manana > > Thanks for review. > >> -Original Message- >> From: Filipe Manana [mailto:fdman...@gmail.com] >> Sent: Friday, November 13, 2015 8:02 PM >> To: Zhao

Re: [PATCH] btrfs: Continue replace when set_block_ro failed

On Mon, Nov 16, 2015 at 10:44 AM, Zhao Lei <zhao...@cn.fujitsu.com> wrote: > Hi, Filipe Manana > >> -Original Message- >> From: linux-btrfs-ow...@vger.kernel.org >> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Filipe Manana >> Sent: Monday, N

Re: strange "No space left on device"

On Sat, Nov 7, 2015 at 11:22 PM, Christoph Anton Mitterer wrote: > Hey. > > I just repeatedly did the following twice on a ~8GB USB stick, under > Debian sid (ergo kernel 4.2.0-1-amd64, btrfsprogs 4.2.2-1). > > First, created some GPT on the stick: > Number Start (sector)

Re: [PATCH v3] btrfs: qgroup: exit the rescan worker during umount

about what changes between versions should go after the "---" (triple dash) below. You should also have mentioned what changed between v2 and v1 as well (see https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Repeated_submissions). > > Signed-off-by: Justin Maggard <jmagg...@n

Re: [PATCH v2] btrfs: test unmount during quota rescan

(btrfs: qgroup: exit the rescan worker during umount). > > Signed-off-by: Justin Maggard <jmagg...@netgear.com> Reviewed-by: Filipe Manana <fdman...@suse.com> > --- Btw, for future patches/versions, here after the --- you should mention what changed between versions of the p

Re: [PATCH] btrfs: qgroup: fix quota disable during rescan

through qgroup_rescan_leaf(). Once you add that, you can add as well: Reviewed-by: Filipe Manana <fdman...@suse.com> Thanks for this and the test. > --- > fs/btrfs/qgroup.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/btrfs/qgroup.c b/fs/

Re: [PATCH] btrfs: test quota disable during quota rescan

h (btrfs: qgroup: fix quota disable during rescan). > > Signed-off-by: Justin Maggard <jmagg...@netgear.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Looks good and it triggers the bug without the btrfs kernel fix. A side note, and if you would like you could do as a sepa

Re: btrfs_sync_file alignment trap on arm (kernel 4.2.5)

On Fri, Nov 6, 2015 at 10:16 PM, Cody P Schafer wrote: > On Wed, Nov 4, 2015 at 5:55 PM, Cody P Schafer wrote: >> Ideas as to what could cause this would be appreciated. >> >> This consistently is triggered shortly after boot (I presume due to >> conmand calling

Re: [PATCH] btrfs: test unmount during quota rescan

On Wed, Oct 7, 2015 at 4:08 PM, Justin Maggard wrote: > This test case tests if we are able to unmount a filesystem while > a quota rescan is running. Up to now (4.3-rc4) this would result > in a kernel NULL pointer dereference. Please mention here the title of the patch

Re: [PATCH v2] btrfs: qgroup: exit the rescan worker during umount

On Thu, Sep 3, 2015 at 2:05 AM, Justin Maggard wrote: > v2: Fix stupid error while making formatting changes... > > I was hitting a consistent NULL pointer dereference during shutdown that > showed the trace running through end_workqueue_bio(). I traced it back to > the

Re: [RFC PATCH] btrfs/ioctl.c: Prefer inode with lowest offset as source for clone

On Tue, Oct 20, 2015 at 2:29 PM, Timofey Titovets wrote: > For performance reason, leave data at the start of disk, is preferable > while deduping Have you made any performance tests to verify that? > It's might sense for the reasons: > 1. Spinning rust - start of the disk

Re: [PATCH v2 00/23] Rework btrfs qgroup reserved space framework

On Fri, Oct 9, 2015 at 6:45 AM, Qu Wenruo wrote: > > > Josef Bacik wrote on 2015/10/08 21:36 -0700: >> >> On 10/08/2015 07:11 PM, Qu Wenruo wrote: >>> >>> In previous rework of qgroup, we succeeded in fixing qgroup accounting >>> part, making the rfer/excl numbers

Re: [PATCH] btrfs: fix resending received snapshot with parent

On Tue, Oct 13, 2015 at 1:31 AM, Ed Tomlinson <e...@aei.ca> wrote: > On Friday, October 9, 2015 4:24:10 PM EDT, Filipe Manana wrote: >> >> On Wed, Sep 30, 2015 at 8:23 PM, Robin Ruede <r.ru...@gmail.com> wrote: >>> >>> This fixes a regression

Re: [PATCH] btrfs: fix use after free iterating extrefs

c...@fb.com> > cc: sta...@vger.kernel.org # v3.7+ > cc: Mark Fasheh <mfas...@suse.de> Reviewed-by: Filipe Manana <fdman...@suse.com> Looks good to me. I failed to notice that problem at commit [1] [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=

Re: [GIT PULL] Btrfs bug fixes

On Tue, Sep 15, 2015 at 12:49 PM, Holger Hoffstätte wrote: > Hello Filipe, > > your mail comes just in time as I was typing a mail about this patch: > > On 09/15/15 04:22, fdman...@kernel.org wrote: >> Btrfs: remove unnecessary locking of cleaner_mutex to

Re: [PATCH] Btrfs: fix read corruption of compressed and shared extents

On Mon, Sep 14, 2015 at 10:08 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > Hi Filepe, > > > wrote on 2015/09/14 09:29 +0100: >> >> From: Filipe Manana <fdman...@suse.com> >> >> If a file has a range pointing to a compressed extent, foll

Re: [PATCH] fstests: test for btrfs incremental send after replacing a file

On Tue, Sep 29, 2015 at 4:54 AM, Eryu Guan <eg...@redhat.com> wrote: > On Sat, Sep 26, 2015 at 12:40:13PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> Test that an incremental send works after a file from the parent snap

Re: Incremental btrfs send/receive fails if file is unlinked and cloned afterwards

On Fri, Sep 25, 2015 at 1:20 PM, Martin Raiber wrote: > Hi, > > the commit "Btrfs: incremental send, check if orphanized dir inode needs > delayed rename" causes incremental send/receive to fail if a file is > unlinked and then reflinked to the same location from the parent >

Re: Btrfs duperemove corrupt data while dedup

On Tue, Sep 29, 2015 at 1:38 PM, Timofey Titovets wrote: > FYI: > Looks like patch: > Btrfs: fix read corruption of compressed and shared extents Try the second part (patch on top of that one) that fixes an additional corner case that I missed earlier:

Re: [PATCH v2] fstests: generic: Check if a bull fallocate will change extent number

On Tue, Sep 29, 2015 at 11:13 AM, Qu Wenruo wrote: > > > 在 2015年09月29日 18:00, Hugo Mills 写道: >> >> On Tue, Sep 29, 2015 at 05:34:24PM +0800, Qu Wenruo wrote: >>> >>> Normally, a bull fallocate call on a fully written and synced file >>> should not add an extent. >> >> >>

<    1   2   3   4   5   6   7   8   >