Establish a way to get definitive pool-level metadata

[mulkieran]

D-Bus alternative:

On the D-Bus this should be a method on the pool interface. It should not be a D-Bus property, as getting the data would require reading from some device(s) in the pool. Note also that on some devices the pool-level metadata might be older. We can call this method GetMetadata. This method selects the winning metadata in the same way as is done during pool setup, which means it checks the timestamp on the BDA and then selects a device that has the winning time from which to read the pool-level metadata. It should be possible to reuse much of the functionality for this from the pool setup code. setup::get_metadata is an obvious candidate. This would require taking a lock on the pool.

Since this information would be useful, on the CLI side it can be returned via an addition to the stratis pool debug subcommand.

Command-line alternative:

Do this via, for example, an extension to stratis-dumpmetadata. In the proposed extension, stratis-dumpmetadata will take multiple devices as arguments. It will read the pool-level metadata from each device and resolve to a single canonical version of the pool-level metadata.

Which is better?

The command-line alternative can work even when the pool is not setup. However, the D-Bus alternative will work with encrypted pools under the current metadata scheme, while the command-line version can not. The command-line version however can be used while stratisd is running and when an encrypted pool is set up, in which case it could read the metadata off the opened devices. The D-Bus tool is easier for a user to make use of assuming they are happy using stratis-cli. Since stratisd locks the pool when reading the devices, there is no problem with inconsistency when using the D-Bus alternative, but there might be with the command-line alternative.

Why do this?

Useful for debugging, testing, and monitoring. At present, stratisd reads the metadata during setup, but once a pool is set up, the metadata is only written by stratisd, never read.

[mulkieran]

No objections registered.

[mulkieran]

This idea has been simplified to "return the metadata that the pool would write now". The principle motivation for this is that, while this should never happen, the pool could have metadata increase in size for some pathological reason so that the metadata could not be written to the devices. In that case, it may be valuable to obtain the pool-level metadata that would be written if there was space to write it.

But then I added back in the ability to read the pool-level metadata from the devices, also. The distinction made is "current" metadata, whatever would be written now, and "last", i.e., most recently written metadata.

[mulkieran]

We can consider this done, we took the via stratisd approach. If we decide to supplement with a command-line tool that reads pool metadata directly, we can file a separate issue for that.