On 10/08/2018 05:29 PM, Holger Hoffstätte wrote:
> On 10/08/18 16:40, Hans van Kranenburg wrote:
>>> Looking at the kernel side of things in fs/btrfs/ioctl.c I see both
>>> BTRFS_IOC_TREE_SEARCH[_V2} unconditionally require CAP_SYS_ADMIN.
>>
>> That's the tree search ioctl, for reading arbitrary metadata.
>>
>> The device stats ioctl is IOC_GET_DEV_STATS...
>
> Yeah..OK, that is clear and gave me the hint to ask: why is it
> calling this in the first place? And as it turns out [1] is where
> it seems to go wrong, as is_block_device() returns 0 (as it should),
> fi_args.num_devices is never set (remains 0) and it proceeds to call
> everything below, eventually calling the BTRFS_IOC_FS_INFO ioctl in
> #1712. And that works fine:
>
> 1711 if (fi_args->num_devices != 1) {
> (gdb) s
> 1712 ret = ioctl(fd, BTRFS_IOC_FS_INFO, fi_args);
> (gdb) s
> 1713 if (ret < 0) {
> (gdb) p ret
> $28 = 0
> (gdb) p *fi_args
> $30 = {
> max_id = 1,
> num_devices = 1,
> fsid = "z%:\371\315\033A\203\267.\200\255;FH\221",
> nodesize = 16384,
> sectorsize = 4096,
> clone_alignment = 4096,
> reserved32 = 0,
> reserved = {0 <repeats 122 times>}
> }
>
> It's only when it goes into search_chunk_tree_for_fs_info()
> where things fail due to CAP_SYS_ADMIN.
>
> And all this explains the actual bug: when I call btrfs device stats
> not on the mountpoint (as I've been trying all this time) but rather
> on the device, it works properly right away as regular user:
>
> (gdb) set args device stats /dev/loop0
> (gdb) r
> Breakpoint 1, get_fs_info (path=path@entry=0x7fffffffe527 "/dev/loop0",
> fi_args=fi_args@entry=0x7fffffffd400,
> di_ret=di_ret@entry=0x7fffffffd3f0) at utils.c:1652
> 1652 {
> (gdb) c
> Continuing.
> [/dev/loop0].write_io_errs 0
> [/dev/loop0].read_io_errs 0
> [/dev/loop0].flush_io_errs 0
> [/dev/loop0].corruption_errs 0
> [/dev/loop0].generation_errs 0
> [Inferior 1 (process 2805) exited normally]
>
> So this is simply a discrepancy in handling a device vs. the device(s)
> for a mountpoint.
Apparently based on what you point it at, it does a different thing.
If you point it at a block device, it will try opening the block device
to find out which devid it has (from the superblock), find out where it
is mounted and then only ask for stats for this one device.
-# btrfs dev stats /dev/xvdc
[/dev/xvdc].write_io_errs 0
[/dev/xvdc].read_io_errs 0
[/dev/xvdc].flush_io_errs 0
[/dev/xvdc].corruption_errs 0
[/dev/xvdc].generation_errs 0
If you point it at a mounted filesystem, it lists stats for all devices.
Since there's no way to get a list of devids, it directly searches the
chunk tree directly for dev_item objects.
-# btrfs dev stats /mountpoint
[/dev/xvdb].write_io_errs 0
[/dev/xvdb].read_io_errs 0
[/dev/xvdb].flush_io_errs 0
[/dev/xvdb].corruption_errs 0
[/dev/xvdb].generation_errs 0
[/dev/xvdc].write_io_errs 0
[/dev/xvdc].read_io_errs 0
[/dev/xvdc].flush_io_errs 0
[/dev/xvdc].corruption_errs 0
[/dev/xvdc].generation_errs 0
[/dev/xvdd].write_io_errs 0
[/dev/xvdd].read_io_errs 0
[/dev/xvdd].flush_io_errs 0
[/dev/xvdd].corruption_errs 0
[/dev/xvdd].generation_errs 0
I do the same thing in the nagios plugin:
https://github.com/knorrie/python-btrfs/blob/master/examples/nagios/plugins/check_btrfs#L131
fs.devices() also looks for dev_items in the chunk tree:
https://github.com/knorrie/python-btrfs/blob/master/btrfs/ctree.py#L481
So, BOOM! you need root.
Or just start a 0, ignore errors and start trying all devids until you
found num_devices amount of them that work, yolo.
>> I can do the device stats ioctl as normal user:
>>
>> import btrfs
>> fs = btrfs.FileSystem('/')
>> btrfs.utils.pretty_print(fs.dev_stats(1))
>>
>> <btrfs.ioctl.DevStats>
>> devid: 1
>> nr_items: 5
>> flags: 0
>> write_errs: 0
>> read_errs: 0
>> flush_errs: 0
>> generation_errs: 0
>> corruption_errs: 0
>
> That works for me too, and that's actually the important part. \o/
> Glad we talked about it. :}
>
> -h
>
> [1]
> https://github.com/kdave/btrfs-progs/blob/7faaca0d9f78f7162ae603231f693dd8e1af2a41/utils.c#L1666
>
>
--
Hans van Kranenburg
