Menu
▾
▴
evms-devel — General questions, bug reports, and development discussions about EVMS
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(19) |
Jun
(30) |
Jul
(49) |
Aug
(9) |
Sep
(87) |
Oct
(90) |
Nov
(80) |
Dec
(51) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(166) |
Feb
(135) |
Mar
(102) |
Apr
(100) |
May
(99) |
Jun
(65) |
Jul
(163) |
Aug
(148) |
Sep
(105) |
Oct
(461) |
Nov
(254) |
Dec
(117) |
| 2003 |
Jan
(76) |
Feb
(94) |
Mar
(127) |
Apr
(159) |
May
(235) |
Jun
(212) |
Jul
(147) |
Aug
(83) |
Sep
(64) |
Oct
(162) |
Nov
(303) |
Dec
(73) |
| 2004 |
Jan
(107) |
Feb
(118) |
Mar
(120) |
Apr
(65) |
May
(121) |
Jun
(83) |
Jul
(70) |
Aug
(88) |
Sep
(152) |
Oct
(159) |
Nov
(187) |
Dec
(74) |
| 2005 |
Jan
(166) |
Feb
(178) |
Mar
(118) |
Apr
(151) |
May
(89) |
Jun
(111) |
Jul
(174) |
Aug
(69) |
Sep
(92) |
Oct
(77) |
Nov
(126) |
Dec
(96) |
| 2006 |
Jan
(88) |
Feb
(122) |
Mar
(174) |
Apr
(55) |
May
(33) |
Jun
(126) |
Jul
(91) |
Aug
(46) |
Sep
(80) |
Oct
(74) |
Nov
(53) |
Dec
(83) |
| 2007 |
Jan
(57) |
Feb
(30) |
Mar
(49) |
Apr
(50) |
May
(31) |
Jun
(59) |
Jul
(20) |
Aug
(29) |
Sep
(12) |
Oct
(7) |
Nov
(11) |
Dec
(35) |
| 2008 |
Jan
(1) |
Feb
(2) |
Mar
(12) |
Apr
(6) |
May
|
Jun
(1) |
Jul
(6) |
Aug
(14) |
Sep
(14) |
Oct
(7) |
Nov
(10) |
Dec
(8) |
| 2009 |
Jan
|
Feb
|
Mar
(2) |
Apr
(5) |
May
|
Jun
(1) |
Jul
|
Aug
(7) |
Sep
(8) |
Oct
(4) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew S. <an...@al...> - 2010-04-21 13:55:38
|
This question is directed especially to the former EVMS team at IBM, but in general to all of us who've finally had to abandon EVMS: Does anyone know of any other tool that's something like a replacement for EVMS? Something that integrates partition, logical volume, and file system management in one interface (not to mention the three parallel interfaces that EVMS offered)? What software is IBM using, recommending, or providing for enterprise storage management these days? What other software, if any, did it have in mind when it decided to abandon EVMS? I've looked around quite a bit, and while the quality of the GUI tools has improved, in general it's the same old hodgepodge that existed before EVMS-- one tool for partition management, another for logical volume management. Thanks, Andrew. |
|
From: Mauro S. <mau...@co...> - 2009-10-12 21:30:43
|
John Huttley ha scritto: > Thats interesting. > Evms isn't under development anymore and doesn't run with MD on kernels > 2.6.28 and later. > Go with lvm, evms is dead. |
|
From: Carruth, R. <Rus...@sm...> - 2009-10-12 21:22:32
|
> -----Original Message----- > From: Mauro Sanna > John Huttley ha scritto: > > Thats interesting. > > Evms isn't under development anymore and doesn't run with MD on kernels > > 2.6.28 and later. > > > Go with lvm, evms is dead. Actually, I went with raw devicemapper, and created all the config info I needed to be able to create and run (when booting after a configuration step) all the partitions I could possibly need, even though I'm using scsi disks (from the point of the view of Linux, anyway). Once getting LVM compiled on the xscale system (that this is targeted to) is an option, I will consider going to LVM then. Rusty |
|
From: Carruth, R. <Rus...@sm...> - 2009-10-12 20:03:20
|
> -----Original Message----- > From: John Huttley [mailto:Jo...@mi...] > Sent: Monday, October 12, 2009 11:57 AM > To: Carruth, Rusty > Cc: evm...@li... > Subject: Re: [Evms-devel] EVMS bug - anybody working to fix bugs any more? > > Thats interesting. > Evms isn't under development anymore and doesn't run with MD on kernels > 2.6.28 and later. Well, we are using evms 2.5.3 with kernel 2.6.18 > > So, no one is fixing anything, but by the same token, no one is breaking > anything either. > > In practice it shouldn't make much difference, since EVMS will use it > based on its UUID. That's all well and good if it worked right. :-) Randomly EVMS will decide that it sees a UUID on a drive, when no such UUID should exist (since nobody created such a UUID on that drive). I do not THINK that this happens when we hot-plug a disk. > > Its not something that I've seen before, though I was wondering how many > disks are on your system? Usually either 1 or 3. It happens most when using 3, but I think that's more because we don't use all the disk space when using 3 disks, but usually DO use it all when using only 1 disk. > Are you hot-plugging disk drivers? Not the drivers, no. However, we do hot-plug disks sometimes. I don't think that this 'raid 255' event is triggered by a hot-plug event, though. IIRC it happens more-or-less randomly (so far as I can tell right now, anyway. Since these happen much more at our customer site than here it's hard to be sure). I did find a reference somewhere to EVMS looking for things starting at 255 and going down from there. Ah, here it is: http://marc.info/?l=evms-devel&m=113761621512057&w=2 Don't know if that is related to this at all or not, but it was interesting to me that they said it started at 255 and worked down - which is exactly what I saw. Thanks! Rusty > > > Regards, > John > > Carruth, Rusty wrote: > > We've discovered an unpleasant bug in EVMS. > > > > Randomly it will decide that there is a raid array 255 present when we > > have not created such a beast. It has even been known to create > > lower-numbered ones as well (254, 253, etc). > > > > Evms says its command line interpreter version 2.5.3 > > > > I looked at the fix logs for 2.5.4 and 2.5.5, and do not see any > > reference to this, other than something in an email from Mike Tran on > > the devel list in 2006 about how evms 'handles the conflict by assigning > > late arriving MD regions starting at 255 downward' (or something like > > that). > > > > But I *have* (supposedly) no late-arriving MD regions! Where is evms > > getting the idea that such a thing exists??? > > > > Has anyone seen this? Or have any clue what I'm talking about? > > > > Has it been fixed? > > > > Thanks! > > > > Rusty > > > > > > ------------------------------------------------------------------------ > ------ > > Come build with us! The BlackBerry® Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and > stay > > ahead of the curve. Join us from November 9-12, 2009. Register > now! > > http://p.sf.net/sfu/devconf > > _______________________________________________ > > Evms-devel mailing list > > Evm...@li... > > To subscribe/unsubscribe, please visit: > > https://lists.sourceforge.net/lists/listinfo/evms-devel > > > > > > Rusty Carruth | CSE SSD Storage Products Division | SMART Modular Technologies Adtron Corporation | 4415 E. Cotton Center Blvd | Phoenix, AZ 85040 Office: 602-735-0300 | Fax: 602-735-0349 | Email: Rus...@sm... | www.smartm.com |
|
From: John H. <Jo...@mi...> - 2009-10-12 18:57:20
|
Thats interesting. Evms isn't under development anymore and doesn't run with MD on kernels 2.6.28 and later. So, no one is fixing anything, but by the same token, no one is breaking anything either. In practice it shouldn't make much difference, since EVMS will use it based on its UUID. Its not something that I've seen before, though I was wondering how many disks are on your system? Are you hot-plugging disk drivers? Regards, John Carruth, Rusty wrote: > We've discovered an unpleasant bug in EVMS. > > Randomly it will decide that there is a raid array 255 present when we > have not created such a beast. It has even been known to create > lower-numbered ones as well (254, 253, etc). > > Evms says its command line interpreter version 2.5.3 > > I looked at the fix logs for 2.5.4 and 2.5.5, and do not see any > reference to this, other than something in an email from Mike Tran on > the devel list in 2006 about how evms 'handles the conflict by assigning > late arriving MD regions starting at 255 downward' (or something like > that). > > But I *have* (supposedly) no late-arriving MD regions! Where is evms > getting the idea that such a thing exists??? > > Has anyone seen this? Or have any clue what I'm talking about? > > Has it been fixed? > > Thanks! > > Rusty > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Evms-devel mailing list > Evm...@li... > To subscribe/unsubscribe, please visit: > https://lists.sourceforge.net/lists/listinfo/evms-devel > > > |
|
From: Carruth, R. <Rus...@sm...> - 2009-09-28 23:57:55
|
We've discovered an unpleasant bug in EVMS. Randomly it will decide that there is a raid array 255 present when we have not created such a beast. It has even been known to create lower-numbered ones as well (254, 253, etc). Evms says its command line interpreter version 2.5.3 I looked at the fix logs for 2.5.4 and 2.5.5, and do not see any reference to this, other than something in an email from Mike Tran on the devel list in 2006 about how evms 'handles the conflict by assigning late arriving MD regions starting at 255 downward' (or something like that). But I *have* (supposedly) no late-arriving MD regions! Where is evms getting the idea that such a thing exists??? Has anyone seen this? Or have any clue what I'm talking about? Has it been fixed? Thanks! Rusty |
|
From: Steinar H. G. <sgu...@bi...> - 2009-09-16 11:26:50
|
On Wed, Sep 16, 2009 at 10:02:46PM +1200, John Huttley wrote: > However i've discovered that i just do not have the time (and not much > of the skill) to do it. > > We need a white knight... Isn't this why EVMS is dead? :-) No white knights. /* Steinar */ -- Homepage: http://www.sesse.net/ |
|
From: John H. <Jo...@mi...> - 2009-09-16 10:03:03
|
Yes its broken. However I don't think the problem is fundamentally difficult since evms is pure userspace. Very likely the result of a small change in the device-mapper API. I was getting ready to have a look it by git -bisect to find the change set reponsible. Doing this stuff on a working machine is a PINA, so I'm powering up a proxmox server for testing. Virtualbox might even be more convenient. The idea is having modest working system on one virtual disk and then building a raid array with 2 more. However i've discovered that i just do not have the time (and not much of the skill) to do it. We need a white knight... Regards, John Andrew Schulman wrote: > John, do you know specifically what has broken EVMS' MD management in kernel > 2.6.29 and later? I posted a question about that problem here > (http://www.nabble.com/%22array-md0-already-has-disks%22-with-kernel-2.6.29-td23131323.html) > and there's a Gentoo bug report about it > (http://bugs.gentoo.org/show_bug.cgi?id=273902). No one seems to know what the > problem is. If EVMS is really permanently broken as of kernel 2.6.29, we need > to know that. > > Thanks, Andrew. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Evms-devel mailing list > Evm...@li... > To subscribe/unsubscribe, please visit: > https://lists.sourceforge.net/lists/listinfo/evms-devel > > > |
|
From: Andrew S. <an...@al...> - 2009-09-16 01:17:07
|
> I would not recommend using evms. > Kernel changes in 2.6.29 and later are incompatible with evms's MD > management code. > > Evms support has been quietly dropped by IBM and no one else has been > working on it. > Its very sad. Yes, sadly, this is true. EVMS is dying or dead and there's nothing else on the horizon that looks to be anywhere close to as good. system-config-lvm shows promise, but it doesn't handle RAID. John, do you know specifically what has broken EVMS' MD management in kernel 2.6.29 and later? I posted a question about that problem here (http://www.nabble.com/%22array-md0-already-has-disks%22-with-kernel-2.6.29-td23131323.html) and there's a Gentoo bug report about it (http://bugs.gentoo.org/show_bug.cgi?id=273902). No one seems to know what the problem is. If EVMS is really permanently broken as of kernel 2.6.29, we need to know that. Thanks, Andrew. |
|
From: John H. <Jo...@mi...> - 2009-09-15 21:26:57
|
I would not recommend using evms. Kernel changes in 2.6.29 and later are incompatible with evms's MD management code. Evms support has been quietly dropped by IBM and no one else has been working on it. Its very sad. --john aur...@gm... wrote: > Hi, > > Before I install EVMS on my Centos 5.3x64 box (unsure it will even > install), I would like to know wether I need to even build a new > kernel if all I desire is a GUI to create, manage, rebuild software > Raids formatted using XFS file system. > > I'm fine with mdadm cli, however I have some users that would prefer a > GUI and have threatened me with installing OpenSolaris for its web > front end to ZFS Raid management. > > I'm sure OpenSolaris is a fine OS but would rather stick to Centos. > > Thanks in advance, > > - aurf > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Evms-devel mailing list > Evm...@li... > To subscribe/unsubscribe, please visit: > https://lists.sourceforge.net/lists/listinfo/evms-devel > > > |
|
From: <aur...@gm...> - 2009-09-15 21:13:06
|
Thanks John. Bummer. - aurf On Sep 15, 2009, at 2:06 PM, John Huttley wrote: > I would not recommend using evms. > Kernel changes in 2.6.29 and later are incompatible with evms's MD > management code. > > Evms support has been quietly dropped by IBM and no one else has > been working on it. > Its very sad. > > --john > > > > > > aur...@gm... wrote: >> Hi, >> >> Before I install EVMS on my Centos 5.3x64 box (unsure it will even >> install), I would like to know wether I need to even build a new >> kernel if all I desire is a GUI to create, manage, rebuild >> software Raids formatted using XFS file system. >> >> I'm fine with mdadm cli, however I have some users that would >> prefer a GUI and have threatened me with installing OpenSolaris >> for its web front end to ZFS Raid management. >> >> I'm sure OpenSolaris is a fine OS but would rather stick to Centos. >> >> Thanks in advance, >> >> - aurf >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports >> 2008 30-Day trial. Simplify your report design, integration and >> deployment - and focus on what you do best, core application >> coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Evms-devel mailing list >> Evm...@li... >> To subscribe/unsubscribe, please visit: >> https://lists.sourceforge.net/lists/listinfo/evms-devel >> >> >> > |
|
From: Steve D. <st...@us...> - 2009-09-15 15:51:52
|
aur...@gm... wrote on 09/13/2009 12:11:27 AM: > Hi, > > Before I install EVMS on my Centos 5.3x64 box (unsure it will even > install), I would like to know wether I need to even build a new > kernel if all I desire is a GUI to create, manage, rebuild software > Raids formatted using XFS file system. > > I'm fine with mdadm cli, however I have some users that would prefer a > GUI and have threatened me with installing OpenSolaris for its web > front end to ZFS Raid management. > > I'm sure OpenSolaris is a fine OS but would rather stick to Centos. > > Thanks in advance, > > - aurf You do not have to build a new kernel to use EVMS. Unless you use the bbr_seg plug-in, EVMS has no runtime code; it just does configuration. You can use EVMS to setup your MD devices. However, note that EVMS will use device-mapper instead of MD for linear and RAID0 mappings. That's because the linear and RAID0 mapping can be done easily and with a shorter code path by using device-mapper. The MD kernel component does not have to get involved. EVMS does use the MD kernel component for RAID1 (mirroring) and RAID4/RAID5. Although you can probably use mdadm to manage arrays created by EVMS, it is better to stick with EVMS once you have started using it. For example, EVMS stores some extra metadata in the MD superblock area that mdadm won't preserve since it knows nothing about it. Steve D. |
|
From: <aur...@gm...> - 2009-09-13 05:11:43
|
Hi, Before I install EVMS on my Centos 5.3x64 box (unsure it will even install), I would like to know wether I need to even build a new kernel if all I desire is a GUI to create, manage, rebuild software Raids formatted using XFS file system. I'm fine with mdadm cli, however I have some users that would prefer a GUI and have threatened me with installing OpenSolaris for its web front end to ZFS Raid management. I'm sure OpenSolaris is a fine OS but would rather stick to Centos. Thanks in advance, - aurf |
|
From: Steve D. <st...@us...> - 2009-08-28 15:46:48
|
Bernward Platz <Ber...@cl...> wrote on 08/27/2009 01:40:29 AM: > Hi Steve, > > thank you very much for you answer! I did the expansion in the same > way you described. But there war something strange: During the > expansion I have seen in the process table a > > fsck.ex3 and then > > a > > resize2fs > > I can not understand this. the emvs gui display that the plugin of > the volume is XFS and the volume is also mounted as XFS-filesystem. > > Can you help? > > Thanks and regards > > Bernward Hi, Bernward. I, too, cannot understand that. Looking at the code I don't see an obvious way that the xfs plug-in would launch ext3 utilities. You may want to check to make sure that fsck.ex3 and resize2fs are being launched by EVMS an not by some other process by coincidence. If you can reproduce the problem it would be helpful to turn on debugging and look at the log file. Run "evms[n,gui] -d debug" to set the debug level to "debug". Once you have reproduced the problem, look at /var/log/evms-engine.log. It will have a lot of information. Search for "evms_commit_changes" to get to the part where EVMS starts saving the changes. Search for "resize2fs" to see if it was EVMS that launched resize2fs, and if so which component of EVMS did it. If you need help looking at the log you can gzip it (it will be a large file) and send it to me and I will take a look. Steve D. |
|
From: Bernward P. <Ber...@cl...> - 2009-08-26 07:42:30
|
Hello, I have a question regarding expanding a evms-volume. Expanding a evms-volume from 4.2TB to 6.4TB was working fine, but if i want also to expand the unterlying xfs-filesystem with xfs_growfs I got a "data size 488369967 too small, old size is 1120493536". I am using evms 2.5.5 on SLES 10. Is this the right forum? Thanks Bernward |
|
From: Adrian P. <ad...@ph...> - 2009-08-24 19:08:11
|
>>>>> "Steven" == Steven <st...@wh...> writes:
Steven> Hi people I have a broken old system with 2x 250GB drives,
Steven> in raid 1, with BBR on it. Since the old system was a
Steven> very trimmed down gentoo I couldn't boot it on other
Steven> hardware, so I tried to recover the drives with a fresh
Steven> debian etch install.
I would suggest dropping back to older releases - I've systems
installed with Debian, upgraded, then to Ubuntu which used EVMS and
now migrated to LVM2, where I had to keep using an older kernel to
begin with exactly because of this problem (no module support for some
EVMS "extensions"). I'd start with Debian sarge or an older Ubuntu
version, something before gutsy should do.
Sincerely,
Adrian Phillips
--
Who really wrote the works of William Shakespeare ?
http://www.pbs.org/wgbh/pages/frontline/shakespeare/
|
|
From: Anthony M. <anm...@li...> - 2009-08-24 16:45:12
|
Andrew Schulman wrote: >> I have a broken old system with 2x 250GB drives, in raid 1, with BBR on it. >> Since the old system was a very trimmed down gentoo I couldn't boot it >> on other hardware, so I tried to recover the drives with a fresh debian >> etch install. >> >> But now I can't get it to work. I compiled my own kernel (2.6.15.7), >> patched it according to the installation instructions, but it ends >> either of 2 ways: >> - If I try to activate the volumes I get an error in EVMS, and some >> notices from devicemapper, saying failed to insert target (bbr) >> - Or I just can't see any SATA disks at all (system is on a IDE drive so >> that boots fine) >> >> Can anyone tell me which distro/setup still supports EVMS+BBR ? >> If not, is there another way (without evms) to recover the data from >> those disks ? It contains my complete photo collection for almost over >> 10 years, and it would be an emotional disaster to loose all those pictures. >> > > Distros and kernels that support EVMS are becoming scarce. Sadly, it's the > death spiral of EVMS. > > The last I looked, SystemRescueCd (http://www.sysresccd.org/Main_Page) > supported EVMS. Not sure about BBR, though. IIRC there's a kernel module, > dm_bbr, that you have to build and insert in order to use BBR? > > When migrating my Gentoo systems away from EVMS to plain old mdadm and/or LVM2 I used older Gentoo Live book CD's that worked just great. They had both EVMS and LVM2 working. You can find a live-cd in your favorite Gentoo Mirror <http://www.gentoo.org/main/en/mirrors2.xml>'s /releases/ folder. > I don't think there's any way to read those drives except by EVMS+BBR. > However, I don't see any reason that you shouldn't be able to build a > kernel to do that, as long as you have the EVMS packages. They're gone > from the Debian archives now, but are still available-- let us know if you > need them. > > Andrew. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Evms-devel mailing list > Evm...@li... > To subscribe/unsubscribe, please visit: > https://lists.sourceforge.net/lists/listinfo/evms-devel > |
|
From: Andrew S. <an...@al...> - 2009-08-24 16:12:49
|
> I have a broken old system with 2x 250GB drives, in raid 1, with BBR on it. > Since the old system was a very trimmed down gentoo I couldn't boot it > on other hardware, so I tried to recover the drives with a fresh debian > etch install. > > But now I can't get it to work. I compiled my own kernel (2.6.15.7), > patched it according to the installation instructions, but it ends > either of 2 ways: > - If I try to activate the volumes I get an error in EVMS, and some > notices from devicemapper, saying failed to insert target (bbr) > - Or I just can't see any SATA disks at all (system is on a IDE drive so > that boots fine) > > Can anyone tell me which distro/setup still supports EVMS+BBR ? > If not, is there another way (without evms) to recover the data from > those disks ? It contains my complete photo collection for almost over > 10 years, and it would be an emotional disaster to loose all those pictures. Distros and kernels that support EVMS are becoming scarce. Sadly, it's the death spiral of EVMS. The last I looked, SystemRescueCd (http://www.sysresccd.org/Main_Page) supported EVMS. Not sure about BBR, though. IIRC there's a kernel module, dm_bbr, that you have to build and insert in order to use BBR? I don't think there's any way to read those drives except by EVMS+BBR. However, I don't see any reason that you shouldn't be able to build a kernel to do that, as long as you have the EVMS packages. They're gone from the Debian archives now, but are still available-- let us know if you need them. Andrew. |
|
From: Steven <st...@wh...> - 2009-08-24 15:26:40
|
Hi people I have a broken old system with 2x 250GB drives, in raid 1, with BBR on it. Since the old system was a very trimmed down gentoo I couldn't boot it on other hardware, so I tried to recover the drives with a fresh debian etch install. But now I can't get it to work. I compiled my own kernel (2.6.15.7), patched it according to the installation instructions, but it ends either of 2 ways: - If I try to activate the volumes I get an error in EVMS, and some notices from devicemapper, saying failed to insert target (bbr) - Or I just can't see any SATA disks at all (system is on a IDE drive so that boots fine) Can anyone tell me which distro/setup still supports EVMS+BBR ? If not, is there another way (without evms) to recover the data from those disks ? It contains my complete photo collection for almost over 10 years, and it would be an emotional disaster to loose all those pictures. I hope someone reads this and maybe can help me. Thanks in advance :-) Steven |
|
From: David <wri...@gm...> - 2009-08-05 14:24:18
|
Hi, Noticed that the "Gentoo" link on this <http://evms.sourceforge.net/> page is broken. Just FYI. (slightly off-topic, would be neat if EVMS supported the BTRFS filesystem). -David |
|
From: Nils K. <ni...@st...> - 2009-06-18 18:36:46
|
Hi! I have a setup with three software RAID arrays, which have been combined into one LVM2 container in EVMS. I had some trouble with harddisks in one of the RAID arrays, but I'm pretty sure that the data in the array is fine. When I boot a Live CD without EVMS and issue a 'vgdisplay --verbose' I get the following: --- Volume group --- VG Name datacontainer1 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 27 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 3 Act PV 3 VG Size 2.66 TB PE Size 32.00 MB Total PE 87150 Alloc PE / Size 87150 / 2.66 TB Free PE / Size 0 / 0 VG UUID y1wkSA-Mp1z-3oRj-3fTU-9aVA-ZIQN-llWqUP --- Logical volume --- LV Name /dev/datacontainer1/dataregion VG Name datacontainer1 LV UUID RnmAbY-2fD6-serM-0X6g-hQVf-Vo1F-FLZhDR LV Write Access read/write LV Status available # open 0 LV Size 2.66 TB Current LE 87150 Segments 5 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2 --- Physical volumes --- PV Name /dev/md3 PV UUID gsyju6-kCtO-0ut2-rQxb-Jj56-jQJf-WtPnKn PV Status allocatable Total PE / Free PE 35770 / 0 PV Name /dev/md1 PV UUID P0nWTm-7clc-Fr8n-p2Ph-UmAE-VrqD-fEqTZ0 PV Status allocatable Total PE / Free PE 29808 / 0 PV Name /dev/md125 PV UUID HjSvH5-7zK1-udaX-CoD3-qWak-PYAv-XNtaPi PV Status allocatable Total PE / Free PE 21572 / 0 So I assumed that the PV on /dev/md3 is working. But back in the installed OS EVMS tells me this: LVM2: The PV with index 0 was not found when discovering container lvm2/datacontainer1. An "error" object will be created in it's place. Any regions in this container that map to this PV will return I/O errors if they attempt to read or write to this PV. Regions that don't map to this PV will work normally. and thus I cannot mount the volume either. So, is /dev/md3 probably broken even though lvdisplay list it? I do have dd-copies of the RAID5 elements and maybe I have assembled the RAID array in the wrong order..? Any help is appreciated, thanks. Nils |
|
From: Andrew S. <an...@al...> - 2009-04-21 10:37:29
|
> > The /linuxrc script > > in my initrd > > tries to drop me into a shell when it can't mount the root FS, but > > with 2.6.29 > > the shell is unresponsive-- no input or output. > > Does the new kernel has modular USB-HID or any other threat that would > prevent modules managing your keyboard to load ? Hm, there are some differences in HID configuration-- I'll look into that. > Similar problems trying to get > 2.6.28; but unsure if they match > yours. I'm using Gentoo linux and my problem sounds related to using > an evms_activate binary compiled a long time ago. Maybe time to > recompile against current libraries just before putting it in the > initrd... My initrd has a complete chroot environment, including evms_activate, that's been stable for a couple of years. I did just try updating the initrd, and there's no change. And evms_activate still works fine with 2.6.26. CONFIG_MD_AUTODETECT is new in the kernel since 2.6.26. I have it set to N, which seems probably best, but maybe I'll try Y to see if it helps. If I can't solve this, then eventually it will be the final push that forces me to abandon EVMS. What a shame. Thanks, Andrew. |
|
From: Steve D. <st...@us...> - 2009-04-20 18:33:36
|
Sorry, Jason. I didn't mean to call you Jim. I don't know where that came from. My apologies.> Steve D. ----- Forwarded by Steve Dobbelstein/Austin/IBM on 04/20/2009 01:32 PM ----- Steve Dobbelstein/Austin/IBM wrote on 04/20/2009 12:50:12 PM: > Steve Dobbelstein/Austin/IBM > 04/20/2009 12:50 PM > > To > > "Jason Ngim" <jas...@os...> > > cc > > evm...@li..., evm...@li... > > Subject > > Re: [Evms-cluster] Expanding OCFS2 Partition after LUN has been > increased in size > > "Jason Ngim" <jas...@os...> wrote on 04/13/2009 07:01:37 AM: > > > "Jason Ngim" <jas...@os...> > > 04/13/2009 07:01 AM > > > > To > > > > <evm...@li...> > > > > cc > > > > Subject > > > > [Evms-cluster] Expanding OCFS2 Partition after LUN has been > increased in size > > > > Dear Gurus > > > > I have a SAN storage connected to 2 servers using Fibre Optics. > > > > In it i have created 4 LUNs. for future expansions, the LUNS will be > > resized to be bigger, and the OCFS2 partition will also be expanded. > > Please tell me how i can achieve it using EVMS. > > > > example: > > > > before > > /dev/sdb 50GB > > /dev/sdb1 50GB (formated using OCFS2) > > > > after > > /dev/sdb 100GB > > /dev/sdb1 100GB (size is also expanded not creating another > > logical partition) > > > > i would like to know how i can configure so that the /dev/sdb1 can > > be logically expanded to the new size. > > Thank you very much!! > > > > Best Regards > > Jason > Hi, Jim. > > Sorry for the late reply. > > The normal way you would go about expanding a volume is to target/ > select the volume for expansion rather than the segment. That is, > one might initially think of expanding the segment, e.g., /dev/sdb1, > first. However, since EVMS coordinates the expansion of the segment > with the expansion of the volume, it needs to know the volume that > is being expanded. After all, that is what you want in the end is a > bigger volume. > > After that explanation, here is the bad news. Looking at the source > code for the OCFS2 plug-in for EVMS, I see that it does not support > expanding or shrinking a volume. :( I assume that at the time the > author wrote the plug-in that OCFS2 did not support changing the > size of a volume. Looking on the web I see that the tune.ocfs2 > utility is supposed to allow you to change the volume size, among > other things. For now, you will have to expand the volume by hand > -- use fdisk to expand /dev/sdb1 and then use tune.ocfs2 to expand > the OCFS2 volume. You will have to do that outside of EVMS, i.e., > don't be running EVMS at the same time you do the expansion. EVMS > will not pick up the changes if you do. EVMS should pick up the > changes from your manual expansion the next time it is started. > This will work if you did a mkfs of OCFS2 on the "compatibility > volume" /dev/evms/sdb1. That is, you did not make an "EVMS volume" > from /dev/sdb1 and then put OCFS2 on the EVMS volume. > > If you made /dev/sdb1 into an EVMS volume then the procedure gets > more complicated. The metadata for the EVMS volume will need to be > migrated for the new volume size. (EVMS volume metadata appears at > the end of the device.) If you are OK with backing up and restoring > your data, the simplest thing to do would be: > 1. Backup the data. > 2. Delete the OCFS2 volume. > 3. Expand /dev/sdb1. > 4. Recreate the EVMS volume from /dev sdb1. > 5. Put OCFS2 on the volume. > 6. Restore your data. > > If you need to leave your data intact, the following procedure > should work (off the top of my head, no testing, no guarantees): > 1. Backup the data, just in case. > 2. With EVMS not running, use fdisk to expand /dev/sdb1. > 3. Temporarily move /lib/evms/<evms-version>/ocfs2* out of the /lib/ > evms/<evms-version>/ directory so that EVMS will not load the plug- > in adn therefore will not be able to recognize /dev/sdb1 as an OCFS2 volume. > 4. Start EVMS. > 5. Recreate the EVMS volume from /dev/sdb1. This will put the EVMS > volume metadata at the end of /dev/sdb1. > 6. Save the changes. You will now have a volume /dev/evms/<name>. > 7. Run tune.ocfs2 on /dev/evms/<name> to set the new size. Do not > run tune.ocfs2 on /dev/sdb1 or it will most likely blow away the > EVMS volume metadata at the end of /dev/sdb1. > 8. Move the OCFS2 plug-in back into the /lib/evms/<evms-version>/ directory. > 9. Now when you start EVMS again you should see the OCFS2 volume > with the new size. > > Your other option is to write up a patch for the OCFS2 plug-in to > give it the ability to resize OCFS2 volumes. :) > > Hope this helps. > > Steve D. |
|
From: Steve D. <st...@us...> - 2009-04-20 17:50:33
|
"Jason Ngim" <jas...@os...> wrote on 04/13/2009 07:01:37 AM: > "Jason Ngim" <jas...@os...> > 04/13/2009 07:01 AM > > To > > <evm...@li...> > > cc > > Subject > > [Evms-cluster] Expanding OCFS2 Partition after LUN has been increased in size > > Dear Gurus > > I have a SAN storage connected to 2 servers using Fibre Optics. > > In it i have created 4 LUNs. for future expansions, the LUNS will be > resized to be bigger, and the OCFS2 partition will also be expanded. > Please tell me how i can achieve it using EVMS. > > example: > > before > /dev/sdb 50GB > /dev/sdb1 50GB (formated using OCFS2) > > after > /dev/sdb 100GB > /dev/sdb1 100GB (size is also expanded not creating another > logical partition) > > i would like to know how i can configure so that the /dev/sdb1 can > be logically expanded to the new size. > Thank you very much!! > > Best Regards > Jason Hi, Jim. Sorry for the late reply. The normal way you would go about expanding a volume is to target/select the volume for expansion rather than the segment. That is, one might initially think of expanding the segment, e.g., /dev/sdb1, first. However, since EVMS coordinates the expansion of the segment with the expansion of the volume, it needs to know the volume that is being expanded. After all, that is what you want in the end is a bigger volume. After that explanation, here is the bad news. Looking at the source code for the OCFS2 plug-in for EVMS, I see that it does not support expanding or shrinking a volume. :( I assume that at the time the author wrote the plug-in that OCFS2 did not support changing the size of a volume. Looking on the web I see that the tune.ocfs2 utility is supposed to allow you to change the volume size, among other things. For now, you will have to expand the volume by hand -- use fdisk to expand /dev/sdb1 and then use tune.ocfs2 to expand the OCFS2 volume. You will have to do that outside of EVMS, i.e., don't be running EVMS at the same time you do the expansion. EVMS will not pick up the changes if you do. EVMS should pick up the changes from your manual expansion the next time it is started. This will work if you did a mkfs of OCFS2 on the "compatibility volume" /dev/evms/sdb1. That is, you did not make an "EVMS volume" from /dev/sdb1 and then put OCFS2 on the EVMS volume. If you made /dev/sdb1 into an EVMS volume then the procedure gets more complicated. The metadata for the EVMS volume will need to be migrated for the new volume size. (EVMS volume metadata appears at the end of the device.) If you are OK with backing up and restoring your data, the simplest thing to do would be: 1. Backup the data. 2. Delete the OCFS2 volume. 3. Expand /dev/sdb1. 4. Recreate the EVMS volume from /dev sdb1. 5. Put OCFS2 on the volume. 6. Restore your data. If you need to leave your data intact, the following procedure should work (off the top of my head, no testing, no guarantees): 1. Backup the data, just in case. 2. With EVMS not running, use fdisk to expand /dev/sdb1. 3. Temporarily move /lib/evms/<evms-version>/ocfs2* out of the /lib/evms/<evms-version>/ directory so that EVMS will not load the plug-in adn therefore will not be able to recognize /dev/sdb1 as an OCFS2 volume. 4. Start EVMS. 5. Recreate the EVMS volume from /dev/sdb1. This will put the EVMS volume metadata at the end of /dev/sdb1. 6. Save the changes. You will now have a volume /dev/evms/<name>. 7. Run tune.ocfs2 on /dev/evms/<name> to set the new size. Do not run tune.ocfs2 on /dev/sdb1 or it will most likely blow away the EVMS volume metadata at the end of /dev/sdb1. 8. Move the OCFS2 plug-in back into the /lib/evms/<evms-version>/ directory. 9. Now when you start EVMS again you should see the OCFS2 volume with the new size. Your other option is to write up a patch for the OCFS2 plug-in to give it the ability to resize OCFS2 volumes. :) Hope this helps. Steve D. |
|
From: Guillaume L. <gui...@ne...> - 2009-04-20 07:06:31
|
Le 20 avr. 09 à 08:54, Andrew Schulman a écrit > It does seem likely that a change in boot device order is to blame > here, but I'm > not sure how to diagnose it when I can't boot. The /linuxrc script > in my initrd > tries to drop me into a shell when it can't mount the root FS, but > with 2.6.29 > the shell is unresponsive-- no input or output. Does the new kernel has modular USB-HID or any other threat that would prevent modules managing your keyboard to load ? > Anyone else have this problem? Suggestions? Similar problems trying to get > 2.6.28; but unsure if they match yours. I'm using Gentoo linux and my problem sounds related to using an evms_activate binary compiled a long time ago. Maybe time to recompile against current libraries just before putting it in the initrd... Cheers, Guillaume Laurès |
222 messages has been excluded from this view by a project administrator.