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
---
tests/common | 4
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
> ---
> tests/common | 4
> tests/common.convert | 3 +++
>
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.
R
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 number.
fs/btrfs/extent-tre
'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 deletions(-)
diff --git a/fs/btrf
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:
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 check
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
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(-)
diff --git a/fs
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 a
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
btrfs_workqueue_normal_con
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 Comm
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
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
> ---
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 fre
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 fi
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 it
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 files changed, 7 insertions(+)
diff --git a/tests/com
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 fai
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 wil
20 matches
Mail list logo