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

Initialize mmp_last_write when the mmp thread starts #10873

Merged
merged 1 commit into from
Sep 9, 2020
Merged

Initialize mmp_last_write when the mmp thread starts #10873

merged 1 commit into from
Sep 9, 2020

Conversation

ofaaland
Copy link
Contributor

@ofaaland ofaaland commented Sep 3, 2020 •
edited
Loading

Motivation and Context

A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O. If this time is too long,

(gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts. If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be see in issue #10838

Description

The value of mmp_last_write doesn't matter before the mmp thread
starts. To give the MMP thread time to issue MMP writes and have them
land, initialize mmp_last_write just before the MMP thread starts.

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (a change to man pages or other documentation)

Checklist:

  • My code follows the ZFS on Linux code style requirements.
  • I have updated the documentation accordingly.
  • I have read the contributing document.
  • I have added tests to cover my changes.
  • I have run the ZFS Test Suite with this change applied.
  • All commit messages are properly formatted and contain Signed-off-by.

@ofaaland ofaaland added the Status: Code Review Needed Ready for review and testing label Sep 3, 2020
@ofaaland ofaaland mentioned this pull request Sep 3, 2020
Closed
behlendorf
behlendorf approved these changes Sep 3, 2020
View reviewed changes
Copy link
Contributor

@behlendorf behlendorf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks for running down this corner case!

@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Sep 4, 2020
@ofaaland
Initialize mmp_last_write when the mmp thread starts
a77e681 
A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O checking configs etc.  If this time is too long,

    (gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts.  If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be seen in issue openzfs#10838

The value of mmp_last_write doesn't matter before the mmp thread
starts.  To give the MMP thread time to issue and land MMP writes,
initialize mmp_last_write when the MMP thread starts.

Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
@behlendorf behlendorf merged commit a74259c into openzfs:master Sep 9, 2020
behlendorf pushed a commit that referenced this pull request Sep 9, 2020
@ofaaland @behlendorf
Initialize mmp_last_write when the mmp thread starts
55de40f 
A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O checking configs etc.  If this time is too long,

    (gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts.  If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be seen in issue #10838

The value of mmp_last_write doesn't matter before the mmp thread
starts.  To give the MMP thread time to issue and land MMP writes,
initialize mmp_last_write when the MMP thread starts.

Reviewed-by: Giuseppe Di Natale <guss80@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
Closes #10873
@ofaaland
Copy link
Contributor Author

Hi @behlendorf is there going to be a zfs-0.8.5? Can you remind me how to get this on that patch list? Thanks!

@ofaaland ofaaland deleted the b-mmp-last-write-1 branch September 10, 2020 01:05
@behlendorf
Copy link
Contributor

@ofaaland I went ahead and added this to the 0.8-release project so we can track it. We also created a zfs-0.8.5-staging branch which you can open a PR against to make sure this gets included.

ofaaland added a commit to ofaaland/zfs that referenced this pull request Sep 10, 2020
@ofaaland
Initialize mmp_last_write when the mmp thread starts
f33e3a8 
A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O checking configs etc.  If this time is too long,

    (gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts.  If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be seen in issue openzfs#10838

The value of mmp_last_write doesn't matter before the mmp thread
starts.  To give the MMP thread time to issue and land MMP writes,
initialize mmp_last_write when the MMP thread starts.

Reviewed-by: Giuseppe Di Natale <guss80@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
Closes openzfs#10873
@stuartthebruce stuartthebruce mentioned this pull request Sep 10, 2020
Closed
tonyhutter pushed a commit that referenced this pull request Sep 16, 2020
@ofaaland
Initialize mmp_last_write when the mmp thread starts (#10912)
ed4c725 
A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O checking configs etc.  If this time is too long,

    (gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts.  If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be seen in issue #10838

The value of mmp_last_write doesn't matter before the mmp thread
starts.  To give the MMP thread time to issue and land MMP writes,
initialize mmp_last_write when the MMP thread starts.

Reviewed-by: Giuseppe Di Natale <guss80@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Closes #10873
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Sep 16, 2020
@ofaaland @tonyhutter
Initialize mmp_last_write when the mmp thread starts (openzfs#10912)
0801e4e 
A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O checking configs etc.  If this time is too long,

    (gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts.  If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be seen in issue openzfs#10838

The value of mmp_last_write doesn't matter before the mmp thread
starts.  To give the MMP thread time to issue and land MMP writes,
initialize mmp_last_write when the MMP thread starts.

Reviewed-by: Giuseppe Di Natale <guss80@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Closes openzfs#10873
@homerl
Copy link

homerl commented Sep 18, 2020

Why not let zpool import return failed? The zpool suspend cause too many production environments crashes.

jsai20 pushed a commit to jsai20/zfs that referenced this pull request Mar 30, 2021
@ofaaland @jsai20
Initialize mmp_last_write when the mmp thread starts
289d136 
A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O checking configs etc.  If this time is too long,

    (gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts.  If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be seen in issue openzfs#10838

The value of mmp_last_write doesn't matter before the mmp thread
starts.  To give the MMP thread time to issue and land MMP writes,
initialize mmp_last_write when the MMP thread starts.

Reviewed-by: Giuseppe Di Natale <guss80@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
Closes openzfs#10873
sempervictus pushed a commit to sempervictus/zfs that referenced this pull request May 31, 2021
@ofaaland
Initialize mmp_last_write when the mmp thread starts
0f45192 
A great deal of time may go by between when mmp_init() is called and
the MMP thread starts, particularly if there are bad devices, because
there is I/O checking configs etc.  If this time is too long,

    (gethrtime() - mmp_last_write) > mmp_fail_ns

at the time the MMP thread starts.  If MMP is configured to suspend
the pool, the pool will be suspended immediately.

This can be seen in issue openzfs#10838

The value of mmp_last_write doesn't matter before the mmp thread
starts.  To give the MMP thread time to issue and land MMP writes,
initialize mmp_last_write when the MMP thread starts.

Reviewed-by: Giuseppe Di Natale <guss80@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
Closes openzfs#10873
@ghost ghost mentioned this pull request Sep 22, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@behlendorf behlendorf behlendorf approved these changes

@dinatale2 dinatale2 dinatale2 approved these changes

Assignees
No one assigned
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@ofaaland @behlendorf @homerl @dinatale2