Re: [rlug] md *NU* continua rebuild dupa reboot - rezolvat

2015-10-01 Fir de Conversatie Mihai Gaitos 
Multumesc tuturor pentru sfaturi. Cateva raspunsuri la intrebari si 
observatii (imi pare rau de intarziere)

Afirmativ, sistemul este pe sda, nu bootez de pe RAID
md este compilat in kernel, nu este modul
mdadm.conf este gol (ma rog, doar comentarii), incepe asa:
# mdadm will function properly without the use of a configuration file,
am presupus (gresit, inteleg acum) ca nu este necesar
Intr-adevar si mie mi s-a parut putin curios ca a devenit md127 dar nu 
am urmarit problema, multumesc de atentionare
In treacat fie spus, partitii de tip RAID am facut acum in cadrul 
testelor, configuratia initiala pe care am observat problema e cu 
discuri intregi; dar chiar si cu discuri intregi tot autodetecteaza 
(kernelul) si creaza array.
Nu am stiut ca driverul din kernel stie doar de superblock 0.9, am fost 
convins ca in 3.x stie si el de 1.2; cum pot determina asta?
In treacat fie spus, aseara am pornit o compilare de kernel 3.19.8, acum 
dimineata am testat si cu el functioneaza asa cum trebuie (desigur 
numele e tot md127, acum am inteles si de ce)

Dupa ce am citit aici,  am scris in mdadm.conf cum zice Vali Dragnuta, 
dar nu am modificat initrd pentru ca nu imi trebuie md vizibil la boot, 
doar dupa. Am adaugat "raid=noautodetect" la linia de comanda a 
kernelului (odata ce am stiut ce trebuie facut a fost simplu de gasit 
optiunea) si asa functioneaza si cu 3.10.17 (default din distributie).
Prefer asa decat sa imi bat capul cu configurarea lui 3.19.8 (cu 
everything default nu imi vede placile de retea, de pilda)

Inca odata multumiri, problema a fost rezolvata.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot - rezolvat

2015-10-01 Fir de Conversatie Mihai Badici 
On Thursday 01 October 2015 09:47:10 Mihai Gaitos wrote:
> Multumesc tuturor pentru sfaturi. Cateva raspunsuri la intrebari si
> observatii (imi pare rau de intarziere)
> 
> Afirmativ, sistemul este pe sda, nu bootez de pe RAID
> md este compilat in kernel, nu este modul
> mdadm.conf este gol (ma rog, doar comentarii), incepe asa:
> # mdadm will function properly without the use of a configuration file,
> am presupus (gresit, inteleg acum) ca nu este necesar
> Intr-adevar si mie mi s-a parut putin curios ca a devenit md127 dar nu
> am urmarit problema, multumesc de atentionare
> In treacat fie spus, partitii de tip RAID am facut acum in cadrul
> testelor, configuratia initiala pe care am observat problema e cu
> discuri intregi; dar chiar si cu discuri intregi tot autodetecteaza
> (kernelul) si creaza array.
> Nu am stiut ca driverul din kernel stie doar de superblock 0.9, am fost
> convins ca in 3.x stie si el de 1.2; cum pot determina asta?
> In treacat fie spus, aseara am pornit o compilare de kernel 3.19.8, acum
> dimineata am testat si cu el functioneaza asa cum trebuie (desigur
> numele e tot md127, acum am inteles si de ce)
> 

Din cate stiu eu, nu exista suport pt 1.2 in nici un kernel.
Cred ca raid=noautodetect e cel care rezolva problema, eu as crede ca 
asa merge chiar daca nu ai mdadm.conf dar nu am testat ( la un moment 
dat am fost asa de intrigat de aceasta problema ca imi facusem o virtuala 
ca sa testez. Sa ma uit sa vad daca o mai am :)


> Dupa ce am citit aici,  am scris in mdadm.conf cum zice Vali Dragnuta,
> dar nu am modificat initrd pentru ca nu imi trebuie md vizibil la boot,
> doar dupa. Am adaugat "raid=noautodetect" la linia de comanda a
> kernelului (odata ce am stiut ce trebuie facut a fost simplu de gasit
> optiunea) si asa functioneaza si cu 3.10.17 (default din distributie).
> Prefer asa decat sa imi bat capul cu configurarea lui 3.19.8 (cu
> everything default nu imi vede placile de retea, de pilda)

Eu nu am mai compilat de mult un kernel, e o legenda urbana despre 
slackeri :)
De fapt, mint, mai compilez pentru laptopul personal, fiindca nu prea 
merge bine placa wireless ( deja sunt la 4.0.1 si nu sunt multumit inca :)  ) 
Oricum, placile de retea sunt compilate ca module, deci probabil nu le-ai 
compilat sau trebuie sa schimbi prin rc.modules calea la cele noi. 
De destul de multa vreme kernelul e acelasi pentru toata lumea, difera 
doar wizard-eria din jurul lor. Am facut inclusiv magarii de genul luat module 
proprietar pentru Suse , compilat aceeasi versiune de kernel pentru 
slackware si modprobe :)

Pe unele distributii merge tocmai pentru ca nu exista suport in initrd 
pentru mdadm ; daca nu ma insel, la debian atunci cand faci un raid1 
pentru boot iti reface initrd. 


> 
> Inca odata multumiri, problema a fost rezolvata.

Si important e ca am mai invatat cu totii cate ceva, me included :)

> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug-- 
Mihai Badici[1] 


[1] http://mihai.badici.ro
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-10-01 Fir de Conversatie manuel "lonely wolf" wolfshant 
On 10/01/2015 12:33 PM, Vali Dragnuta wrote:
> Incorect :
>
> A. Debian cere explicit mdadm.conf
> https://wiki.debian.org/SoftwareRAID
> Cindva am mai avut discutia asta, s-a reintrodus necesitatea de a avea
> mdadm.conf pentru un motiv anume, momentan nu gasesc detaliile tehnice,
> mai caut.
>
>
> B. RHEL/Centos 5 si 6 (nu am testat inca pe 7)
> RHEL5 cere explicit mdadm.conf, conform documentatiei
Pe 5 nu am mai incercat de multa vreme asa ca nu mai stiu.

> RHEL6 se comporta astfel : Daca faci array cu metadate 1.x post
> instalare si nu le treci in mdadm.conf, dupa urmatorul reboot deviceul
> este detectat drept md127,
corect

> este inutilizabil si nici nu se
> sincronizeaza. Arata asa :
> Personalities : [raid1]
> md127 : active (auto-read-only) raid1 sdc1[1] sdb1[0]
>488252928 blocks super 1.2 [2/2] [UU]
>   resync=PENDING
>bitmap: 4/4 pages [16KB], 65536KB chunk
cel putin centos 6.5 si urmatoarele merg bine mersi faca niciun 
mdadm.conf. am in uz raiduri facute la luni/ani post instalarea initiala 
si am dat intimplator peste situatia asta cind la reboot m-am trezit cu 
md127 si md126 in loc de md4 si md5 cum le botezasem eu la creare. se 
sincronizeaza insa si functioneaza fara pb.

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-10-01 Fir de Conversatie Mihai Gaitos 
manuel "lonely wolf" wolfshant wrote:
> cel putin centos 6.5 si urmatoarele merg bine mersi faca niciun
> mdadm.conf. am in uz raiduri facute la luni/ani post instalarea initiala
> si am dat intimplator peste situatia asta cind la reboot m-am trezit cu
> md127 si md126 in loc de md4 si md5 cum le botezasem eu la creare. se
> sincronizeaza insa si functioneaza fara pb.
In lumina experientei mele negative (mai ales ca asta nu e o situatie 
prea comuna - reboot in timpul rebuildului) as sugera ca cel putin 
pentru kernel <=3.10.17 sa testati (pe o configuratie similara, vm etc) 
ce se intampla in cazul in care matricea este in process de rebuild si 
se da reboot. Sau mare grija cu ce se intampla cat matricea este in rebuild.

Mie unul scenariul mi se pare destul de scary, pentru ca mai ales la 
matrici mari ai schimbat un HDD si te duci linistit la culcare cat el 
isi face rebuild. Daca se intampla pana de curent taman atunci si el 
porneste "curat" fara sa stie ca nu a terminat rebuildul sunt sanse de 
silent data corruption - cea mai neplacuta varianta.

Mentionez ca desi problema a fost intampinata pe un server de teste, eu 
pana azi aveam si in productie o masina in configuratie similara; de azi 
e cu mdadm.conf :)

Cu kernel 3.19.8 functioneaza ok si fara mdadm.conf (matricea se 
porneste ca md127 dar isi continua rebuildul in mod corect)

PS: In cazul in care cineva se intreaba cum naiba am putut da peste o 
asemenea situatie, raspunsul este ca faceam "Truck based replication" la 
drbd: 
https://drbd.linbit.com/users-guide/s-using-truck-based-replication.html 
(care nu merge chiar ca in documentatie dar asta e alta istorie)
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-10-01 Fir de Conversatie Vali Dragnuta 
Incorect :

A. Debian cere explicit mdadm.conf
https://wiki.debian.org/SoftwareRAID  
Cindva am mai avut discutia asta, s-a reintrodus necesitatea de a avea
mdadm.conf pentru un motiv anume, momentan nu gasesc detaliile tehnice,
mai caut.


B. RHEL/Centos 5 si 6 (nu am testat inca pe 7)
RHEL5 cere explicit mdadm.conf, conform documentatiei
RHEL6 se comporta astfel : Daca faci array cu metadate 1.x post
instalare si nu le treci in mdadm.conf, dupa urmatorul reboot deviceul
este detectat drept md127, este inutilizabil si nici nu se
sincronizeaza. Arata asa :
Personalities : [raid1] 
md127 : active (auto-read-only) raid1 sdc1[1] sdb1[0]
  488252928 blocks super 1.2 [2/2] [UU]
resync=PENDING
  bitmap: 4/4 pages [16KB], 65536KB chunk

Conform linkului tau, :
 Version 1.2 superblocks will not automatically assemble with a numbered
device name unless specifically told to do so.  There are two way to do
this:

1. Pass the --name= option to the mdadm --create command.  This
will cause the name to be a simple number, and mdadm will assume that
you want the array created with that number as the device name.  Aka, 0
will get assembled as /dev/md0, 1 as /dev/md1, etc.
-> Nu functioneaza

2. Create an ARRAY line in the mdadm.conf file that specifies the uuid
of the array and the name you wish the array to have 
-> asta este fix ca am recomandat eu initial, si functioneaza.



___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie manuel "lonely wolf" wolfshant 
On 09/30/2015 10:37 PM, Vali Dragnuta wrote:
> Probabil ca nu e de fapt activ. Prin alte distributii, dupa ce faci
> matricea trebuie musai sa produci si /etc/mdadm.conf cu ceva gen
> mdadm --examine --scan > /etc/mdadm.conf si eventual rebuild de
> initramfs daca ai.
in distributiile decente (aka mdadm suficient de recent incit sa 
foloseasca metadate v1.2) mdadm.conf nu mai e strict necesar  de vreo 5 ani


> Dupa ce faci asta o sa-ti fie initializat la boot si o sa porneasca
> reconstructia de unde a ramas.
kernelul ar trebui sa recunoasca de la boot ca raid-ul e bulit, 
comparind metadatele de pe membri


> Oricum, numele deviceului de md127 seamana a initializare incompleta la
> boot => fa-i mdadm.conf.
nu e nimic incomplet. daca in mdadm.conf din initrd/initramfs nu are 
trecut alt nume, kernelul aloca automat la pornire numele md127, md126...
a se vedea explicatiile de la 
https://bugzilla.redhat.com/show_bug.cgi?id=606481#c1 si urmatoarele 
comentarii

/me thinks kernelul ALA din slackware e compilat cu optiuni incomplete. 
dar cum nu mai folosesc slack de vreo 18 ani, poate gresesc

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie Vali Dragnuta 
Probabil ca nu e de fapt activ. Prin alte distributii, dupa ce faci
matricea trebuie musai sa produci si /etc/mdadm.conf cu ceva gen
mdadm --examine --scan > /etc/mdadm.conf si eventual rebuild de
initramfs daca ai. 
Dupa ce faci asta o sa-ti fie initializat la boot si o sa porneasca
reconstructia de unde a ramas.
Oricum, numele deviceului de md127 seamana a initializare incompleta la
boot => fa-i mdadm.conf.


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie Mihai Badici 
On Wednesday 30 September 2015 23:04:11 manuel lonely wolf wolfshant 
wrote:
> On 09/30/2015 10:37 PM, Vali Dragnuta wrote:
> > Probabil ca nu e de fapt activ. Prin alte distributii, dupa ce faci
> > matricea trebuie musai sa produci si /etc/mdadm.conf cu ceva gen
> > mdadm --examine --scan > /etc/mdadm.conf si eventual rebuild de
> > initramfs daca ai.
> 
> in distributiile decente (aka mdadm suficient de recent incit sa
> foloseasca metadate v1.2) mdadm.conf nu mai e strict necesar  de vreo 
5 ani
> 
> > Dupa ce faci asta o sa-ti fie initializat la boot si o sa porneasca
> > reconstructia de unde a ramas.
> 
> kernelul ar trebui sa recunoasca de la boot ca raid-ul e bulit,
> comparind metadatele de pe membri
> 
> > Oricum, numele deviceului de md127 seamana a initializare incompleta 
la
> > boot => fa-i mdadm.conf.
> 
> nu e nimic incomplet. daca in mdadm.conf din initrd/initramfs nu are
> trecut alt nume, kernelul aloca automat la pornire numele md127, 
md126...
> a se vedea explicatiile de la
> https://bugzilla.redhat.com/show_bug.cgi?id=606481#c1 si urmatoarele
> comentarii
> 
> /me thinks kernelul ALA din slackware e compilat cu optiuni incomplete.
> dar cum nu mai folosesc slack de vreo 18 ani, poate gresesc

Nu cred, din cate am vazut atata stie la boot , doar metadata .9
N-am mai compilat de mult un kernel de slackware, asa e compilat de la 
mama (tata) lui :)   Nu depinde neaparat de distributie. mdadm este 
suficient de recent, pentru ca dupa cum se vede, a facut raid-ul cu 
metadata 1.2, ca doar nu l-a facut pe ubuntu  :)   . 
S-ar putea totusi sa ai dreptate si sa fie ceva indecent, si anume initrd-ul 
furnizat by default de distributie, care e bazat pe busybox si asta sa aiba 
un mdadm mai vechi. 




> 
> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug-- 
Mihai Badici[1] 


[1] http://mihai.badici.ro
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie Mihai Badici 
On Wednesday 30 September 2015 22:37:33 Vali Dragnuta wrote:
> Probabil ca nu e de fapt activ. Prin alte distributii, dupa ce faci
> matricea trebuie musai sa produci si /etc/mdadm.conf cu ceva gen
> mdadm --examine --scan > /etc/mdadm.conf si eventual rebuild de
> initramfs daca ai.
> Dupa ce faci asta o sa-ti fie initializat la boot si o sa porneasca
> reconstructia de unde a ramas.
> Oricum, numele deviceului de md127 seamana a initializare incompleta la
> boot => fa-i mdadm.conf.


Numele device-ului exact asta inseamna, ca el l-a facut cu metadata 1.2 ( 
care e default in mdadm) si este asamblat de catre kernel. Care kernel nu 
stie decat varianta veche. ( Am intalnit-o destul de des ca sa ma intrige si 
sa caut explicatia).
In alte distributii, se foloseste un kernel cu suportul de mdadm compilat ca 
modul. Din cauza asta asamblarea se produce dupa boot, cu tool-ul din 
userspace, care eventual are nevoie de mdadm.conf. De fapt informatia e 
deja prezenta pe disc, dar dupa boot n-o mai citeste nimeni, deci banuiesc 
ca de fapt rostul mdadm.conf este ca scriptul de init, care o fi el, sa stie ce 
matrici sa asambleze. Kernelul nu are nevoie de mdadm.conf pentru ca 
detecteaza  partitia de tip raid si foloseste informatia de pe ea.
Cred ca ar merita sa incerce manual sa dezasambleze matricea si sa o 
asambleze la loc, cred ca o va asambla ca md1 sau 2, cum a definit-o 
initial, si nu ca md127.



> 
> 
> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug-- 
Mihai Badici[1] 


[1] http://mihai.badici.ro
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie manuel "lonely wolf" wolfshant 
On 09/30/2015 10:57 PM, Mihai Badici wrote:
> On Wednesday 30 September 2015 22:50:04 Bogdan-Stefan Rotariu wrote:
>>> On 30 Sep 2015, at 22:37, Vali Dragnuta 
> wrote:
>>> Oricum, numele deviceului de md127 seamana a initializare incompleta
> la
>>> boot => fa-i mdadm.conf.
>> Si fiind vorba de slackware nu ar strica sa faci si un mkinitrd, sa stie si
>> kernelul de mdadm.conf ___
>> RLUG mailing list
>> RLUG@lists.lug.ro
>> http://lists.lug.ro/mailman/listinfo/rlug
> Nu imi e clar cum e influentat mkinitrd de mdadm.conf?--
>
in RH cel putin, fara mdadm.conf, kernelul aloca el un nume automat la 
boot. mkinitrd / dracut includ mdadm.conf in initrd/initramfs si il fac 
astfel disponibil kernelului la boot
nu stiu insa care e comportamentul la slackware
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie Mihai Badici 

> > Nu imi e clar cum e influentat mkinitrd de mdadm.conf?--
> 
> in RH cel putin, fara mdadm.conf, kernelul aloca el un nume automat la
> boot. mkinitrd / dracut includ mdadm.conf in initrd/initramfs si il fac
> astfel disponibil kernelului la boot
> nu stiu insa care e comportamentul la slackware

Ideea era ca mkinitrd face un initrd din ce se gaseste in /boot/initrd-tree , 
deci nu are treaba cu /etc/mdadm.conf decat daca il copiezi in /boot/initrd-
tree/etc
Dar cred ca m-ai dus pe o pista corecta, si anume ca e vorba de fapt de 
initrd si nu de kernel cum credeam eu, asa ca poate merge sa copieze 
mdadm-ul din /sbin/ in initrd-tree/sbin si sa faca un initrd nou.
In ghidul slackware scrie sa faci partitiile de boot cu metadata 0.9 dar 
probabil asta e varianta simpla, la care nu compilezi nimic :)
Cred ca e la fel si la debian dealtfel; caracteristica slackware nu e ca are 
pachete vechi ( de obicei sunt chiar mai noi ca la altele)  ci ca are putine :)



> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug-- 
Mihai Badici[1] 


[1] http://mihai.badici.ro
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

[rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie Mihai Gaitos 
Salut!

Am intampinat urmatoarea problema pe Slackware 14.1 (kernel 3.10.17 x64, 
mdadm 3.2.6)
Se da un array RAID1 construit din sdb si sdc. La un moment dat sdb este 
inlocuit (hot) si se declanseaza un rebuild. Problema este ca daca se da 
reboot la calculator inainte de terminarea rebuildului, acesta nu mai 
este finalizat iar matricea apare clean (fara degraded/recovering). 
Evident datele sunt aiurea (corupte, sdb era hdd nou).

Nu reusesc sa gasesc nimic relevant cu exceptia unui bug mai vechi 
raportat in Fedora in 2012:
https://bugzilla.redhat.com/show_bug.cgi?id=817039
Sugestia acolo a fost update la mdadm; al meu este deja mai nou si 
oricum mdadm este user-space, nu cred ca aici e problema. Pentru orice 
eventualitate am pus mdadm 3.3.4 dar problema persista.

Am testat si cu partitii tip 0xfd, si pe un alt sistem tot Slackware 
14.1 dar cu kernel x86; se intampla la fel.

Tot ce tine de RAID este facut strict din Linux, nu am folosit eventuale 
facilitati de software-RAID ale placilor de baza.

E vreo optiune care imi scapa sau este un bug pe undeva. In ultima 
varianta, in afara de kernel (si de mdadm pe care l-am actualizat) mai 
poate fi si alta componenta care sa afecteze functionarea RAID-ului?

In fine, are cineva la indemana un sistem cu care sa testeze? Pasii ar fi:
root@nxen:~# mdadm -C /dev/md127 --level=1 --raid-devices=2 /dev/sdb1 
/dev/sdc1
dupa ce e in stare clean (fara resyncing)
root@nxen:~# mdadm --manage /dev/md127 --fail /dev/sdc1
mdadm: set /dev/sdc1 faulty in /dev/md127
root@nxen:~# mdadm --manage /dev/md127 --remove failed
mdadm: hot removed 8:33 from /dev/md127
root@nxen:~# mdadm --manage /dev/md127 -a /dev/sdc1
mdadm: added /dev/sdc1
si incepe reconstructia:
root@nxen:~# mdadm --detail /dev/md127
root@nxen:~#  mdadm --detail /dev/md127
/dev/md127:
 Version : 1.2
   Creation Time : Wed Sep 30 14:48:05 2015
  Raid Level : raid1
  Array Size : 20955136 (19.98 GiB 21.46 GB)
   Used Dev Size : 20955136 (19.98 GiB 21.46 GB)
Raid Devices : 2
   Total Devices : 2
 Persistence : Superblock is persistent

 Update Time : Wed Sep 30 14:55:52 2015
   State : active, degraded, recovering
  Active Devices : 1
Working Devices : 2
  Failed Devices : 0
   Spare Devices : 1

  Rebuild Status : 1% complete

Name : nxen:127  (local to host nxen)
UUID : 7589d8f8:0d8b5716:06e07bfa:28407522
  Events : 23

 Number   Major   Minor   RaidDevice State
0   8   170  active sync   /dev/sdb1
2   8   331  spare rebuilding   /dev/sdc1
se da reboot si la verificare este totul "ca nou"
root@nxen:~# mdadm --detail /dev/md127
/dev/md127:
 Version : 1.2
   Creation Time : Wed Sep 30 14:48:05 2015
  Raid Level : raid1
  Array Size : 20955136 (19.98 GiB 21.46 GB)
   Used Dev Size : 20955136 (19.98 GiB 21.46 GB)
Raid Devices : 2
   Total Devices : 2
 Persistence : Superblock is persistent

 Update Time : Wed Sep 30 14:56:35 2015
   State : clean
  Active Devices : 2
Working Devices : 2
  Failed Devices : 0
   Spare Devices : 0

Name : nxen:127  (local to host nxen)
UUID : 7589d8f8:0d8b5716:06e07bfa:28407522
  Events : 26

 Number   Major   Minor   RaidDevice State
0   8   170  active sync   /dev/sdb1
2   8   331  active sync   /dev/sdc1


Multumesc,
Mihai Gaitos
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Re: [rlug] md *NU* continua rebuild dupa reboot

2015-09-30 Fir de Conversatie Mihai Badici 
On Wednesday 30 September 2015 15:01:32 Mihai Gaitos wrote:
> Salut!
> 
> Am intampinat urmatoarea problema pe Slackware 14.1 (kernel 3.10.17 
x64,
> mdadm 3.2.6)
> Se da un array RAID1 construit din sdb si sdc. La un moment dat sdb 
este
> inlocuit (hot) si se declanseaza un rebuild. Problema este ca daca se da
> reboot la calculator inainte de terminarea rebuildului, acesta nu mai
> este finalizat iar matricea apare clean (fara degraded/recovering).
> Evident datele sunt aiurea (corupte, sdb era hdd nou).
Presupun ca sistemul e pe sda?
Ma gandesc ca apare o inconsistenta de la faptul ca raid-ul e facut cu 
tool-ul din userspace ( metadata 1.2) dar e asamblat de catre kernel ( de 
asta il vede ca md127 desi tu l-ai facut probabil mda2 ).
Nu pot acum sa testez dar ma gandesc ca ar trebui sa incerci urmatoarele 
variante: 
1. Nu stiu precis cum dar presupun ca poti impiedica asamblarea matricii 
de catre kernel, pana acum nu mi-am pus problema. La slack mdadm e 
compilat in kernel dar driverul ala  recunoaste doar metadata 0.9 . Daca 
nu ai nevoie de raid la boot poti incerca un kernel fara driver compilat 
(cred ca ala fara -huge).
2. Sa incerci sa faci raid-ul de la inceput cu metadata 0.9-- 
Mihai Badici[1] 


[1] http://mihai.badici.ro
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug