Re: [Libguestfs] [PATCH 1/2] New API: btrfs_filesystem_show

-----Original Message----- From: Richard W.M. Jones [mailto:rjones@redhat.com] Sent: Friday, March 06, 2015 4:43 PM To: Chen, Hanxiao/陈 晗霄 Cc: libguestfs(a)redhat.com Subject: Re: [Libguestfs] [PATCH 1/2] New API: btrfs_filesystem_show On Fri, Mar 06, 2015 at 07:39:36AM +0000, Chen, Hanxiao wrote: > > > > -----Original Message----- > > From: Richard W.M. Jones [mailto:rjones@redhat.com] > > Sent: Thursday, March 05, 2015 8:59 PM > > To: Chen, Hanxiao/陈 晗霄 > > Cc: libguestfs(a)redhat.com > > Subject: Re: [Libguestfs] [PATCH 1/2] New API: btrfs_filesystem_show > > > > AFAICT this API doesn't work: > > > > $ ./run guestfish -N fs:btrfs btrfs-filesystem-show /dev/sda1 > > libguestfs: error: btrfs_filesystem_show: /dev/sda1: > > > > That might be a bug of btrfs-progs. v3.17 works fine. > I'll fix it. > > > When I tried the btrfs-filesystem-show-all API, I see a lot of > > structure in the output: > > > > $ ./run guestfish -N fs:btrfs btrfs-filesystem-show-all > > Label: none uuid: f7754d86-baa1-40e7-a563-46976e81d64c > > Total devices 1 FS bytes used 28.00KiB > > devid 1 size 99.88MiB used 12.00MiB path /dev/sda1 > > > > Btrfs v3.18 > > > > Usually we should try to turn that text into structs, otherwise every > > consumer of libguestfs has to write parsing code themselves. > > > > *However* in this case I'm having a hard time understanding why anyone > > would want to use the API. Most likely if they were debugging a btrfs > > problem, they'd be using 'virt-rescue' and would be able to run > > arbitrary commands. Some of the other information, like UUID and > > label is available through other APIs (eg. get-uuid). Other > > information like the layout of devices could be modelled with some > > very complex structs on the libguestfs side, but does anyone need > > this? > > > > btrfs filesystem show could tell user info when they what to use: > btrfs filesystem balance > > What's more, > it could tell us if some of the btrfs device is missing: > If we had 10 btrfs devices but one of them is missing, we could use > btrfs-filesystem-show to find out which one is missing in a convenient way. I don't doubt that it's useful, but these kind of user-facing debugging operations would probably be done using 'virt-rescue'.