Linux LVM users
 help / color / mirror / Atom feed
* [linux-lvm] Just for information ....
@ 2001-11-20 12:39 Igor Dumaire
  2001-11-20 13:55 ` Andreas Dilger
  0 siblings, 1 reply; 6+ messages in thread
From: Igor Dumaire @ 2001-11-20 12:39 UTC (permalink / raw)
  To: list LVM

Hi,

I have 4 disks : 1 for system and 3 for data with LVM (only 1 vg).

If my system drive burn, Can I read my datas with an other system compiled with
LVM ?

Thanks,

-- 
Igor Dumaire

www.LTUtech.com - Making Sense of Visual Content
------------------------------------------------

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [linux-lvm] Just for information ....
  2001-11-20 12:39 [linux-lvm] Just for information Igor Dumaire
@ 2001-11-20 13:55 ` Andreas Dilger
  2001-11-20 14:39   ` Wichert Akkerman
  0 siblings, 1 reply; 6+ messages in thread
From: Andreas Dilger @ 2001-11-20 13:55 UTC (permalink / raw)
  To: Igor Dumaire; +Cc: list LVM

On Nov 20, 2001  19:40 +0100, Igor Dumaire wrote:
> I have 4 disks : 1 for system and 3 for data with LVM (only 1 vg).
> 
> If my system drive burn, Can I read my datas with an other system compiled
> with LVM ?

Yes.  You will need to do a vgscan to find the new disks.  Hopefully they
will not have the same VG name as another VG on that system.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [linux-lvm] Just for information ....
  2001-11-20 13:55 ` Andreas Dilger
@ 2001-11-20 14:39   ` Wichert Akkerman
  2001-11-20 15:36     ` Chad C. Walstrom
  2001-11-20 16:05     ` Andreas Dilger
  0 siblings, 2 replies; 6+ messages in thread
From: Wichert Akkerman @ 2001-11-20 14:39 UTC (permalink / raw)
  To: list LVM; +Cc: Igor Dumaire

Previously Andreas Dilger wrote:
> Yes.  You will need to do a vgscan to find the new disks.  Hopefully they
> will not have the same VG name as another VG on that system.

What if they do?

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [linux-lvm] Just for information ....
  2001-11-20 14:39   ` Wichert Akkerman
@ 2001-11-20 15:36     ` Chad C. Walstrom
  2001-11-20 16:05     ` Andreas Dilger
  1 sibling, 0 replies; 6+ messages in thread
From: Chad C. Walstrom @ 2001-11-20 15:36 UTC (permalink / raw)
  To: linux-lvm

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

On Tue, Nov 20, 2001 at 09:41:04PM +0100, Wichert Akkerman wrote:
> Previously Andreas Dilger wrote:
> > Yes.  You will need to do a vgscan to find the new disks.  Hopefully they
> > will not have the same VG name as another VG on that system.
> 
> What if they do?

Nothing, originally.  Your last "vgchange -a y" should populate the
/etc/lvmtab.d directory with the current working volume group data.
Even if you have two vg's of the same name, your last one should be the
active one.

I had to go back to the original system and do a vgexport <vgname> in
order to import it on the new system.  I've considered naming vg's after
their host (and possibly media type).  That way, I'll know I have at
least a stub of a unique name for the vg.

As far as keeping VG's separate based on media...  I'm torn.  It's a
simple way of making sure I don't loose data if the IDE disk goes bad --
which has happened to me -- while the SCSI disk remains fine.

Unless I'm using RAID, grouping multiple physical disks together in one
VG means I have to pay extra special attention to where the LV's
allocate their PE's.

-- 
Chad Walstrom <chewie@wookimus.net>                 | a.k.a. ^chewie
http://www.wookimus.net/                            | s.k.a. gunnarr
Key fingerprint = B4AB D627 9CBD 687E 7A31  1950 0CC7 0B18 206C 5AFD


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [linux-lvm] Just for information ....
  2001-11-20 14:39   ` Wichert Akkerman
  2001-11-20 15:36     ` Chad C. Walstrom
@ 2001-11-20 16:05     ` Andreas Dilger
  2001-11-23  6:07       ` Heinz J . Mauelshagen
  1 sibling, 1 reply; 6+ messages in thread
From: Andreas Dilger @ 2001-11-20 16:05 UTC (permalink / raw)
  To: list LVM, Igor Dumaire

On Nov 20, 2001  21:41 +0100, Wichert Akkerman wrote:
> Previously Andreas Dilger wrote:
> > Yes.  You will need to do a vgscan to find the new disks.  Hopefully they
> > will not have the same VG name as another VG on that system.
> 
> What if they do?

Then it will depend on disk ordering which one you get under that name, and
the other will be unavailable.  vgscan will see all of the disks, but then
start checking the UUIDs on the PVs against the list on the "first" disk,
and the extra disks with UUIDs that don't match will be discarded.

I don't think there are any likely scenarios with LVM 0.9+ that will cause
problems, but since UUIDs were only introduced in 0.9, it may be much harder
to handle this in older LVM versions.

You might be able to vgexport the disks from the "other" VG at that time,
and reimport it with a different name, but I don't know how reliable that
will be (if it even works).  LVM has been confused by less.  Better to just
"not do that" in the first place.

FYI, AIX LVM does not keep the VG name on the disk itself, only a UUID.
You also never do something like "vgscan" at boot time to reconfigure
the LVM setup.  When you attach the disks to a new system, you have to
import them (at which point they get a name that is stored in a config
file in /etc), and your LVM config is never touched until you change it.
When you export the VG, it also doesn't write to the disks, just deletes
the config from /etc.  This means you don't need to do anything to the
VG before moving it to another system.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [linux-lvm] Just for information ....
  2001-11-20 16:05     ` Andreas Dilger
@ 2001-11-23  6:07       ` Heinz J . Mauelshagen
  0 siblings, 0 replies; 6+ messages in thread
From: Heinz J . Mauelshagen @ 2001-11-23  6:07 UTC (permalink / raw)
  To: linux-lvm

On Tue, Nov 20, 2001 at 03:06:38PM -0700, Andreas Dilger wrote:
> On Nov 20, 2001  21:41 +0100, Wichert Akkerman wrote:
> > Previously Andreas Dilger wrote:
> > > Yes.  You will need to do a vgscan to find the new disks.  Hopefully they
> > > will not have the same VG name as another VG on that system.
> > 
> > What if they do?
> 
> Then it will depend on disk ordering which one you get under that name, and
> the other will be unavailable.  vgscan will see all of the disks, but then
> start checking the UUIDs on the PVs against the list on the "first" disk,
> and the extra disks with UUIDs that don't match will be discarded.

Worst case would be a temporary disconnect of the PVs belonging to one
of the VGs which share the same name. vgscan+vgrename the found one and
reconnect the drives and vgscan again.


> 
> I don't think there are any likely scenarios with LVM 0.9+ that will cause
> problems, but since UUIDs were only introduced in 0.9, it may be much harder
> to handle this in older LVM versions.

See above.

> 
> You might be able to vgexport the disks from the "other" VG at that time,
> and reimport it with a different name, but I don't know how reliable that
> will be (if it even works).  LVM has been confused by less.

???

> Better to just
> "not do that" in the first place.
> 
> FYI, AIX LVM does not keep the VG name on the disk itself, only a UUID.
> You also never do something like "vgscan" at boot time to reconfigure
> the LVM setup.  When you attach the disks to a new system, you have to
> import them (at which point they get a name that is stored in a config
> file in /etc), and your LVM config is never touched until you change it.
> When you export the VG, it also doesn't write to the disks, just deletes
> the config from /etc.  This means you don't need to do anything to the
> VG before moving it to another system.

Well, actually you can just "vgscan" in the VG without vgexport'ing it
in Linux LVM as well. vgexport/vgimport exactly is the clean procedure
to make sure that name clashes don't happen!

> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> 
> 
> _______________________________________________
> 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-11-23  6:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-11-20 12:39 [linux-lvm] Just for information Igor Dumaire
2001-11-20 13:55 ` Andreas Dilger
2001-11-20 14:39   ` Wichert Akkerman
2001-11-20 15:36     ` Chad C. Walstrom
2001-11-20 16:05     ` Andreas Dilger
2001-11-23  6:07       ` Heinz J . Mauelshagen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox