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.

Sign up for GitHub

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

Jump to bottom

panic with changes 'Cap metaslab memory usage' #9253

Closed
ikozhukhov opened this issue Aug 29, 2019 · 0 comments
Closed

panic with changes 'Cap metaslab memory usage' #9253

ikozhukhov opened this issue Aug 29, 2019 · 0 comments

Comments

@ikozhukhov
Copy link
Contributor

commit f09fda5 introduce panic with merge to DilOS by test zpool_upgrade_002_pos.ksh

System information

Type Version/Name
Distribution Name DilOS
Distribution Version
Linux Kernel
Architecture
ZFS Version
SPL Version

Describe the problem you're observing

Describe how to reproduce the problem

Include any warning/errors/backtraces from the system logs

panic[cpu2]/thread=fffffe00110ccc20: assertion failed: txg <= spa_final_dirty_txg(spa), file: ../../common/fs/zfs/metaslab.c, line: 3568

fffffe00110cc930 genunix:process_type+19acfd ()
fffffe00110cc9e0 zfs:metaslab_sync+8a0 ()
fffffe00110cca40 zfs:vdev_sync+d3 ()
fffffe00110ccac0 zfs:spa_sync_iterate_to_convergence+16b ()
fffffe00110ccb40 zfs:spa_sync+25a ()
fffffe00110ccc00 zfs:txg_sync_thread+2b1 ()
fffffe00110ccc10 unix:thread_start+8 ()

new PR fixed it:
#9231

ztest@zfs-tests2:~$ ./z2.sh
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/setup.ksh (run as root) [00:00] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_001_pos.ksh (run as root) [00:00] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_002_pos.ksh (run as root) [01:28] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_003_pos.ksh (run as root) [00:03] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_004_pos.ksh (run as root) [01:36] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_005_neg.ksh (run as root) [00:00] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_006_neg.ksh (run as root) [00:00] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_007_pos.ksh (run as root) [00:33] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_008_pos.ksh (run as root) [07:16] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/zpool_upgrade_009_neg.ksh (run as root) [00:28] [PASS]
Test: /opt/zfs-tests/tests/functional/cli_root/zpool_upgrade/cleanup.ksh (run as root) [00:01] [PASS]

Results Summary
PASS	  11

Running Time:	00:11:29
Percent passed:	100.0%
Log directory:	/var/tmp/test_results/20190829T142524
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 24, 2019
@pcd1193182 @tonyhutter
Prevent metaslab_sync panic due to spa_final_dirty_txg
d667e5d 
If a pool enables the SPACEMAP_HISTOGRAM feature shortly before being
exported, we can enter a situation that causes a kernel panic. Any metaslabs
that are loaded during the final dirty txg and haven't already been condensed
will cause metaslab_sync to proceed after the final dirty txg so that the
condense can be performed, which there are assertions to prevent. Because of
the nature of this issue, there are a number of ways we can enter this
state. Rather than try to prevent each of them one by one, potentially missing
some edge cases, we instead cut it off at the point of intersection; by
preventing metaslab_sync from proceeding if it would only do so to perform a
condense and we're past the final dirty txg, we preserve the utility of the
existing asserts while preventing this particular issue.

Reviewed-by: Matt Ahrens <matt@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes openzfs#9185
Closes openzfs#9186
Closes openzfs#9231
Closes openzfs#9253
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 27, 2019
@pcd1193182 @tonyhutter
Prevent metaslab_sync panic due to spa_final_dirty_txg
f187167 
If a pool enables the SPACEMAP_HISTOGRAM feature shortly before being
exported, we can enter a situation that causes a kernel panic. Any metaslabs
that are loaded during the final dirty txg and haven't already been condensed
will cause metaslab_sync to proceed after the final dirty txg so that the
condense can be performed, which there are assertions to prevent. Because of
the nature of this issue, there are a number of ways we can enter this
state. Rather than try to prevent each of them one by one, potentially missing
some edge cases, we instead cut it off at the point of intersection; by
preventing metaslab_sync from proceeding if it would only do so to perform a
condense and we're past the final dirty txg, we preserve the utility of the
existing asserts while preventing this particular issue.

Reviewed-by: Matt Ahrens <matt@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes openzfs#9185
Closes openzfs#9186
Closes openzfs#9231
Closes openzfs#9253
tonyhutter pushed a commit that referenced this issue Jan 23, 2020
@pcd1193182 @tonyhutter
Prevent metaslab_sync panic due to spa_final_dirty_txg
ebdb770 
If a pool enables the SPACEMAP_HISTOGRAM feature shortly before being
exported, we can enter a situation that causes a kernel panic. Any metaslabs
that are loaded during the final dirty txg and haven't already been condensed
will cause metaslab_sync to proceed after the final dirty txg so that the
condense can be performed, which there are assertions to prevent. Because of
the nature of this issue, there are a number of ways we can enter this
state. Rather than try to prevent each of them one by one, potentially missing
some edge cases, we instead cut it off at the point of intersection; by
preventing metaslab_sync from proceeding if it would only do so to perform a
condense and we're past the final dirty txg, we preserve the utility of the
existing asserts while preventing this particular issue.

Reviewed-by: Matt Ahrens <matt@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes #9185
Closes #9186
Closes #9231
Closes #9253
allanjude pushed a commit to KlaraSystems/zfs that referenced this issue Apr 28, 2020
@pcd1193182
Prevent metaslab_sync panic due to spa_final_dirty_txg
97dd071 
If a pool enables the SPACEMAP_HISTOGRAM feature shortly before being
exported, we can enter a situation that causes a kernel panic. Any metaslabs
that are loaded during the final dirty txg and haven't already been condensed
will cause metaslab_sync to proceed after the final dirty txg so that the
condense can be performed, which there are assertions to prevent. Because of
the nature of this issue, there are a number of ways we can enter this
state. Rather than try to prevent each of them one by one, potentially missing
some edge cases, we instead cut it off at the point of intersection; by
preventing metaslab_sync from proceeding if it would only do so to perform a
condense and we're past the final dirty txg, we preserve the utility of the
existing asserts while preventing this particular issue.

Reviewed-by: Matt Ahrens <matt@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes openzfs#9185
Closes openzfs#9186
Closes openzfs#9231
Closes openzfs#9253
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ikozhukhov