Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON output broken for btrfs subvolume subcommands #833

Open
frantisekhanzlikbl opened this issue Jul 1, 2024 · 2 comments
Open

JSON output broken for btrfs subvolume subcommands #833

frantisekhanzlikbl opened this issue Jul 1, 2024 · 2 comments
Labels
bug experimental Experimental or unstable feature

Comments

@frantisekhanzlikbl
Copy link

frantisekhanzlikbl commented Jul 1, 2024

From my understanding, the three btrfs subvolume subcommands list, show, and get-default should respect the global --format=json flag. Currently, none of them seem to do so. Instead, all of them print ERROR: output format json is unsupported for this command. btrfs --format=json device stats seems to work fine, so it's not all JSON output being broken, just the subvolume subcommands.

Version information:

uname -a Linux tartaros 6.6.32 #1-NixOS SMP PREEMPT_DYNAMIC Sat May 25 14:22:56 UTC 2024 x86_64 GNU/Linux
btrfs --version btrfs-progs v6.9.2
@kdave
Copy link
Owner

kdave commented Jul 2, 2024

The json output for the subvolume related commands is currently enabled only in the experimental build. The format hasn't been finalized, at least list does not print complete subvolume information and it still depends on the parameters, the way multiple objects are enumerated in the json is also not unified.

To see the difference run:

$ btrfs subvolume list /mnt
{
  "__header": {
    "version": "1"
  },
  "subvolume-list": [
    {
      "id": 19112,
      "generation": 7730702,
      "top_level": 5,
      "path": "test"
    },
    {
      "id": 19113,
      "generation": 7730702,
      "top_level": 5,
      "path": "test-snap"
    }
  ]
}

and

btrfs --format=json subvol list -pcguqR /mnt
{
  "__header": {
    "version": "1"
  },
  "subvolume-list": [
    {
      "id": 19112,
      "generation": 7730702,
      "cgeneration": 7730701,
      "parent": 5,
      "top_level": 5,
      "parent_uuid": null,
      "received_uuid": null,
      "uuid": "dc16dd1b-825f-3245-94a8-557672d6cf85",
      "path": "test"
    },
    {
      "id": 19113,
      "generation": 7730702,
      "cgeneration": 7730702,
      "parent": 5,
      "top_level": 5,
      "parent_uuid": "dc16dd1b-825f-3245-94a8-557672d6cf85",
      "received_uuid": null,
      "uuid": "91708196-fd07-2242-8b8e-af9375474a09",
      "path": "test-snap"
    }
  ]
}

This is still missing the send and receive related transaction ids, times, and maybe other inforamtion that's available and does not have to be conditional like that.

@kdave kdave added bug experimental Experimental or unstable feature labels Jul 2, 2024
@frantisekhanzlikbl
Copy link
Author

frantisekhanzlikbl commented Jul 3, 2024

Ohh, I did not realise that, thanks!

Perhaps a note in the error message or in Documentation/dev/dev-json.rst could be added? It was not clear to me at all as an outsider that there were such things as experimental builds (even though

#if EXPERIMENTAL
should've made that clear. ':)). I'd volunteer to make the changes, but I hardly know reST and would rather not touch any C I don't understand in its entirety.

Either way, it is entirely reasonable that the feature is not on by default if the format is not yet stabilised, even though I really wish it were. The horrendous greps I'm doing to at least attempt to handle newlines in filenames and such haunt me in my dreams. :)

Sorry for the false report. Unless you wish to use the issue to track the stabilisation or docs update, feel free to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug experimental Experimental or unstable feature
Projects
None yet
Development

No branches or pull requests

2 participants