User:Chrismurphy/lvm2btrfs

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.