LVM Support (Page 1 of 2)

well, afaik no one is really working on it. We have some plans and it shouldn't be that hard to implement, but i'd like to implement support for RAID first.
See http://bugzilla.gnome.org/show_bug.cgi?id=160787 for more info.

Did you consider helping with this yourself? We could talk a bit and you could start writing a 'LVM core' for gparted. As soon as that's finished we talk about the GUI modifications.

well, you can learn to code, can't you? c++/gtkmm isn't that hard to learn. It all depends on your available time and your motivation.

There are excellent tutorials out there, let me know if you are interested

ok, then you just have to wait

Hi david ! Happy to see you here : Who is not against us is for us
Well, personaly i dont even know three word of C++ language. but i am only maintaining livecd and docs.
Plors (the GParted dev) would srely be happy to meet you , but he is absolutly overbooked somewhere in Surinam ...

Any way, i am current fedora user, and i have alos interests about lvm. Plors use to work with gentoo, and hope to have as much info as possible to set lvm in GParted...
You may have a look at some bug (notabug)  which claim for this feature...

This description of the implementation of LVM appears usefull:

http://en.wikipedia.org/wiki/Logical_Vo … 28Linux%29

Their description of the metadata in a PV makes it sound like one could physically move a PV safely as long as its visibility to the hosts that use it does not change.  (Naturally, the administrator would have to know this.) 

A copy to a device to be removed; i.e., for backup, should work, but a copy within the same disk farm would probably confuse the device mapper next time a survey was done since the UUIDs would be duplicated.  When making HW mirrors of Windows partitions, NEC arrays may make changes to the GUIDs in the disk headers in order to allow the copy to be remounted by the same system.  Perhaps a UUID "twiddle" could be an adminstrative option in cases where the image copies are created in the same disk farm.  All the PVs to be copied in a VG would need to get the same treatment in order to make the whole VG consistent.  Due to this type of issue, you would probably warn an admin about operations on only partial VGs.

My interest is more in manipulating the PVs than the LVs.  After all, one should be able to use LVM tools for the LVs.

I wanted to investigate the "mobility" of LVM PV devices.  I created two PVs on an external USB drive whose drive letter was SDA.  One PV was a primary partition and the other was within an extended partition.  I created a VG with the two PVs.  I put a simple EXT3 file system on the VG striped between the two PVs and copied a single file.  I used Fedora Core 6.

I then migrated the external drive to a different system with Fedora Core 6 and succeeded in discovering the VG and mounting the EXT3 file system.  On this second system the external drive was device SDB.  This demonstrates that the LVM discovery system is indeed impervious to drive letter changes.  However, a hex dump of the first few blocks of the partition reveal that the device names are included in the metadata.

This indicates that it should be possible to use gparted to MOVE a PV, even between disks, possibly requiring a rescan in order to reactivate the VG.

What about COPY?

I did a web search and found no entries which indicated how LVM would behave if it were confronted with multiple copies of the same PV.  What would occur if we were to perform a copy of a PV using Gparted without masking the existence of the one of the copies with zoning, or some other type of access control?

I may get a chance to try this on one of our EMC arrays using TimeFinder to perform HW copies of the devices.  I will try to remember to ask the folks at EMC labs if they know how it might behave during one of our teleconferences.

Hi,

I guess this is not the right place, sorry, I couldn't find any better (i.e. more LVM specific) forum :-(

I want to resize a LVM Physical Volume, i.e. a partition that has LVM on it.  Thanks to gparted, I have some free space on the disk just before the LVM volume.  According to the pvresize man page, I just need to change the place used by the LVM partition to include the free space, e.g. using fdisk, and then run pvresize.  However, I read somewhere that this will only work if the free space comes behind the existing LVM area.  Is that right?  If so, is there a way of moving the filesystem data from the end to the beginning of the enlarged space?

Making the free space into a new partition doesn't work since I already have 4 primary partitions.

Any ideas?  Any suggestions where I should rather post this?

Regards,
    Martin

Detection of lvm2 physical volumes has been added to the Gnome SVN repository
for inclusion in the next release of GParted (0.4.2).

Please note that Logical Volume Management is not yet supported by GParted.

I am still trying to get my head around how LVM will be graphically presented,
and what is involved in re-engineering the core architecture of GParted to
support LVM.  If you have some ideas, I am open to suggestions.

Hi!

Please don't mix up hierarchy levels in the Linux storage architecture.
ext3 is a file system; it is used to make a given block of storage space usable for storing your files there. It is the layer in the storage architecture that is closest to the userland.
If LVM is used, it is located one level below ethe file system, but one level above the physical hard drives and the partitions created there: It is used to create "virtual partitions" (called Logical Volumes) that span multiple hard drives, "physical" partitions, or RAID arrays. It is NOT part of any file system (at least as far as I know), but you must use a file system on these Logical Volumes to make them usable.

There definitiely are approaches to include RAID and LVM functionality into the file system layer, so RAID and volume maganegemtn can be fine-tuned to the needs of the specific file system layout; one implementation of such a file system is Sun's ZFS (uncluded in OpenSolaris and also usable on several *BSD systems).
However, to my best knowledge, btrfs is planned to include RAID functionality - but no LVM-like features.

I would also like to see full LVM support, but with consideration for LUKS at a later time.

There are all manner of combinations of LUKS and LVM... LVM on LUKS encrypted partition, LUKS encrypted volumes, or my preference LVM on a LUKS encrypted disk (ie no partitions and no partition table).

No C++, but willing to learn if I can find the right resources. My background was assembly, writing communications protocols way back in the dark ages. I say "was" because it is all but forgotten. Between '83 and '03 I didn't even look at a computer. Gentoo user now for 5 years.

Thanks.