Join GitHub today
Merge master-libblockdev to master #260
This PR is basically a proposal to switch to using libblockdev for everything we can. Gaining speed and clarity, getting rid of many ugly lines of code and sharing common base with other storage-related projects like blivet and hopefully others in future.
All of the changes went through the review process already as they have been added as PRs for the master-libblockdev branch in the recent months. We have also been running our tests on the master-libblockdev branch as well as Cockpit's storage-related tests. None of which are signaling any regressions.
So this PR is really about the discussion and (hopefully) common agreement on taking this step forward. The +/- stats are not as great as we have hoped for, there have been some tests added only to the master-libblockdev branch so in total we are definitely shrinking the codebase here. Plus a lot of complex code was replaced by a similar number of lines which are however very simple few-line functions.
May 30, 2017
9 of 12 checks passed
So, we moved off of udisks1 to get around the LVM dependency because software raid is dangerous. Then the project swallows libblockdev which requires... LVM. Unfortunately, I'll have to recommend its retirement when 2.6.5 is no longer sustainable. Please consider a --without-lvm2 flag for the future. As opinions go, I think leaning on BTRFS / ZFSonLinux would be a much better idea than going anywhere near md.
My apologies then, there was a post on here about md/lvm being part of the core api. The recent downstream docks also seem to think it's required. I'll have a go at building this latest myself and see if there's a way to keep unneeded/wanted dependencies out of the build. I should have considered this, downstream devs don't always play with configure switches.
I'm still looking at it, but the only thing I can say for certain is that building udisks requires no less than 5 additional packages it did not need before. (This is after putting every single "--without-package" that was possible in libblockdev.) Well, at least the Qt ecosystem has enough sense not to require udisks.
I'll note this is not to poke fault at the udisks developers. You're going where features are available. It is just unfortunate that, like so many of the modern Linux initiatives, there is a focus on throwing in everything possible, including the kitchen sink into every package. Small/lightweight is nowhere to be seen, and I wonder how long that will last in a world of battery powered computers. After all, who needs raid, lvm, etc. on a smartphone?
I don't really see this as throwing everything in - it seems to me more like providing a comprehensive API providing suport for wide range of technologies. That way developers that want to use many different storage devices in their application can just use a single consistent API and don't have to use many different libraries, each with a different API. And the libraries themselves are still there, udisks just provides a nice consistent abstraction layer above them.
As for comprehensive API vs battery powered devices - if implemented correctly there should be no real overhead vs an API that suports less, as the parts that are not in use should not have any performance degradation effect.
As for RAID & LVM on a smartphone - I'm writing this on a smarphone that uses LVM - a Jolla C. It has two LVs formatted with EXT4, one for home and one for rootfs. And it's predecessor, the Jolla 1, even used btrfs. But that turned out to be a bad idea due to overall btrfs deficiencies and they switched to LVM + EXT4, which works fine since then AFAIK.