Re: [PATCH][v2] btrfs: run delayed items before dropping the snapshot

y making the delayed > items > per-root, and then simply drop any delayed items for roots that we are going > to > delete. But for now just a quick and easy solution is the safest. > > Cc: sta...@vger.kernel.org > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana Looks good now. Tha

Re: [PATCH 2/2] btrfs: run delayed items before dropping the snapshot

On Fri, Nov 30, 2018 at 5:12 PM Filipe Manana wrote: > > On Fri, Nov 30, 2018 at 4:53 PM Josef Bacik wrote: > > > > From: Josef Bacik > > > > With my delayed refs patches in place we started seeing a large amount > > of aborts in __btrfs_free_extent >

Re: [PATCH 1/2] btrfs: catch cow on deleting snapshots

ease use btrfs_warn(), it makes sure we use a consistent message style, identifies the fs, etc. Also, "thats" should be "that is" or "that's". With that fixed, Reviewed-by: Filipe Manana > + > if (trans->transaction != fs_info->running_transaction)

Re: [PATCH 2/2] btrfs: run delayed items before dropping the snapshot

y making the delayed > items > per-root, and then simply drop any delayed items for roots that we are going > to > delete. But for now just a quick and easy solution is the safest. > > Cc: sta...@vger.kernel.org > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana Great catch

Re: [PATCH v2 1/3] btrfs: scrub: maintain the unlock order in scrub thread

On Thu, Nov 29, 2018 at 9:27 AM Anand Jain wrote: > > The device_list_mutex and scrub_lock creates a nested locks in > btrfs_scrub_dev(). > > During lock the order is device_list_mutex and then scrub_lock, and during > unlock, the order is device_list_mutex and then scrub_lock. > Fix this to the

Re: [PATCH] btrfs: skip file_extent generation check for free_space_inode in run_delalloc_nocow

write the inode to the disk. > > Fixes: 78d4295b1eee ("btrfs: lift some btrfs_cross_ref_exist checks in nocow > path") > Signed-off-by: Lu Fengqi The code changes look good to me. Reviewed-by: Filipe Manana Thanks. > --- > fs/btrfs/inode.c | 3 ++- > 1 file cha

Re: [PATCH 2/3] btrfs: wakeup cleaner thread when adding delayed iput

On Wed, Nov 28, 2018 at 7:09 PM David Sterba wrote: > > On Tue, Nov 27, 2018 at 03:08:08PM -0500, Josef Bacik wrote: > > On Tue, Nov 27, 2018 at 07:59:42PM +, Chris Mason wrote: > > > On 27 Nov 2018, at 14:54, Josef Bacik wrote: > > > > > > > On Tue, Nov 27, 2018 at 10:26:15AM +0200, Nikolay

Re: [PATCH v4] Btrfs: fix deadlock with memory reclaim during scrub

On Wed, Nov 28, 2018 at 2:22 PM David Sterba wrote: > > On Mon, Nov 26, 2018 at 08:10:30PM +, Filipe Manana wrote: > > On Mon, Nov 26, 2018 at 6:17 PM David Sterba wrote: > > > > > > On Fri, Nov 23, 2018 at 06:25:40PM +, fdman...@kernel.org wrot

Re: [RFC PATCH] btrfs: drop file privileges in btrfs_clone_files

On Wed, Nov 28, 2018 at 9:26 AM Lu Fengqi wrote: > > On Wed, Nov 28, 2018 at 09:48:07AM +0200, Nikolay Borisov wrote: > > > > > >On 28.11.18 г. 9:46 ч., Christoph Hellwig wrote: > >> On Wed, Nov 28, 2018 at 09:44:59AM +0200, Nikolay Borisov wrote: > >>> > >>> > >>> On 28.11.18 г. 5:07 ч., Lu

Re: [PATCH] btrfs: only run delayed refs if we're committing

On Tue, Nov 27, 2018 at 7:22 PM Josef Bacik wrote: > > On Fri, Nov 23, 2018 at 04:59:32PM +, Filipe Manana wrote: > > On Thu, Nov 22, 2018 at 12:35 AM Josef Bacik wrote: > > > > > > I noticed in a giant dbench run that we spent a lot of time on lock > > &g

Re: [PATCH v4] Btrfs: fix deadlock with memory reclaim during scrub

On Mon, Nov 26, 2018 at 6:17 PM David Sterba wrote: > > On Fri, Nov 23, 2018 at 06:25:40PM +, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > When a transaction commit starts, it attempts to pause scrub and it blocks > > until the scrub is pa

Re: [PATCH] Btrfs: bring back key search optimization to btrfs_search_old_slot()

On Fri, Nov 16, 2018 at 11:09 AM wrote: > > From: Filipe Manana > > Commit d7396f07358a ("Btrfs: optimize key searches in btrfs_search_slot"), > dated from August 2013, introduced an optimization to search for keys in a > node/leaf to both btrfs_search_slot

Re: [PATCH] btrfs: only run delayed refs if we're committing

On Thu, Nov 22, 2018 at 12:35 AM Josef Bacik wrote: > > I noticed in a giant dbench run that we spent a lot of time on lock > contention while running transaction commit. This is because dbench > results in a lot of fsync()'s that do a btrfs_transaction_commit(), and > they all run the delayed

Re: [PATCH v2] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation

On Mon, Nov 19, 2018 at 2:48 PM Qu Wenruo wrote: > > > > On 2018/11/19 下午10:15, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > If the quota enable and snapshot creation ioctls are called concurrently > > we can get into a deadlock where th

Re: [PATCH] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation

On Mon, Nov 19, 2018 at 11:52 AM Filipe Manana wrote: > > On Mon, Nov 19, 2018 at 11:35 AM Qu Wenruo wrote: > > > > > > > > On 2018/11/19 下午7:13, Filipe Manana wrote: > > > On Mon, Nov 19, 2018 at 11:09 AM Qu Wenruo wrote: > > >> > > &

Re: [PATCH] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation

On Mon, Nov 19, 2018 at 11:35 AM Qu Wenruo wrote: > > > > On 2018/11/19 下午7:13, Filipe Manana wrote: > > On Mon, Nov 19, 2018 at 11:09 AM Qu Wenruo wrote: > >> > >> > >> > >> On 2018/11/19 下午5:48, fdman...@kernel.org wrote: > >>>

Re: [PATCH] Btrfs: fix deadlock when enabling quotas due to concurrent snapshot creation

On Mon, Nov 19, 2018 at 11:09 AM Qu Wenruo wrote: > > > > On 2018/11/19 下午5:48, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > If the quota enable and snapshot creation ioctls are called concurrently > > we can get into a deadlock where th

Re: [PATCH] btrfs: introduce feature to forget a btrfs device

On Wed, Nov 14, 2018 at 11:15 AM Filipe Manana wrote: > > On Wed, Nov 14, 2018 at 9:14 AM Anand Jain wrote: > > > > Support for a new command 'btrfs dev forget [dev]' is proposed here > > to undo the effects of 'btrfs dev scan [dev]'. For this purpose > > this

Re: [PATCH] btrfs: introduce feature to forget a btrfs device

On Wed, Nov 14, 2018 at 9:14 AM Anand Jain wrote: > > Support for a new command 'btrfs dev forget [dev]' is proposed here > to undo the effects of 'btrfs dev scan [dev]'. For this purpose > this patch proposes to use ioctl #5 as it was empty. > IOW(BTRFS_IOCTL_MAGIC, 5, ..) > This patch

Re: [PATCH v2 0/6] btrfs: qgroup: Delay subtree scan to reduce overhead

On Tue, Nov 13, 2018 at 5:08 PM David Sterba wrote: > > On Mon, Nov 12, 2018 at 10:33:33PM +0100, David Sterba wrote: > > On Thu, Nov 08, 2018 at 01:49:12PM +0800, Qu Wenruo wrote: > > > This patchset can be fetched from github: > > >

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

On Tue, Nov 13, 2018 at 2:31 PM David Sterba wrote: > > On Thu, Nov 08, 2018 at 02:48:29PM +, Filipe Manana wrote: > > On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana wrote: > > > > > > On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote: > > > > > >

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

On Fri, Nov 9, 2018 at 12:27 AM Qu Wenruo wrote: > > > > On 2018/11/8 下午10:48, Filipe Manana wrote: > > On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana wrote: > >> > >> On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote: > >>> > >>>

Re: [PATCH] Btrfs: incremental send, fix infinite loop when apply children dir moves

ath loop with 267, > > and then we add 259, 265 to the stack, but we don't remove from > > pending_dir_moves rb_tree. > > > > 7. In round 15, we processing 266, we delayed the rename because 266 > > has a path loop with 270, > > So we look for parent_ino equal to 27

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

On Thu, Nov 8, 2018 at 2:37 PM Filipe Manana wrote: > > On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote: > > > > > > > > On 2018/11/8 下午9:17, fdman...@kernel.org wrote: > > > From: Filipe Manana > > > > > > When creating a block group we d

Re: [PATCH] Btrfs: do not set log for full commit when creating non-data block groups

On Thu, Nov 8, 2018 at 2:35 PM Qu Wenruo wrote: > > > > On 2018/11/8 下午9:17, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > When creating a block group we don't need to set the log for full commit > > if the new block group is not used f

Re: [PATCH v4] Btrfs: fix deadlock on tree root leaf when finding free extent

On Mon, Nov 5, 2018 at 4:34 PM David Sterba wrote: > > On Mon, Nov 05, 2018 at 04:30:35PM +, Filipe Manana wrote: > > On Mon, Nov 5, 2018 at 4:29 PM David Sterba wrote: > > > > > > On Wed, Oct 24, 2018 at 01:48:40PM +0100, Filipe Manana wrote: > > > &g

Re: [PATCH v4] Btrfs: fix deadlock on tree root leaf when finding free extent

On Mon, Nov 5, 2018 at 4:29 PM David Sterba wrote: > > On Wed, Oct 24, 2018 at 01:48:40PM +0100, Filipe Manana wrote: > > > Ah ok makes sense. Well in that case lets just make > > > btrfs_read_locked_inode() > > > take a path, and allocate it in bt

Re: [PATCH] Btrfs: incremental send, fix infinite loop when apply children dir moves

On Mon, Nov 5, 2018 at 4:10 AM robbieko wrote: > > Filipe Manana 於 2018-10-30 19:36 寫到: > > On Tue, Oct 30, 2018 at 7:00 AM robbieko wrote: > >> > >> From: Robbie Ko > >> > >> In apply_children_dir_moves, we first create an empty list (stack),

Re: [PATCH] Btrfs: fix cur_offset in the error case for nocow

t a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index 181c58b..b62299b 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -1532,10 +1532,10 @@ static noinline int run_delalloc_nocow(struct inode > *inode, > > if (cur_offset <= end && cow_start == (u64)-1) { >

Re: [PATCH] Btrfs: incremental send, fix infinite loop when apply children dir moves

On Tue, Oct 30, 2018 at 7:00 AM robbieko wrote: > > From: Robbie Ko > > In apply_children_dir_moves, we first create an empty list (stack), > then we get an entry from pending_dir_moves and add it to the stack, > but we didn't delete the entry from rb_tree. > > So, in add_pending_dir_move, we

Re: [PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

trfs check won't report qgroup error. > > To fix the false alerts, just skip any manual qgroup number comparison, > and let fsck done after the test case to detect problem. > > This also elimiate the necessary of using specified mount and mkfs > option, allowing us to improve cover

Re: [PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

On Mon, Oct 29, 2018 at 11:33 AM Qu Wenruo wrote: > > > > On 2018/10/29 下午5:52, Filipe Manana wrote: > > On Mon, Oct 29, 2018 at 6:31 AM Qu Wenruo wrote: > >> > >> For latest kernel, there is a chance that btrfs/057 reports false > >> errors. >

Re: [PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

On Mon, Oct 29, 2018 at 6:31 AM Qu Wenruo wrote: > > For latest kernel, there is a chance that btrfs/057 reports false > errors. By latest kernel you mean 4.20? > > The false error would look like: > btrfs/057 4s ... - output mismatch (see >

Re: [PATCH v4] Btrfs: fix deadlock on tree root leaf when finding free extent

On Wed, Oct 24, 2018 at 1:40 PM Josef Bacik wrote: > > On Wed, Oct 24, 2018 at 12:53:59PM +0100, Filipe Manana wrote: > > On Wed, Oct 24, 2018 at 12:37 PM Josef Bacik wrote: > > > > > > On Wed, Oct 24, 2018 at 10:13:03AM +0100, fdman...@kernel.org wrot

Re: [PATCH v4] Btrfs: fix deadlock on tree root leaf when finding free extent

On Wed, Oct 24, 2018 at 12:37 PM Josef Bacik wrote: > > On Wed, Oct 24, 2018 at 10:13:03AM +0100, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > When we are writing out a free space cache, during the transaction commit > > phase, we can end up in a dea

Re: [PATCH v3] Btrfs: fix deadlock on tree root leaf when finding free extent

On Wed, Oct 24, 2018 at 5:08 AM Josef Bacik wrote: > > On Mon, Oct 22, 2018 at 11:05:08PM +0100, Filipe Manana wrote: > > On Mon, Oct 22, 2018 at 8:18 PM Josef Bacik wrote: > > > > > > On Mon, Oct 22, 2018 at 08:10:37PM +0100, fdman...@kernel.org wrot

Re: [PATCH v3] Btrfs: fix deadlock on tree root leaf when finding free extent

On Mon, Oct 22, 2018 at 8:18 PM Josef Bacik wrote: > > On Mon, Oct 22, 2018 at 08:10:37PM +0100, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > When we are writing out a free space cache, during the transaction commit > > phase, we can end up in a dea

Re: [PATCH v2] Btrfs: fix deadlock on tree root leaf when finding free extent

On Mon, Oct 22, 2018 at 7:56 PM Josef Bacik wrote: > > On Mon, Oct 22, 2018 at 07:48:30PM +0100, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > When we are writing out a free space cache, during the transaction commit > > phase, we can end up in a dea

Re: [PATCH] Btrfs: fix deadlock on tree root leaf when finding free extent

On Mon, Oct 22, 2018 at 7:07 PM Josef Bacik wrote: > > On Mon, Oct 22, 2018 at 10:09:46AM +0100, fdman...@kernel.org wrote: > > From: Filipe Manana > > > > When we are writing out a free space cache, during the transaction commit > > phase, we can end up in a dea

Re: [PATCH] Btrfs: fix deadlock on tree root leaf when finding free extent

On Mon, Oct 22, 2018 at 10:10 AM wrote: > > From: Filipe Manana > > When we are writing out a free space cache, during the transaction commit > phase, we can end up in a deadlock which results in a stack trace like the > following: > > schedule+0x28/0x80 > btrf

Re: [PATCH] Btrfs: fix deadlock on tree root leaf when finding free extent

On Mon, Oct 22, 2018 at 10:10 AM wrote: > > From: Filipe Manana > > When we are writing out a free space cache, during the transaction commit > phase, we can end up in a deadlock which results in a stack trace like the > following: > > schedule+0x28/0x80 > btrf

Re: Btrfs resize seems to deadlock

ime the resize operation finished successfully. Great, thanks for testing! > On Sun, Oct 21, 2018 at 1:56 AM Filipe Manana wrote: > > > > On Sun, Oct 21, 2018 at 6:05 AM Andrew Nelson > > wrote: > > > > > > Also, is the drive in a safe state to use? Is ther

Re: [PATCH] btrfs/154: test for device dynamic rescan

On Sun, Oct 21, 2018 at 10:20 AM Nikolay Borisov wrote: > > > > On 21.10.2018 10:16, Filipe Manana wrote: > > On Mon, Nov 13, 2017 at 2:26 AM Anand Jain wrote: > >> > >> Make sure missing device is included in the alloc list when it is > >> scanned on

Re: [PATCH] btrfs/154: test for device dynamic rescan

On Mon, Nov 13, 2017 at 2:26 AM Anand Jain wrote: > > Make sure missing device is included in the alloc list when it is > scanned on a mounted FS. > > This test case needs btrfs kernel patch which is in the ML > [PATCH] btrfs: handle dynamically reappearing missing device > Without the kernel

Re: Btrfs resize seems to deadlock

-t 1" command, but > > the output is ~55mb. Is there something in particular you are looking > > for in this? > > On Sat, Oct 20, 2018 at 1:34 PM Filipe Manana wrote: > > > > > > On Sat, Oct 20, 2018 at 9:27 PM Liu Bo wrote: > > > > > > > &

Re: Btrfs resize seems to deadlock

On Sat, Oct 20, 2018 at 9:27 PM Liu Bo wrote: > > On Fri, Oct 19, 2018 at 7:09 PM Andrew Nelson > wrote: > > > > I am having an issue with btrfs resize in Fedora 28. I am attempting > > to enlarge my Btrfs partition. Every time I run "btrfs filesystem > > resize max $MOUNT", the command runs

Re: [PATCH 42/42] btrfs: don't run delayed_iputs in commit

evict_refill_and_join > btrfs_commit_transaction > ... forever > > We have plenty of other places where we run delayed iputs that are much > safer, let those do the work. > > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana > --- > fs/btrfs/transaction.c | 9 - >

Re: [PATCH 14/42] btrfs: reset max_extent_size properly

ize when we add a new chunk or add new space. > > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana > --- > fs/btrfs/extent-tree.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index cd2280962c8c..f845

Re: [PATCH 20/42] btrfs: don't use ctl->free_space for max_extent_size

rately and _only_ use the > max_free_space if we don't have a max_extent_size, as that means our > original request was too large to search any of the block groups for and > therefore wouldn't have a max_extent_size set. > > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana > --- >

Re: [PATCH 19/42] btrfs: set max_extent_size properly

On Thu, Oct 11, 2018 at 8:57 PM Josef Bacik wrote: > > From: Josef Bacik > > We can't use entry->bytes if our entry is a bitmap entry, we need to use > entry->max_extent_size in that case. Fix up all the logic to make this > consistent. > > Signed-off-by: Josef Bac

Re: [PATCH 32/42] btrfs: only free reserved extent if we didn't insert it

ar the reserved extent reservation, resulting in a negative > accounting of the reserved bytes for the block group and space info. > Fix this by only doing the free if we didn't successfully insert a file > extent for this extent. > > Signed-off-by: Josef Bacik > Reviewed-by: Omar San

Re: [PATCH 42/42] btrfs: don't run delayed_iputs in commit

evict_refill_and_join > btrfs_commit_transaction > ... forever > > We have plenty of other places where we run delayed iputs that are much > safer, let those do the work. > > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana Great catch! > --- > fs/btrfs/transaction.c |

Re: [PATCH 37/42] btrfs: wakeup cleaner thread when adding delayed iput

hat we can free up that space as quickly as possible. > > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana > --- > fs/btrfs/inode.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index 2b257d14bd3d..0a1671fb03bf 100644 &g

Re: BTRFS related kernel backtrace on boot on 4.18.7 after blackout due to discharged battery

On Fri, Oct 5, 2018 at 3:23 PM Martin Steigerwald wrote: > > Hello! > > On ThinkPad T520 after battery was discharged and machine just blacked > out. > > Is that some sign of regular consistency check / replay or something to > investigate further? I think it's harmless, if anything were messed

Re: [PATCH v6] test unaligned punch hole at ENOSPC

) <-- ENOSPC > > We don't fail punch hole if the holes are aligned with the file > extent boundaries as it shall involve just dropping the related > extents, without truncating data extent blocks. > > Signed-off-by: Anand Jain Reviewed-by: Filipe Manana Looks good, thanks! >

Re: [PATCH 18/42] btrfs: move the dio_sem higher up the callchain

ng with dio_sem. > > Signed-off-by: Josef Bacik Reviewed-by: Filipe Manana Looks good, thanks. However as David said, it would be nice to have a sample trace pasted in the changelog (several fstests test cases trigger this often). > --- > fs/btrfs/file.c | 12

Re: btrfs send receive ERROR: chown failed: No such file or directory

On Tue, Oct 2, 2018 at 7:02 AM Leonard Lausen wrote: > > Hello, > > does anyone have an idea about below issue? It is a severe issue as it > renders btrfs send / receive dysfunctional and it is not clear if there > may be a data corruption issue hiding in the current send / receive > code. > >

Re: [PATCH v5] test unaligned punch hole at ENOSPC

On Sat, Sep 29, 2018 at 1:52 AM Anand Jain wrote: > > Try to punch hole with unaligned size and offset when the FS is > full. Mainly holes are punched at locations which are unaligned > with the file extent boundaries when the FS is full by data. > As the punching holes at unaligned location will

Re: [PATCH v3] test unaligned punch hole at ENOSPC

On Fri, Sep 28, 2018 at 6:08 PM Filipe Manana wrote: > > On Fri, Sep 28, 2018 at 3:51 PM Anand Jain wrote: > > > > Try to punch hole with unaligned size and offset when the FS > > returns ENOSPC > > The FS returns ENOSPC is confusing. It's more clear to say when

Re: [PATCH v3] test unaligned punch hole at ENOSPC

On Fri, Sep 28, 2018 at 3:51 PM Anand Jain wrote: > > Try to punch hole with unaligned size and offset when the FS > returns ENOSPC The FS returns ENOSPC is confusing. It's more clear to say when the filesystem doesn't have more space available for data allocation. > > Signed-off-by: Anand Jain

Re: Strange behavior (possible bugs) in btrfs

ks. > > Thanks, > Jayashree Mohan > > Thanks, > Jayashree Mohan > > > > On Fri, May 11, 2018 at 10:45 AM Filipe Manana wrote: > > > > On Mon, Apr 30, 2018 at 5:04 PM, Vijay Chidambaram > > wrote: > > > Hi, > > > > > > We found two

Re: [PATCH] generic: test for deduplication between different files

On Mon, Aug 20, 2018 at 12:11 AM, Dave Chinner wrote: > [cc linux-...@vger.kernel.org] > > On Fri, Aug 17, 2018 at 09:39:24AM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> Test that deduplication of an entire file that has a size that is not >>

Re: [patch] file dedupe (and maybe clone) data corruption (was Re: [PATCH] generic: test for deduplication between different files)

On Mon, Aug 20, 2018 at 2:09 AM, Dave Chinner wrote: > [cc linux-fsdevel now, too] > > On Mon, Aug 20, 2018 at 09:11:26AM +1000, Dave Chinner wrote: >> [cc linux-...@vger.kernel.org] >> >> On Fri, Aug 17, 2018 at 09:39:24AM +0100, fdman...@kernel.org wrot

Re: [PATCH] generic: test for deduplication between different files

On Sun, Aug 19, 2018 at 5:19 PM, Eryu Guan wrote: > On Sun, Aug 19, 2018 at 04:41:31PM +0100, Filipe Manana wrote: >> On Sun, Aug 19, 2018 at 3:07 PM, Eryu Guan wrote: >> > On Fri, Aug 17, 2018 at 09:39:24AM +0100, fdman...@kernel.org wrote: >> >> From: F

Re: [PATCH] generic: test for deduplication between different files

On Sun, Aug 19, 2018 at 3:07 PM, Eryu Guan wrote: > On Fri, Aug 17, 2018 at 09:39:24AM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> Test that deduplication of an entire file that has a size that is not >> aligned to the filesystem's block size

Re: [PATCH 2/2] Btrfs: sync log after logging new name

On Tue, Aug 14, 2018 at 11:53 PM, David Sterba wrote: > On Tue, Aug 14, 2018 at 12:04:05PM -0700, Omar Sandoval wrote: >> On Mon, Jun 18, 2018 at 01:06:16PM +0200, David Sterba wrote: >> > On Fri, Jun 15, 2018 at 05:19:07PM +0100, Filipe Manana wrote: >> > > On Fri,

Re: [PATCH] fstests: btrfs: Add test for corrupted orphan qgroup numbers

On Fri, Aug 10, 2018 at 9:46 AM, Qu Wenruo wrote: > > > On 8/9/18 5:26 PM, Filipe Manana wrote: >> On Thu, Aug 9, 2018 at 8:45 AM, Qu Wenruo wrote: >>> This bug is exposed by populating a high level qgroup, and then make it >>> orphan (high level qgroup

Re: [PATCH v2] fstests: btrfs: Add test for corrupted childless qgroup numbers

On Fri, Aug 10, 2018 at 3:20 AM, Qu Wenruo wrote: > This bug is exposed by populating a high level qgroup, and then make it > childless with old qgroup numbers, and finally do rescan. > > Normally rescan should zero out all qgroups' accounting number, but due > to a kernel bug which won't mark

Re: [PATCH] fstests: btrfs: Add test for corrupted orphan qgroup numbers

On Thu, Aug 9, 2018 at 8:45 AM, Qu Wenruo wrote: > This bug is exposed by populating a high level qgroup, and then make it > orphan (high level qgroup without child) Same comment as in the kernel patch: "That sentence is confusing. An orphan, by definition [1], is someone (or something in this

Re: [PATCH v2] btrfs: qgroup: Dirty all qgroups before rescan

On Thu, Aug 9, 2018 at 8:08 AM, Qu Wenruo wrote: > [BUG] > In the following case, rescan won't zero out the number of qgroup 1/0: > -- > $ mkfs.btrfs -fq $DEV > $ mount $DEV /mnt > > $ btrfs quota enable /mnt > $ btrfs qgroup create 1/0 /mnt > $ btrfs sub create /mnt/sub > $ btrfs qgroup

Re: [PATCH] Btrfs: optimization to avoid ENOSPC for nocow writes after snapshot when low on data space

On Mon, Aug 6, 2018 at 3:33 AM, robbieko wrote: > Filipe Manana 於 2018-08-03 18:22 寫到: > >> On Fri, Aug 3, 2018 at 10:13 AM, robbieko wrote: >>> >>> From: Robbie Ko >>> >>> Commit e9894fd3e3b3 ("Btrfs: fix snapshot vs nocow writting&

Re: [PATCH] btrfs: revert fs_devices state on error of btrfs_init_new_device()

On Fri, Aug 3, 2018 at 8:29 AM, Anand Jain wrote: > > > On 08/03/2018 02:36 PM, Anand Jain wrote: >> >> >> >> >> On 07/31/2018 07:47 PM, Filipe Manana wrote: >>> >>> On Tue, Jul 31, 2018 at 11:12 AM, Anand Jain >>> wro

Re: [PATCH] Btrfs: optimization to avoid ENOSPC for nocow writes after snapshot when low on data space

tomic_inc(>will_be_snapshotted); > smp_mb__after_atomic(); > /* wait for no snapshot writes */ > @@ -787,6 +792,13 @@ static int create_snapshot(struct btrfs_root *root, > struct inode *dir, > if (ret) > goto dec_and_free

Re: [PATCH] Btrfs: fix data lose with snapshot when nospace

On Wed, Aug 1, 2018 at 1:54 PM, Filipe Manana wrote: > On Wed, Aug 1, 2018 at 11:20 AM, robbieko wrote: >> Filipe Manana 於 2018-07-31 19:33 寫到: >> >>> On Tue, Jul 31, 2018 at 11:17 AM, robbieko wrote: >>>> >>>> Filipe Manana 於 2018-07-30 20:34

Re: [PATCH] Btrfs: fix data lose with snapshot when nospace

On Wed, Aug 1, 2018 at 11:20 AM, robbieko wrote: > Filipe Manana 於 2018-07-31 19:33 寫到: > >> On Tue, Jul 31, 2018 at 11:17 AM, robbieko wrote: >>> >>> Filipe Manana 於 2018-07-30 20:34 寫到: >>> >>>> On Mon, Jul 30, 2018 at 12:28 PM, Filipe Manana

Re: [PATCH] btrfs: revert fs_devices state on error of btrfs_init_new_device()

On Tue, Jul 31, 2018 at 11:12 AM, Anand Jain wrote: > > > On 07/27/2018 08:04 AM, Naohiro Aota wrote: >> >> When btrfs hits error after modifying fs_devices in >> btrfs_init_new_device() (such as btrfs_add_dev_item() returns error), it >> leaves everything as is, but frees allocated btrfs_device.

Re: [PATCH] Btrfs: fix data lose with snapshot when nospace

On Tue, Jul 31, 2018 at 11:17 AM, robbieko wrote: > Filipe Manana 於 2018-07-30 20:34 寫到: > >> On Mon, Jul 30, 2018 at 12:28 PM, Filipe Manana >> wrote: >>> >>> On Mon, Jul 30, 2018 at 12:08 PM, Filipe Manana >>> wrote: >>>> &g

Re: [PATCH] btrfs: revert fs_devices state on error of btrfs_init_new_device()

Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling") > Signed-off-by: Naohiro Aota Reviewed-by: Filipe Manana Looks good, only fs_info->fs_devices->rotating isn't restored but currently that causes no problems. > --- > fs/btrfs/volumes.c | 28

Re: [PATCH] Btrfs: fix data lose with snapshot when nospace

On Mon, Jul 30, 2018 at 12:28 PM, Filipe Manana wrote: > On Mon, Jul 30, 2018 at 12:08 PM, Filipe Manana wrote: >> On Mon, Jul 30, 2018 at 11:21 AM, robbieko wrote: >>> From: Robbie Ko >>> >>> Commit e9894fd3e3b3 ("Btrfs: fix snapshot vs nocow wr

Re: [PATCH] Btrfs: fix data lose with snapshot when nospace

On Mon, Jul 30, 2018 at 12:08 PM, Filipe Manana wrote: > On Mon, Jul 30, 2018 at 11:21 AM, robbieko wrote: >> From: Robbie Ko >> >> Commit e9894fd3e3b3 ("Btrfs: fix snapshot vs nocow writting") >> modified the nocow writeback mechanism, if you create a snap

Re: [PATCH] Btrfs: fix data lose with snapshot when nospace

On Mon, Jul 30, 2018 at 11:21 AM, robbieko wrote: > From: Robbie Ko > > Commit e9894fd3e3b3 ("Btrfs: fix snapshot vs nocow writting") > modified the nocow writeback mechanism, if you create a snapshot, > it will always switch to cow writeback. > > This will cause data loss when there is no

Re: [PATCH] btrfs: introduce feature to forget a btrfs device

On Thu, Jul 26, 2018 at 12:32 PM, Anand Jain wrote: > Support for a new command 'btrfs dev forget [dev]' is proposed here, > to undo the effects of 'btrfs dev scan [dev]'. For this purpose, > this patch proposes to use ioctl #5 as it was empty. > IOW(BTRFS_IOCTL_MAGIC, 5, ..) > This patch

Re: [PATCH 17/22] btrfs: don't take the dio_sem in the fsync path

On Thu, Jul 19, 2018 at 4:54 PM, Josef Bacik wrote: > On Thu, Jul 19, 2018 at 04:21:58PM +0100, Filipe Manana wrote: >> On Thu, Jul 19, 2018 at 3:50 PM, Josef Bacik wrote: >> > Since we've changed the fsync() path to always run ordered extents >> > before doing the

Re: [PATCH 17/22] btrfs: don't take the dio_sem in the fsync path

On Thu, Jul 19, 2018 at 3:50 PM, Josef Bacik wrote: > Since we've changed the fsync() path to always run ordered extents > before doing the tree log we no longer need to take the dio_sem in the > tree log path. This gets rid of a lockdep splat that I was seeing with > the AIO tests. So

Re: [PATCH 17/22] btrfs: don't take the dio_sem in the fsync path

On Thu, Jul 19, 2018 at 3:50 PM, Josef Bacik wrote: > Since we've changed the fsync() path to always run ordered extents > before doing the tree log we no longer need to take the dio_sem in the > tree log path. This gets rid of a lockdep splat that I was seeing with > the AIO tests. The dio_sem

Re: About hung task on generic/041

On Wed, Jul 11, 2018 at 10:02 AM, Lu Fengqi wrote: > Hi, > > When I run generic/041 with v4.18-rc3 (turn on kasan and hung task > detection), btrfs-transaction kthread will trigger the hung task timeout > (stall at wait_event in btrfs_commit_transaction). At the same time, you > can see that

Re: [PATCH] Btrfs: fix mount failure when qgroup rescan is in progress

On Wed, Jun 27, 2018 at 4:55 PM, Nikolay Borisov wrote: > > > On 27.06.2018 18:45, Filipe Manana wrote: >> On Wed, Jun 27, 2018 at 4:44 PM, Nikolay Borisov wrote: >>> >>> >>> On 27.06.2018 02:43, fdman...@kernel.org wrote: >>>> From: Fil

Re: [PATCH] Btrfs: fix mount failure when qgroup rescan is in progress

On Wed, Jun 27, 2018 at 4:44 PM, Nikolay Borisov wrote: > > > On 27.06.2018 02:43, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> If a power failure happens while the qgroup rescan kthread is running, >> the next mount operation will always

Re: [PATCH v4] btrfs: Don't remove block group still has pinned down bytes

st teach btrfs_delete_unused_bgs() to skip block group who still has > pinned bytes. > > However there is a minor side effect, since currently we only queue > empty blocks at update_block_group(), and such empty block group with > pinned bytes won't go through update_block_group(

Re: [PATCH 1/2] Btrfs: fix return value on rename exchange failure

On Tue, Jun 19, 2018 at 2:38 PM, David Sterba wrote: > On Mon, Jun 11, 2018 at 07:24:16PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> If we failed during a rename exchange operation after starting/joining a >> transaction, we would end up replaci

Re: [PATCH v3] btrfs: Don't remove block group still has pinned down bytes

On Wed, Jun 20, 2018 at 12:03 PM, Qu Wenruo wrote: > > > On 2018年06月20日 17:33, Filipe Manana wrote: >> On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote: >>> >>> >>> On 2018年06月20日 17:13, Filipe Manana wrote: >>>> On Fri, Jun 15, 2018 at 2:35

Re: [PATCH v3] btrfs: Don't remove block group still has pinned down bytes

On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote: > > > On 2018年06月20日 17:13, Filipe Manana wrote: >> On Fri, Jun 15, 2018 at 2:35 AM, Qu Wenruo wrote: >>> [BUG] >>> Under certain KVM load and LTP tests, we are possible to hit the >>&g

Re: [PATCH v3] btrfs: Don't remove block group still has pinned down bytes

On Fri, Jun 15, 2018 at 2:35 AM, Qu Wenruo wrote: > [BUG] > Under certain KVM load and LTP tests, we are possible to hit the > following calltrace if quota is enabled: > -- > BTRFS critical (device vda2): unable to find logical 8820195328 length 4096 > BTRFS critical (device vda2): unable to

Re: [PATCH] Btrfs: fix physical offset reported by fiemap for inline extents

On Wed, Jun 20, 2018 at 3:55 AM, robbieko wrote: > fdman...@kernel.org 於 2018-06-19 19:31 寫到: > >> From: Filipe Manana >> >> Commit 9d311e11fc1f ("Btrfs: fiemap: pass correct bytenr when >> fm_extent_count is zero") introduced a regression where we no l

Re: [PATCH 2/2] Btrfs: sync log after logging new name

On Fri, Jun 15, 2018 at 4:54 PM, David Sterba wrote: > On Mon, Jun 11, 2018 at 07:24:28PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana >> Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes") >> Reported-by: Vijay Chidambaram

Re: [GIT PULL] Btrfs updates for 4.18

On Mon, Jun 11, 2018 at 9:14 AM, Anand Jain wrote: > > > On 06/10/2018 12:21 AM, Filipe Manana wrote: >> >> On Mon, Jun 4, 2018 at 4:43 PM, David Sterba wrote: >>> >>> Hi, >>> >>> there are some new features and a usual load of cleanu

Re: [GIT PULL] Btrfs updates for 4.18

On Mon, Jun 4, 2018 at 4:43 PM, David Sterba wrote: > Hi, > > there are some new features and a usual load of cleanups, more details below. > > Specifically, there's a set of new non-privileged ioctls to allow > subvolume listing. It works but still needs a security review as it's a > new

Re: [PATCH 1/4] btrfs: always wait on ordered extents at fsync time

On Wed, May 23, 2018 at 4:58 PM, Josef Bacik wrote: > From: Josef Bacik > > There's a priority inversion that exists currently with btrfs fsync. In > some cases we will collect outstanding ordered extents onto a list and > only wait on them at the very last

Re: [PATCH 2/2] btrfs: always wait on ordered extents at fsync time

we had to do around getting > the right checksums. Killing all of this makes our lives easier and > gets rid of the priority inversion. Much easier! > > Signed-off-by: Josef Bacik <jba...@fb.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Looks good to me. Happy to s

Re: Strange behavior (possible bugs) in btrfs

On Mon, Apr 30, 2018 at 5:04 PM, Vijay Chidambaram wrote: > Hi, > > We found two more cases where the btrfs behavior is a little strange. > In one case, an fsync-ed file goes missing after a crash. In the > other, a renamed file shows up in both directories after a crash. > >

  1   2   3   4   5   6   7   8   >