From: AJ Lewis <lewis@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Problem with vgscan/ vgcfgrestore
Date: Tue, 13 Mar 2001 11:40:54 -0600 [thread overview]
Message-ID: <20010313114054.E15679@sistina.com> (raw)
In-Reply-To: <20010313084102.A28227@colombina.comedia.it>; from bluca@comedia.it on Tue, Mar 13, 2001 at 08:41:02AM +0100
[-- 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 --]
prev parent reply other threads:[~2001-03-13 17:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-12 18:40 [linux-lvm] Problem with vgscan/ vgcfgrestore Daniel Whicker
2001-03-12 23:19 ` Andreas Dilger
2001-03-13 0:16 ` Daniel E Whicker
2001-03-13 0:23 ` Wichert Akkerman
2001-03-13 0:56 ` Andreas Dilger
2001-03-13 1:14 ` Wichert Akkerman
2001-03-13 1:40 ` Andreas Dilger
2001-03-13 22:26 ` Wichert Akkerman
2001-03-13 23:02 ` Andreas Dilger
2001-03-14 2:17 ` Rik van Riel
2001-03-13 5:12 ` AJ Lewis
2001-03-13 9:41 ` Jason Walker
2001-03-13 9:57 ` Patrick Caulfield
2001-03-13 17:35 ` AJ Lewis
2001-03-13 0:59 ` Andreas Dilger
2001-03-13 7:41 ` Luca Berra
2001-03-13 17:40 ` AJ Lewis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010313114054.E15679@sistina.com \
--to=lewis@sistina.com \
--cc=linux-lvm@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).