Tradeoffs in where you store volume management metadata
One of the divisions between different logical volume systems is where and how they store the metadata about what logical volumes exist and what they're made up of. Roughly speaking there are two choices: 'in-band', where you store the metadata in a reserved area of some of the disk space you're managing, and 'out-of-band', where you store it outside. In-band storage is used by Linux software RAID and LVM; out of band storage is used by Solaris DiskSuite.
(Technically you can get Linux software RAID to use a form of out of band storage, where the 'metadata' is saving a script to assemble the array. My impression is that this is not widely used.)
The advantage of in-band metadata is that your data is self-describing. If you have access to the underlying storage, you always know enough to reassemble the object; you are never stuck with valid data that you can't touch because you don't know enough to put it together.
The advantage of out of band metadata is that you can import existing data into your volume system, because adding storage space to the volume system doesn't require writing metadata to some spot of it. (Obviously this only works for RAID 0 or RAID 1 storage.)
One of DiskSuite's cooler tricks is the ability to import an existing filesystem on an existing partition into DiskSuite without having to dump and restore anything. You unmount the filesystem, tell DiskSuite to make the partition into a metadevice, and then you can mount the metadevice and your filesystem is back, fully intact. (In the extreme this can be done without unmounting, although you have to reboot to activate things; this is handy for things like the root filesystem.)
Despite the cool tricks possible with out of band metadata, I prefer in-band metadata; it's simpler and you don't have to scramble to find space for the metadata and to back it up.