[linux-lvm] Problem with vgscan/ vgcfgrestore

[linux-lvm] Problem with vgscan/ vgcfgrestore

[Daniel Whicker]

[-- Attachment #1: smime.p7m --]
[-- Type: application/x-pkcs7-mime, Size: 762778 bytes --]

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Andreas Dilger]

Daniel Whicker writes:
[Attachment, skipping...]

Anyways,
vgscan doesn't appear to be finding any of your PVs because they are missing
the "HM" magic for the PV, or so err -268 tells me.  The only PV that appears
intact is /dev/hdc, which ends up being discarded because it isn't in the dir
cache.  You can see that nothing is found from pv_read_all_pv() - it reports
"np: 0" at the end.

Are you running devfs, or even have it compiled into the kernel by any chance?
It also appears you are not running the current CVS code (pretty much a must
when tracking down problems) because you are going into lvm_add_dir_cache()
multiple times.

Here is a patch which fixes up lvm_dir_cache() to report about devices
it is probing, to help track down these problems.  I've been using this
for a while on my system, so it should be OK to add to CVS.  It also
cleans up a bit of the good old LVM_DIR_PREFIX stuff at the same time.

Cheers, Andreas
==========================================================================
diff -u -u -r1.4.2.6 lvm_dir_cache.c
--- tools/lib/lvm_dir_cache.c	2001/02/20 15:00:08	1.4.2.6
+++ tools/lib/lvm_dir_cache.c	2001/03/12 23:00:28
@@ -45,9 +45,8 @@
 
 #include <liblvm.h>
 
-char *dirname = NULL;
 int  lvm_dir_cache_hit ( dir_cache_t*, int, dev_t);
-void lvm_add_dir_cache ( char*, char*);
+int  lvm_add_dir_cache ( char *, char *);
 
 static dir_cache_t *dir_cache = NULL;
 static int cache_size = 0;
@@ -64,15 +64,15 @@
    char minor[20] = { 0, };
    char blocks[20] = { 0, };
    char devname[30] = { 0, };
-   static char *devdir[] = {
-      "/dev/ida",
-      "/dev/ide/hd",
-      "/dev/loop",
-      "/dev/md",
-      "/dev/rd",
-      "/dev/sd",
-      "/dev/cciss",
-      "/dev",
+   char *devsub[] = {
+      "cciss/",
+      "ida/",
+      "ide/hd/",
+      "loop/",
+      "md/",
+      "rd/",
+      "sd/",
+      "",
       NULL
    };
    struct dirent **dirent = NULL;
@@ -94,24 +94,24 @@
                    " %s %s %s %s\n",
                    major, minor, blocks, devname);
           if ( atoi ( major) > 0 && atoi ( major) != LVM_BLK_MAJOR) {
-             lvm_add_dir_cache ( "/dev", devname);
+             lvm_add_dir_cache(LVM_DIR_PREFIX, devname);
           }
       }   
       fclose ( proc);
    }
    if ( cache_size == 0 && lvm_check_devfs() == FALSE) {
-      for ( d = 0; devdir[d] != NULL; d++) {
-         dirname = devdir[d];
-         debug ( "lvm_dir_cache -- calling scandir() with %s\n",
-                 dirname);
+      for ( d = 0; devsub[d] != NULL; d++) {
+         char dirname[NAME_LEN];
+         sprintf(dirname, LVM_DIR_PREFIX "%s", devsub[d]);
+         debug ( "lvm_dir_cache -- calling scandir() with %s\n", dirname);
          if ( ( dirent_count = scandir ( dirname, &dirent,
                                          NULL,
                                          alphasort)) > 0) {
             for ( n = 0; n < dirent_count; n++) {
                lvm_add_dir_cache ( dirname, dirent[n]->d_name);
+               free ( dirent[n]);
             }
 
-            for ( n = 0; n < dirent_count; n++) free ( dirent[n]);
             free ( dirent);
          }
          debug ( "lvm_dir_cache -- AFTER calling scandir() "
@@ -130,21 +132,23 @@
 }
 
 
-void lvm_add_dir_cache ( char *directory, char *devname) {
+int lvm_add_dir_cache ( char *directory, char *devname)
+{
    char devpath[NAME_LEN] = { 0, };
    dir_cache_t *dir_cache_sav = NULL;
    struct stat stat_b;
+   int ret = FALSE;
 
-   debug_enter ( "lvm_add_dir_cache -- CALLED\n");
+   debug_enter ( "lvm_add_dir_cache -- CALLED with %s%s\n", directory, devname);
 
    if ( directory != NULL && devname != NULL) {
-      sprintf ( devpath, "%s/%s%c", directory, devname, 0);
+      sprintf ( devpath, "%s%s", directory, devname);
       if ( stat ( devpath, &stat_b) == -1 ||
            lvm_check_dev ( &stat_b, TRUE) == FALSE)
          goto lvm_add_dir_cache_end;
    
-      if ( lvm_dir_cache_hit ( dir_cache, cache_size,
-                               stat_b.st_rdev) == FALSE) {
+      if ((ret = lvm_dir_cache_hit(dir_cache, cache_size,
+                                   stat_b.st_rdev) == FALSE)) {
          dir_cache_sav = dir_cache;
          if ( ( dir_cache =
                    realloc ( dir_cache,
@@ -170,13 +176,13 @@
          dir_cache[cache_size].st_rdev = stat_b.st_rdev;
          dir_cache[cache_size].st_mode = stat_b.st_mode;
          cache_size++;
+         ret = TRUE;
       }
    }
 
 lvm_add_dir_cache_end:
-
-   debug_leave ( "lvm_add_dir_cache -- LEAVING\n");
-   return;
+   debug_leave ( "lvm_add_dir_cache -- LEAVING with ret: %d\n", ret);
+   return ret;
 }
 
 
@@ -185,9 +191,9 @@
    int d = 0;
    dir_cache_t *dir_cache = NULL, *ret = NULL;
 
-   debug_enter ( "lvm_dir_cache_find -- CALLED\n");
+   debug_enter ( "lvm_dir_cache_find -- CALLED with %s\n", dev_name);
 
-   if ( dev_name != NULL && pv_check_name ( dev_name) == 0) {
+   if ( dev_name != NULL) {
       d = lvm_dir_cache ( &dir_cache);
       for ( d--; d >= 0; d--) {
          if ( strcmp ( dev_name, dir_cache[d].dev_name) == 0) {
@@ -197,7 +203,7 @@
       }
    }
 
-   debug_leave ( "lvm_dir_cache_find -- LEAVING\n");
+   debug_leave ( "lvm_dir_cache_find -- LEAVING with entry: %d\n", ret ? d:-1);
    return ret;
 }
 
@@ -223,7 +230,7 @@
 
 int lvm_check_devfs ( void) {
    int ret = FALSE;
-   char dummy[NAME_LEN];
+   char dir[NAME_LEN];
    char type[32];
    FILE *mounts = NULL;
 
@@ -232,10 +239,9 @@
    if ( ( mounts = fopen ( "/proc/mounts", "r")) != NULL) {
       while ( !feof ( mounts)) {
           fgets ( line, 127, mounts);
-          sscanf ( line,
-                   "%s %s %s %s\n",
-                   dummy, dummy, type, dummy);
-          if ( strcmp ( type, "devfs") == 0) {
+          sscanf ( line, "%*s %s %s %*s", dir, type);
+          if ( strcmp ( type, "devfs") == 0 &&
+	       strncmp ( dir, LVM_DIR_PREFIX, sizeof(LVM_DIR_PREFIX) - 1)) {
              ret = TRUE;
              break;
           }
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

RE: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Daniel E Whicker]

Andreas,
	Thanks for helping.  I did in fact have devfs compiled in and mounted to an
alternative path.  The only other oddness in the kernel was reiserfs.
Beyond that, everything is pretty vanilla.  I'm rebuilding the OS on that
system at the moment, but as soon as I'm done, I'll get 2.4.2 with LVM
.9.1b5 and your patch installed and see how it goes from there.  In the
meantime, is there any way of restoring the "HM" magic to the PVs
nondestructively?

Gang,
	Sorry for bomblasting ya'll with those earlier messages.  I'd failed to
look at the file sizes before emailing that.  Won't happen again.  As far as
the digital signatures preventing plaintext messaging:  baaaaad M$.  (Note:
signatures have been removed)

Thanks for your patience and assistance.

-----Original Message-----
From: linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com]On
Behalf Of Andreas Dilger
Sent: Monday, March 12, 2001 5:19 PM
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

Anyways,
vgscan doesn't appear to be finding any of your PVs because they are missing
the "HM" magic for the PV, or so err -268 tells me.  The only PV that
appears
intact is /dev/hdc, which ends up being discarded because it isn't in the
dir
cache.  You can see that nothing is found from pv_read_all_pv() - it reports
"np: 0" at the end.

Are you running devfs, or even have it compiled into the kernel by any
chance?
It also appears you are not running the current CVS code (pretty much a must
when tracking down problems) because you are going into lvm_add_dir_cache()
multiple times.

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Wichert Akkerman]

Previously Daniel E Whicker wrote:
> system at the moment, but as soon as I'm done, I'll get 2.4.2 with LVM
> .9.1b5 and your patch installed and see how it goes from there.

It seems 0.9.1b6 is out there as well, although it's not mentioned on
all the webpages and not on any mirrors..

Wichert (browsing the patch to figure out why IOP reverted to 10).

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Andreas Dilger]

Wichert Akkerman writes:
> It seems 0.9.1b6 is out there as well, although it's not mentioned on
> all the webpages and not on any mirrors..

Just released this minute...

> Wichert (browsing the patch to figure out why IOP reverted to 10).

IOP was reverted to 10 because the 1 reason it was changed to 11 was
removed (*).  Having IOP 11 tools, when stock 2.4.x has IOP 10 is just
asking for lots of bug reports, not to mention headaches for users.

Cheers, Andreas

(*) The VG_CREATE ioctl data was modified in an incompatible way in beta4
    to accomodate devfs users.  This caused a bug for older kernel code,
    and in beta5 the IOP was changed to 11.  After protests, the VG_CREATE
    ioctl was reverted to the original behaviour (as VG_CREATE_OLD with
    the old number), and a new ioctl with the new behaviour became VG_CREATE.
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Wichert Akkerman]

Previously Andreas Dilger wrote:
> Just released this minute...

I just saw the announce :)

> IOP was reverted to 10 because the 1 reason it was changed to 11 was
> removed (*).  Having IOP 11 tools, when stock 2.4.x has IOP 10 is just
> asking for lots of bug reports, not to mention headaches for users.

I figured that out by now. I think I'll add the LVM10 ioctls to 
strace 4.4 actually :)

BTW, the current LVM tools violate the FHS by putting binaries in
/sbin/lvm-*/. Would you accept a patch to move that to /lib/lvm-*/
instead?

Wichet.

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Andreas Dilger]

Wichert writes:
> > IOP was reverted to 10 because the 1 reason it was changed to 11 was
> > removed (*).  Having IOP 11 tools, when stock 2.4.x has IOP 10 is just
> > asking for lots of bug reports, not to mention headaches for users.
> 
> I figured that out by now. I think I'll add the LVM10 ioctls to 
> strace 4.4 actually :)

That would be nice.

> BTW, the current LVM tools violate the FHS by putting binaries in
> /sbin/lvm-*/. Would you accept a patch to move that to /lib/lvm-*/
> instead?

Why is FHS violated when binaries are in /sbin?  In any case, I have
my tools in /lib/lvm-iop10, and only the wrapper script in /sbin.  If
installed properly, the wrapper is < 1k, hardlinked to all tool names.

I agree it is a bit of a mess with _all_ of the tools going into /sbin,
when only a couple are needed@boot time.  However, it does make life
easier if you have trouble activating your LVs.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Wichert Akkerman]

Previously Andreas Dilger wrote:
> Wichert writes:
> > I figured that out by now. I think I'll add the LVM10 ioctls to 
> > strace 4.4 actually :)
> 
> That would be nice.

Turns out this is impossible: LVM made the same mistake some of the OSS
sound drivers did and used ioctl numbers that the kernel already uses
for other purposes. This is not a problem for the kernel itself, but
means a tool like strace can't decode syscalls.

Wichert.

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Andreas Dilger]

Wichert, you write:
> Previously Andreas Dilger wrote:
> > Wichert writes:
> > > I think I'll add the LVM10 ioctls to strace 4.4 actually :)
> > 
> > That would be nice.
> 
> Turns out this is impossible: LVM made the same mistake some of the OSS
> sound drivers did and used ioctl numbers that the kernel already uses
> for other purposes. This is not a problem for the kernel itself, but
> means a tool like strace can't decode syscalls.

What are they duplicated with?  I was recently checking the 2.4.x version
of Documentation/ioctl-number.txt, and there was nothing for 0xFE at all.
In fact, just to avoid this problem, I submitted a patch to the list here
(and to MEC) to "register" the LVM ioctl numbers.

Hard to avoid duplicating ioctl numbers, if it is not documented anywhere.
Does strace know about other ioctl numbers not listed in ioctl-number.txt?
Interested in making a patch which lists them and submitting it to Linus?

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Rik van Riel]

On Tue, 13 Mar 2001, Wichert Akkerman wrote:
> Previously Andreas Dilger wrote:
> > Wichert writes:
> > > I figured that out by now. I think I'll add the LVM10 ioctls to 
> > > strace 4.4 actually :)
> > 
> > That would be nice.
> 
> Turns out this is impossible: LVM made the same mistake some of the
> OSS sound drivers did and used ioctl numbers that the kernel already
> uses for other purposes. This is not a problem for the kernel itself,
> but means a tool like strace can't decode syscalls.

Good thing this can be fixed with IOP-11 in 2.5 ;)

(at least, I can't really see a large base of user
programs becoming dependant on the LVM ABI...)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[AJ Lewis]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On Tue, Mar 13, 2001 at 02:14:39AM +0100, Wichert Akkerman wrote:
> BTW, the current LVM tools violate the FHS by putting binaries in
> /sbin/lvm-*/. Would you accept a patch to move that to /lib/lvm-*/
> instead?

Erm.../lib/lvm-*/?  Really?  Hmm...guess I need to read the FHS.  Anyone got
a pointer to that?

I've been planning on putting the connectiva type wrapper scripts into the
mainline LVM src, but haven't had a chance yet.  This would make hard links to
the wrapper script for all of the tools in /sbin, but the tools themselves
would be located in /lib/lvm-*/.  Would that violate the FHS?

More info on this would be very useful.

Thanks,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-----Begin Obligatory Humorous Quote----------------------------------------
Choose a job you love, and you will never have to work a day in your life.
-----End Obligatory Humorous Quote------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Jason Walker]

On Mon, 12 Mar 2001, AJ Lewis wrote:

> On Tue, Mar 13, 2001 at 02:14:39AM +0100, Wichert Akkerman wrote:
> 
> Erm.../lib/lvm-*/?  Really?  Hmm...guess I need to read the FHS.  Anyone got
> a pointer to that?

http://www.pathname.com/fhs/
This posting has inspired me to read up on FHS...looks cool so far :)

-- 
Jason Walker -- unseen@sover.net, perlgod@hotmail.com
UIN: 110493687
AIM: Nightface

/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \
			 

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Patrick Caulfield]

On Mon, Mar 12, 2001 at 11:12:08PM -0600, AJ Lewis wrote:
> On Tue, Mar 13, 2001 at 02:14:39AM +0100, Wichert Akkerman wrote:
> > BTW, the current LVM tools violate the FHS by putting binaries in
> > /sbin/lvm-*/. Would you accept a patch to move that to /lib/lvm-*/
> > instead?
> 
> Erm.../lib/lvm-*/?  Really?  Hmm...guess I need to read the FHS.  Anyone got
> a pointer to that?

www.pathname.com/fhs


patrick

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[AJ Lewis]

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]

On Tue, Mar 13, 2001 at 09:57:11AM +0000, Patrick Caulfield wrote:
> On Mon, Mar 12, 2001 at 11:12:08PM -0600, AJ Lewis wrote:
> > On Tue, Mar 13, 2001 at 02:14:39AM +0100, Wichert Akkerman wrote:
> > > BTW, the current LVM tools violate the FHS by putting binaries in
> > > /sbin/lvm-*/. Would you accept a patch to move that to /lib/lvm-*/
> > > instead?
> > 
> > Erm.../lib/lvm-*/?  Really?  Hmm...guess I need to read the FHS.  Anyone got
> > a pointer to that?
> 
> www.pathname.com/fhs

OK, I'm confused now.  The current LVM tools are installed in /sbin, not
/sbin/lvm-*/.  If you are getting packages from distros that place the
binaries in /sbin/lvm-*/ you need to talk to the distros.  AFAICT, the LVM
tools *should* be in /sbin

This from the current FHS 2.1 standard:

Utilities used for system administration (and other root-only commands) are
stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin typically contains
binaries essential for booting the system in addition to the binaries in
/bin. Anything executed after /usr is known to be mounted (when there are no
problems) should be placed into /usr/sbin. Local-only system administration
binaries should be placed into /usr/local/sbin

And this is what the FHS has to say about /lib:

The /lib directory contains those shared library images needed to boot the
system and run the commands in the root filesystem.

So how does having LVM binaries in /lib/lvm-*/ _not_ violate the FHS?

Regards,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-----Begin Obligatory Humorous Quote----------------------------------------
Einstein said that talking to yourself is a sign of intelligence.
Answering yourself, however, is a sign of insanity.
-----End Obligatory Humorous Quote------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Andreas Dilger]

Daniel Whiker writes:
> Thanks for helping.  I did in fact have devfs compiled in and mounted to an
> alternative path.

Currently devfs and LVM don't work well together, especially if it is not
mounted on /dev.  My patch fixes a small part of this, but it is still
safer to simply configure devfs out of the kernel when using LVM, until
your system is working properly.

> Beyond that, everything is pretty vanilla.  I'm rebuilding the OS on that
> system at the moment, but as soon as I'm done, I'll get 2.4.2 with LVM
> .9.1b5 and your patch installed and see how it goes from there.  In the
> meantime, is there any way of restoring the "HM" magic to the PVs
> nondestructively?

I think this may have been caused by the devfs strangeness.  Start out
with devfs out of the kernel entirely, and go from there.  I don't think
2.4.2 will help you.  You need to apply an LVM kernel patch anyways.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[Luca Berra]

On Mon, Mar 12, 2001 at 05:59:54PM -0700, Andreas Dilger wrote:
> Daniel Whiker writes:
> > Thanks for helping.  I did in fact have devfs compiled in and mounted to an
> > alternative path.
> 
> Currently devfs and LVM don't work well together, especially if it is not
> mounted on /dev.  My patch fixes a small part of this, but it is still
> safer to simply configure devfs out of the kernel when using LVM, until
> your system is working properly.
> 
I believe the big problem is that when lvm is compiled in /proc/partitions
contains device names in devfs format, if devfs is not mounted the lvm dir
cache will get filled with devfs names, which do not exist.
Another problem with devfs is symlinks (eg: /dev/sda), the lvm dircache will
contain only the long name (/dev/scsi/....).

i have a couple of ideas, but no time to code (sorry)
1) using realpath in the tools to solve issue 2
2) checking if the devices mentioned in /proc/partition do really exist, else
  switch the cache to "scan the dev directory mode"

	but better than the above 
3) add another structure to the cache which contains aliases to the device
 we have in the cache, aliases are added dynamically when found on the command
 line or in the VGDA of a PV. We use 
	alias[c].name=possible alias;
	lstat(possible alias, &statbuf)
	if (S_ISLNK(statbuf.st_mode)) {
		alias[c].target=lvm_dir_cache_find(realpath(possible alias));
		if !(alias[c].target) stat(realptah(possible alias), &statbuf)
	}
	if (S_ISBLK(statbuf.st_mode)) {
		alias[c].target=lvm_dir_cache_find_dev(statbuf.st_dev>>8,statbuf.st_mode&((1<<8)-1));
		/* the above function has to be written*/
	}
	if (!alias[c].target) complain(loudly);
	c++;

  then we modify lvm_dir_cache_find to loop also on alias[], before it starts searching th
  cache.

regards,
L.
	
P.S. in case you did not notice the above is not real code :)
		
		
		

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: [linux-lvm] Problem with vgscan/ vgcfgrestore

[AJ Lewis]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

On Tue, Mar 13, 2001 at 08:41:02AM +0100, Luca Berra wrote:
> i have a couple of ideas, but no time to code (sorry)
> 1) using realpath in the tools to solve issue 2

This should be done no matter what.  I can't think of any good reason not to
have the tools follow sym-links.

> 2) checking if the devices mentioned in /proc/partition do really exist, else
>   switch the cache to "scan the dev directory mode"

I believe this is the way it works at present

> 	but better than the above 
> 3) add another structure to the cache which contains aliases to the device
>  we have in the cache, aliases are added dynamically when found on the command
>  line or in the VGDA of a PV. We use 
> 	alias[c].name=possible alias;
> 	lstat(possible alias, &statbuf)
> 	if (S_ISLNK(statbuf.st_mode)) {
> 		alias[c].target=lvm_dir_cache_find(realpath(possible alias));
> 		if !(alias[c].target) stat(realptah(possible alias), &statbuf)
> 	}
> 	if (S_ISBLK(statbuf.st_mode)) {
> 		alias[c].target=lvm_dir_cache_find_dev(statbuf.st_dev>>8,statbuf.st_mode&((1<<8)-1));
> 		/* the above function has to be written*/
> 	}
> 	if (!alias[c].target) complain(loudly);
> 	c++;
> 
>   then we modify lvm_dir_cache_find to loop also on alias[], before it starts searching th
>   cache.

This looks interesting...and could possibly help a lot as well.

Regards,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-----Begin Obligatory Humorous Quote----------------------------------------
Life's short and hard, kind of like a bodybuilding elf
-----End Obligatory Humorous Quote------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]