On 26-Sep-23 17:22, Adrian Sevcenco via RLUG wrote:
On 9/26/23 14:51, Alex 'CAVE' Cernat via RLUG wrote:
On 26-Sep-23 14:36, Adrian Sevcenco via RLUG wrote:
Din ce stiu la raid6 e detectabila notiunea de chunk corupt si se
reface (cu repair in loc de check) dar pentru raid1 am inteles ca
solutia pentru bit-rot e sa pui sub raid1 un dm-integrity
bine am citit si raid6 facut peste dm-integrity dar nu vad rostul
Adrian
la raid6+ da, pentru ca ai 2+ paritati (presupunand ca raidul e 100%
functional cu toate hardurile, daca nu ... cred ca sanatate), insa mai
fiecare chunk are si celelate 2 paritati, cu 2 discuri cazute poti sa
faci rebuild chiar si in productie ... doar ca iti cam tzatzaie
backside-ul ca rebuildul in productie poate dura si mai mult de o
saptamana si daca ai un un-recoverable error la ce ai in rest in
timpul rebuild-ului atunci chiar ai pierdut tot (poti sa ai nroc si sa
lamuresti md-ul ca ce i se pare lui ca lipsestes in mod ne-recuperabil
de fapt e ok si apoi sa iti mearga fsck-ul pe ce se vede in sistemul
de fisiere si sa ai doar un numar de indouri lipsa)
nu vorbeam de refacerea array-ului, vorbeam de integritatea datelor; din
2 paritati cred ca poti sa-ti dai seama care din stripe-uri a luat-o
razna si sa corectezi problema (combinatorica + brute force, sau poate o
fi ceva mai inteligent), dintr-o singura paritate poti constata doar ca
ceva e belit, aka ai cel mult error detection, nu si correction
Dupa primele 2x100 TB pierdute acum scot direct din productie md-urile
cu 2 discuri picate, dar nu s-a mai intimplat de atunci (era o masina
dubioasa cu cablaj dubios la expandere etc)
jos cutzu, poti detecta eroarea citind de pe disc, dar nu ai de unde
sa stii care date sunt cele corecte
de aia la zfs au bagat din start checksumming, acolo integritatea
datelor se testeaza chiar on-the-fly si repararea asisderea (cat timp
nu esti marele ghinionist sa ti se beleasca fix chunkurile care
trebuie :-P); si asta la orice fel de raid, inclusiv mirror; la
non-raid, doar stii ca ai pus-o de mamaliga, eventual poate te apuci
de brute-force sa reconstitui datele :-D
din punctul meu de vedere zfs-ul e irelevant atat timp cat nu exista
in kernel .. evident punctul meu de vedere e irelevant, dar sunt multi
oameni cu mult hardware in spate care gandesc (si actioneaza) la fel ...
pe aceiasi idee in cercul meu "social" ferme de gpu computing cu
nvidia au fost inlocuite cu insticturile de la amd ...
nu pentru performante este iubit zfs-ul (desi culmea, daca investesti
destul in hardware poti obtine rezultate chiar comparabile cu
"concurenta"), ci pentru "feature-urile" care le are
tu am vazut ca esti pe calea "palariei", afaik ubuntu are support in
kernel, iar pe debian ai pachetele de kernel & utils de la proxmox
(recompilat kernelul din ubuntu), pe care le folosesc cu succes de
cateva versiuni incoace, deci s-ar putea sa fac in curand deceniul :-P
in plus tin minte ca acum ani de zile a fost testat la profilul nostru
de load-uri si a fost categorisit ca imposibil de utilizat :D
noi (cercul meu "social" :) ) folosim un sistem numit EOS, ce e un fel
de sistem distribuit de fisiere (ce foloseste fs-uri existente pe
masina deci nu raw block deviceuri) ce are si checksumming si stie si
modele de redundanta, doar ca are niste quirk-uri ce pentru oameni
saraci ca mine (4 PB) il fac un pic detrimental utilizarii, desi ar fi
niste facilitati obligatorii pentru siguranta datelor (in fault mode,
daca nu gaseste prin cluster un fs pentru recovery atunci blocheaza
cel putin write-ul la grupul respectiv de fs-uri)
Mno, nu e vineri dar mi-a fost dor de o flama pe aici ... am putea sa
mai bagam ca prea e liniste :D
pai da, cam liniste pe grupul asta, toata lumea o fi pe fb (sau mai nou
noile generatii-s pe tictoci)
idem pe la san-uri si (macar) unele hw raid, doar ca pe acolo sunt mai
NAS-uri vrei sa zici ? sa san-urile sunt mai multe discuri prin
diverse locuri in data center la care au access 1 sau mai multe
servere (prin SAS) .. e ca si cum ar fi in carcasa (asa cum in curand
o sa fie memoria, gpu-uri, NIC-uri/DPU-uri, NVME etc prin CXL)
nope, nas am zis, nas am gandit; bine, sper ca nu m-au pacalit cu
terminologia zfs, insa un "scrub" nu vad cum il pot traduce decat ca o
operatie de verificare a array-ului (sau plural), poate eventual si ceva
rebalansare, daca e cazul
au san-urile de la hp (chiar si alea msa mici) de vreo 10 ani cel putin
mult sau mai putin "invaluite in magie", ca nu ai acces low level
mda, acum 15-20 ani am fost fan la placile raid hw dar dupa niste
intimplari (legate si de faptul ca la noi servere pot sa fie in
productie si dupa 10 ani) m-am jurat ca nu mai folosesc asa ceva vreodata
sunt bune daca urmezi "calea"; daca iesi de pe traseul lor (de exemplu
sa te apuci sa pui zfs pe niste hp-uri) deja incepe distractie maxima,
iti doresti sa fi luat niste troace, ca sigur erau mai putine batai de cap
insa dupa cum ziceam, daca nu te abati din "intented usage", ai mai
putine batai de cap decat daca ai fi pornit cu "vaporware"
bine, cand esti gogu sau amazon si ai milioane de pseudo-waporware (de
fapt nu-i, doar cel mult arata de la distanta), deja e alta mancare de
peste, ca ala devine "de firma"
Alex
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
