Fix out-of-order ZIL txtype lost on hardlinked files #9061
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
behlendorf
reviewed
Jul 18, 2019
There was a problem hiding this comment.
Nice job running this down, the proposed fix makes good sense. This looks like a potentially very long standing bug. As part of this change we're going to want to update the slog/slog_replay_fs.ksh test to cover this case. In the original issue you mentioned running in to an issue with zpool freeze, is that still the case?
|
I tried today on master but didn't hit any issue with zpool freeze. It
could be something was wrong on my side.
I'll look into it changing the test case.
…On Thu, Jul 18, 2019, 3:03 PM Brian Behlendorf ***@***.***> wrote:
***@***.**** commented on this pull request.
Nice job running this down, the proposed fix makes good sense. This looks
like a potentially very long standing bug. As part of this change we're
going to want to update the slog/slog_replay_fs.ksh test to cover this
case. In the original issue you mentioned running in to an issue with zpool
freeze, is that still the case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9061>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA5G6AQJNOLR4PMEDVRQA3QADSEVANCNFSM4IE7DR5A>
.
|
Actually, let me take that back. I hit it after another try... |
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Closes openzfs#8769 Signed-off-by: Chunwei Chen <david.chen@nutanix.com>
|
The repro in #8769 seems to be pretty reliable if you do it with zpool freeze, and it only happen on second time. However, I have never hit it with "echo b > /proc/sysrq-trigger". So I think this is probably a separate issue in zpool freeze. Unless they also did zpool freeze on their pool. |
Codecov Report
@@ Coverage Diff @@
## master #9061 +/- ##
==========================================
+ Coverage 78.67% 78.74% +0.07%
==========================================
Files 400 400
Lines 121009 120993 -16
==========================================
+ Hits 95199 95276 +77
+ Misses 25810 25717 -93
Continue to review full report at Codecov.
|
I'm not sure what you mean by the 'second time' here. Do you mean running it twice using the same pool? |
|
Yes. Do zpool freeze, run script, export and import. Then do zpool freeze,
run script, export and import. And it will hit assert.
…On Fri, Jul 26, 2019, 6:05 PM Brian Behlendorf ***@***.***> wrote:
The repro in #8769 <#8769> seems
to be pretty reliable if you do it with zpool freeze, and it only happen on
second time.
I'm not sure what you mean by the 'second time' here. Do you mean running
it twice using the same pool?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9061>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA5G6HKPCCRJJK3VGY2WNDQBONNDANCNFSM4IE7DR5A>
.
|
grwilson
approved these changes
Aug 13, 2019
behlendorf
approved these changes
Aug 13, 2019
behlendorf
added
Status: Accepted
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Aug 21, 2019
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Chunwei Chen <david.chen@nutanix.com> Closes openzfs#8769 Closes openzfs#9061
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Aug 22, 2019
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Chunwei Chen <david.chen@nutanix.com> Closes openzfs#8769 Closes openzfs#9061
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Aug 23, 2019
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Chunwei Chen <david.chen@nutanix.com> Closes openzfs#8769 Closes openzfs#9061
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Sep 17, 2019
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Chunwei Chen <david.chen@nutanix.com> Closes openzfs#8769 Closes openzfs#9061
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Sep 18, 2019
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Chunwei Chen <david.chen@nutanix.com> Closes openzfs#8769 Closes openzfs#9061
tonyhutter
pushed a commit
to tonyhutter/zfs
that referenced
this pull request
Sep 23, 2019
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Chunwei Chen <david.chen@nutanix.com> Closes openzfs#8769 Closes openzfs#9061
tonyhutter
pushed a commit
that referenced
this pull request
Sep 26, 2019
We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Prakash Surya <prakash.surya@delphix.com> Signed-off-by: Chunwei Chen <david.chen@nutanix.com> Closes #8769 Closes #9061
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We should only call zil_remove_async when an object is removed. However,
in current implementation, it is called whenever TX_REMOVE is called. In
the case of hardlinked file, every unlink will generate TX_REMOVE and
causing operations to be dropped even when the object is not removed.
We fix this by only calling zil_remove_async when the file is fully
unlinked.
Motivation and Context
#8769
Description
How Has This Been Tested?
Tested with the repro in #8769
Types of changes
Checklist:
Signed-off-by.