Re: [PATCH 3/3] btrfs-progs: convert-test: trigger chunk allocation after convert

At 12/14/2016 07:51 AM, Tsutomu Itoh wrote: On 2016/12/13 18:44, Qu Wenruo wrote: Populate fs after convert so we can trigger data chunk allocation. This can expose too restrict old rollback condition Reported-by: Chandan Rajendra Signed-off-by: Qu Wenruo

Re: [PATCH 3/3] btrfs-progs: convert-test: trigger chunk allocation after convert

On 2016/12/13 18:44, Qu Wenruo wrote: > Populate fs after convert so we can trigger data chunk allocation. > This can expose too restrict old rollback condition > > Reported-by: Chandan Rajendra > Signed-off-by: Qu Wenruo > --- >

[PATCH v2] Btrfs: fix lockdep warning about log_mutex

While checking INODE_REF/INODE_EXTREF for a corner case, we may acquire a different inode's log_mutex with holding the current inode's log_mutex, and lockdep has complained this with a possilble deadlock warning. Fix this by using mutex_lock_nested() when processing the other inode's log_mutex.

[PATCH v2] Btrfs: use down_read_nested to make lockdep silent

If @block_group is not @used_bg, it'll try to get @used_bg's lock without droping @block_group 's lock and lockdep has throwed a scary deadlock warning about it. Fix it by using down_read_nested. Signed-off-by: Liu Bo --- v2: Use 'SINGLE_DEPTH_NESTING' to avoid magic

[PATCH v2] Btrfs: add 'inode' for extent map tracepoint

'inode' is an important field for btrfs_get_extent, lets trace it. Signed-off-by: Liu Bo --- v2: add 'unsigned long long' for consistence. fs/btrfs/inode.c | 2 +- include/trace/events/btrfs.h | 12 2 files changed, 9 insertions(+), 5

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

Hi, unfortunately I did not dump meminfo before the crash. Here is the actual meminfo as of now with the copy running for about 3 hours. MemTotal: 32806572 kB MemFree: 197336 kB MemAvailable: 31226888 kB Buffers: 52 kB Cached: 30603160 kB SwapCached:

[PATCH] Btrfs: fix comment in btrfs_page_mkwrite

The comment about "page_mkwrite gets called every time the page is dirtied" in btrfs_page_mkwrite is not correct, it only gets called the first time the page gets dirtied after the page faults in. However, we don't need to touch the code because it works well, although the proper logic is to

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

Hi David, It has GFP_NOFS flags, according to definition, the issue might have happened during initial DISK/IO. By the way, did you get a chance to dump the meminfo and run "top" before the system hang? It seems more info about the system running state needed to know the issue. Thanks. Xin  

[PATCH] btrfs: drop unused extent_op arg from btrfs_add_delayed_data_ref

btrfs_add_delayed_data_ref is always called with a NULL extent_op, so let's drop the argument. Signed-off-by: Jeff Mahoney --- fs/btrfs/delayed-ref.c | 6 ++ fs/btrfs/delayed-ref.h | 3 +-- fs/btrfs/extent-tree.c | 7 +++ 3 files changed, 6 insertions(+), 10 deletions(-)

[PATCH] btrfs: fix error handling when run_delayed_extent_op fails

In __btrfs_run_delayed_refs, the error path when run_delayed_extent_op fails sets locked_ref->processing = 0 but doesn't re-increment delayed_refs->num_heads_ready. As a result, we can end up triggering the WARN_ON in btrfs_select_ref_head since the head remains in the tree with ->processing = 0

Re: [PATCH] btrfs: limit async_work allocation and worker func duration

On 12/12/2016 03:35 PM, Maxim Patlasov wrote: On 12/12/2016 06:54 AM, David Sterba wrote: As far as we don't have any NO_THRESHOLD users of btrfs_workqueue_normal_congested for now, I tend to think it's better to add a descriptive comment and simply return "false" from

page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

Hi, I receive the following page allocation stall while copying lots of large files from one btrfs hdd to another. Dec 13 13:04:29 server kernel: kworker/u16:8: page allocation stalls for 12260ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL) Dec 13 13:04:29 server kernel: CPU: 0 PID: 24959

Re: [PATCH] Btrfs: Coding style fixes

On Mon, Dec 12, 2016 at 07:28:46PM +0100, Seraphime Kirkovski wrote: > On Mon, Dec 12, 2016 at 05:11:56PM +0100, David Sterba wrote: > > This type of change is more like a cleanup and you can find more > > instances where the type is applied to just one of the operands, while > > min_t/max_t would

Re: [PATCH 2/2] btrfs: qgroup: Fix qgroup reserved space underflow by only freeing reserved ranges

On Friday, December 02, 2016 10:03:07 AM Qu Wenruo wrote: > [BUG] > For the following case, btrfs can underflow qgroup reserved space > at error path: > (Page size 4K, function name without "btrfs_" prefix) > > Task A | Task B >

Re: [PATCH 1/2] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

On Friday, December 02, 2016 10:03:06 AM Qu Wenruo wrote: > Introduce a new parameter, struct extent_changeset for > btrfs_qgroup_reserved_data() and its callers. > > Such extent_changeset was used in btrfs_qgroup_reserve_data() to record > which range it reserved in current reserve, so it can

btrfs check --repair question

Hi. I had two cases of 'ref mismatch on extents ..', like you. Any attempt at recovery has much worsened the problem. I suggest you save importanto data and delete and recreate the partition. I always have a partition for re-install from scratch, so that I can recover data from damaged

[PATCH 1/3] btrfs-progs: file-item: Fix wrong file extents inserted

If we specify NO_HOLES incompat feature when converting, the result image still uses hole file extents. And further more, the hole is incorrect as its disk_num_bytes is not zero. The problem is at btrfs_insert_file_extent() which doesn't check if we are going to insert hole file extent. Modify

[PATCH 3/3] btrfs-progs: convert-test: trigger chunk allocation after convert

Populate fs after convert so we can trigger data chunk allocation. This can expose too restrict old rollback condition Reported-by: Chandan Rajendra Signed-off-by: Qu Wenruo --- tests/common | 4 tests/common.convert | 3 +++ 2

[PATCH 2/3] btrfs-progs: convert: Rework rollback to handle new convert image

Although commit 9c4b820412746b3 tried to make the rollback condition less restrict, to co-operate with new rollback behavior, it's still too restrict. If btrfs allocates a new data chunk, it's highly possible that the new chunk will not be 1:1 mapped anymore. And this makes old rollback check

[PATCH 0/3] Convert rollback rework and test enhancement

Current convert rollback condition is too restrict for new convert behavior, and has several problems. 1) Can't rollback new convert image with new data chunk Chunk level check can't handle newly allocated data chunk, which is not 1:1 mapped but completely valid in new behavior. The last patch