Re: btrfs-progs and btrfs(8) inconsistencies

[Goffredo Baroncelli <kreijack@inwind.it>]

On 2016-02-07 11:07, Qu Wenruo wrote:
> +1 too.
> 
> But first in C, then python wrapper.
> 
> Not sure why there is no such libbtrfs for C wrapper of btrfs ioctls.
> 
> Maybe just because current btrfs ioctl is too easy to use?

Unfortunately no. 

I think the main problem of writing a libbtrfs, is the code changes needed. 
In fact in order to avoid code duplication (and to have more testing), the btrfs command has to be a client of libbtrfs. But it is not easy: you have to refactoring the error handling and the message printing...

> AFAIK, systemd (container storage part) calls btrfs ioctl directly, especially for subvolume/snapshot creation mainly > because the design of them are quite easy.

Also udev does the same (I don't remember if this happened before or after it went under the systemd umbrella).

I remember a case where it was impossible to change the semantic of BTRFS_IOC_DEVICES_READY: on the basis of its name, it could be seems that this ioctl should _only_ check if a filesystem is ready. Unfortunately it register also the device [1].
It was discussed in the ML to change its semantic, but having already widespread client  like udev it was impossible to do (even tough we could discuss to change their name)


> Thanks,
> Qu 


BR
G.Baroncelli


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772744