A new month has come and that means new releases of libblockdev and UDisks2 have come too. We are trying to stick to the golden rule of successful open-source projects – “Release early, release often.” – and even if there are no major changes and no new major features, we do regular releases every month. Usually the target date is the end of the month which then in reality means a new release is done at the beginning of the month that follows. And that is exactly what happened this time too. libblockdev-2.15 was released on December 1st and UDisks-2.7.5 on December 4th.
A talk about UDisks2 was given at the OpenAlt 2017 conference in Brno, Czech Republic on November 5th 2017. It summarizes the history and evolution of the UDisks project and provides an insight into the development and big changes that have been happening in the last two years.
A new upstream version of UDisks2 was released on Friday (June 2nd) — version 2.7.0. People following the recent development of UDisks2 and our recent blog posts   should know that this is a big version bump which can only mean one thing: the pull request changing UDisks to use libblockdev where possible was merged! Which is almost 100 commits with changes.
As a recent blog post mentioned, there is a pull request for UDisks proposing the master-libblockdev branch to be merged into master. What would that mean? master-libblockdev is a parallel branch we have been working on in the last few months which has custom code in UDisks replaced by calls of the libblockdev library where possible. So for things like creating partitions, setting up MD RAID, LVM, etc. it’s not using the CLI tools, but instead calls libblockdev functions.
Two recent blog posts are focusing on reporting and monitoring of storage events related to failures, recoveries and in general device state changes. However, there are other things happening to storage. The storage configuration is from time to time changed either by administrator(s) or automatically as a reaction to some trigger. And there are components of the system, together with its users, that could/would benefit from getting the information about such changes.
In the previous blog post we have presented a proposal for reporting and monitoring storage-related events using journald and structured logging. To test if the proposal is viable we need some proof of concept. Such a PoC should demonstrate the complexity of the proposed solution as well as the sufficiency of the proposed set of stored (logged) items and the catalog entry.
With any type of storage failures and errors happen. Depending on the setup and the their extent such failures and errors might be anything from mere annoyance to critical import. However, they all have one thing in common — they need to be properly reported so that counter-actions and fixups (e.g. replacing a failed drive, restoring data from a backup, etc.) can happen.