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

Stop upgrade thread at the end of 'zfs recv' #5328

Merged
merged 1 commit into from
Oct 25, 2016

Conversation

jxiong
Copy link
Contributor

@jxiong jxiong commented Oct 24, 2016

'zfs recv' could disown a living objset without calling

dmu_objset_disown(). This will cause the problem that the objset

would be released while upgrading thread is still running.



This patch calls dmu_objset_upgrade_stop() in dmu_recv_end().



ZoL-bug-id: #5295



Signed-off-by: Jinshan Xiong [email protected]

@mention-bot
Copy link

@jxiong, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nedbass, @behlendorf and @ahrens to be potential reviewers.

@behlendorf
Copy link
Contributor

@jxiong thanks for looking in to this. After looking at the fix a few questions come to mind.

  1. zfs send/recv only operates on snapshots. Snapshots are immutable and thus can never be upgraded to include the quotaobj information. Given that it seems like the z_upgrade thread should be skipped them entirely so there would be no need to stop it as this patch does. We should perhaps make sure it's never started for this dataset.

  2. Once all the snapshots are received there's the question of when the new filesystems should be automatically upgraded. This will automatically happen at next mount, but it may make sense to schedule it sooner at the end of zfs recv.

There was a strange build failure for CentOS 6, I've resubmitted that build to see if it's reproducible.

@jxiong
Copy link
Contributor Author

jxiong commented Oct 25, 2016

@behlendorf it is a better solution by not triggering upgrade for snapshot, but ZFS_TYPE_SNAPSHOT is a ZPL layer information and I don't know how to access in DMU layer. What do you suggest?

  1. Once all the ... of zfs recv.

Sorry I don't quite understand this - what does 'new file systems' refer to?

@behlendorf
Copy link
Contributor

better solution by not triggering upgrade for snapshot. What do you suggest?

I was thinking either dmu_objset_is_snapshot() or dsl_dataset_is_snapshot().

what does 'new file systems' refer to?

Sorry this could have been worded better. I was just referring to the new dataset which can be mounted after receiving the snapshots. But since these will get automatically mounted anyway and thus owned that should trigger the upgrade. So I don't think we need to do anything extra. Nevermind 2) above.

'zfs recv' could disown a living objset without calling
dmu_objset_disown(). This will cause the problem that the objset
would be released while upgrading thread is still running.

This patch avoids the problem by checking if a dataset is snapshot
before calling dmu_objset_userobjspace_upgrade().

ZoL-bug-id: openzfs#5295

Signed-off-by: Jinshan Xiong <[email protected]>
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.

Thanks for the quick patch! Nice and simple.

@behlendorf behlendorf merged commit 16fa68f into openzfs:master Oct 25, 2016
@jxiong jxiong deleted the issue_5295 branch October 26, 2016 05:03
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

Successfully merging this pull request may close these issues.

3 participants