[linux-lvm] Could vgscan read a file of "preferred" LV name -> minor device id ?

[linux-lvm] Could vgscan read a file of "preferred" LV name -> minor device id ?

[Piete Brooks]

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 ]]

Re: [linux-lvm] Could vgscan read a file of "preferred" LV name -> minor device id ?

[Patrick Caulfield]

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)?

patrick

Re: [linux-lvm] Could vgscan read a file of "preferred" LV name -> minor device id ?

[Heinz J . Mauelshagen]

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-