Re: [PATCH 3/3] btrfs: sysfs: protect reading label by lock

On Tue, Apr 26, 2016 at 3:32 PM, David Sterba wrote: > If the label setting ioctl races with sysfs label handler, we could get > mixed result in the output, part old part new. We should either get the > old or new label. The chances to hit this race are low. > > Signed-off-by:

Re: [RFC PATCH] btrfs: correct inode's outstanding_extents computation

On Thu, May 19, 2016 at 11:49 AM, Wang Xiaoguang wrote: > This issue was revealed by modifing BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, > When modifing BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, fsstress test often gets > these warnings from btrfs_destroy_inode(): >

Re: [PATCH] btrfs: remove unnecessary btrfs_delalloc_release_metadata() call

On Thu, May 19, 2016 at 10:44 AM, Wang Xiaoguang wrote: > In __btrfs_write_out_cache(), we don't call btrfs_delalloc_reserve_metadata() > or btrfs_delalloc_reserve_space() to reserve metadata space, so we also should > not call btrfs_delalloc_release_metadata(), in

Re: [RFC PATCH] btrfs: correct inode's outstanding_extents computation

On Mon, May 23, 2016 at 7:05 AM, Wang Xiaoguang <wangxg.f...@cn.fujitsu.com> wrote: > hello, > > > On 05/19/2016 07:01 PM, Filipe Manana wrote: >> >> On Thu, May 19, 2016 at 11:49 AM, Wang Xiaoguang >> <wangxg.f...@cn.fujitsu.com> wrote: &

Re: [PATCH 6/6] Btrfs: fix race between device replace and chunk allocation

On Fri, May 20, 2016 at 4:30 PM, Josef Bacik <jo...@toxicpanda.com> wrote: > On Fri, May 20, 2016 at 12:45 AM, <fdman...@kernel.org> wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> While iterating and copying extents from the source device, the

Re: Device replace issues and disabling it until they are solved

On Wed, May 11, 2016 at 10:29 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > Filipe Manana wrote on 2016/05/11 10:09 +0100: >> >> Hi, >> >> I've noticed some time ago that our device replace implementation is >> unreliable. Basically under several

Re: Device replace issues and disabling it until they are solved

On Wed, May 11, 2016 at 10:09 AM, Filipe Manana <fdman...@kernel.org> wrote: > Hi, > > I've noticed some time ago that our device replace implementation is > unreliable. Basically under several situations it ends up not copying > extents (both data and metadata) from the

Re: [PATCH 1/2] Btrfs: fix race between fsync and direct IO writes for prealloc extents

On Wed, May 11, 2016 at 4:41 PM, Josef Bacik <jba...@fb.com> wrote: > On 05/09/2016 07:01 AM, fdman...@kernel.org wrote: >> >> From: Filipe Manana <fdman...@suse.com> >> >> When we do a direct IO write against a preallocated extent (fallocate) >> that d

Device replace issues and disabling it until they are solved

Hi, I've noticed some time ago that our device replace implementation is unreliable. Basically under several situations it ends up not copying extents (both data and metadata) from the old device to the new device (I briefly talked about some of the problems with Josef at LSF). Essentially it

Re: [PATCH] btrfs: ioctl: reorder exclusive op check in RM_DEV

On Wed, May 4, 2016 at 10:32 AM, David Sterba wrote: > From: David Sterba > > Move the op exclusivity check before the other code (same as in > ADD_DEV). > > Signed-off-by: David Sterba > --- > fs/btrfs/ioctl.c | 23 +++ >

Re: [PATCH, maybe WRONG] btrfs: don't let btrfs_recover_relocation get stuck waiting for cleaner_kthread to delete a snapshot

On Wed, May 4, 2016 at 2:10 AM, Zygo Blaxell wrote: > This is one way to fix a long hang during mounts. There's probably a > better way, but this is the one I've used to get my filesystems up > and running. > > We start the cleaner kthread first because the

Re: [PATCH] btrfs: don't force mounts to wait for cleaner_kthread to delete one or more subvolumes

process will not be blocked by the cleaner kthread. > The cleaner kthread is already prepared for mutex contention and will > just go to sleep until the mutex is available. You miss your Signed-off-by: tag (git format-patch or git commit with -s add it automatically). Once you get that, you

Re: [PATCH 3/3] Btrfs: don't do unnecessary delalloc flushes when relocating

On Tue, May 10, 2016 at 12:56 AM, Liu Bo <bo.li@oracle.com> wrote: > On Mon, Apr 25, 2016 at 02:01:12AM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> Before we start the actual relocation process of a block group, we do

Re: [PATCH] fstests: btrfs: Test fiemap ioctl on completely deduped file

On Tue, May 10, 2016 at 9:39 AM, Qu Wenruo wrote: > For a completely deduped file, which means all its file extent are > pointing to one bytenr, if calling fiemap on it, btrfs will cause soft > hang up or just takes years long. > > This bug can be reproduced even without

Re: [PATCH v2] btrfs: qgroup: Fix qgroup accounting when creating snapshot

On Thu, Apr 14, 2016 at 2:30 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > Filipe Manana wrote on 2016/04/13 17:23 +0100: >> >> On Tue, Apr 12, 2016 at 8:35 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> Current btr

Re: [PATCH] Btrfs: fix loading of orphan roots leading to BUG_ON

On Thu, Apr 14, 2016 at 6:34 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > Ping? > > Cc: Chris and David > > It seems that this fix is missing in 4.6 merge window. > Or did I miss something? 4.5-rc7: https://lkml.org/lkml/2016/3/4/695 > > Thanks, > Qu > &

Re: [PATCH RFC] btrfs: send: Disable clone detection

On Tue, Jul 26, 2016 at 1:57 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 07/25/2016 09:48 PM, Filipe Manana wrote: >> >> On Mon, Jul 25, 2016 at 8:19 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> This patch will

Re: [PATCH 1/3] btrfs: add test for an incremental send after moving directories around

On Tue, Jul 12, 2016 at 4:58 AM, Eryu Guan <eg...@redhat.com> wrote: > On Sat, Jul 02, 2016 at 01:32:08PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> Test that an incremental send operation works after doing radical chan

Re: [PATCH v2] Btrfs: fix unexpected balance crash due to BUG_ON

On Mon, Jul 11, 2016 at 6:21 PM, Liu Bo wrote: > Mounting a btrfs can resume previous balance operations asynchronously. > An user got a crash when one drive has some corrupt sectors. > > Since balance can cancel itself in case of any error, we can gracefully > return errors

Re: [PATCH RFC] btrfs: send: Disable clone detection

subvolumes), isn't it the same problem? The backref code has to find all such inodes/offsets/roots and take again the same long time... Following your logic, it seems like everything that uses the backref walking code should be disabled. > > Cc: Filipe Manana <fdman...@gmail.com> > R

Re: [PATCH RFC] btrfs: send: Disable clone detection

On Tue, Jul 26, 2016 at 11:04 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 07/26/2016 05:28 PM, Filipe Manana wrote: >> >> On Tue, Jul 26, 2016 at 1:57 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> >>> >

Re: Btrfs send to send out metadata and data separately

On Tue, Aug 2, 2016 at 2:20 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 08/02/2016 02:00 AM, Filipe Manana wrote: >> >> On Fri, Jul 29, 2016 at 1:40 PM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >>> >>> Hi Filipe, and maintainers, &

Re: [PATCH v3 2/3] btrfs: relocation: Fix leaking qgroups numbers on data extents

swapping is done, and qgroup > will account these data extents correctly. Hi Qu, This changelog should mention this fixes a regression introduced in the 4.2 kernel. It's specially important for people responsible to backport fixes to earlier kernel releases. > > Cc: Mark Fasheh <mfas...@suse.de&g

Re: btrfs on sparc64 results in kernel stack trace in 1 minute test

On Thu, Jul 14, 2016 at 11:08 AM, Anatoly Pugachev wrote: > Hi! > > I'm using git (describe, v4.7-rc7-16-gcf875cc) kernel, > with patch "fix extent buffer bitmap tests on big-endian systems", see > [1] (to be able to load/use btrfs module) > > and getting brtfs filesystem

Re: [PATCH] btrfs: test whether fallocate(2) can preallocate half of the whole fs space

On Wed, Jul 20, 2016 at 8:34 AM, Wang Xiaoguang wrote: > Currently in btrfs, there is something wrong with data space reservation. > For example, if we try to preallocate more than haf of whole fs space, > ENOSPC will occur, but indeed fs still has free space to

Re: Btrfs send to send out metadata and data separately

On Fri, Jul 29, 2016 at 1:40 PM, Qu Wenruo wrote: > Hi Filipe, and maintainers, > > I'm recently working on the root fix to free send from calling backref walk. > > My current idea is to send data and metadata separately, and only do clone > detection inside the send

Re: [PATCH 1/2] btrfs: fix fsfreeze hang caused by delayed iputs deal

On Wed, Jun 29, 2016 at 6:15 AM, Wang Xiaoguang wrote: > When running fstests generic/068, sometimes we got below WARNING: > xfs_io D 8800331dbb20 0 6697 6693 0x0080 > 8800331dbb20 88007acfc140 880034d895c0 8800331dc000 >

Re: [PATCH 2/2] btrfs: replace: Use ref counts to avoid destroying target device when canceled

On Tue, Jan 17, 2017 at 1:10 AM, Qu Wenruo wrote: > When dev-replace and scrub are run at the same time, dev-replace can be > canceled by scrub. It's quite common for btrfs/069. > > While in that case, target device can be destroyed at cancel time, > leading to a

Re: [PATCH] Btrfs: fix assertion failure when freeing block groups at close_ctree()

On Thu, Feb 2, 2017 at 6:53 PM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Feb 02, 2017 at 06:32:01PM +0000, Filipe Manana wrote: >> On Thu, Feb 2, 2017 at 6:19 PM, Liu Bo <bo.li@oracle.com> wrote: >> > On Wed, Feb 01, 2017 at 11:01:28PM +, fdman...@kernel

Re: [PATCH] Btrfs: fix assertion failure when freeing block groups at close_ctree()

On Thu, Feb 2, 2017 at 6:19 PM, Liu Bo <bo.li@oracle.com> wrote: > On Wed, Feb 01, 2017 at 11:01:28PM +, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> At close_ctree() we free the block groups and then only after we wait f

Re: [PATCH] Btrfs: bulk delete checksum items in the same leaf

On Tue, Jan 31, 2017 at 1:02 AM, Omar Sandoval <osan...@osandov.com> wrote: > On Sat, Jan 28, 2017 at 06:06:32AM +, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> Very often we have the checksums for an extent spread in multip

Re: Very slow balance / btrfs-transaction

On Tue, Feb 7, 2017 at 12:22 AM, Qu Wenruo wrote: > > > At 02/07/2017 12:09 AM, Goldwyn Rodrigues wrote: >> >> >> Hi Qu, >> >> On 02/05/2017 07:45 PM, Qu Wenruo wrote: >>> >>> >>> >>> At 02/04/2017 09:47 AM, Jorg Bornschein wrote: February 4, 2017 1:07 AM,

Re: Very slow balance / btrfs-transaction

On Wed, Feb 8, 2017 at 12:39 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 02/07/2017 11:55 PM, Filipe Manana wrote: >> >> On Tue, Feb 7, 2017 at 12:22 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>>

Re: [PATCH] btrfs: qgroup: Move half of the qgroup accounting time out of commit trans

ing the state to TRANS_STATE_UNBLOCKED. This should be explained somehow in the changelog. > > But please note that, this won't speedup qgroup overall, it just moves > half of the cost out of commit_transaction(). > > Cc: Filipe Manana <fdman...@suse.com> > Signed-off-by: Qu Wenruo &

Re: [PATCH 0/1] btrfs lockdep annotation

On Tue, Jan 24, 2017 at 9:01 AM, Christian Borntraeger wrote: > Chris, > > since my bug report about this did not result in any fix and since It was fixed and the fix landed in 4.10-rc4:

Re: [PATCH] Btrfs: fix leak subvol subv_writers conter

On Fri, Oct 7, 2016 at 3:01 AM, robbieko wrote: > From: Robbie Ko > > In run_delalloc_nocow, maybe not release subv_writers conter, > will lead to create snapshot hang. > > Signed-off-by: Robbie Ko I've picked this into my

Re: [PATCH] Btrfs: fix -EINVEL in tree log recovering

On Tue, Oct 11, 2016 at 10:01 AM, robbieko wrote: > From: Robbie Ko > > when tree log recovery, space_cache rebuild or dirty maybe save the cache. > and then replay extent with disk_bytenr and disk_num_bytes, > but disk_bytenr and disk_num_bytes

Re: [PATCH] Btrfs: try harder to migrate items to left sibling before splitting a leaf

On Wed, Feb 22, 2017 at 12:07 AM, Liu Bo <bo.li@oracle.com> wrote: > On Sun, Feb 19, 2017 at 08:56:39PM +, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> Before attempting to split a leaf we try to migrate items from the leaf

Re: Why is btrfs_run_delayed_refs() run multiple times

On Mon, Feb 20, 2017 at 5:08 PM, Goldwyn Rodrigues wrote: > Hi, > > Why do we call btrfs_run_delayed_refs multiple times in a function? Some > of the examples are: > > btrfs_commit_transaction() > commit_cowonly_roots() > > Is it because one call can generate more delayed refs

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

On Mon, Feb 20, 2017 at 12:31 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 02/17/2017 11:25 PM, Filipe Manana wrote: >> >> On Fri, Feb 17, 2017 at 12:37 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> >>> >

Re: [PATCH] Btrfs: remove unnecessary constraint when splitting a leaf

On Sat, Feb 18, 2017 at 12:34 AM, Liu Bo <bo.li@oracle.com> wrote: > On Fri, Feb 17, 2017 at 07:16:04PM +, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> If we want to append an item to a leaf we were trying to move off fr

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

On Fri, Feb 17, 2017 at 12:37 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 02/16/2017 06:03 PM, Filipe Manana wrote: >> >> On Thu, Feb 16, 2017 at 12:39 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> >>> >

Re: [PATCH v2] btrfs: relocation: Enhance kernel error output for relocation

On Tue, Feb 14, 2017 at 12:57 AM, Qu Wenruo wrote: > When balance(relocation) fails, btrfs-progs will report like: > > ERROR: error during balancing '/mnt/scratch': Input/output error > There may be more info in syslog - try dmesg | tail > > However kernel can't provide

Re: [PATCH v2] btrfs: qgroup: Move half of the qgroup accounting time out of commit trans

ting. > > This patch moves the @old_roots search part out of > commit_transaction(), so in theory we can half the time qgroup time > consumption at commit_transaction(). > > But please note that, this won't speedup qgroup overall, the total time > consumption is still the sam

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

On Thu, Feb 16, 2017 at 12:39 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 02/15/2017 11:59 PM, Filipe Manana wrote: >> >> On Wed, Feb 15, 2017 at 8:49 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> If run btrfs/125 wit

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

On Wed, Feb 15, 2017 at 8:49 AM, Qu Wenruo wrote: > If run btrfs/125 with nospace_cache or space_cache=v2 mount option, > btrfs will block with the following backtrace: > > Call Trace: > __schedule+0x2d4/0xae0 > schedule+0x3d/0x90 >

Re: [PATCH v3 4/6] Btrfs: incremental send, fix invalid path for rmdir operations

On Thu, Jan 5, 2017 at 8:24 AM, robbieko wrote: > From: Robbie Ko > > Under certain situations, an incremental send operation can Again, missing some word after the word "can". Copy pasting change logs is not that good > a rmdir operation that

Re: [PATCH v3 2/6] Btrfs: incremental send, fix invalid path for truncate operations

On Thu, Jan 5, 2017 at 8:24 AM, robbieko wrote: > From: Robbie Ko > > Under certain situations, an incremental send operation can Again, missing some word after the word "can", without it the phrase doesn't make any sense. Tip: don't copy paste

Re: [PATCH v3 1/6] Btrfs: incremental send, fix failure to rename with the name collision

On Thu, Jan 5, 2017 at 8:24 AM, robbieko wrote: > From: Robbie Ko > > Under certain situations, an incremental send operation can Missing some word after the word "can". > a rename operation that will make the receiving end fail when > attempting

Re: [PATCH v2 4/4] xfstests: btrfs/134: add test for incremental send which renames a directory already being deleted

On Wed, Nov 2, 2016 at 3:52 AM, robbieko wrote: > Hi Eryu Guan, > > Yes, it need apply > [PATCH] "Btrfs: incremental send, do not skip generation inconsistency check > for inode 256." > and test again, it will failed. > > because current code there is a problem, but just

Re: [PATCH v3 2/4] xfstests: btrfs/132: add test for invaild update time by an incremental send

On Thu, Jan 5, 2017 at 11:31 AM, Filipe Manana <fdman...@gmail.com> wrote: > On Thu, Jan 5, 2017 at 2:45 AM, robbieko <robbi...@synology.com> wrote: >> Filipe Manana 於 2017-01-04 21:09 寫到: >> >>> On Wed, Jan 4, 2017 at 10:53 AM, robbieko <robbi...@synolog

Re: [PATCH v4] btrfs: Handle delalloc error correctly to avoid ordered extent deadlock

data > release, so btrfs_cleanup_ordered_extents() doesn't need to do it. > > For compression, it's calling writepage_end_io_hook() itself to handle > its error, and any submitted ordered extent will have its bio submitted, > so no need to worry about compression part. > > Suggested-

Re: [PATCH v4] btrfs: Handle delalloc error correctly to avoid ordered extent deadlock

On Mon, Feb 27, 2017 at 4:14 PM, Filipe Manana <fdman...@kernel.org> wrote: Also, forgot to mention before, looking at the subject, the term deadlock is not correct, as it's a hang. A deadlock is when a task is trying to acquire a resource (typically a lock) that is already held by some

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

Re: Btrfs send to send out metadata and data separately

On Wed, Aug 24, 2016 at 3:36 AM, Qu Wenruo <quwen...@cn.fujitsu.com> 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 <quwe

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo wrote: > This can only happen with CONFIG_BTRFS_FS_CHECK_INTEGRITY=y. > > Commit 1ba98d0 ("Btrfs: detect corruption when non-root leaf has zero item") > assumes that a leaf is its root when leaf->bytenr == btrfs_root_bytenr(root), >

Re: Is stability a joke? (wiki updated)

On Mon, Sep 12, 2016 at 5:56 PM, Austin S. Hemmelgarn wrote: > On 2016-09-12 12:27, David Sterba wrote: >> >> On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote: I therefore would like to propose that some sort of feature / stability matrix for the

Re: [PATCH] Btrfs: fix fsync deadlock in log_new_dir_dentries

On Fri, Oct 7, 2016 at 11:05 AM, robbieko wrote: > From: Robbie Ko > > We found a fsync deadlock ie. 32021->32020->32028->14431->14436->32021, > in log_new_dir_dentries, because btrfs_search_forward get path lock, then > call btrfs_iget will get

Re: [PATCH] Btrfs: fix fsync deadlock in log_new_dir_dentries

lease avoid mixing inline replies with top posting, it just breaks the thread. thanks > > Thanks. > robbieko > > Filipe Manana <fdman...@gmail.com> 於 2016-10-07 18:23 寫道： > > On Fri, Oct 7, 2016 at 11:05 AM, robbieko <robbi...@synology.com> wrote: >> From:

Re: [PATCH] Btrfs: fix enospc in punch hole

On Fri, Oct 7, 2016 at 7:09 AM, robbieko wrote: > From: Robbie Ko > > when extent-tree level > BTRFS_MAX_LEVEL / 2, > __btrfs_drop_extents -> btrfs_duplicate_item -> > setup_leaf_for_split -> split_leaf > maybe enospc, because min_size is too small,

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On Tue, Sep 6, 2016 at 10:51 PM, Liu Bo <bo.li@oracle.com> wrote: > Hi Filipe, > > On Mon, Sep 05, 2016 at 04:28:09PM +0100, Filipe Manana wrote: >> On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo <bo.li@oracle.com> wrote: >> > This can only happen wi

Re: [PATCH] btrfs-progs: Initialize btrfs_path before use

On Mon, Oct 24, 2016 at 3:57 PM, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > While performing an fsck, an assertion failure occurs because of reusing path > in a loop. > ctree.c:1112: btrfs_search_slot: Warning: assertion `p->nodes[0] != NULL` >

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On Mon, Oct 17, 2016 at 4:44 PM, Liu Bo <bo.li@oracle.com> wrote: > On Mon, Oct 17, 2016 at 03:00:25PM +0200, David Sterba wrote: >> On Thu, Oct 13, 2016 at 09:47:11AM +0100, Filipe Manana wrote: >> > > Since the crash is similar to the call chains fr

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On Wed, Nov 23, 2016 at 1:15 PM, Filipe Manana <fdman...@gmail.com> wrote: > On Mon, Oct 17, 2016 at 4:44 PM, Liu Bo <bo.li@oracle.com> wrote: >> On Mon, Oct 17, 2016 at 03:00:25PM +0200, David Sterba wrote: >>> On Thu, Oct 13, 2016 at 09:47:11AM +0100, Fili

Re: [PATCH v2] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

t))" instead, just like > how we check whether leaf is a root in __btrfs_cow_block(). > > Fixes: 1ba98d086fe3 (Btrfs: detect corruption when non-root leaf has zero > item) > Cc: sta...@vger.kernel.org # 4.8+ > Reported-by: Jeff Mahoney <je...@suse.com> > Signed-off-by: Liu

Re: resend: Re: Btrfs: adjust len of writes if following a preallocated extent

On Wed, Nov 23, 2016 at 9:22 PM, Liu Bo wrote: > Hi, > > On Wed, Nov 23, 2016 at 06:21:35PM +0100, Stefan Priebe - Profihost AG wrote: >> Hi, >> >> sorry last mail was from the wrong box. >> >> Am 04.11.2016 um 20:20 schrieb Liu Bo: >> > If we have >> > >> >

Re: [PATCH 1/3] Btrfs: remove balance warning that does not reflect a problem

On Fri, Nov 18, 2016 at 9:37 AM, <fdman...@kernel.org> wrote: > From: Filipe Manana <fdman...@suse.com> > > On openSUSE/SLE systems where balance is triggered periodically in the > background, snapshotting happens when doing package installations and > upgrades, and (

Re: [PATCH v2 3/6] Btrfs: incremental send, add generation for waiting_dir_move struct and check it in can_rmdir.

On Fri, Oct 28, 2016 at 2:40 AM, robbieko wrote: > From: Robbie Ko > > Example scenario: > Parent snapshot: > | dir258/ (ino 258, gen 27) > | dir257/ (ino 257, gen 27) > | dir259/ (ino 259, gen 27) > > Send snapshot: > |

Re: [PATCH 5/5] Btrfs: incremental send, add gen check if has waiting_dir_move in the will_overwrite_ref

On Wed, Oct 12, 2016 at 9:12 AM, robbieko wrote: > From: Robbie Ko > > There a some case similar as before. As before what? Each change log should be complete and the reader is not supposed to guess what's the previous patch or commit this is

Re: [PATCH] btrfs: fix silent data corruption while reading compressed inline extents

On Wed, Oct 12, 2016 at 3:28 AM, Zygo Blaxell wrote: > rsync -S causes a large number of small writes separated by small seeks > to form sparse holes in files that contain runs of zero bytes. Rarely, > this can lead btrfs to write a file with a compressed inline

Re: [PATCH 2/5] Btrfs: incremental send, add gen for is_waiting_for_rm when some corner case

On Wed, Oct 12, 2016 at 9:12 AM, robbieko wrote: > From: Robbie Ko > > There a one case for old_gen waiting_for_rm, > but new_gen use get_cur_path with the same inode. > > Example: > Parent snapshot: > | dir258/ (ino 258, dir) >

Re: [PATCH] Btrfs: fix enospc in punch hole

ng a new one), a new node might be added to each level of the tree (since there's a new key and every parent node was full). Having detailed and well written change logs is important... Thanks > > Thanks. > robbieko > > Filipe Manana 於 2016-10-07 18:18 寫到: > >> On Fri, Oct

Re: [PATCH 3/5] Btrfs: incremental send, add gen in waiting_dir_move for some corner case

On Wed, Oct 12, 2016 at 9:12 AM, robbieko wrote: > From: Robbie Ko > > There a some case similar as before. As before what? Each change log should be complete and the reader is not supposed to guess what's the previous patch or commit this is

Re: [PATCH] Btrfs: fix fsync deadlock in log_new_dir_dentries

I am sorry, I express not clear enough. >>> This number is pid, and the above are their call trace respectively. >> >> >> And why did you replace the continue statement with a break statement? >> >> Also please avoid mixing inline replies with top posting,

Re: [PATCH 1/5] Btrfs: incremental send, fix don't skip root inode in overwrite_ref

On Wed, Oct 12, 2016 at 9:12 AM, robbieko wrote: > From: Robbie Ko > > When root dir item change, don't skip will_overwrite_ref, > because root inode always exist. What do you mean by root dir item change? You mean indoe 256 changed, how did it

Re: [PATCH 4/5] Btrfs: incremental send, add gen check in did_overwrite_ref

On Wed, Oct 12, 2016 at 9:12 AM, robbieko wrote: > From: Robbie Ko > > There a some case similar as before. As before what? Each change log should be complete and the reader is not supposed to guess what's the previous patch or commit this is

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On Thu, Oct 13, 2016 at 1:37 AM, Liu Bo <bo.li@oracle.com> wrote: > On Wed, Oct 12, 2016 at 10:23:52PM +0100, Filipe Manana wrote: >> On Tue, Sep 6, 2016 at 10:51 PM, Liu Bo <bo.li@oracle.com> wrote: >> > Hi Filipe, >> > >> > On Mon, Sep 0

Re: [PATCH 1/4] btrfs: add test for an incremental send don't skip overwrite ref for inode 256

sh > +# FS QA Test No. btrfs/131 > +# > +# Test that an incremental send operation does not skip inode 256 check > +# overwrite ref, because inode 256 always exist. > +# > +#------- > +# Copyright (C) 20

Re: [PATCH 0/4] Btrfs: add serval test case for incremental send

On Thu, Oct 13, 2016 at 12:04 PM, robbieko wrote: > From: Robbie Ko > > Patch for test btrfs incremental send. > > Robbie Ko (4): > btrfs: add test for an incremental send don't skip overwrite ref for > inode 256 > btrfs: add test for an

Re: resend: Re: Btrfs: adjust len of writes if following a preallocated extent

On Fri, Dec 2, 2016 at 1:41 AM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Nov 24, 2016 at 11:13:37AM +0000, Filipe Manana wrote: >> On Wed, Nov 23, 2016 at 9:22 PM, Liu Bo <bo.li@oracle.com> wrote: >> > Hi, >> > >> > On Wed, Nov 23, 2016 a

Re: [PATCH] Btrfs: fix fsync deadlock in log_new_dir_dentries

On Fri, Oct 28, 2016 at 3:48 AM, robbieko wrote: > From: Robbie Ko > > We found a fsync deadlock in log_new_dir_dentries, because > btrfs_search_forward get path lock, then call btrfs_iget will > get another extent_buffer lock, maybe occur deadlock.

Re: [PATCH] Btrfs: fix infinite loop when tree log recovery

On Fri, Oct 7, 2016 at 10:30 AM, robbieko wrote: > From: Robbie Ko > > if log tree like below: > leaf N: > ... > item 240 key (282 DIR_LOG_ITEM 0) itemoff 8189 itemsize 8 > dir log end 1275809046 > leaf N+1: >

Re: [PATCH v2] Btrfs: fix enospc in hole punching

On Fri, Oct 28, 2016 at 3:32 AM, robbieko wrote: > From: Robbie Ko > > The hole punching can result in adding new leafs (and as a consequence > new nodes) to the tree because when we find file extent items that span > beyond the hole range we may end

Re: [PATCH] fstests: btrfs, add missing umount for raid5 tests 124 and 125

; +sleep 40 # give it a few seconds to actually die... That might work for that test, but certainly not for btrfs/12[45] as mentioned above. Besides, that's a terrible solution. What guarantees you have that 40 seconds is enough for everyone... thanks > > # succ

Re: [PATCH] Btrfs: fix lockdep warning about log_mutex

arning. > > Fix this by using mutex_lock_nested() when processing the other inode's > log_mutex. > > Signed-off-by: Liu Bo <bo.li....@oracle.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Thanks, it works and it's simple. > --- > fs/btrfs/tree-log.c | 12 ++

Re: [PATCH] Btrfs: fix infinite loop when tree log recovery

ed by fsync when logging directory entries > Btrfs: fix enospc in hole punching > So what's the next step ? > modify patch change log and then send again ? You don't need to do anything else for those patches. Thanks. > > Thanks. > robbieko > > Filipe Manana 於 2016-12-0

Re: [PATCH] Btrfs: adjust outstanding_extents counter properly when dio write is split

On Fri, Dec 23, 2016 at 1:13 AM, Liu Bo wrote: > Currently how btrfs dio deals with split dio write is not good > enough if dio write is split into several segments due to the > lack of contiguous space, a large dio write like 'dd bs=1G count=1' > can end up with incorrect

Re: [PATCH] Btrfs: Fix deadlock between direct IO and fast fsync

trfs=147998603528213=2 I was on vacations and waiting for Josef's feedback as well (cc'ed but never replied) before making a change log and formalizing the proposed patch in that thread. >From my point of view, it's ok and you can have: Reviewed-by: Filipe Manana <fdman...@suse.com> thanks

Re: [PATCH v3 2/4] xfstests: btrfs/132: add test for invaild update time by an incremental send

On Wed, Jan 4, 2017 at 10:53 AM, robbieko wrote: > From: Robbie Ko > > Test that an incremental send operation dosen't' work because > it tries to update the time to a deleted directory after it finishes > a move operation. > > The other one is that

Re: [PATCH v3 4/4] xfstests: btrfs/134: add test for incremental send which renames a directory already being deleted

On Wed, Jan 4, 2017 at 10:53 AM, robbieko wrote: > From: Robbie Ko > > Test that an incremental send operation dosen't work because dosen't -> doesn't > it tries to rename a directory which is already deleted. > > This test exercises scenarios used

Re: [PATCH v3 4/4] xfstests: btrfs/134: add test for incremental send which renames a directory already being deleted

On Thu, Jan 5, 2017 at 5:22 AM, robbieko <robbi...@synology.com> wrote: > Filipe Manana 於 2017-01-04 21:07 寫到: > >> On Wed, Jan 4, 2017 at 10:53 AM, robbieko <robbi...@synology.com> wrote: >>> >>> From: Robbie Ko <robbi...@synology.com> >>>

Re: [PATCH v3 2/4] xfstests: btrfs/132: add test for invaild update time by an incremental send

On Thu, Jan 5, 2017 at 2:45 AM, robbieko <robbi...@synology.com> wrote: > Filipe Manana 於 2017-01-04 21:09 寫到: > >> On Wed, Jan 4, 2017 at 10:53 AM, robbieko <robbi...@synology.com> wrote: >>> >>> From: Robbie Ko <robbi...@synology.com> >>>

Re: [PATCH] fstests: add test for btrfs send/receive with sparse files

On Tue, Mar 21, 2017 at 6:50 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > Hi Filipe, > > At 02/15/2017 04:35 AM, fdman...@kernel.org wrote: >> >> From: Filipe Manana <fdman...@suse.com> >> >> Test that both a full and incremental btrfs send ope

Re: [PATCH] fstests: regression test for btrfs dio read repair

On Wed, Apr 12, 2017 at 2:27 AM, Liu Bo wrote: > This case tests whether dio read can repair the bad copy if we have > a good copy. Regardless of being a test we should have always had (thanks for this!), it would be useful to mention we had a regression (as the test

Re: [PATCH] fstests: regression test for btrfs buffered read's repair

On Wed, Apr 12, 2017 at 2:27 AM, Liu Bo wrote: > This case tests whether buffered read can repair the bad copy if we > have a good copy. Regardless of being a test we should have always had (thanks for this!), it would be useful to mention we had a regression (as the test

Re: [PATCH 1/3] common/rc: test that xfs_io's falloc command supports specific flags

On Thu, Apr 6, 2017 at 3:18 PM, Eryu Guan <eg...@redhat.com> wrote: > On Tue, Apr 04, 2017 at 07:34:29AM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> For example NFS 4.2 supports fallocate but it does not support its >> K

Re: [PATCH v3] fstests: btrfs: Check if btrfs will create inline-then-regular file extents

whitespace issues > Use fsync instead of sync > Use $XFS_IO_PROG instead of calling xfs_io directly > Always output corruption possibility into seqres.full > > v3: > All suggested by Filipe Manana > Fix gra

Re: [PATCH] btrfs: add missing memset while reading compressed inline extents

On Wed, Mar 22, 2017 at 2:37 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 03/09/2017 10:05 AM, Zygo Blaxell wrote: >> >> On Wed, Mar 08, 2017 at 10:27:33AM +, Filipe Manana wrote: >>> >>> On Wed, Mar 8, 2017 at 3:18 AM, Zygo Blax

Re: [PATCH 1/3] common/rc: test that xfs_io's falloc command supports specific flags

On Fri, Apr 7, 2017 at 9:51 AM, Eryu Guan <eg...@redhat.com> wrote: > On Tue, Apr 04, 2017 at 07:34:29AM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> For example NFS 4.2 supports fallocate but it does not support its >> K

<    1   2   3   4   5   6   7   8   >