Change how BlockDevMgr::last_update_time is initialized

[GuillaumeGomez]

Fixes #1509.

@mulkieran: Is it how you had it in mind?

[stratis-bot]

Test with Jenkins?

[stratis-bot]

Test with Jenkins?

[mulkieran]

ok to test

[mulkieran]

@GuillaumeGomez Thanks for the PR! You'll note that in BlockDevMgr::initialize last_update_time is set to None.

This is more-or-less necessarily correct, because when the block devices belonging to the blockdevmgr are first claimed by stratisd, the actual value of the variable length metadata is not yet known. This metadata contains information about all sorts of higher-level devices that haven't yet been constructed.
So, the last_update_time must remain an Option.

However, at some later time, stratisd may come up again, and see devices that have already been initialized, and construct a blockdevmgr to manage them. Currently, it, incorrectly, constructs the blockdevmgr with a last_update_time value of None. It should, instead, find out the last update time from the existing metadata on the devices which it has been given.

I think that the area where the crucial mistake is made is really where StratPool::setup calls Backstore::setup with a last_update_time value of None. That can't always be right.

I would encourage you to look at the method get_metadata. This method is looking for the most recent variable length metadata written to all the devices. Unfortunately, having found the most recent value, it only return the metadata, and not the update time. If it can be expanded to return both values, then the value is available to StratPool::setup.

I'm afraid that the solution is less localized than I thought, but I think that that is the right place to start.

[mulkieran]

Please see comment.

[GuillaumeGomez]

I'll take a look.

[stratis-bot]

Test with Jenkins?

[mulkieran]

Superceded by #1590.