On Sun, Jan 9, 2011 at 7:32 AM, Alan Chandler <a...@chandlerfamily.org.uk> wrote: > I think I start to get it now. Its the fact that subvolumes can be > snapshotted etc without mounting them that is the difference. I guess I am > too used to thinking like LVM and I was thinking subvolumes where like an > LV. They are, but not quite the same.
Let see if I can match up the terminology and layers a bit: LVM Physical Volume == Btrfs disk == ZFS disk / vdevs LVM Volume Group == Btrfs "filesystem" == ZFS storage pool LVM Logical Volume == Btrfs subvolume == ZFS volume 'normal' filesysm == Btrfs subvolume (when mounted) == ZFS filesystem Does that look about right? LVM: A physical volume is the lowest layer in LVM and they are combined into a volume group which is then split up into logical volumes, and formatted with a filesystem. Btrfs: A bunch of disks are "formatted" into a btrfs "filesystem" which is then split up into sub-volumes (sub-volumes are auto-formatted with a btrfs filesystem). ZFS: A bunch of disks are combined into virtual devices, then combined into a ZFS storage pool, which can be split up into either volumes formatted with any filesystem, or ZFS filesystems. Just curious, why all the new terminology in btrfs for things that already existed? And why are old terms overloaded with new meanings? I don't think I've seen a write-up about that anywhere (or I don't remember it if I have). Perhaps it's time to start looking at separating the btrfs pool creation tools out of mkfs (or renaming mkfs.btrfs), since you're really building a a storage pool, and not a filesystem. It would prevent a lot of confusion with new users. It's great that there's a separate btrfs tool for manipulating btrfs setups, but "mkfs.btrfs" is just wrong for creating the btrfs setup. -- Freddie Cash fjwc...@gmail.com -- 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
