HDD Prep for Vinum LVM

Beeblebrox

Beeblebrox

I'm more experienced with linux but trying to switch to bsd. I like the advantages of LVM2 so I definitely want to use a similar setup on my fbsd 8.1 installation. There is no raid or mirroring; I just like the robustness. I tried ZFS but found that it requires too much memory and although I have 1 GB ram on a 64 bit system, the LV's became unstable and gave me problems. So I'm stuck with vinum (I don't feel confident enough to try Hammer or like)

Unfortunately fbsd does not seem to have a GUI like gparted nor for vinum (if there were that would be great!) So I'm trying to prep my HDD from an 8.1 pc-bsd installed on a second disk. Now the question is:
- I could probably manage setting up the large extended partition with 30 GB slices (logical partitions) inside it. At that point does vinum behave like LVM2? From what I have read so far the logic seems the same (volume group vg and lv's inside it). So can I expect to name the group and then the LV's - a GUI tool would really be great no chance of porting some linux GUI here I suppose?
- After all of the above, should I move (tar / untar) existing slices (root /var /usr etc) to the logical volumes or is there an easier way for a clean install? Ch 21.9 of the manual gives some info but this is more for a raid setup. I think I would have to pass a command to the bootloader menu on the live Cd so that vinum lV's are recognised by the sysinstall. Is that command something like geom_vinum_load="YES" ? and where would I place it?
Thx.
 
Precisely where I started babe, and I do refer to "Ch 21.9 of the manual" in my post. Not much help though, as it's more geared to enjoy your raids. In fact, this is better as a summary of the thing: http://www.jurai.net/~scanner/vinum-howto.html
I don't find anywhere a description of how to move or install to the LV after newfs command, and the first question is for someone who has tried to setup vinum.
Thanx anywhoo
 
Beeblebrox said:
I'm more experienced with linux but trying to switch to bsd. I like the advantages of LVM2 so I definitely want to use a similar setup on my fbsd 8.1 installation. There is no raid or mirroring; I just like the robustness. I tried ZFS but found that it requires too much memory and although I have 1 GB ram on a 64 bit system, the LV's became unstable and gave me problems. So I'm stuck with vinum (I don't feel confident enough to try Hammer or like)

Unfortunately fbsd does not seem to have a GUI like gparted nor for vinum (if there were that would be great!) So I'm trying to prep my HDD from an 8.1 pc-bsd installed on a second disk. Now the question is:
- I could probably manage setting up the large extended partition with 30 GB slices (logical partitions) inside it. At that point does vinum behave like LVM2? From what I have read so far the logic seems the same (volume group vg and lv's inside it). So can I expect to name the group and then the LV's - a GUI tool would really be great no chance of porting some linux GUI here I suppose?
- After all of the above, should I move (tar / untar) existing slices (root /var /usr etc) to the logical volumes or is there an easier way for a clean install? Ch 21.9 of the manual gives some info but this is more for a raid setup. I think I would have to pass a command to the bootloader menu on the live Cd so that vinum lV's are recognised by the sysinstall. Is that command something like geom_vinum_load="YES" ? and where would I place it?
Thx.
Click to expand...

If you have no intent to use or administer multiple volumes with mirroring, raid or whatever, I would not recommend to use vinum. If you simply want the ability to concatenate disks, use gconcat. If you would like the labeling functionality, you can use glabel.
 
Thanks Lulf.
I liked LVM2 mainly for the easy re-size / move from or to a partition / extend across disks etc. I also found it easy to manage, both due to available GUI's and the simple command structure.
I looked into again ZFS over the weekend and the mountpoint / tank mentality is quite different than LVM. It has certain good features that I was interested in (like compression of sub-folders or no need for fsck) but in the end I like the flexibility LVM provides.
I will look into the 2 modules you suggest thx for that. In the mean time, I also found this - anyone have any thoughts on this?

IT'S LVM2 ON DRAGONFLY BSD. Apparently netBSD already has LVM2.
http://www.shiningsilence.com/dbsdlog/2010/07/14/6093.html
 
UPDATE: For those looking for answers on this. Lesson from the whole post: Back to ZFS!
lulf: Sorry gconcat & glabel not what I'm looking for.

The main problem, and I suppose I could not articulate it sufficiently, was that I wanted to understand the differences in how the structure of the 3 systems compared.

LVM: you create vol-group (vg) then lv's (volumes) lv's have static space allocation. The nice thing is entirely movable in emergency (hdd fail scenario - which I get a lot)

ZFS: Similar but dynamic space allocation (advise if wrong) so you actually do not have to worry about "what's left?" Many other advantages of course, but my main concern was memory. The answer to manage this is: Set params in boot/loader.conf for vm.kmem_size & vm.kmem_size_max

VINUM: looks outdated compared to the 2 above (in my humble opinion). vg (group)/lv (volume) looks like some redundant mixture and it is not 1-1 comparable to LVM. the group acts like a partition + volumes are just mountpoints?

In the end, concise info is much better than long-winded accounts and for me after some time it was tl;dr
Hope this helps + thx anyway
 
I've used quite a bit of LVM and DM in some Debian and Centos installs I admin, and I'll take GEOM over it any day of the week. GEOM has a some missing features compared to DM, but DM has a lot of missing features compared to GEOM.

GEOM's missing resize ability is probably more due to the fact that no FreeBSD FS's support shrinking whereas at least the more common ones on Linux do. There are ways around it, but that's another thread. GEOM also has no need for something like LVM snapshots since UFS and ZFS support live FS's snapshots. No more umounting LVM's to take your snapshot.

Vinum and more specifically gvinum are hardly outdated. If you really need a GUI, I guess you'll have to use another OS because there isn't one available. FWIW, I've never use a GUI to manage LVM's either. I didn't even know they existed, but they are useless to me anyway.

FYI, GEOM also has the ability to use LVM devices: http://www.freebsd.org/news/status/report-2007-10-2007-12.html#LVM-geom-class
 
Thanks GD, for the useful post. I usually use the GUI to check the LV partition order - that is to make sure swap is before usr and home or archive is at the very end etc; but that's probably because I don't know how to do it from the command line.

Could you please let me know how the volume/group setup works in geom? Compared to LVM where you have /dev-mapper/vgroup/lv and where you can create as many lv's as you wish, geom seems to need separate vg/lv sets for each lv? I did not get the logic here...
Thanks.
 
Well the FreeBSD equivalent really depends on your usage. Since there is no direct equivalent of LVM in FreeBSD(device-ampper and GEOM are similar in some respects, but quite different in others.), different usage patterns dictate different methods.

Let's say for example you're using Linux as some sort of hypervisor eg Virtualbox, XEN, KVM. When I'm using this type of setup, I will generally assign an LV to a guest instance to use a hard disk. When using FreeBSD, options vary. If I am using ZFS, I use ZVOL's which in a way are similar to LVM's(except ZVOL have all the ZFS goodness like transparent compression etc). They are resizable virtual block devices that integrate with GEOM. If you're using ZFS or UFS, you can use either it's own dedicated partition/slice, or a raw image/sparse file. With ZFS and FreeBSD jails, you can also dedicate a ZFS filesystem to the jail with it's own independent attributes. Sparse files are easier to work with in FreeBSD vs Linux IMO. They are easy to create with the

% truncate

command, and easier to mount with mdconfig. Once they are mounted, the md devices also become GEOM members and you can do with them what you would with any other GEOM class.

As you see, there are a lot of ways to skin the cat here, so citing specifically what you use LVM for would probably lead to a more helpful answer.
 
Ok I'd like to retract some of the statements I made about GEOM's shortcomings vs LVM. I started playing around with gvirstor() and that geom class pretty much offers exactly the things I said GEOM didn't do well. For reference, you can use a gvirstor as a fairly close equivalent to an LVM PV/VG.
 
You must log in or register to reply here.
Back
Top