pvs,pvdisplay btrfs filesystem show (shows all btrfs, mounted or not) vgs,vgdisplay btrfs device /mnt (device allocation info) btrfs filesystem usage /mnt (most complete command) lvs btrfs subvolume list (not exact analogs) lvdisplay btrfs subvolume show (not exact analogs) pvcreate+ btrfs device add /dev/ /mnt (mkfs and resize are implied) vgextend+ lvresize+ resize2fs/xfs_growfs; (fsadm resize) (fsadm resize); btrfs device remove /dev/ /mnt (data migration, resize, magic wipe are implied) resize2fs/xfs_growfs+ lvresize+ vgreduce+ pvcreate resize2fs/xfs_growfs btrfs filesystem resize pvmove btrfs replace; or (preferred; new drive must be equal to or larger than old) btrfs device add; then (mkfs and resize are implied) btrfs device remove (data migration, resize, magic wipe are implied) lvcreate btrfs snapshot create lvcreate --snapshot btrfs subvolume snapshot -r (lvm snapshots are initially ro, btrfs snapshots are rw unless -r is used) lvremove btrfs subvolume delete ? btrfs filesystem du (btrfs specific du, shows total, shared, and exclusive usage for a subvolume or directory; only comes into play with snapshotting and reflinks, otherwise it'll match regular du) ? btrfs scrub start/status/cancel/resume (online metadata/data integrity check, only csum verification, is not an fsck) Why do 'du' and 'btrfs filesystem du' totals differ? Most likely due to inline extents. du will compute small files with a minimum 4KiB, the data block size. But the actual storage consumption of small files when inline (saved with the inode metadata in a leaf, hence inline) is quite a bit less.