All 'logical' block devices behave pretty much like physical ones.
So you are free to put partition tables on top of lvs or dmcrypt block
devices, you can aswell put each other on top of each other. It just
adds possible layers of failure and or overhead.
Since LVs give you the opportunity to be created in whatever size you
wish, in many usage cases it is perfectly normal and straight forward to
put a filesystem ontop of an LV instead of a partition table.
To the other guy: Whenever you export some LV as LUN or Blockdevice via
network as example, you will end up with a partition table on top of the
logical blockdevice, which is prefectly normal and okay. i.e. if you'd
want to export some LV via iSCSI to a windows box, you are pretty much
required to have either a partition table ontop of the lv, or some other
disk slicing scheme (EFI Partitions, dynamic volume signatures, whatsoever).
Just for your Information.
Adam, there is a blkid command coming with the e2fsprogs, it will print
all UUIDs+type of all your physical and logical volumes.
I.E.: /dev/mdXXX: UUID="<yourUUID" TYPE="LVM2_member"
Just another option to get an overview of the current situation maybe,
if you cannot find the UUIDs otherwise.
Regards
-Sven
Adam Olsen schrieb:
On Tue, Jul 21, 2009 at 11:49 PM, Ron Johnson<ron.l.johnson@cox.net> wrote:
Why didn't I have to? This has always worked for me:
# mkfs.${TYPE} /dev/some_vg/some_lv
Perhaps you're not required to. I just always assumed you did, so I
always have. It does work, and works how you'd expect it to.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
