On Sun, Jan 09, 2011 at 09:59:46AM -0800, Freddie Cash wrote:

On Sun, Jan 9, 2011 at 7:32 AM, Alan Chandler
[off-list ref] wrote:

quoted

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?

   Kind of. The thing is that the way that btrfs works is massively
different to the way that LVM works (and probably massively different
to the way that ZFS works, but I don't know much about ZFS, so I can't
comment there). I think that trying to think of btrfs in LVM terms is
going to lead you to a large number of incorrect conclusions. It's
just not a good model to use.

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).

   No, subvolumes are a part of the whole filesystem. In btrfs, there
is only one filesystem. There are 6 main B-trees that store metadata
in btrfs (plus a couple of others). One of those is the "filesystem
tree" (or FS tree), which contains all the metadata associated with
the normal POSIX directory/file namespace (basically all the inode and
xattr data). When you create a subvolume, a new FS tree is created,
but it shares *all* of the other btrfs B-trees.

   There is only one filesystem, but there may be distinct namespaces
within that filesystem that can be mounted as if they were
filesystems. Think of it more like NFSv4, where there's one overall
namespace exported per server, but clients can mount subsections of
it.

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.

   OK, this is _definitely_ not the way that btrfs works. As I said
above, a btrfs subvolume is just a namespace that is mountable in its
own right. It's *not* a block device, and can't be formatted with any
other filesystem.

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).

   The main awkward piece of btrfs terminology is the use of "RAID" to
describe btrfs's replication strategies. It's not RAID, and thinking
of it in RAID terms is causing lots of confusion. Most of the other
things in btrfs are, I think, named relatively sanely.

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.

   I think this is the wrong thing to do. I hope my explanation above
helps.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
      --- Try everything once,  except incest and folk-dancing. ---