list subvolumes with new btrfs command

[C Anthony Risinger]

hello,

i maintain an unofficial initrd hook in Arch Linux that allows BTRFS
to be used as the root device.  i am trying to update the hook to use
the more extensive btrfs command, adding support for users to change
their default subvolume from within the initrd (i'm creating a sort of
rollback feature, in conjunction with automatic snapshotting via the
package manager), and adding support for hot spares (via a second
BTRFS pool in which devices are stolen to repair the primary array).

anyways, i'm having trouble getting a listing of subvolumes:

$ btrfs subvolume list /
ERROR: can't perform the search

the machine has a BTRFS root.  i have also tried creating a snapshot
and pointing the command at that, but i get the same results.  am i
using the command wrong?  relevant code is from btrfs-list.c:

ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
if (ret  0) {
  fprintf(stderr, ERROR: can't perform the search\n);
  return 0;
}

kernel:

$ uname -r
2.6.33-ARCH

is there a new CONFIG_* kernel parameter that needs to be set since
2.6.32?  everything seems to be in order and working fine... any help
appreciated.

thanks,
C Anthony
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: list subvolumes with new btrfs command

[sniper]

2010/4/26 C Anthony Risinger anth...@extof.me:
 hello,

 i maintain an unofficial initrd hook in Arch Linux that allows BTRFS
 to be used as the root device.  i am trying to update the hook to use
 the more extensive btrfs command, adding support for users to change
 their default subvolume from within the initrd (i'm creating a sort of
 rollback feature, in conjunction with automatic snapshotting via the
 package manager), and adding support for hot spares (via a second
 BTRFS pool in which devices are stolen to repair the primary array).

 anyways, i'm having trouble getting a listing of subvolumes:

 $ btrfs subvolume list /
 ERROR: can't perform the search

 the machine has a BTRFS root.  i have also tried creating a snapshot
 and pointing the command at that, but i get the same results.  am i
 using the command wrong?  relevant code is from btrfs-list.c:

 ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
 if (ret  0) {
  fprintf(stderr, ERROR: can't perform the search\n);
  return 0;
 }

need super root? in my ubuntu10.04 with latest btrfs-progs:

$ ./btrfs subvolume list /media/sda3-100g/
ERROR: can't perform the search
$ sudo ./btrfs subvolume list /media/sda3-100g/
ID 258 top level 5 path misc/snap/snap-4-26

 kernel:

 $ uname -r
 2.6.33-ARCH

 is there a new CONFIG_* kernel parameter that needs to be set since
 2.6.32?  everything seems to be in order and working fine... any help
 appreciated.

 thanks,
 C Anthony
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: list subvolumes with new btrfs command

[C Anthony Risinger]

 need super root? in my ubuntu10.04 with latest btrfs-progs:

 $ ./btrfs subvolume list /media/sda3-100g/
 ERROR: can't perform the search
 $ sudo ./btrfs subvolume list /media/sda3-100g/
 ID 258 top level 5 path misc/snap/snap-4-26

ah sorry, i forgot to mention that it doesn't work as super user
either, same result:

$ sudo btrfs subvolume list /
ERROR: can't perform the search

the btrfs-progs in ubuntu is probably slightly behind git HEAD (what
i'm using in Arch package), maybe it broke recently, i might try to
bisect and see it i can pinpoint to problem commit.  i am also using
kernel 2.6.33 (ubuntu is .32 i think) that's why i thought maybe there
was an issue there; it seems like the ioctl() call is failing no
matter what in my case.

other details i can think of:
1) filesystem was created by a 2.6.31 kernel

i will use loopback + BTRFS to test what is happening here and report
back; maybe i can't scan / ...?  thanks for the response, any other
input is very much appreciated.

thanks,
C Anthony
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html