On Wed, Jan 27, 2016 at 2:09 PM, Daniel E. Shub <daniel.e.shub@xxxxxxxxx> wrote: > I am experiencing what I think might be a bug with: btrfs subvolume list -o > > I reported it at https://bugzilla.kernel.org/show_bug.cgi?id=109861, > but have read that bugs should be sent to the mailing list also. > > My root file system is on a btrfs partition and I have created btrfs > subvolumes in /chroot and /var/lib. The following behavior seems > incorrect > > # btrfs subvolume list -o /chroot > ID 593 gen 6616 top level 5 path chroot/base-devel/root > ID 594 gen 6618 top level 5 path chroot/multilib-devel/root > ID 595 gen 6620 top level 5 path chroot/base/root > ID 597 gen 6624 top level 5 path chroot/twm/root > ID 599 gen 6628 top level 5 path chroot/lxde/root > ID 601 gen 6655 top level 5 path chroot/wheezy/root > ID 602 gen 6684 top level 5 path chroot/sid/root > ID 603 gen 6862 top level 5 path var/lib/machines > > The man page for btrfs subvolume says > -o print only subvolumes below specified <path>. > > so I expected to only see the subvolumes below /chroot and to not see > /var/lib/machines/. > > I am running Arch Linux with the 4.2.5 kernel and btrfs-progs v4.3.1. I agree that it's confusing because of the word <path>. It may actually be a bug in documentation setting up the wrong expectation. If chroot were a subvolume, this would work as you expect. Since chroot is a directory, in effect it's a request to show all subvolumes on the fs-tree that this directory is on, i.e. subvolume id 5, which would be all subvolumes. Whereas if chroot were a subvolume, the -o would limit results to subvolumes having a top level at or below the subvolume ID of chroot. I think. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
