Today, as my wife and I were headed into Target, I thought of the cheap USB thumb drives they usually have on sale, and I was tempted to purchase some. Then I got to thinking: what if I could use those thumb drives as one disk, using LVM, and have the ability to take that LVM structure from computer to computer? For example, say I have 6 2GB USB thumb drives. I have 12GB of storage total. Maybe I want to fit a DVD ISO or two on the disks. LVM would be perfect for this, if it remains on one computer. Wouldn't it be nice if I could take those 6 drives to another computer, scan for the LVs, and mount them, keeping all my data in perfect order? Well, after a bit of hacking about, I figured it out, and it's cleaner than you would think.
I'm not going to bother teaching you about the concepts behind LVM here. Suffice it to say, that LVM provides complete flexibility and control over your disk pools, where editing and manipulating partitions would be troublesome. The idea behind LVM is to create a pool of disk space, whether it comes from one drive, or many, and have the ability to chop up that pool to create mount points easily, as well as resizing the volumes, either larger or smaller.
So, to get started, let's keep it simple. I have two 32MB USB thumb drives with me right now for this post. When I plug them into my computer, my Linux kernel might recognize them as /dev/sdy and /dev/sdz, for example. You can find these results by running "fdisk -l" as root, checking the end of the dmesg command, or checking the end of /var/log/messages.
If they have a filesystem on them, and your desktop mounts them automatically, like GNOME or KDE will traditionally do, then you'll need to unmount the devices. Once unmounted, we'll need to partition the devices, and label the partitions as "Linux LVM". I'll leave that step up to you. Some good utilities of making this happen are fdisk, sfdisk or parted. You will only need one partition on each drive. Make sure the partition covers the whole disk, and make sure the partition is labeled as "Linux LVM". If the partition is not labeled appropriately, it could cause problems for you later down the road.
Now that you have your disks partitioned, and labeled correctly, let's start building the LVM structure. This is done by creating physical volumes first, then adding them to a disk pool, and chopping up the disk pool as needed for our mount points. Caution: This next step will erase any filesystem, and as a result, any data on the drives.
Pull up a terminal, type as root, and pay attention to the output:
# pvcreate /dev/sd{y,z}1
Physical volume "/dev/sdy1" successfully created
Physical volume "/dev/sdz1" successfully created
Now, time to add these two physical volumes to a drive pool. This next step is important, because you will give a name to the volume group. This name must be unique! Reason being: if you take this LVM structure to another computer, and it already has LVM implemented with a volume group that has the same name as yours, you'll run into snags. So, for me, I used my GnuPG keyID. I figure that will be unique enough, that I shouldn't encounter it on any computers I plan on using this with. But, you can name it whatever you want. Name it something that is useful to you. Of course, name it something very unique.
So, continuing in your terminal, type as root and watch the output:
# vgcreate 8086060F /dev/sd{y,z}1
Volume group "8086060F" successfully created
Cool, at this point, I have about 64MB of space that I can chop up any way I see fit. Maybe I want a 50MB volume and a 14MB volume. Maybe I want one massive 64MB volume. Maybe I want 64 1MB volumes. The point is, you decide. When I create my logical volumes, I'll be using the "lvcreate" command, which is rather detailed, so spending some time in the man pages will be of value.
Before continuing, we need to find out exactly how much space I have in my pool. LVM is keeping some metadata on the disks, so I will be losing some space. But how much? This is important to know when I start creating my logical volumes. I can get this data by running the "vgdisplay 8086060F" command:
# vgdisplay 8086060F --- Volume group --- VG Name 8086060F System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 52.00 MB PE Size 4.00 MB Total PE 13 Alloc PE / Size 0 / 0 Free PE / Size 13 / 52.00 MB VG UUID F0pWrc-030s-03Uo-SoLl-7Tvf-ZETc-3hcxfG
"Free PE/Size" is what we're looking at. In this case, LVM is using 12MB of metadata stored on the disks for its operations. If each extent is 4MB and I have 52MB of space, then that means I have 13 physical extents that I can use. This is the "PE" number. So, I'm going to use that number when creating my logical volume. I'm also going to name it something personal; something that has some meaning to me. Because this will be holding my personal data, I'll name it "personal".
Pull up a terminal, and as root:
# lvcreate -n personal -l 13 8086060F Logical volume "personal" created
Sweet! I have a logical volume that I can now put a filesystem on, mount, and start moving data to. So, let's get to it:
# mke2fs -j /dev/8086060F/personal ... [Output snipped] .. This filesystem will be automatically checked every 34 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
Next, let's mount it:
# mount /dev/8086060F/personal /mnt # echo "Testing file on LVM" > /mnt/file.txt
We now at this point have our LVM structure created, formated, mounted and data on it. Now, the key is to take these thumb drives out of the computer, take them to a separate computer, and rebuild the exact LVM structure keeping the data in tact. After all, that's what we're after, right? Mobile LVM?
Unmount the device:
# umount /mnt
If you get an error here, run fuser, with its various options, to find why the umount is failing.
Now with the logical volume unmounted, we need to deactivate it. This effectively takes the volume offline, so it can't be accessed for data retrieval or storage. This can be handled with the "lvchange" command. Looking at the man page, in order to activate or deactivate a logical volume, you need to pass the "-a" switch. "-a y" would activate it, and "-a n" would deactivate it.
In your terminal:
# lvchange -a n /dev/8086060F/personal
No output will be there, but the device "/dev/8086060F/personal" should no longer exist. Now, we need to do the same thing with the volume group, telling LVM that we are finished with this group, and we no longer need its data. Surprise, surprise, this is done with the "vgchange" command, and we pass the same switch with its argument:
# vgchange -a n 8086060F 0 logical volume(s) in volume group "8086060F" now active
At this point, it is safe to unplug the drives from your computer, and plug them into the new computer.
It's typically best practice to notice how the Linux kernel identifies the drives when plugging them into a new machine. Knowing this information won't necessarily be of vital importance to us during this tutorial, but it could be of importance when troubleshooting. Let's say the kernel recognized the drives as /dev/sdk and /dev/sdl.
At any event, we need to have LVM2 and Ext3 installed on this new machine, if they aren't already. Once those are installed, all we need to do is run pvscan to search the system for any new physical volumes. It should find our newly plugged in thumb drives, with all their metadata:
# pvscan PV /dev/sdk1 VG 8086060F lvm2 [24.00 MB / 0 free] PV /dev/sdl1 VG 8086060F lvm2 [28.00 MB / 0 free] Total: 2 [52.00 MB] / in use: 2 [52.00 MB] / in no VG: 0 [0 ]
Cool. It found them, and it's telling me that they belong to a volume group called "8086060F". If this volume group already exists on the new computer, LVM will let me know. This is why we needed to create a new volume group that had a very unique name.
All that's left, is to activate the volume group, then activate the logical volumes, and I should be able to mount the volume, and access the data. Let's give it a try:
# vgchange -a y 8086060F 1 logical volume(s) in volume group "8086060F" now active
Sweet! So far so good. Notice too that I passed "-a y" to activate the group, where previously, I passed "-a n" to deactivate it. Now the logical volume:
# lvchange -a y /dev/8086060F/personal
No output, but can I mount it and access the data?
# mount /dev/8086060F /mnt # cat /mnt/file.txt Testing file on LVM
YES! WE DID IT! We've rebuilt the LVM structure on a completely different computer, and our data remained untouched. At this point, I can modify, add, remove data on the LVM to my hearts content. When I'm finished, as you're already aware, I can unmount the volume, deactivate the LV, deactivate the VG and remove the drives for the next computer.
This process, as you have figured out, has quite a few steps to it, and it requires some knowledge about how LVM works. However, this pays off, I think, and it's rather straight forward.
Not all is peaches and cream. You might have made a mistake during the process. Maybe you pulled out the drives before deactivating, and when you get to the new computer, it won't build the LVM structure, or something equally as troublesome. LVM keeps a cache on all it's operations in "/etc/lvm/cache/.cache". You can safely remove this file, if it gets in your way. LVM will recreate it as necessary. That might fix your problem, it might not, but it's worth pointing out.
I currently have 10 USB thumb drives, each of differing sizes as well as 3 mobile external hard disks. I've got roughly 200GB of raw storage at my disposal. With just flat filesystems, I can't put down a 100GB file, unless I have a drive large enough to support it. The largest drive in my collection is a mere 80GB, so LVM fits the bill perfectly in making this possible, by combining all the disks. And because I can tear it down and rebuild it regardless of the computer I'm sitting at, as long as LVM2 and the Ext3 filesystem are supported, I can access the data.
Of course, you can choose any filesystem you want here. Just remember, however, that XFS does not support shrinking the filesystem. But, it's your drives, so do what you want.
Further, if you really wanted to have fun, because you have multiple disks, you could totally take advantage of Linux software RAID. Because the structure we outlined above doesn't cover redundancy, if you lose a disk, your data could be corrupted. So, RAID would make sense, however, it complicates the mobility, by making sure Linux software RAID is also installed on the target machine, and it adds an extra step to activating the drives by rebuilding the RAID array first THEN rebuilding the LVs. And of course, if you're paranoid, you could add encryption on top of it with cryptesetup and LUKS. Again, though, another step getting to your data when tearing down and rebuilding. All thoughts for another post.
I don't care what you say, this is just too cool for school.
{ 1 } Comments