Vratislav Podzimek

Funny story this one... Anyway, I take it the only reliable way to see if all devices from a volume are present is to use ``btrfs fi show`` and parse...

> The `libblockdev` API looks rather sane and simple but will necessarily bring some maintainance burden (although rather small) And it's the best API for zram in the world! (sadly)

I think having a `struct BDCryptoLUKSCredentials` or something like that makes most sense. Adding separate parameters for all the possible ways to pass the secret to the function and twice...

I vote for the option 2. And regarding the functions where it would be ambiguous, I don't care. It's the callee's responsibility to pass non-`NULL` `GError **` if they want...

I still vote for option 1. Using `gint` would require documenting the return values and `if (bd_crypto_device_is_luks())` would be a broken code because `bool(-1)` is `TRUE`. I think the functions...

Hi, we have the [`bd_lvm_cache_stats()`](http://storaged.org/libblockdev/libblockdev-LVM.html#bd-lvm-cache-stats) function which is actually just [querying DM info](https://github.com/storaged-project/libblockdev/blob/master/src/plugins/lvm.c#L2267). It would be very easy to add a similar function for a generic DM thin pool used...

OH! I somehow read `dm-cache` instead of `dm-thin`, please ignore my previous comment. In the result of [`bd_lvm_lvinfo()`](http://storaged.org/libblockdev/libblockdev-LVM.html#bd-lvm-lvinfo) we have `data_percent` and `metadata_percent`, which is the usage info when then...

I'll take a look at how hard it would be to add some `bd_dm_pool_stats()` function, hopefully for DM pools in general (to get back to my cache-misleading-path :smile:).

Looks good to me now.

> statvfs works if the filesystem is mounted, but not for an unmounted fs The same applies to `df`, right?