Adopting libatasmart

[antoniovazquezblanco]

Sorry as this is not the best place to ask the following question...

I have stumbled across some of the bugs present in libatasmart. I am affected by some of them and after some search many bug reports in incorrect places pop up... As far as I know libatasmart is no longer being maintained and it seems that its been a while since the original author made a commit to the project...

I have some fixes for the library but find myself in the same position as those who are reporting bugs out of place, I do not have a place to contribute to...

After no responses in many places, I was wondering if storaged project may be a place to mirror libatasmart and make pull requests. It seems many people arrive here after stumbling with libatasmart related bugs...

Project maintainers probably already have enough in their plates but working around these known issues may also imply more work that may be solved with less effort by going this route.

I hope this message is understood in a positive way and in under no conditions I meant to negatively impact this project or its maintainters although this suggestion is clearly overstepping my boundaries. I did not mean to be unrespectful.

Thanks for your work!

[tbzatek]

Thank you for your message, I do appreciate you decided to approach us. We've ourselves been asking what future the libatasmart holds and if it makes sense to invest time to improve it and bring it up to date. After all we're getting constant flow of bugreports about wrong SMART data, attributes and temperature.

One other possibility we've been exploring recently was to embrace smartmontools instead. A proof of concept libblockdev plugin has emerged as a result: storaged-project/libblockdev#835. Both options have their pros and cons but for now we're leaning towards smartmontools as a well-maintained project with a good database of drives (i.e. quirks) as well as good SCSI and SAS support.

Given how understaffed udisks is at the moment I don't see it realistic to adopt libatasmart on a responsible level of maintenance. Shall we decide to go the smartmontools way the libatasmart dependency will be removed for good.

[antoniovazquezblanco]

Thanks @tbzatek for the fast response.

I could read a little bit about libblockdev and how smartmontools will be supported by it. I also peaked at smartmontools issues to find that the will probably will not break the tool into a lib and the executable because they now support json output...

It is a shame because I really apreciate the principles behind libatasmart as stated by the author: lean, small and clean implementation of an ATA S.M.A.R.T. reading and parsing library.

Anyways, congratulations on the work being done and thanks for taking the time to reply.

[tbzatek]

I also peaked at smartmontools issues to find that the will probably will not break the tool into a lib and the executable because they now support json output...

I still hope it will happen one day. In any case we could rewrite the libblockdev plugin anytime without breaking its API.

It is also worth noting that the mentioned plugin does not intend to provide full functionality of smartmontools, only a subset of basic functionality for brief health monitoring.

[antoniovazquezblanco]

I still hope it will happen one day.

I hope it too.

In any case we could rewrite the libblockdev plugin anytime without breaking its API.

I fully understand the point. It works as an abstraction layer. I also understand that libblockdev has many other functionalities and objectives in mind but I kind of wonder if part of the reasons for libblockdev to exist was to work around the bugs present in libatasmart by calling smartmontools.

Thanks @tbzatek for the feedback and congrats on the work of this project! :)

[tbzatek]

I kind of wonder if part of the reasons for libblockdev to exist was to work around the bugs present in libatasmart by calling smartmontools.

The primary reason for moving the functionality to libblockdev was reusability by other projects as it's a stateless library and provides various bindings. The very first idea was to just move the code while still building on top of libatasmart. But it was a matter of choosing well-maintained project at the end of the day.

Feel free to have a look around in libblockdev, there's much more to offer.