Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zfs 0.7 hangs receiving 16M block (reproducible) #7365

Closed
fling- opened this issue Mar 29, 2018 · 2 comments
Closed

zfs 0.7 hangs receiving 16M block (reproducible) #7365

fling- opened this issue Mar 29, 2018 · 2 comments

Comments

@fling-
Copy link
Contributor

fling- commented Mar 29, 2018

System information

Type Version/Name
Distribution Name gentoo
Distribution Version 17.1
Linux Kernel 4.15.3
Architecture amd64
ZFS Version 0.7.6-1
SPL Version 0.7.6-1

Describe the problem you're observing

zfs hangs receiving 16M blocks when I'm trying to migrate data between pools
Looks like I'm stuck in the middle of migration as I can't send without -L because of #6224

Describe how to reproduce the problem

Using https://gist.github.com/fling-/c66bf1e4a082b5cf9cd4d1106fe6e2bc

Include any warning/errors/backtraces from the system logs

# zfs send -LRe studio/gentoo@old-pool | mbuffer -L -m 512M | zfs recv -u new-root/gentoo
in @  0.0 KiB/s, out @  0.0 KiB/s, 2248 MiB total, buffer 100% full^C

recv hangs in D state:

952 pts/11   D+     0:03 zfs recv -u new-root/gentoo
@zrav
Copy link

zrav commented Apr 3, 2018

If it is acceptable to re-send all the data using <=128k blocks, as a workaround you could restart sending from scratch without -L. #6224 only occurs when you incrementally send small blocks with large blocks already present on the target.

behlendorf added a commit to behlendorf/zfs that referenced this issue Apr 7, 2018
When using 16MB blocks the send/recv queue's aren't quite big
enough.  This change leaves the default 16M queue size which a
good value for most pools.  But it additionally ensures that the
queue sizes are at least twice the allowed zfs_max_recordsize.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue openzfs#7365
@behlendorf
Copy link
Contributor

@fling- thank you for the excellent reproducer, that definitely helped in reproducing the issue and identify the root cause. I've opened #7404 with a proposed fix.

tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Apr 16, 2018
When using 16MB blocks the send/recv queue's aren't quite big
enough.  This change leaves the default 16M queue size which a
good value for most pools.  But it additionally ensures that the
queue sizes are at least twice the allowed zfs_max_recordsize.

Reviewed-by: loli10K <ezomori.nozomu@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#7365 
Closes openzfs#7404
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue May 4, 2018
When using 16MB blocks the send/recv queue's aren't quite big
enough.  This change leaves the default 16M queue size which a
good value for most pools.  But it additionally ensures that the
queue sizes are at least twice the allowed zfs_max_recordsize.

Reviewed-by: loli10K <ezomori.nozomu@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#7365 
Closes openzfs#7404
tonyhutter pushed a commit that referenced this issue May 10, 2018
When using 16MB blocks the send/recv queue's aren't quite big
enough.  This change leaves the default 16M queue size which a
good value for most pools.  But it additionally ensures that the
queue sizes are at least twice the allowed zfs_max_recordsize.

Reviewed-by: loli10K <ezomori.nozomu@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #7365
Closes #7404
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants