Re: Getting EVMS working again after mdadm --grow
Steve Dobbelstein <[email protected]> Tue, 4 Nov 2008 17:29:40 -0600
| Newsgroups | gmane.linux.evms.devel |
|---|---|
| Message-ID | <OF275F6AD2.54E19171-ON862574F7.007DB8F4-862574F7.00811102@us.ibm.com> |
--===============3062293699157058939== Content-type: multipart/alternative; Boundary="0__=09BBFE64DFEE3E648f9e8a93df938690918c09BBFE64DFEE3E64" Content-Disposition: inline --0__=09BBFE64DFEE3E648f9e8a93df938690918c09BBFE64DFEE3E64 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Brian Kuschak <[email protected]> wrote on 11/04/2008 03:17:21 PM: > > OK. I'm crawling through the LVM2 plug-in code. I see > > the place where it > > logs the warning, "Object %s recorded size > > (%"PRIu64") does not match > > actual size (%"PRIu64")\n", which is > > what you see in your log. It is the > > else side of an if clause that checks if it should display > > the device size > > prompt. Apparently, the setting for the device size prompt > > is "no", > > otherwise instead of logging a message it would have put up > > a prompt asking > > you if the object was indeed a PV. Look at your > > /etc/evsm.conf file. In > > the "lvm2" section there is an option > > "device_size_prompt". I will bet it > > is set to "no". Try changing it to > > "yes". When you are prompted whether > > md/md0 is an LVM2 PV, answer "yes". Be sure to > > answer "no" for the other > > objects, such as sd[acdef]. Answering "yes" for > > md/md0 will cause the LVM2 > > plug-in to write the correct object size to the LVM > > metadata. Once you are > > finished, change the setting of > > "device_size_prompt" back to "no" or > > else > > you will be asked if sd[acdef] are PVs every time you start > > EVMS. > > I followed your instructions and it appears that things are working > again! Yea!! Woohoo! > I do still see these messages about size mismatch, though: > > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label on > object sde, sector 1. > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sde recorded > size (2500527104) does not match actual size (1250263728) > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label on > object sdd, sector 1. > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sdd recorded > size (2500527104) does not match actual size (1250263728) > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label on > object sdc, sector 1. > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sdc recorded > size (625163264) does not match actual size (312581808) > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label on > object sda, sector 1. > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sda recorded > size (625163264) does not match actual size (321672960) > > Do I need to worry about these? No, don't worry about them. As I mentioned in my previous note, just s= et "device_size_prompt" back to "no" in /etc/evsm.conf. You are always guaranteed to get at least one of those messages when yo= u use MD devices in an LVM container. At least one of the MD disks is go= ing to have the LVM2 metadata at the front of the disk because that disk is= at the beginning of the MD device. The size recorded in the LVM metadata = is the size of the MD device. But when the LVM2 plug-in examines the disk= , say, sdd, it will see that the size in the LVM metadata does not match = the size of sdd. The LVM2 plug-in should ignore the disk and wait until md= /md0 is created. When it examines md/md0 it will see that the size in the metadata matches the size of the device and will use it as a PV. On a RAID5 array you should only have one disk that contains the LVM2 metadata, because only one disk contains the first sectors of the MD device. That you have more than one disk presenting the error probably= means you have stale LVM metadata on those other disks. It can be igno= red. The metadata will be part of the free space on the md/md0 device. > One thing that is different, however, is that previously the volumes > page showed /dev/evms/big_volume as my mounted object, and this is > what I activate in my sysinit script. After the fixes, this is now > shown as /dev/evms/lvm2/lvm_on_raid_group_120/big_volume. I updated > my init script with this object and it mounts properly. I'm just > curious: why the change? > > -Brian Your volume has changed from an "EVMS volume" to a "compatibility volum= e". When you create an EVMS volume you give it a name that is meaningful to= you. A compatibility volume cannot be named. Its name is compatible w= ith what Linux would call the volume. In your case, under standard Linux t= he volume would be accessed as /dev/lvm2/lvm_on_raid_group_120/big_volume.= Why did the volume change? EVMS keeps its information about an EVMS vo= lume on the last two sectors of the device. The volume size presented is tw= o sectors less than the size of the device. When you expanded the big_vo= lume LV the EVMS metadata was no longer in the last two sectors of the devic= e. Without the EVMS metadata, EVMS created a compatibility volume instead = of an EVMS volume. What can you do about it? You *may* be able to select the volume and b= e presented with an option to convert it to an EVMS volume. EVMS will no= t present the option if it cannot safely overwrite the last two sectors o= n the LV. Sometimes a file system doesn't allocate all of the available sectors. For example, a file system that allocates in 4KB chunks (8 sectors) will leave 5 sectors free on a device with 800005 sectors. If= that is the case then EVMS can use the unused sectors. Sometimes EVMS = can shrink the volume to make room for the two sectors it needs. I am goin= g to guess that is your case you will not be able to convert the volume to a= n EVMS volume. LVM serves up volumes in multiples of its chunk size, say= , 4MB, which is most likely a multiple of the XFS allocation size, so the= re won't be any unused sectors. XFS does not do shrinking, so EVMS will n= ot be able to create the space that it needs for its metadata. EVMS won't= be able to create its metadata for an EVMS volume, so it won't let you con= vert it. :( At least you have it working using the compatibility volume. Steve D.= --0__=09BBFE64DFEE3E648f9e8a93df938690918c09BBFE64DFEE3E64 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p><tt>Brian Kuschak <[email protected]> wrote on 11/04/2008 03:= 17:21 PM:<br> <br> > > OK. I'm crawling through the LVM2 plug-in code. I= see<br> > > the place where it<br> > > logs the warning, "Object %s recorded size<br> > > (%"PRIu64") does not match<br> > > actual size (%"PRIu64")\n", which is<br> > > what you see in your log. It is the<br> > > else side of an if clause that checks if it should display<br= > > > the device size<br> > > prompt. Apparently, the setting for the device size pro= mpt<br> > > is "no",<br> > > otherwise instead of logging a message it would have put up<b= r> > > a prompt asking<br> > > you if the object was indeed a PV. Look at your<br> > > /etc/evsm.conf file. In<br> > > the "lvm2" section there is an option<br> > > "device_size_prompt". I will bet it<br> > > is set to "no". Try changing it to<br> > > "yes". When you are prompted whether<br> > > md/md0 is an LVM2 PV, answer "yes". Be sure t= o<br> > > answer "no" for the other<br> > > objects, such as sd[acdef]. Answering "yes" f= or<br> > > md/md0 will cause the LVM2<br> > > plug-in to write the correct object size to the LVM<br> > > metadata. Once you are<br> > > finished, change the setting of<br> > > "device_size_prompt" back to "no" or<br> > > else<br> > > you will be asked if sd[acdef] are PVs every time you start<b= r> > > EVMS.<br> > <br> > I followed your instructions and it appears that things are workin= g <br> > again! Yea!!</tt><br> <br> <tt>Woohoo!</tt><br> <br> <tt>> I do still see these messages about size mismatch, though:<br>= > <br> > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label = on<br> > object sde, sector 1.<br> > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sde record= ed<br> > size (2500527104) does not match actual size (1250263728)<br> > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label = on<br> > object sdd, sector 1.<br> > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sdd record= ed<br> > size (2500527104) does not match actual size (1250263728)<br> > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label = on<br> > object sdc, sector 1.<br> > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sdc record= ed<br> > size (625163264) does not match actual size (312581808)<br> > Nov 04 13:12:24 netdisk _6_ LVM2: read_pv_label: Found LVM2 label = on<br> > object sda, sector 1.<br> > Nov 04 13:12:24 netdisk _3_ LVM2: check_pv_size: Object sda record= ed<br> > size (625163264) does not match actual size (321672960)<br> > <br> > Do I need to worry about these? <br> </tt><br> <tt>No, don't worry about them. As I mentioned in my previous not= e, just set "device_size_prompt" back to "no" in /e= tc/evsm.conf.</tt><br> <br> <tt>You are always guaranteed to get at least one of those messages whe= n you use MD devices in an LVM container. At least one of the MD = disks is going to have the LVM2 metadata at the front of the disk becau= se that disk is at the beginning of the MD device. The size recor= ded in the LVM metadata is the size of the MD device. But when th= e LVM2 plug-in examines the disk, say, sdd, it will see that the size i= n the LVM metadata does not match the size of sdd. The LVM2 plug-= in should ignore the disk and wait until md/md0 is created. When = it examines md/md0 it will see that the size in the metadata matches th= e size of the device and will use it as a PV.</tt><br> <br> <tt>On a RAID5 array you should only have one disk that contains the LV= M2 metadata, because only one disk contains the first sectors of the MD= device. That you have more than one disk presenting the error pr= obably means you have stale LVM metadata on those other disks. It= can be ignored. The metadata will be part of the free space on t= he md/md0 device.</tt><br> <tt><br> > One thing that is different, however, is that previously the volum= es<br> > page showed /dev/evms/big_volume as my mounted object, and this is= <br> > what I activate in my sysinit script. After the fixes, this = is now <br> > shown as /dev/evms/lvm2/lvm_on_raid_group_120/big_volume. I = updated<br> > my init script with this object and it mounts properly. I'm = just <br> > curious: why the change? <br> > <br> > -Brian<br> </tt><br> <tt>Your volume has changed from an "EVMS volume" to a "= compatibility volume". When you create an EVMS volume you gi= ve it a name that is meaningful to you. A compatibility volume ca= nnot be named. Its name is compatible with what Linux would call = the volume. In your case, under standard Linux the volume would b= e accessed as /dev/lvm2/lvm_on_raid_group_120/big_volume.</tt><br> <br> <tt>Why did the volume change? EVMS keeps its information about a= n EVMS volume on the last two sectors of the device. The volume s= ize presented is two sectors less than the size of the device. Wh= en you expanded the big_volume LV the EVMS metadata was no longer in th= e last two sectors of the device. Without the EVMS metadata, EVMS= created a compatibility volume instead of an EVMS volume.</tt><br> <br> <tt>What can you do about it? You *may* be able to select the vol= ume and be presented with an option to convert it to an EVMS volume. &n= bsp;EVMS will not present the option if it cannot safely overwrite the = last two sectors on the LV. Sometimes a file system doesn't alloc= ate all of the available sectors. For example, a file system that= allocates in 4KB chunks (8 sectors) will leave 5 sectors free on a dev= ice with 800005 sectors. If that is the case then EVMS can use th= e unused sectors. Sometimes EVMS can shrink the volume to make ro= om for the two sectors it needs. I am going to guess that is your= case you will not be able to convert the volume to an EVMS volume. &nb= sp;LVM serves up volumes in multiples of its chunk size, say, 4MB, whic= h is most likely a multiple of the XFS allocation size, so there won't = be any unused sectors. XFS does not do shrinking, so EVMS will no= t be able to create the space that it needs for its metadata. EVM= S won't be able to create its metadata for an EVMS volume, so it won't = let you convert it. :( At least you have it working using t= he compatibility volume.</tt><br> <br> <tt>Steve D.</tt><br> </body></html>= --0__=09BBFE64DFEE3E648f9e8a93df938690918c09BBFE64DFEE3E64-- --===============3062293699157058939== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ --===============3062293699157058939== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Evms-devel mailing list [email protected] To subscribe/unsubscribe, please visit: https://lists.sourceforge.net/lists/listinfo/evms-devel --===============3062293699157058939==--