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

feat(readonly): Adding test cases for uzfs zvol readonly support #288

Merged
merged 5 commits into from
Feb 3, 2020

Conversation

mynktl
Copy link
Member

@mynktl mynktl commented Jan 31, 2020

changes:

  • Adding support to make uzfs zvol readonly
    To set zvol readonly:
zfs  set io.openebs:readonly=on testp/testv

To unset zvol readonly:

zfs  set io.openebs:readonly=off testp/vol1

Test cases added for following scenarios:

  • If zvol is set readonly then zrepl shouldn't scan this zvol to make connection with target
  • if zvol was already connected while setting readonly mode then write/snapshot{prepare/create} will fail, but read will be allowed.

Fixes: openebs/openebs#2937
Signed-off-by: mayank mayank.patel@mayadata.io

Signed-off-by: mayank <mayank.patel@mayadata.io>
@mynktl
Copy link
Member Author

mynktl commented Jan 31, 2020

depends on openebs-archive/libcstor#41

error = zfs_set_targetip_prehook(zc->zc_name, source, targetip,
&curtargetip[0]);
} else {
error = uzfs_zfs_set_prop(zc->zc_name, source, nvl);

Choose a reason for hiding this comment

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

any errors in zfs_set_prop_nvlist needs reverting the changes done here.. instead, this can be called if no errors after performing zfs_set_prop_nvlist..

Choose a reason for hiding this comment

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

lets make the fn name as 'uzfs_zinfo_set_prop' as this performs setting few flags on zinfo as well in case of readonly flag..

Choose a reason for hiding this comment

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

calling function that can set all properties will make those variables get set in zinfo / zv.. for ex., zvol_workers will be set in zv, but, it won't get impacted until zrepl restarts..
So, instead of calling function saying uzfs_zinfo_set_prop, how about setting only for uzfs_zinfo_set_readonly if prop is READONLY

Copy link
Member Author

Choose a reason for hiding this comment

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

done

vishnuitta
vishnuitta previously approved these changes Feb 3, 2020
Copy link

@vishnuitta vishnuitta left a comment

Choose a reason for hiding this comment

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

changes are good

@@ -359,6 +359,8 @@ zfs_prop_init(void)
PROP_DEFAULT, ZFS_TYPE_VOLUME, "<zvol worker>", "NWORKER");
zprop_register_string(ZFS_PROP_REPLICA_ID, "io.openebs:zvol_replica_id",
"", PROP_DEFAULT, ZFS_TYPE_VOLUME, "<replica id>", "REPLICA_ID");
zprop_register_string(ZFS_PROP_ZVOL_READONLY, "io.openebs:readonly", "",
Copy link
Member

Choose a reason for hiding this comment

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

@vishnuitta @mynktl , io.openebs:readonly does not convey it's meaning, also it conflicts with the existing readony property. Can we rename it to io.openebs:suspend (or some better name)?

Copy link
Member Author

Choose a reason for hiding this comment

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

both property have the same functionality but at different layer. To differentiate this i thought of giving a different name. One more point, this is completely limited to cstor API layer only, so better to group it with organization.

error = zfs_set_targetip_prehook(zc->zc_name, source, targetip,
&curtargetip[0]);
} else if (error == 0 && nvlist_lookup_string(nvl,
Copy link
Member

Choose a reason for hiding this comment

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

lets allow setting both (targetip and readonly) at once if we want to?

Copy link
Member Author

@mynktl mynktl Feb 3, 2020

Choose a reason for hiding this comment

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

we can do that, but that will complicate creation part i think from control plane, need to check. We can plan this in next release.

Choose a reason for hiding this comment

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

what is the problem if we remove 'else' which allows both the settings?

pawanpraka1
pawanpraka1 previously approved these changes Feb 3, 2020
Copy link
Member

@pawanpraka1 pawanpraka1 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.

few minor comments.

Signed-off-by: mayank <mayank.patel@mayadata.io>
@mynktl mynktl dismissed stale reviews from pawanpraka1 and vishnuitta via 2b37d0c February 3, 2020 15:24
Copy link

@vishnuitta vishnuitta left a comment

Choose a reason for hiding this comment

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

changes are good

@vishnuitta vishnuitta merged commit 8142588 into mayadata-io:develop Feb 3, 2020
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.

cstor-pool process crashes in loop due to pool being full
3 participants