From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Could vgscan read a file of "preferred" LV name -> minor device id ?
Date: Tue Jan 15 08:03:02 2002 [thread overview]
Message-ID: <20020115150022.C11005@sistina.com> (raw)
In-Reply-To: <20020111104116.GB1274@tykepenguin.com>; from caulfield@sistina.com on Fri, Jan 11, 2002 at 10:41:16AM +0000
On Fri, Jan 11, 2002 at 10:41:16AM +0000, Patrick Caulfield wrote:
> On Fri, Jan 11, 2002 at 07:11:00AM +0000, Piete Brooks wrote:
> > I'm getting complaints from NFS users that when servers reboot, they often
> > find that their mounts have the wrong data. I've never really worked out
> > which end hold what in NFS FHs, but the basic idea is that a client identifies
> > a FH which encodes (major dev id,minor dev id,inode number,version).
> > This appears to break down when a new LV is created ane the server rebooted.
> > As the /dev/<vg>/<lv> nodes are numbered strictly in the order that they are
> > discovered, all LV minor device IDs on subsequent VGs are renumbered, so any
> > remote caching of FHs breaks (( as with SCSI )).
> >
> > Is that about right ?
> >
> > Would it be possible for vgscan to read a "hints" file consisting of <vg>/<lv>
> > and minor device number pairs ?
> >
> > As each <vg>/<lv> is found, if it's in the file, the nominated minor device id
> > is used; if it's not found, then the next minor device id which is not listed
> > in the file is used.
> >
> > [[ I use devfs, so using existing data in /dev/ would not help -- but I think
> > it would do no harm to use that data by default ]]
> >
>
> I thought Heinz had fixed this in 1.0.1, what version are you using (tools &
> kernel)?
That's right. It is in since 1.0.1.
>
> patrick
>
>
> _______________________________________________
> 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2002-01-15 8:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-11 1:11 [linux-lvm] Could vgscan read a file of "preferred" LV name -> minor device id ? Piete Brooks
2002-01-11 4:42 ` Patrick Caulfield
2002-01-15 8:03 ` Heinz J . Mauelshagen [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=20020115150022.C11005@sistina.com \
--to=mauelshagen@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.