Heinz, Thanks for your input on this, but I have now gone back to standard linux partitions on these disks and everything works fine. I am assuming that there are compatibility issues with using LVM on a 160GB disk on a promise ATA133 TX2 controller and I am going to give up on LVM for now. I would love to be able to use it, as it seems to be extremely useful, but given the teething problems i have had, I cant really rely on it. I hope to be able to try again at a later date, maybe things will have changed by then. Thanks again for your time... Leigh Waldie --------------------------------------- From: "Leigh Waldie" <lw@mih-assoc.com> To: <linux-lvm@sistina.com> Date: Thu, 4 Jul 2002 13:22:45 +0100 Subject: [linux-lvm] Re: RE: ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume group "data_disks" from physical volume(s) (Heinz J . Mauelshagen) Reply-To: linux-lvm@sistina.com Thanks for the reply... -----Original Message----- From: linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com]On Behalf Of linux-lvm-request@sistina.com Sent: 04 July 2002 10:49 >Message: 7 >Date: Thu, 4 Jul 2002 11:34:54 +0200 >From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com> >To: linux-lvm@sistina.com >Subject: Re: [linux-lvm] RE: ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume group "data_disks" from physical volume(s) >Reply-To: linux-lvm@sistina.com >On Wed, Jul 03, 2002 at 02:25:20PM +0100, Leigh Waldie wrote: >> Further... >> >> Output from pvdata /dev/hde reveals that there is no vg info on the disk, >> however there is vg info on the second disk /dev/hdb... >Then the vgcfgrestore must have been unsuccessfull :( indeed it was >"vgchange -an" is not needed. It doesn't write to the PVs it just tries >to deactivate the VGs in core. >> >> Is there any way of recovering the vg info from hdb onto hde ? >vgcfgrestore! >Look with "vgcfgrestore -ll ..." if your backup fits your config, the output from vgcfgrestore -ll -n data_disks -f /etc/lvmconf/data_disks.conf looked good to me. It listed the volume group , the logical volume and the two PVs and all the sizes seem correct. So i went ahead to the next step... >run > pvcreate -ff /dev/hde worked ok - said it was successful >and > vgcfgrestore -n data_disks -f /etc/lvmconf/YourPreferedArchive /dev/hde when i run vgcfgrestore -n data_disks -f /etc/lvmconf/data_disks.conf /dev/hde it reports that VG for data_disks successfully restored to /dev/hde but it also says : you may not have an actual backup of restored volume group "data_disks" and when i try vgscan i get the same error as in the subject line above...( pvdata /dev/hde still shows no volume group on the PV ) I have several other cfg backups which I have also tried, all of which give me the same result. I'm pretty much coming to the conclusion that something else is happening here but I dont know what... I suspect that the disk controller may be screwing up. I got fed up with trying all the correct tools as they were obviously having a problem with this disk so i used dd to back up the first 512k of the /dev/hde disk and the used dd again to "copy" the first 512k of data from disk /dev/hdb to /dev/hde just to test whether or not pvdata would then like the disk ( I know I couldn't use the disk in this state, just trying it out of interest ). The results are very strange. If I use "dd if=/dev/hde |xxd |more" I can see that the VG UUID is at hex 0x0001200 for 32 bytes, but if I use "xxd /dev/hde |more" I can see the VG uuid at hex 0x0001000 for 32 bytes, which is where I presume it is meant to be judging by the data on the other disks. This is leading me to suspect a hardware problem, so I think I will try moving the disk onto another controller and see how that goes.. >and > vgscan ; vgchange -ay >That should do the trick. >The open question is, what overwrote your LVM metadata (and hopefully just >it) on /dev/hde in the first place. >Regards, >Heinz -- The LVM Guy -- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.372 / Virus Database: 207 - Release Date: 20/06/2002 --__--__-- Message: 2 Date: Thu, 4 Jul 2002 14:34:51 +0200 From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com> To: linux-lvm@sistina.com Subject: Re: [linux-lvm] Re: RE: ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume group "data_disks" from physical volume(s) (Heinz J . Mauelshagen) Reply-To: linux-lvm@sistina.com Leigh, that pvdata still can't see the VGDA after your successfull vgcfgrestore indeed points to a hardware flaw. You should find the VG UUID at offset 0x400 on the disk with metadata created by LVM versions before 0.9.1 Beta 8. With newer LVM versions it sits at offset 0x1000 as you suggested (LVM_VGDA_ALIGN definition in tools/lib/liblvm.h). Please get back once you sorted out any HW problems. Regards, Heinz -- The LVM Guy -- On Thu, Jul 04, 2002 at 01:22:45PM +0100, Leigh Waldie wrote: > Thanks for the reply... > > -----Original Message----- > From: linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com]On > Behalf Of linux-lvm-request@sistina.com > Sent: 04 July 2002 10:49 > >Message: 7 > >Date: Thu, 4 Jul 2002 11:34:54 +0200 > >From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com> > >To: linux-lvm@sistina.com > >Subject: Re: [linux-lvm] RE: ERROR "vg_read_with_pv_and_lv(): current PV" > can't get data of volume group "data_disks" from physical volume(s) > >Reply-To: linux-lvm@sistina.com > > >On Wed, Jul 03, 2002 at 02:25:20PM +0100, Leigh Waldie wrote: > >> Further... > >> > >> Output from pvdata /dev/hde reveals that there is no vg info on the disk, > >> however there is vg info on the second disk /dev/hdb... > > >Then the vgcfgrestore must have been unsuccessfull :( > > indeed it was > > >"vgchange -an" is not needed. It doesn't write to the PVs it just tries > >to deactivate the VGs in core. > > >> > >> Is there any way of recovering the vg info from hdb onto hde ? > > >vgcfgrestore! > > >Look with "vgcfgrestore -ll ..." if your backup fits your config, > > the output from vgcfgrestore -ll -n data_disks -f > /etc/lvmconf/data_disks.conf looked good to me. > It listed the volume group , the logical volume and the two PVs and all the > sizes seem correct. > So i went ahead to the next step... > > >run > > > pvcreate -ff /dev/hde > > worked ok - said it was successful > > >and > > > vgcfgrestore -n data_disks -f /etc/lvmconf/YourPreferedArchive /dev/hde > > when i run > vgcfgrestore -n data_disks -f /etc/lvmconf/data_disks.conf /dev/hde > > it reports that VG for data_disks successfully restored to /dev/hde > but it also says : you may not have an actual backup of restored volume > group "data_disks" > > and when i try vgscan i get the same error as in the subject line > above...( pvdata /dev/hde still shows no volume group on the PV ) > > I have several other cfg backups which I have also tried, all of which give > me the same result. > > I'm pretty much coming to the conclusion that something else is happening > here but I dont know what... > I suspect that the disk controller may be screwing up. > > I got fed up with trying all the correct tools as they were obviously having > a problem with this disk so i used dd to back up the first 512k of the > /dev/hde disk and the used dd again to "copy" the first 512k of data from > disk /dev/hdb to /dev/hde just to test whether or not pvdata would then like > the disk ( I know I couldn't use the disk in this state, just trying it out > of interest ). > > The results are very strange. > > If I use "dd if=/dev/hde |xxd |more" I can see that the VG UUID is at hex > 0x0001200 for 32 bytes, but if I use "xxd /dev/hde |more" I can see the VG > uuid at hex 0x0001000 for 32 bytes, which is where I presume it is meant to > be judging by the data on the other disks. > > This is leading me to suspect a hardware problem, so I think I will try > moving the disk onto another controller and see how that goes.. > > > >and > > > vgscan ; vgchange -ay > > > >That should do the trick. > > > >The open question is, what overwrote your LVM metadata (and hopefully just > >it) on /dev/hde in the first place. > > >Regards, > >Heinz -- The LVM Guy -- > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.372 / Virus Database: 207 - Release Date: 20/06/2002 > > > _______________________________________________ > linux-lvm mailing list > linux-lvm@sistina.com > http://lists.sistina.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany Mauelshagen@Sistina.com +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =- --__--__-- Message: 3 Subject: Re: [linux-lvm] ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume group From: Eamonn Hamilton <eamonn@snifter.freeserve.co.uk> To: linux-lvm@sistina.com Date: 04 Jul 2002 16:02:12 +0100 Reply-To: linux-lvm@sistina.com no problem, files are on the way :-) On Thu, 2002-07-04 at 10:20, Heinz J . Mauelshagen wrote: > > Eamonn, > > could you send the output to me directly (mge@sistina.com), please? > > On Tue, Jul 02, 2002 at 12:55:43PM +0100, Eamonn Hamilton wrote: > > > > > > Hi. > > > > I'm getting the error as shown in the subject line from a system which > > was shut down improperly ( read: turned off ! ). Is there anything I can > > do to recover this, as the disks all seem fine, and pvscan finds the > > physical volumes. > > > > Any pointers gratefully received .. > > > > Cheers, > > Eamonn > > > > P.S > > > > pvscan -d and vgscan -d on request, as I don't want to throw 70k at the > > list :-) > > > > > > > > > > _______________________________________________ > > linux-lvm mailing list > > linux-lvm@sistina.com > > http://lists.sistina.com/mailman/listinfo/linux-lvm > > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html > > -- > > Regards, > Heinz -- The LVM Guy -- > > *** Software bugs are stupid. > Nevertheless it needs not so stupid people to solve them *** > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =- > > Heinz Mauelshagen Sistina Software Inc. > Senior Consultant/Developer Am Sonnenhang 11 > 56242 Marienrachdorf > Germany > Mauelshagen@Sistina.com +49 2626 141200 > FAX 924446 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =- > > _______________________________________________ > linux-lvm mailing list > linux-lvm@sistina.com > http://lists.sistina.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html > --__--__-- Message: 4 From: "James B. Byrne " <ByrneJB@Harte-Lyne.ca> Organization: Harte & Lyne Limited To: linux-lvm@sistina.com Date: Thu, 4 Jul 2002 11:11:49 -0400 Subject: [linux-lvm] Re: linux-lvm digest, Vol 1 #624 - 8 msgs Reply-To: linux-lvm@sistina.com On 4 Jul 2002 at 4:49, "Heinz J . Mauelshagen" <mauelshagen@sistina.com> wrote: > Did you just grow the LV? > Yes > You need to extend the FS using the respective FS resizing tool as > well (resize2fs, resize_reiserfs, ...). > Did that too. > BTW: for ext2 the e2fsadm(8) command, which comes with LVM does both > for you. > > I tried this originally but I can't remember if it worked first off or if in my ignorance I ran it out of sequence, had problems, and ended up doing something else. In any case eventually I managed to get the file system up to 350 Mb. > This doesn't really explain the local/remote difference unless: > > - local users had root credentials avoiding the fs > "reserved block count" to matter As it turned out the local user did have root capability but when su to a non-privileged user the local file transfers also worked. > > - files uploaded where very large compared to the locally stored files The reverse in fact, the local files moved in for testing averaged 10x the size of normal ftp uploads. However, the culprit was discovered and it wasn't lvm. The problem appears to have been a simple permission problem in the directory tree for the ftp chroot. Why pureftpd chose to report this as a disk full error is beyond me. However, it is worth noting that rebooting the system, without making any other changes, caused pureftp to subsequently report a different error message for the same activity. The message didn't actually say access forbidden ( I think that it was more like "non existent file", but with the application of a little intuition it did point to a permissions problem. Regards, Jim --- e-mail is NOT a secure channel James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 --__--__-- Message: 5 From: "Mark Peloquin" <markpeloquin@hotmail.com> To: linux-kernel@vger.kernel.org Cc: joe@fib011235813.fsnet.co.uk, linux-lvm@sistina.com Subject: Re: [linux-lvm] LVM2 modifies the buffer_head struct? Date: Fri, 05 Jul 2002 00:21:56 -0500 Reply-To: linux-lvm@sistina.com On 2002-07-02 14:17:02, Joe wrote: >This is a horrible hack to get around the fact that ext3 uses the >b_private field for its own purposes after the buffer_head has been >handed to the block layer (it doesn't just use b_private when in the >b_end_io function). Is this acceptable behaviour ? Other > filesystems >do not have similar problems as far as I know. Under what conditions does ext3 exhibit this behaviour? In EVMS, we have been stacking the b_private field (for many months), and have not seen any problems or have had any problems reported with ext3. Mark _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com --__--__-- Message: 6 Date: Fri, 5 Jul 2002 11:54:22 +0200 From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com> To: linux-lvm@sistina.com Subject: Re: [linux-lvm] Re: linux-lvm digest, Vol 1 #624 - 8 msgs Reply-To: linux-lvm@sistina.com James, good to hear that it works for you now. Cheers, Heinz -- The LVM Guy -- On Thu, Jul 04, 2002 at 11:11:49AM -0400, James B. Byrne wrote: > On 4 Jul 2002 at 4:49, "Heinz J . Mauelshagen" > <mauelshagen@sistina.com> wrote: > > > Did you just grow the LV? > > > > Yes > > > You need to extend the FS using the respective FS resizing tool as > > well (resize2fs, resize_reiserfs, ...). > > > > Did that too. > > > BTW: for ext2 the e2fsadm(8) command, which comes with LVM does both > > for you. > > > > > > I tried this originally but I can't remember if it worked first off or if in > my ignorance I ran it out of sequence, had problems, and ended up > doing something else. In any case eventually I managed to get the > file system up to 350 Mb. > > > This doesn't really explain the local/remote difference unless: > > > > - local users had root credentials avoiding the fs > > "reserved block count" to matter > > As it turned out the local user did have root capability but when su to > a non-privileged user the local file transfers also worked. > > > > - files uploaded where very large compared to the locally stored files > > The reverse in fact, the local files moved in for testing averaged 10x > the size of normal ftp uploads. However, the culprit was discovered > and it wasn't lvm. The problem appears to have been a simple > permission problem in the directory tree for the ftp chroot. Why > pureftpd chose to report this as a disk full error is beyond me. > > However, it is worth noting that rebooting the system, without > making any other changes, caused pureftp to subsequently report a > different error message for the same activity. The message didn't > actually say access forbidden ( I think that it was more like "non > existent file", but with the application of a little intuition it did point to > a permissions problem. > > Regards, > Jim > > > --- e-mail is NOT a secure channel > James B. Byrne mailto:ByrneJB@Harte-Lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > > > _______________________________________________ > linux-lvm mailing list > linux-lvm@sistina.com > http://lists.sistina.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany Mauelshagen@Sistina.com +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =- --__--__-- Message: 7 From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: <linux-LVM@sistina.com> Date: Fri, 5 Jul 2002 12:28:09 +0200 Subject: [linux-lvm] Tr: Possible LVM bug in 2.4.19-rc1 Reply-To: linux-lvm@sistina.com ---------------- D=E9but du message transmis ---------------- Sujet: Possible LVM bug in 2.4.19-rc1 Envoy=E9: jeudi 4 juillet 2002 13:59 De: Benjamin Herrenschmidt <benh@kernel.crashing.org> =C0: linux-kernel@vger.kernel.org Hi ! Olaf and I have been tracking down a bug where the kernel died into lvm=5Fblk=5Fopen() during boot on pmac, and later on other PPCs when trying to access an unconfigured LVM block device (or an LVM minor not associated yet). This typically happened in the pmac root discovery code which walks all gendisks, but I beleive there are other possible exploits. Here's what I've tracked down so far: static int lvm=5Fblk=5Fopen(struct inode *inode, struct file *file) { =09int minor =3D MINOR(inode->i=5Frdev); =09lv=5Ft *lv=5Fptr; =09vg=5Ft *vg=5Fptr =3D vg[VG=5FBLK(minor)]; =09P=5FDEV("blk=5Fopen MINOR: %d VG#: %d LV#: %d mode: %s%s\n", =09 minor, VG=5FBLK(minor), LV=5FBLK(minor), =09 MODE=5FTO=5FSTR(file->f=5Fmode)); #ifdef LVM=5FTOTAL=5FRESET =09 if (lvm=5Freset=5Fspindown > 0) =09 =09return -EPERM; #endif =09if (vg=5Fptr !=3D NULL && =09 (vg=5Fptr->vg=5Fstatus & VG=5FACTIVE) && .../... At this point, no association have been made. That is VG=5FBLK(minor) will return vg=5Flv=5Fmap[minor].vg=5Fnumber which has been initialized to ABS=5FMAX=5FVG in lvm=5Finit=5Fvars(). That means that vg=5Fptr is set to vg[ABS=5FMAX=5FVG], which is right = outside the array bounds, as vg is declared to be /* volume group descriptor area pointers */ vg=5Ft *vg[ABS=5FMAX=5FVG]; So, as soon as we dereference vg=5Fptr, we get whatever garbage is located right after the array, and not the NULL value we would expect for a non initialized association. If my understanding is correct, then a simple fix would be to /* volume group descriptor area pointers */ - vg=5Ft *vg[ABS=5FMAX=5FVG]; + vg=5Ft *vg[ABS=5FMAX=5FVG+1]; though it's a bit hackish... maybe we should just test VG=5FBLK < ABS=5FMAX=5FVG Also, the loop initializing vg array to NULL can probably be removed from lvm=5Finit=5Fvars as vg is part of the BSS and thus cleared by default. Did I miss something =3F Ben. ----------------- Fin du message transmis ----------------- --__--__-- Message: 8 Date: Fri, 5 Jul 2002 22:53:24 +0200 From: Kai Weber <lists@glorybox.de> To: linux-lvm@sistina.com Subject: [linux-lvm] Get rid of files of a non existing volume group Reply-To: linux-lvm@sistina.com Hi, I have lost a hard disk (died). I had a volume group on this disk. Now I have replaced the disk with a new one and wanted to create the old scheme on this disk: $ vgcreate datavg /dev/hdb1 vgcreate -- directory /dev/datavg already exists As you can see the old /dev/datavg still exists on my root-partition. How do I get rid of the old files? There is no VG datavg anymore, but I want to have the name back. Can I 'rm -rf /dev/datavg' the files? Or should I do a vgextend? vgscan does not find the VG datavg anymore. Kai --__--__-- Message: 9 Date: Sat, 6 Jul 2002 09:27:58 +0100 From: Patrick Caulfield <caulfield@sistina.com> To: linux-lvm@sistina.com Subject: Re: [linux-lvm] Get rid of files of a non existing volume group Reply-To: linux-lvm@sistina.com On Fri, Jul 05, 2002 at 10:53:24PM +0200, Kai Weber wrote: > Hi, > > I have lost a hard disk (died). I had a volume group on this disk. Now I > have replaced the disk with a new one and wanted to create the old scheme > on this disk: > > $ vgcreate datavg /dev/hdb1 > vgcreate -- directory /dev/datavg already exists > > As you can see the old /dev/datavg still exists on my root-partition. How > do I get rid of the old files? There is no VG datavg anymore, but I want to > have the name back. > > Can I 'rm -rf /dev/datavg' the files? Or should I do a vgextend? You can safely delete the directory. When you re-created the VG and LVs then nodes will be re-created. > vgscan does not find the VG datavg anymore. Well...er... if it's a totally new disk it won't. :) patrick --__--__-- Message: 10 Date: Sat, 6 Jul 2002 15:00:52 +0200 From: Kai Weber <lists@glorybox.de> To: linux-lvm@sistina.com Subject: Re: [linux-lvm] Get rid of files of a non existing volume group Reply-To: linux-lvm@sistina.com + Patrick Caulfield <caulfield@sistina.com>: > > Can I 'rm -rf /dev/datavg' the files? Or should I do a vgextend? > > You can safely delete the directory. When you re-created the VG and > LVs then nodes will be re-created. It worked. I ever thought the dev-files for LVM are created dynamicly. So I feared removing the files would not be succesfull. And I am not a friend of experiments... *g* Thank you Kai --__--__-- Message: 11 Date: Sat, 6 Jul 2002 13:39:39 -0300 (BRT) From: Rik van Riel <riel@conectiva.com.br> To: linux-lvm@sistina.com Subject: [linux-lvm] lvm & 2.5 Reply-To: linux-lvm@sistina.com Hi, are there any plans to fix lvm support for 2.5 or should I drop lvm from my test boxes until 2.6 comes out ? Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ --__--__-- _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm End of linux-lvm Digest --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/2002 _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
