1

Topic: LVM Support

First off i would like to say how much i like GParted its such a handy program to have.

i understand that you are working on LVM support

i was wondering if you have any idea when it will be ready as its impossible to find some software that supports LVM disks.

Thanks in advance
    MikeTheGreek

2

Re: LVM Support

Hi Mike !
I know there is no soft to make some operations on LVM, but it could be reason about that...
Anyway enbale LVM features is on the todo of the dev with raid support too.
The biggest problem is that he hasnt enough sparetime to work on the project :-/

Larry
GParted-project Admin
Former GParted-LiveCD maintainer (2007)

3

Re: LVM Support

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.

4

Re: LVM Support

i would write it my self but i cant code at all.

thanks

5

Re: LVM Support

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 smile

6

Re: LVM Support

hehe realy wish i had the time to learn (its never intrrsted me any way) just like you i just dont have the time.

7

Re: LVM Support

ok, then you just have to wait smile

8

Re: LVM Support

I use Gparted Live CD and evangelize for it.  Great product!  Thanks.

I have installed Fedora Core both at work and at home.  I have been avoiding LVM on my work machines since it precluded use with Gparted for organizing the disks.

I do program C++, but not gtkmm.  I taught C++ in our plant for two years.  I contributed to the file access method and the journalization method for one of the file systems of GCOS 8.  I am familiar with issues of disk space allocation and partitioning, having set up several of our customers with remote disk replication for disaster recovery.

I don't exactly have spare time, but I would like to discuss this 'LVM core' to see what would be involved.

9

Re: LVM Support

Hi david ! Happy to see you here : Who is not against us is for us big_smile
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...

Larry
GParted-project Admin
Former GParted-LiveCD maintainer (2007)

10

Re: LVM Support

I would like to start a discussion about appropriate features.  For instance, for starters I would like to be able to identify, move and copy individual PV's which belong to a VG.  Currently I don't need to resize and I can live with full copies which are not aware of "used" space.  Of course, it is always best to add partial features so that the same code can be reused for a full implementation. 

What I want could probably be done by accessing the VG in raw mode.  In order to be able to properly administer the fs on each LV, one would probably have to employ the LVM library and "mount" the VG.

I would like to see a description of the metadata used to manage the VG.  I am not looking forward to "cracking" the tables by examining a hex dump.

We would also have issues about LVM1 and LVM2.

11

Re: LVM Support

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.

12

Re: LVM Support

BTW : LVM package is on the last livecd iso : you may try any test you want. And if you need other tools, i can easly add any package : just tell my and i 'll customize the livecd iso... for beta-tests.
thx a bunch !

http://gparted-forum.surf4.info/viewtopic.php?id=313

Larry
GParted-project Admin
Former GParted-LiveCD maintainer (2007)

13

Re: LVM Support

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.

14

Re: LVM Support

I found the following two links while looking for information on duplicated LVM components:

https://www.redhat.com/archives/linux-l … 00044.html

https://www.redhat.com/archives/linux-l … 00026.html

The two solutions are similar, but different.  The Krenz solution notes that the user needs an option for changing the VG name, but they may not want to change it.

15

Re: LVM Support

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

16

Re: LVM Support

any news on the progress for gui support for LVM?

I am interested in helping out. However, I would need some serious guidance from those that know how to program in gtkmm+.

I looked into this earlier but could not get anywhere. I have a weak background in c++ and have made several console apps for my work and such.

But I would like to start helping out if at all possible!

Where can I start? What kind of development environment will I need to start?

17

Re: LVM Support

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.

18

Re: LVM Support

LarryT wrote:

Hi david ! Happy to see you here : Who is not against us is for us big_smile
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 also 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...

LVM is still ext3, but my discussions with Fedora developers is that it will disappear with future standardizing on btfrs.  It is just a matter of time. 

btfrs is supposed to be a superset of lvm.

19 (edited by stormhead 2009-05-22 10:52:15)

Re: LVM Support

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.

20

Re: LVM Support

gedakc wrote:

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.

Hey all,

I really like gparted, really nice piece of open software that can (out)compete commercial software. Use it already a long time to do all kinds of complex rearrangements to my filesystems and it never even damaged any of my data. However LVM support is definitely something I would appreciate.

I am not a programmer, however I don't think that re-engineering the core is necessary. I have some small ideas how to incorporate LVM into gparted, without turning the whole program upside down. Unfortunately I don't know how to do this.
I think that assigning physical volumes could be done in the standard disk layout, as it now already displays LVM partitions. To assign you could just enter a new option in the create new partition menu, like with a "Assign to LVM" option.
To show the volume group management you could extend the disk selection drop down menu with a "Volume Management" disk, and with the different volume groups available on the system as separate disks.
On "Volume Management" disk you should be able to see, and manipulate (creating, resizing, and removing) the different volume groups, like it were partitions on a normal disk. And the different volume groups could be handled again as separate disks, making it possible to do the normal stuff on there, like creating and resizing all kind of different filesystems. But instead of making and resizing only the partitions it should also handle the logical volumes that lay underneath in the same way.
It would make the disk drop down menu a bit more complicated, but by using different icons I think most users would still get it.

Hope that anybody can make start with incorporation of LVM(2) support, with or without my suggestions. If I could do it myself I would have started it right away, unfortunately I cannot...

21

Re: LVM Support

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.

22

Re: LVM Support

One resource that I found useful for learning C++ is the book "Thinking in C++" by Bruce Eckel.  An electronic version is offered freely on the web site:
http://www.mindview.net/Books/TICPP/Thi … CPP2e.html

23

Re: LVM Support

Thanks. smile

24 (edited by Janethalloren11 2010-08-18 12:10:01)

Re: LVM Support

That's great, gedakc...

I want to learn C++ from this book..

I hope I will do this..

Janet halloren

25

Re: LVM Support

For those who plan on using LVM, I really recommend doing so on a RAID system, either hardware or software. Let me clarify!

The Drawback

    * I would like plenty of storage for my TV!
    * I don't wish to lose data if a disk crashes
    * I need to add more disks later

The answers:

    * Buy disks - a number of them
    * Use RAID
    * Use LVM

What's RAID?

RAID (Redundant Arrays of Cheap Disks) is about putting your data on 2 or extra disks in such a manner that if considered one of them crashes you do not lose your knowledge (it is as if all the pieces is saved twice - however cleverer!)

[comment: since I did this I've had one in every of my disks die and be RMA'd. No lost data smile OTOH, through the month that the drive was away I was 'unprotected' and had a minor learn error which caused a lot bother - but fortunately no information loss]

    Observe that you should always have one spare matched drive in home for any RAID system, so if one fails, you can change it immediately.

You at all times lose some house - but we don't need to lose half (which is what occurs with simple 'mirroring') so we want to use raid5. That way we will buy four disks (or more!) and solely 'lose' 1 of them.

Why not simply use RAID?

If we run out of room then we have to allocate more. You possibly can't (presently) add disks to a RAID5 array.

That is now not true for users of the 2.6.17 and above linux kernel. To develop and present raid it's important to enable the following kernel choice:

System Drivers->Mutliple devices driver assist (RAID and LVM)->RAID support->RAID-4/RAID-5/RAID-6 mode-> Support including drives to raid-5 array (experimental)

Then to resize your raid5 simply run:

  mdadm --add /dev/md1 /dev/sdb1
  mdadm --develop /dev/md1 --raid-disks=four (new number of disks)

Observe: This causes the raid to restripe itself which took about 11 hours on my machine.

What's LVM?

What LVM lets you do is accumulate all your disks, raid arrays and what-not into an enormous 'box' of storage (known as a volume group). You'll be able to then make logical volumes from this space (- assume partitions). The great factor is that you can then simply add extra disks into the big collection and allocate space to existing logical volumes - ie grow them. Primarily you may have a partition that starts on one disk and ends on another (and should embody one other in the middle!)
Why not simply use LVM?

LVM only allows you to mirror or stripe - we wish resilience but mirroring is unhealthy - we need to buy twice as much storage as we would like (or more realistically - we solely end up using half of what we will afford wink ).
How many disks?

For raid5 you need a minimum of 3. You can go up from there, and every extra drive adds that much more space. You have to do a little pre-planning as it's not necessarily straightforward so as to add drives to the array after it is constructed. LVM also adds to this problem. There exists a utility raidreconf, however it's not well supported, and cannot operate while the drive is mounted. It is also doubtful you could resize the lvm bodily volume. As such to add drives, you'll have to copy the information off, and re-create the array. Maintain this in mind earlier than you retailer 600 Gb of data, after which might want to copy it off somewhere.

The Answer

Do both smile

    * Create a raid5 array and add it to our 'box'.
    * Then we make a filesystem from the area within the box.
    * In the future we will add one other array and add that to the field too.
    * Then we are able to 'grow' the filesystem.

Oh yes - that's one other thing. You could use a filesystem that can grow - so either Reiser or XFS. XFS cannot shrink so (despite having labored for SGI myself) I might use Reiser. (You want to set data=sorted as kernel parameter on pre 2.6.6 kernels so a power outage will not cause information loss). [Later edit: I changed my mind after having had just a few corruptions - I now have pure XFS]

Reiser shouldn't be a good choice for delusion, as it's good for small information, not very giant files. XFS is the most effective choice.