Vratislav Podzimek

Release time again for libblockdev and udisks!

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.

UDisks 2.7.0 released

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 [1] [2] 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.

Reporting and monitoring storage actions

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.

Storage event reporting and monitoring - PoC

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.

Reporting and monitoring storage events

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.

Pages