snapshot request to controller service is not guarantee consistency

[hoyho]

In current design, when a user request to create a snapshot in kubernetes cluster, the volume data is not guarantee consistency.
consider following step:

1. Create PVC and Pod and assume volume mounted and being use (more specifically , we can assume the volume format as xfs)
2. Do some IO operation inside the pod with the volume：

3. create a snapshot
4. external-snapshotter sidecar is listening the CR and then call CSI driver to create a snapshots via storage backend.
5. However, If the CSI driver or storage backend create snapshots right now, there's some data cache need to sync to backend, or they may be still in pagecache and causes data lost. (That means snapshots required the user to call echo 3 > /proc/sys/vm/drop_caches or fsync or something before the snapshots, which may not sound as a real "snapshots").

snap result without sync IO：

6. gRPC call to controllerServer is unlike call to nodeServer. It is not possible to sync IO IMO.

If there's any solution to promise that?

[xing-yang]

The underlying Storage System will need to ensure it is crash consistent.

[hoyho]

That's not easy to make sure that from storage side.
At least I see someone have face the problem too ceph/ceph-csi#1532
Do you think is it possible to introduce a new interface to NodeServer in CSI spec?

[xing-yang]

There was a proposal about this a while back in the CSI spec:
container-storage-interface/spec#407
We still have not reached consensus on going forward with it yet.

We are working on adding a pod inline definition to do the quiesce. See here: kubernetes/enhancements#1995

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.