Ceph » CephFS

@Patrick, I have several discussion points wrt the approach

1. Should we add more clients and/or more mountpoints to the workloads? This would affect all running tasks and may have a non-linear impact on the test runtime
2. Since this is not a functional test of the quiesce feature, should we just issue a quiesce of the fs root? If that is the case, we could cope with a background script config
3. Having a separate snapshot workload, we could have that perform the snapshot for us while we are doing background quiesces.

Leonid Usov wrote:

@Patrick, I have several discussion points wrt the approach

1. Should we add more clients and/or more mountpoints to the workloads? This would affect all running tasks and may have a non-linear impact on the test runtime

Not at this time. Make the thrasher capable of handling multiple subvolumes (probably a list as part of its task config, i.e. yaml).

2. Since this is not a functional test of the quiesce feature, should we just issue a quiesce of the fs root?

I want us to exercise the `ceph fs subvolume quiesce` interface as well.

If that is the case, we could cope with a background script config

Didn't understand this question.

3. Having a separate snapshot workload, we could have that perform the snapshot for us while we are doing background quiesces.

I think having the snapshot part of the quiesce thrasher makes sense. It's not a big lift.

If that is the case, we could cope with a background script config

Didn't understand this question.

I meant that if we could suffice with a simple periodic quiesce to the root, then we didn't even need a dedicated trasher script, just a yaml config file with the shell loop that issues the quiesce and sleeps for some time.
This approach will cover multiple subvolumes since it would be quiescing root

then we didn't even need a dedicated trasher script, just a yaml config file with the shell loop that issues the quiesce and sleeps for some time.

disregarding the way it'll be implemented, I would like to focus on the suggestion to quiesce the root. I appreciate that we'd like to test the quiesce subvolume commands, but I don't think this is the main goal of this background trasher. I think that the main goal is to see how different workloads respond to quiesces, and for that we don't need to do anything else but just quiescing everything periodically.

As for the quiesce subvolume, we should have dedicated functional tests that focus on those aspects, creating multiple clients, mountpoints etc.

Leonid Usov wrote:

If that is the case, we could cope with a background script config

Didn't understand this question.

I meant that if we could suffice with a simple periodic quiesce to the root, then we didn't even need a dedicated trasher script, just a yaml config file with the shell loop that issues the quiesce and sleeps for some time.
This approach will cover multiple subvolumes since it would be quiescing root

But then there's no verification. The quiesce thrasher gives us the opportunity to do e2e testing and verification.

We shouldn't overload. The background quiesce is an important test, but it is not functional e2e testing. For that we need a separate dedicated suite, like the one you have in functional for the quiesce path. In that dedicated suite we'll have more control over the number of clients, mount points, subvolumes etc.

Here I will use the quiesce database to install the pause so it will be an e2e test in that regard. However, the type of workloads we're running gives us very little control over advanced quiesce scenarios. There are just 2 mount points, 1 for fuse and 1 for kmount, and just two subvolumes one per each mount. Changing that for the sake of quiesce doesn't make sense, since the workloads are very different and aren't that flexible.