Gibet hier nen LVM-Experten?

[Dieter Franzke]

Hi,

Am Montag, 20. Januar 2003 08:02 schrieb Jan-Benedict Glaw:
> On Mon, 2003-01-20 07:58:25 +0100, Dieter Franzke <dililikima at gmx.net>
>
> wrote in message <200301200758.25034.dililikima at gmx.net>:
> > Am Montag, 20. Januar 2003 07:46 schrieb Jan-Benedict Glaw:
> > > On Mon, 2003-01-20 07:39:02 +0100, Dieter Franzke <dililikima at gmx.net>
> > >
> > > wrote in message <200301200739.02336.dililikima at gmx.net>:
> > > > Nun wollte ich das ganze mal testen, und habe die VG deaktiviert und
> > > > wollte sie dann wieder aktivieren.
> > > > Das deaktivieren mittels vgchange ging, das erneute aktivieren
> > > > liefert nur noch einen Error: ERROR Bad Adrress in activating volume
> > > > group data.
> > >
> > >Was passiert, wenn Du das
> > > Script Deiner Distribution, um LVM zu stoppen und zu starten ausführst?
> >
> > das gleich Ergebnis.....
> >
> > Werde wohl um ein restore nicht umhinkommen, seufz.....
>
> Das denke ich nicht unbedingt. LVM ist recht stabil, wie wäre es, wenn
> Du einfach mal alle Kommandos mit '-d' und gaaanz vielen '-v's
> ausführst. Dann kann man schonmal sehen, woher's exakt kommt.

...da werd ich nicht so recht schlau draus:

Auszug:

<55555> lv_check_name -- CALLED with lv_name: "/dev/data/data"
<666666> lvm_check_chars -- CALLED with name: "/dev/data/data"
<666666> lvm_check_chars -- LEAVING with ret: 0
<666666> vg_check_name -- CALLED with VG: data
<7777777> lvm_check_chars -- CALLED with name: "data"
<7777777> lvm_check_chars -- LEAVING with ret: 0
<666666> vg_check_name -- LEAVING with ret: 0
<55555> lv_check_name -- LEAVING with ret: 0
<55555> vg_check_name -- CALLED with VG: data
<666666> lvm_check_chars -- CALLED with name: "data"
<666666> lvm_check_chars -- LEAVING with ret: 0
<55555> vg_check_name -- LEAVING with ret: 0
<4444> lv_check_consistency -- LEAVING with ret: 0
<333> lv_check_consistency_all_lv -- vg->lv[1]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[2]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[3]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[4]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[5]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[6]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[7]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[8]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[9]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[10]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[11]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[12]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[13]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[14]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[15]: 0  name: (null)
<333> lv_check_consistency_all_lv -- vg->lv[16]: 0  name: (null)
..........
get so weiter bis                                   lv[256] 
und wiederholt sich auf allen Platten.

wenn ich aber einen vgck mache ---> alles konsistent

Was wäre denn schlimmstenfalls passiert, wenn die Platte schon ne Macke gehabt 
hätte?
Dann müßte ich doch eigentlich noch Zugriff auf die anderen Daten haben?
Ich nutze LVM jetzt schon so lange, so etwas ist mir noch nie passiert.

Die weiteren debug-infos sagen, dass lvm immer versucht die Platten über die 
vg anzusprechen und immer einen fallback auf die Quelldevices /dev/sda sdb 
macht.
Obwohl da eine LVM-PArtition mit xfs drauf ist.
Jetzt habe ich weder über lvm Zugriff, noch kann ich die Dinger direkt 
mounten...schluchz


- 
registered linuxuser 199810
it's time to close windows....