@@ -1024,15 +1024,41 @@ Note that the commands above are all non-blocking. If we want to wait for the qu
10241024to reach the `QUIESCED ` state, we should await it at some point. ``--await `` can be given
10251025along with other arguments to let the system know our intention.
10261026
1027- Technically, there are two types of await: `quiesce await ` and `release await `. The former
1028- is the default, and the latter can only be achieved with ``--release `` present in the argument list.
1029- To avoid confision, it is not permitted to issue a `quiesce await ` when the set is already `RELEASING `
1030- or `RELEASED `. Trying to ``--release `` a set that is not `QUIESCED ` is an ``EPERM `` error as well, regardless
1031- of whether await is requested alongside. However, it's not an error to `release await `
1032- an already released set, or to `quiesce await ` a `QUIESCED ` one.
1033-
1034- When awaiting, one may also specify a maximum duration that they would like this await request to block for,
1035- not affecting the two intrinsic timeouts discussed above. If the target awaited state isn't reached
1027+ There are two types of await: `quiesce await ` and `release await `. The former is the default,
1028+ and the latter can only be achieved with ``--release `` present in the argument list.
1029+ To avoid confision, it is not permitted to issue a `quiesce await ` when the set is not `QUIESCING `.
1030+ Trying to ``--release `` a set that is not `QUIESCED ` is an ``EPERM `` error as well, regardless
1031+ of whether await is requested alongside. However, it's not an error to `release await `
1032+ an already released set, or to `quiesce await ` a `QUIESCED ` one - those are successful no-ops.
1033+
1034+ Since a set is awaited after the application of the ``--await ``-augmented command, the await operation
1035+ may mask a successful result with its own error. A good example is trying to cancel-await a set:
1036+
1037+ .. prompt :: bash $ auto
1038+
1039+ $ ceph fs quiesce fs1 --set-id set1 --cancel --await
1040+ {
1041+ // ...
1042+ "sets": {
1043+ "set1": {
1044+ // ...
1045+ "state": {
1046+ "name": "CANCELED",
1047+ "age": 0
1048+ },
1049+ // ...
1050+ }
1051+ }
1052+ }
1053+ Error EPERM:
1054+
1055+ Although ``--cancel `` will succeed syncrhonously for a set in an active state, awaiting a canceled
1056+ set is not permitted, hence this call will result in an ``EPERM ``. This is deliberately different from
1057+ returning a ``EINVAL `` error, denoting an error on the user's side, to simplify the system's behavior
1058+ when ``--await `` is requested. As a result, it's also a simpler model for the user to work with.
1059+
1060+ When awaiting, one may specify a maximum duration that they would like this await request to block for,
1061+ orthogonally to the two intrinsic set timeouts discussed above. If the target awaited state isn't reached
10361062within the specified duration, then ``EINPROGRESS `` is returned. For that, one should use the argument
10371063``--await-for=<seconds> ``. One could think of ``--await `` as equivalent to ``--await-for=Infinity ``.
10381064While it doesn't make sense to specify both arguments, it is not considered an error. If
0 commit comments