GoT heeft kuren... picserver en search plat.

[elevator]

Het overlijden van meerdere disken blijft altijd een risico, en kan je heel weinig aan doen - behalve een backup hebben. Dat de backups niet (goed) werkte, is gewoon domme pech, en is weinig aan te doen.

curry684 schreef op 18 August 2003 @ 17:16:
Om maar even een praktijkvoorbeeld te geven van 'megarare cases': collega van mij had laatst een gevalletje te pakken met een Dell server met SCSI-RAID aan boord waarbij binnen 30 minuten beide harde schijven mechanisch overleden. Soms heb je zo'n pech dat geen voorzorgen er tegen bestand zijn

Dan heb je het ook over een merk

[Wekkel]

Ik neem aan dat Murphy's law al langs is gekomen?

[Snow_King]

Ik vind het wel jammer, ik had in mijn foto-album 25mb aan foto's staan, screenshots van games e.d.

Voorbeeld: Desert Combat - Battlefield 1942 Modification (Deel II)

Iets waar ik de grootste hekel aan hem is kruisjes in een topic, daarom liet ik al mijn foto's staan in mijn foto-album voor mensen die het later nog eens bekeken.

Ik moet toch zeggen dat ik dit op zijn zachts uitgedrukt niet leuk vind, ik heb alle foto's nog wel, maar toch, ik betaal er toch voor?
Ik kan nu dus 25mb aan pics gaan uppen en allemaal posts gaan editen, waar ik eigenlijk geen zin in heb....

* Snow_King is nog steeds tevreden, maar ben wat teleurgesteld

[ Voor 9% gewijzigd door Snow_King op 19-08-2003 14:28 ]

[mOrPhie]

* mOrPhie heeft net het mailtje gelezen.

Ik wilde even zeggen (na mijn zee van kritische opmerkingen) dat ik het mailtje erg netjes vind. daarvoor. De acties die hierop ondernomen worden stemmen me zeer goed en wijst uit dat t.net er echt moeite voor doet (daar twijfelde ik niet aan natuurlijk, maar huiverig wordt je wel na zoiets als dit). Ga zo door in elk geval!

[ Voor 20% gewijzigd door mOrPhie op 19-08-2003 15:36 ]

[LauPro]

ACM schreef op 18 augustus 2003 @ 17:56:
Dus omdat het FS door fouten van/in de raidcontroller verneukt raakt moeten we een "bewezen" FS (ext3 is toch redelijk stabiel dacht ik zo), maar gaan vervangen door iets anders

Er was, waarschijnlijk, geen enkel FS bestand geweest hiertegen. Een raidcontroller hoort namelijk de complete datastructuur op de schijven "in tact te houden" (naar het OS toe iig) en als ie dat niet doet is _elk_ FS het haasje, of je nou Ext3, Reiser, XFS, whatever gebruikt...

Als ik jou was dan zou ik maar is gaan onderzoeken welk FS hier wel tegen bestand is, en ik weet zeker dat dit bestaat. Maar voor zover ik heb begrepen is het _hele_ FS onderuit gegaan, of is dat een klein stukje? Aangezien er toch nog data terug is gekomen is dus niet het hele FS onderuit gegaan. Imo wel een reden om te zoeken naar een FS dat bijvoorbeeld bestanden wat meer verspreid over het medium (fragmenteerd), voor foto's e.d. heb je toch niet zo'n hoge datatransfer nodig. En btw: populaire FS's zijn niet altijd de beste.

[Anoniem: 13874]

Knap FS dat gewoon dingen goed gaat opslaan als de raidcontroller de data verkeerd opslaat

Ext2 is nu eenmaal onder linux het bewezen FS. Ext3 de opvolger met journaling ondersteuning is een vrij logische keuze op een productieserver t.o.v. reiserfs, xfs etc.

[ Voor 51% gewijzigd door Anoniem: 13874 op 19-08-2003 17:12 ]

[ACM]

LauPro schreef op 19 augustus 2003 @ 16:58:
Als ik jou was dan zou ik maar is gaan onderzoeken welk FS hier wel tegen bestand is, en ik weet zeker dat dit bestaat. Maar voor zover ik heb begrepen is het _hele_ FS onderuit gegaan, of is dat een klein stukje?

Nee, niet het hele, dat kan haast niet met ext2/3.

Aangezien er toch nog data terug is gekomen is dus niet het hele FS onderuit gegaan. Imo wel een reden om te zoeken naar een FS dat bijvoorbeeld bestanden wat meer verspreid over het medium (fragmenteerd), voor foto's e.d. heb je toch niet zo'n hoge datatransfer nodig. En btw: populaire FS's zijn niet altijd de beste.

Ext2/3 slaan de data gedecentraliseerd op. Er is niet 1 plaats waar de file-locatie-tabel is (zoals de FAT in een FAT-tabel en de MFT bij NTFS (die laatste weet ik niet zeker)), echter wel maar een paar waar de "root locatie tabel" is.

De files worden wel enigszins ruimtelijk opgeslagen daarin, maar omdat op hetzelfde FS ook andere files staan (de omega-db, t.net-plaatjes en usericons bijvoorbeeld en ik zie niet zo goed waarom die op een ander FS zou moeten) die _wel_ performance nodig hebben, zie ik niet in waarom er een FS dat "zichzelf fragmenteerd" gebruikt zou moeten worden.
Zeker gezien het feit dat er sprake is van een Raid, waardoor de fysieke locatie van een file of een deel ervan toch niet door het FS en zelfs niet perse door het OS afgedwongen kan worden.

Ik betwijfel nog steeds ten zeerste dat er een FS is dat hier totaal tegen bestand geweest zou zijn, ik heb nauwelijks ervaring met andere linux-fs-en (behalve reiser, maar dat is bij mij nog nooit in een crash-situatie geweest) maar ik verwacht dat de andere journaling-filesystems er hooguit een beetje beter tegen bestand hadden kunnen zijn. Een FS kan je tegen OS-crashes beschermen, maar als er fysiek iets mis is, is het FS nergens meer. Tenzij ie alle files dubbel op gaat slaan ofzo, maar daar heb je nou juist RAID voor

[LauPro]

Anoniem: 13874 schreef op 19 augustus 2003 @ 17:10:
Knap FS dat gewoon dingen goed gaat opslaan als de raidcontroller de data verkeerd opslaat

Niet opslaan, maar gegevens nog kan lezen.

ACM schreef op 19 augustus 2003 @ 17:22:
Nee, niet het hele, dat kan haast niet met ext2/3.

Ok, dan stel ik bij deze vast dat de uitspraak 'het filesystem is onderuit gegaan' niet klopt.

Ext2/3 slaan de data gedecentraliseerd op. Er is niet 1 plaats waar de file-locatie-tabel is (zoals de FAT in een FAT-tabel en de MFT bij NTFS (die laatste weet ik niet zeker)), echter wel maar een paar waar de "root locatie tabel" is.

FAT != data, laten we dat even vaststellen. Daarnaast staat bij FAT32 en NTFS ook niet de hele FAT op 1 plek.

De files worden wel enigszins ruimtelijk opgeslagen daarin, maar omdat op hetzelfde FS ook andere files staan (de omega-db, t.net-plaatjes en usericons bijvoorbeeld en ik zie niet zo goed waarom die op een ander FS zou moeten) die _wel_ performance nodig hebben, zie ik niet in waarom er een FS dat "zichzelf fragmenteerd" gebruikt zou moeten worden.
Zeker gezien het feit dat er sprake is van een Raid, waardoor de fysieke locatie van een file of een deel ervan toch niet door het FS en zelfs niet perse door het OS afgedwongen kan worden.

Omdat er in dit geval hele bestanden weg zijn, dat komt omdat er een deel van het virtuele medium ontbreekt en dat is weer te verwijten aan de RAID-controller oid. Stel dat (ik stel het even grof voor) er 100 bestanden op een schijf staan, en 10% van die bestanden 'crasht'/raken beschadigd -> onleesbaar. Dan zijn dus 10 bestanden gewoon weg, stel dat het FS van tevoren alle bestanden had verspreid, dan zouden er statistisch gezien 20 bestanden half-leesbaar zijn geworden. Voor webservices lijkt mij dat beter omdat de beschadigde data dus wel leesbaar blijft en bijvoorbeeld afbeeldingen in slechtere kwaliteit (die zijn er dus al, die bestanden stonden dus net op de rand van het 'gat') of andere vormen van dataverlies. Op deze mannier hoef je de bezoekers niet direct teleur te stellen, het werkt gewoon allemaal wat 'minder' maar het blijft doordraaien.

Ik betwijfel nog steeds ten zeerste dat er een FS is dat hier totaal tegen bestand geweest zou zijn, ik heb nauwelijks ervaring met andere linux-fs-en (behalve reiser, maar dat is bij mij nog nooit in een crash-situatie geweest) maar ik verwacht dat de andere journaling-filesystems er hooguit een beetje beter tegen bestand hadden kunnen zijn. Een FS kan je tegen OS-crashes beschermen, maar als er fysiek iets mis is, is het FS nergens meer. Tenzij ie alle files dubbel op gaat slaan ofzo, maar daar heb je nou juist RAID voor

Journaling FS's staan hier los van dat is in principe alleen maar relevant wanneer de stroom weg zou vallen of dat de schrijfoperatie plotseling wordt gestaakt. Theoretisch gezien zou dat dus *iets* meer dataverlies kunnen opleveren vanwege het journalling-gebeuren.

[ Voor 17% gewijzigd door LauPro op 19-08-2003 18:00 ]

[ACM]

LauPro schreef op 19 augustus 2003 @ 17:55:
Ok, dan stel ik bij deze vast dat de uitspraak 'het filesystem is onderuit gegaan' niet klopt.

Het filesystem kon de data niet goed meer terughalen, hoe dat precies gebeurt is is in deze context niet eens zo relevant, want de data was op het moment dat het FS ermee overweg moest weg. Ik heb het dan wel over data van de hdd, niet zozeer van het FS. Bestanden en bestandsreferenties zijn voor de hdd allemaal data en daar waren delen van weg/corrupt/onleesbaar/whatever.

Ik ben niet echt in staat om de bitstructuur die beschikbaar was te analyseren en daar een duidelijke en eenduidige verklaring uit te moeten geven.

De makkelijkste uitleg is gewoon dat de RAID-config dusdanige problemen veroorzaakte dat het FS zijn werk niet goed meer kon doen, ongeacht wie er nou precies verantwoordelijk voor die falende werking was.

Omdat er in dit geval hele bestanden weg zijn, dat komt omdat er een deel van het virtuele medium ontbreekt en dat is weer te verwijten aan de RAID-controller oid. Stel dat (ik stel het even grof voor) er 100 bestanden op een schijf staan, en 10% van die bestanden 'crasht'/raken beschadigd -> onleesbaar. Dan zijn dus 10 bestanden gewoon weg, stel dat het FS van tevoren alle bestanden had verspreid, dan zouden er statistisch gezien 20 bestanden half-leesbaar zijn geworden. Voor webservices lijkt mij dat beter omdat de beschadigde data dus wel leesbaar blijft en bijvoorbeeld afbeeldingen in slechtere kwaliteit (die zijn er dus al, die bestanden stonden dus net op de rand van het 'gat') of andere vormen van dataverlies. Op deze mannier hoef je de bezoekers niet direct teleur te stellen, het werkt gewoon allemaal wat 'minder' maar het blijft doordraaien.

Er zijn allerlei half leesbare bestanden, allerlei complete en allerlei compleet verdwenen bestanden. Die half leesbare zijn grotendeels corrupt, want hoewel jpg er in sommige gevallen mee overweg kan dat de helft van de data weg is, kunnen lang niet alle bestandstypen dat.
Ik zie niet in hoe dit de bezoekers minder zou teleurstellen...

Journaling FS's staan hier los van dat is in principe alleen maar relevant wanneer de stroom weg zou vallen of dat de schrijfoperatie plotseling wordt gestaakt. Theoretisch gezien zou dat dus *iets* meer dataverlies kunnen opleveren vanwege het journalling-gebeuren.

't Gaat mij erom dat die FS-en met het oog op _robuustheid_ zijn ontwikkeld, mede door hun journaling, maar ook door hun opslagstrategien zelf. Ik zie niet in hoe een opslagstrategie met meer of minder spreiding de gevolgen een onvoorspelbare uitval kan doen verkleinen...
Ook jij weet niet wat er allemaal weg was, misschien van elke diskblock wel 1/5e deel, dan kan je nog zoveel spreiding hebben, maar dan is er nog net zoveel weg dan.

En als je een FS kent dat beter is dan Ext2/3 in dit geval, laat het me weten, maar we gaan echt niet een of ander vaag experimenteel FS inzetten op een productieserver, terwijl er een FS is dat al jaren stabiel is... (ok ext3 wat korter, maar het is wel de opvolger van ext2).

[Kees]

LauPro schreef op 19 August 2003 @ 17:55:
Ok, dan stel ik bij deze vast dat de uitspraak 'het filesystem is onderuit gegaan' niet klopt.

Je doet maar. maar het blijft een feit dat het FS zodanig verrot was (missende, dubbele inodes, namen die weg zijn van de files, entries in dirs die niet meer klopten etc) dat de hele structuur weg was, en een FS is juist voor die structuur.

FAT != data, laten we dat even vaststellen. Daarnaast staat bij FAT32 en NTFS ook niet de hele FAT op 1 plek.

zonder FAT, of met een gedeeltelijke FAT kun je nog steeds veel data kwijt zijn. zeker als je meer dan 250.000 bestanden hebt en alle namen daarvan weg zijn.

Omdat er in dit geval hele bestanden weg zijn, dat komt omdat er een deel van het virtuele medium ontbreekt en dat is weer te verwijten aan de RAID-controller oid. Stel dat (ik stel het even grof voor) er 100 bestanden op een schijf staan, en 10% van die bestanden 'crasht'/raken beschadigd -> onleesbaar. Dan zijn dus 10 bestanden gewoon weg, stel dat het FS van tevoren alle bestanden had verspreid, dan zouden er statistisch gezien 20 bestanden half-leesbaar zijn geworden. Voor webservices lijkt mij dat beter omdat de beschadigde data dus wel leesbaar blijft en bijvoorbeeld afbeeldingen in slechtere kwaliteit (die zijn er dus al, die bestanden stonden dus net op de rand van het 'gat') of andere vormen van dataverlies. Op deze mannier hoef je de bezoekers niet direct teleur te stellen, het werkt gewoon allemaal wat 'minder' maar het blijft doordraaien.

Journaling FS's staan hier los van dat is in principe alleen maar relevant wanneer de stroom weg zou vallen of dat de schrijfoperatie plotseling wordt gestaakt. Theoretisch gezien zou dat dus *iets* meer dataverlies kunnen opleveren vanwege het journalling-gebeuren.

Theorie hebben we niets aan, er is namelijk geen FS of raidcontroller die werkt zoals jij zegt, onderbouw je eigen theorie eens met practische voorbeelden. Verder is wat jij zegt ook helemaal niet waar, je hebt vaak liever dat er 10 plaatjes weg zijn dan er 20 beschadigt zijn, want met die beschadigde kun je vaak ook geen kant meer op, en zul je dus 20 plaatjes moeten vervangen ipv 10. Verder zul je ze vaak ook niet onder de originele bestandsnaam meer aantreffen, hetgeen het identificeren nog moeilijker maakt. Ook is bij de 'schade' de kans op onherstelbare schade erg groot aanwezig, en een halve database kan bijvoorbeeld niet gebruikt worden aangezien er belangrijke gegevens missen.

Kortom, beschadigde bestanden zijn niet beter dan verwijderde bestanden,. Verder, dingen als 'dan zou ik maar onderzoeken welk FS daar wel tegen bestand is' zijn volkomen uit de lucht gegrepen, er is geen (lokaal) FS dat ik ken dat tegen dergelijke crashes bestand is, en jij kent het ook niet, anders was je allang met linkjes aangekomen om je verhaal te onderbouwen.

[LauPro]

Kees schreef op 19 August 2003 @ 18:38:
zonder FAT, of met een gedeeltelijke FAT kun je nog steeds veel data kwijt zijn. zeker als je meer dan 250.000 bestanden hebt en alle namen daarvan weg zijn.

Dat begrijp ik, maar de 'de FAT is kwijt' betekent dus niet dat belangrijke data ook echt verloren is gegaan, sterker nog: ik heb een keer met de optie 'verloren bestandsfragmenten omzetten naar bestanden' nog veel belangrijke data terug kunnen krijgen, ik geef toe dat het een monnikenwerk is maar dan kom je bij de vraag 'hoe belangrijk is belangrijk' .

Theorie hebben we niets aan, er is namelijk geen FS of raidcontroller die werkt zoals jij zegt, onderbouw je eigen theorie eens met practische voorbeelden. Verder is wat jij zegt ook helemaal niet waar, je hebt vaak liever dat er 10 plaatjes weg zijn dan er 20 beschadigt zijn, want met die beschadigde kun je vaak ook geen kant meer op, en zul je dus 20 plaatjes moeten vervangen ipv 10. Verder zul je ze vaak ook niet onder de originele bestandsnaam meer aantreffen, hetgeen het identificeren nog moeilijker maakt. Ook is bij de 'schade' de kans op onherstelbare schade erg groot aanwezig, en een halve database kan bijvoorbeeld niet gebruikt worden aangezien er belangrijke gegevens missen.

Er vanuitgaande dat er later een backup overheen wordt gezet. En de backupsoftware zal toch alle bestanden moeten controlleren omdat je niet precies weet wat er allemaal mist. Het terugzetten van de backup zal niet langer gaan duren of moeilijker worden.

Kortom, beschadigde bestanden zijn niet beter dan verwijderde bestanden,. Verder, dingen als 'dan zou ik maar onderzoeken welk FS daar wel tegen bestand is' zijn volkomen uit de lucht gegrepen, er is geen (lokaal) FS dat ik ken dat tegen dergelijke crashes bestand is, en jij kent het ook niet, anders was je allang met linkjes aangekomen om je verhaal te onderbouwen.

Het lijkt mij niet aan mij om dat uit te zoeken, dat hoor je te doen als systeembeheerder-zijnde imo. Maargoed ik zeg ook niet dat het FS zoals ik het beschrijf exact bestaat, maar er zijn bijvoorbeeld andere alternatieven om redundantie in het FS te garanderen.

Maargoed, ik ben even aan het zoeken geslagen en ik denk dat een 'virtuele harde schijf' de oplossing is die het dichtste bij mijn verhaal in de buurt komt. Dit is omdat deze software vaak ook een pariteitsbit kan wegschrijven. Daarnaast heb je het voordeel dat die 250k bestanden wat beter/overzichtelijker kunnen worden ingedeeld.

Maar even voor de duidelijkheid: ik ga nu dus in op het standardpunt dat er niks kan worden gedaan aan een controller die de data fout doorgeeft.

[ Voor 6% gewijzigd door LauPro op 19-08-2003 19:54 ]

[moto-moi]

LauPro schreef op 19 augustus 2003 @ 19:51:sterker nog: ik heb een keer met de optie 'verloren bestandsfragmenten omzetten naar bestanden' nog veel belangrijke data terug kunnen krijgen, ik geef toe dat het een monnikenwerk is maar dan kom je bij de vraag 'hoe belangrijk is belangrijk' .

Goh, en wat denk jij dat er gebeurt is na die crash ?
Dat kees en ACM naa rbuiten zijn gelopen, een sigaretje op hebben gestoken, de schouders op hebben gehaald, en hebben getikt 'Joh, rot voor jullie, maar alles is weg, pech gehad, better luck next time' ?

Kees en ACM zijn meteen aan de slag gegaan om in de /lost+found directory files te vinden en veilig te stellen..

En tsja, dan op een gegeven moment hou je clusters over waar je niets mee kan, die kun je wel allemaal met aan elkaar gaan plakken om te zien of het wat toonbaars wordt, maar dan kom je inderdaad op het puntje 'hoe belangrijk is belangrijk'.. Ik denk dat niemand er wat mee opschiet als kees over 2 maanden nog stukjes aanelkaar aan het plakken is van LuNaTiC's laatste vakantiefoto's, of wel soms ?

Want hoe graag mensen het ook willen ontkennen : Vertrouwen op een gegevensdrager is nooit goed te praten.

Dus de mensen die hun foto's hebben geupload, en hun lokale copy niet meer hebben, tis natuurlijk rot voor ze, maar je moet altijd rekening met zoiets houden IMO..

Disclamer: Dit is puur door moto-moi als user geschreven, en weerspiegeld in geen enkel opzicht het crewstandpunt

[elevator]

LauPro schreef op 19 August 2003 @ 16:58:
Als ik jou was dan zou ik maar is gaan onderzoeken welk FS hier wel tegen bestand is, en ik weet zeker dat dit bestaat.

Kan je dan met een link aankomen? Het liefste met een link van een betaalbare FS oplossing?

De meeste filesystems houden hun structuur op een aantal plaatsen bij. Je kan het wel *overal* weggaan zetten, maar de performance penalty is dan reusachtig (als jij je file table op 8 plekken op je disk ga zetten, zal je die ook bij elke update van je filesystem, daadwerkelijk je filetable moeten updaten), en is dus niet de moeite waard.

Ook de MFT$ van NTFS kan corrupt gaan - die kans is klein, maar ook ik heb het eens met een corrupte Mylex gehad dat die na een reboot de complete MFT$ leegtrok, en toen eindige ik ook met een FOUND.001 t/m FOUND.999 in m'n root.
NTFS is dan ook geen goed filesystem meer?

Als je een heel klein beetje research doet, zal je zien dat bijna alle oplossingen meer effort steken in het fysiek redudant maken van gegevens (eg: bv. het log shipping wat Oracle kan, of via software een software mirror houden), dan in het creeeren van een "atomic"-proof filesystem.

Jouw oplossing zou alleen volstaan, als het filesystem z'n files over een 'x' aantal disken zou verspreiden, en redudant weg zetten, en dat is nou net waar we RAID voor kopen.

LauPro schreef op 19 augustus 2003 @ 17:55:
Stel dat (ik stel het even grof voor) er 100 bestanden op een schijf staan, en 10% van die bestanden 'crasht'/raken beschadigd -> onleesbaar. Dan zijn dus 10 bestanden gewoon weg, stel dat het FS van tevoren alle bestanden had verspreid, dan zouden er statistisch gezien 20 bestanden half-leesbaar zijn geworden. Voor webservices lijkt mij dat beter omdat de beschadigde data dus wel leesbaar blijft en bijvoorbeeld afbeeldingen in slechtere kwaliteit (die zijn er dus al, die bestanden stonden dus net op de rand van het 'gat') of andere vormen van dataverlies. Op deze mannier hoef je de bezoekers niet direct teleur te stellen, het werkt gewoon allemaal wat 'minder' maar het blijft doordraaien.

Dit bestaat. We noemen het RAID en bestaat in veel varianten. Voorbeeldje:

Je pakt 3 disken, je zet er alle data 1 keer op, plus net voldoende info om 1 disk te kunnen reconstrueren. Je hebt dus ruimte van ongeveer 2 disken nodig, en je verspreid de data over ongeveer 3 disken. Ja, je leest het goed. We gooien maar liefst 33% diskruimte weg. Als er nu 1 disk kapot gaat, dan is het allemaal wat langzamer, maar dan werkt het nog wel.

Wat jij blijft voorstellen, is een software matige variant van een RAID systeem, en zoals we weten kan software bijna nooit de performance halen die een dedicated product (eg: een raid controller) kan halen.

[Anoniem: 13874]

Laupro hoe vaak moet er nog gezegd worden dat het door T.net gebruikte FS op deze serverconfig de beste/ meest stabiele optie is

Het lijkt wel of je constant vergeet dat het een hardwarematig probleem is en niet een softwarematig probleem.

[ Voor 30% gewijzigd door Anoniem: 13874 op 19-08-2003 20:31 ]

[ACM]

LauPro schreef op 19 August 2003 @ 19:51:
ik heb een keer met de optie 'verloren bestandsfragmenten omzetten naar bestanden' nog veel belangrijke data terug kunnen krijgen, ik geef toe dat het een monnikenwerk is maar dan kom je bij de vraag 'hoe belangrijk is belangrijk' .

Wat dus precies is wat we gedaan hebben... Zie moto-moi.

Het lijkt mij niet aan mij om dat uit te zoeken, dat hoor je te doen als systeembeheerder-zijnde imo. Maargoed ik zeg ook niet dat het FS zoals ik het beschrijf exact bestaat, maar er zijn bijvoorbeeld andere alternatieven om redundantie in het FS te garanderen.

Uiteraard weet ik dat wij het beste FS zouden moeten kiezen, maar na een analyse van de stabiel beschikbare filesystems in linux hebben wij besloten ext3 te nemen.
Als jij een nog betere weet, die wij over het hoofd hebben gezien, laat ons het weten, dat is wat ik daarmee bedoelde.

Maargoed, ik ben even aan het zoeken geslagen en ik denk dat een 'virtuele harde schijf' de oplossing is die het dichtste bij mijn verhaal in de buurt komt. Dit is omdat deze software vaak ook een pariteitsbit kan wegschrijven.

Euh? Dat is toch precies wat een raidcontroller al doet Alleen dan hardwarematig.

Daarnaast heb je het voordeel dat die 250k bestanden wat beter/overzichtelijker kunnen worden ingedeeld.

Die vat ik niet... Dat overzichtelijk indelen kan je met directories doen, niet door het op een ander type filesystem te zetten, lijkt me.

Maar even voor de duidelijkheid: ik ga nu dus in op het standardpunt dat er niks kan worden gedaan aan een controller die de data fout doorgeeft.

Als een controller een zeker bitpatroon weergeeft is de kans erg klein dat je het originele bitpatroon terug kan krijgen. Zelfs als je nog ergens een pariteitsbitje hebt is er niet eens zoveel garantie voor.
Tenzij je zeer inefficiente opslag prefereert en je een absolute dataveiligheid moet hebben, wij kozen ervoor omdat met een gerenomeerde hardwarematige oplossing te doen, het zgn RAID-5 systeem...

Een filesystem, zeker een experimenteel of niet-standaard iets, kan net zo goed fouten maken als een RAID-controller.

[ Voor 3% gewijzigd door ACM op 19-08-2003 20:33 ]

[LauPro]

Laat ik even duidelijk uitleggen wat ik bedoel:
Een RAID-controller zorgt ervoor dat schijfuitval *mag*, het heeft verder niets te maken met de werkelijke data. Je zult dus die werkelijke data moeten beschermen tegen fouten van die RAID controllers. Waarom heb ik bijvoorbeeld een RAID-controller genomen: omdat ik niet het risico wil lopen dat er (weer) een harde schijf stuk gaat en je niet afhankeljik bent van 1 harde schijf. En dát is de reden waarom je RAID neemt.

Bijvoorbeeld een programma als 'QuickPar' wat ik vandaag toevallig tegenkwam doet al ongeveer wat ik bedoel. Het gaat er dus om dat je delen van een bestand elders op hetzelfde volume opslaat. Of dat nu op FS-niveau gebeurt, of op 'bestandsniveau' dat staat er even los van. Het is natuurlijk wel noodzaak om die '.par bestanden' (of wat de uitvoer wel niet mag zijn) niet in dezelfde map als de bestanden zelf te zetten (zoals ik al zei: elders op het volume).

En voor de duidelijkheid: dit is een voorbeeld om aan te geven dat dergelijke software bestaat. Ik heb verder ook geen ervaring met crashende filesystems oid maar ik kan mij haast niet voorstellen dat er niet zo iets bestaat anno 2003 waarmee je pariteiten kan berekenen (op volume-niveau) en die elders weg kan schrijven.

Maargoed, imo heeft deze software niet zoveel zin op bestandsniveau omdat als het filesystem verrot is je niet meer zo goed bij die bestanden komt. Daarom viel ik meteen met de deur in huis met dat FS met ingebouwde beveiliging (ik kan het niet zo 1-2-3 vinden, maar ik weet zeker dat het is).

Er schiet mij ineens een hele praktische oplossing te binnen: je maakt twee partities van precies dezelfde grootte en je laat alles 'mirorren' (is ook vast wel en tool voor en anders maak je er een ). Dan ben je nl ook klaar. Als een deel van de schijf crasht dan staat dezelfde data altijd nog verderop op dezelfde schijf -> precies wat ik bedoel. Is partitie 1 verrot? Dan mount je de tweede ipv de eerste en herstel je de eerste weer en klaar, wellicht een idee?

[ Voor 3% gewijzigd door LauPro op 19-08-2003 21:44 ]

[elevator]

LauPro schreef op 19 August 2003 @ 21:43:
Bijvoorbeeld een programma

[...]
PAR bestanden (staat voor PARity, btw )
[...]

En voor de duidelijkheid: dit is een voorbeeld om aan te geven dat dergelijke software bestaat. Ik heb verder ook geen ervaring met crashende filesystems oid maar ik kan mij haast niet voorstellen dat er niet zo iets bestaat anno 2003 waarmee je pariteiten kan berekenen (op volume-niveau) en die elders weg kan schrijven.

Zit je ons nu in de zeik te nemen, of neem je gewoon niet de moeite om te leren wat RAID5 ? In beide gevallen, ga je schamen en doe je huiswerk.

Laten we eens hier beginnen: http://www.webopedia.com/TERM/R/RAID.html

quote: http://www.webopedia.com/TERM/R/RAID.html

(raid) Level 5: Provides data striping at the byte level and also stripe error correction information. This results in excellent performance and good fault tolerance.

Zoals je in dit plaatje kan zien:

is dit precies wat jij voorsteelt. Je berekent parity op disk niveau.

---

WAT JIJ VOORSTELT IS PRECIES WAT RAID IS

---

Maargoed, imo heeft deze software niet zoveel zin op bestandsniveau omdat als het filesystem verrot is je niet meer zo goed bij die bestanden komt. Daarom viel ik meteen met de deur in huis met dat FS met ingebouwde beveiliging (ik kan het niet zo 1-2-3 vinden, maar ik weet zeker dat het is).

Er schiet mij ineens een hele praktische oplossing te binnen: je maakt twee partities van precies dezelfde grootte en je laat alles 'mirorren' (is ook vast wel en tool voor en anders maak je er een ). Dan ben je nl ook klaar. Als een deel van de schijf crasht dan staat dezelfde data altijd nog verderop op dezelfde schijf -> precies wat ik bedoel. Is partitie 1 verrot? Dan mount je de tweede ipv de eerste en herstel je de eerste weer en klaar, wellicht een idee?

En wat denk jij dat RAID1 is

Zie: http://www.acnc.com/04_01_10.html:


Elke disk wordt volledig gemirrored naar elke andere disk.

[ Voor 20% gewijzigd door elevator op 19-08-2003 21:59 ]

[LauPro]

elevator schreef op 19 August 2003 @ 21:51:
[...]
Zit je ons nu in de zeik te nemen, of neem je gewoon niet de moeite om te leren wat RAID5 ? In beide gevallen, ga je schamen en doe je huiswerk.

Lees:

quote: http://gathering.tweakers...message/18545649#18545649

Je zult dus die werkelijke data moeten beschermen tegen fouten van die RAID controllers

edit2:

is dit precies wat jij voorsteelt. Je berekent parity op disk niveau.

Dat is niet waar, ik had het over volume-niveau.

edit3: Schamen? Huiswerk? Begin jij eerst maar is bij RAID, dat staat voor Redundant Array of Inexpensive Disks. Je maakt de harde schijven redundant, en niet de data op het volume van die schijven. En dat is wat er in dit geval ontbrak, en daar had ik het over.

[ Voor 45% gewijzigd door LauPro op 19-08-2003 22:08 ]

[elevator]

LauPro schreef op 19 augustus 2003 @ 21:58:
Laat ik er maar mee ophouden ook, dit heeft niets meer te maken met het topic.
Dat is niet waar, ik had het over volume-niveau.

Ok:


Als het bij de rode pijl mis gaat (oftewel - de RAID controller gaat fout), dan is het *onmogelijk* om die data toch betrouwbaar weg te schrijven. Een PC systeem is een reeks dependencies, niet los van elkaar opererende systemen:

- Een harddisk is afhankelijk van de raid controller
- De RAID controller is afhankelijk van de PCI bus
- De PCI bus is afhankelijk van je CPU
- De CPU is afhankelijk van je PSU

etc. Dependencies. Zonder je 1e dependency, failed je hele systeem. Hoe *lager* je in de dependency boom komt, hoe groter het risico op falen.

edit3: Schamen? Huiswerk? Begin jij eerst maar is bij RAID, dat staat voor Redundant Array of Inexpensive Disks. Je maakt de harde schijven redundant, en niet de data op het volume van die schijven. En dat is wat er in dit geval ontbrak, en daar had ik het over.

Je kan onmogelijk je logische structuur redudant maken als je fysieke structuur niet te vertrouwen is

[ Voor 20% gewijzigd door elevator op 19-08-2003 22:07 ]

[LauPro]

elevator schreef op 19 August 2003 @ 22:06:
[...]
dan is het *onmogelijk* om die data toch betrouwbaar weg te schrijven

Wie heeft het hier over wegschrijven, heb je mij dat ooit horen zeggen . Daarnaast staat jouw verhaal totaal los van waar ik het over heb, dat is namelijk simpelweg het redundant maken van de data op/van het volume.

[elevator]

LauPro schreef op 19 augustus 2003 @ 22:11:
Wie heeft het hier over wegschrijven, heb je mij dat ooit horen zeggen .

Hoe ga jij data op een volume krijgen zonder te schrijven dan ?

Daarnaast staat jouw verhaal totaal los van waar ik het over heb, dat is namelijk simpelweg het redundant maken van de data op/van het volume.

Nee, nee. Jij hebt het over een filesystem, wat data redudant weg zit op 1 RAID set, en daarmee het probleem van de kapotte raid controller omzeilt.

[LauPro]

elevator schreef op 19 August 2003 @ 22:13:
[...]
Hoe ga jij data op een volume krijgen zonder te schrijven dan ?

Dat was toch helemaal niet het uitgangspunt, teminste niet de mijne? We zitten op het moment dat de RAID-array het prima doet, er is alleen data beschadigd op het volume (en dus het FS en dus de bestanden). In dat geval is het beter om die data gespreid op dat volume te zetten imo (van tevoren natuurlijk).

[ Voor 3% gewijzigd door LauPro op 19-08-2003 22:22 ]

[whoami]

LauPro schreef op 19 August 2003 @ 21:58:
edit3: Schamen? Huiswerk? Begin jij eerst maar is bij RAID, dat staat voor Redundant Array of Inexpensive Disks. Je maakt de harde schijven redundant, en niet de data op het volume van die schijven. En dat is wat er in dit geval ontbrak, en daar had ik het over.

Als het zo zou zijn (wat het dus niet is), wat is het nut van RAID dan volgens jou?

[elevator]

LauPro schreef op 19 August 2003 @ 22:21:
Dat was toch helemaal niet het uitgangspunt, teminste niet de mijne? We zitten op het moment dat de RAID-array het prima doet, er is alleen data beschadigd op het volume (en dus het FS en dus de bestanden). In dat geval is het beter om die data gespreid op dat volume te zetten imo (van tevoren natuurlijk).

Maar hoe krijg jij corruptie op je volume dan?

Fyisch (eg: disken kapot) kan niet - dat wordt ondervangen door de RAID controller.
De RAID controller kan niet kapot gaan - dat wordt ondervangen doordat LauPro zegt dat dat niet het geval is.

Hoe krijg jij anders logische corruptie op je volume's, zonder dat je 'verspreiding' ook aangetast is ?

[LauPro]

elevator schreef op 19 August 2003 @ 22:25:
[...]
Maar hoe krijg jij corruptie op je volume dan?

Fyisch (eg: disken kapot) kan niet - dat wordt ondervangen door de RAID controller.
De RAID controller kan niet kapot gaan - dat wordt ondervangen doordat LauPro zegt dat dat niet het geval is.

Hoe krijg jij anders logische corruptie op je volume's, zonder dat je 'verspreiding' ook aangetast is ?

Jij hebt blijkbaar helemaaal niet je huiswerk gedaan. Stel je dit even voor: Je hebt een RAID 5 configuratie met 3 schijven. Schijf 1 raakt brak (niet stuk dus, brak). Nu moet ik je bekennen dat ik niet exact weet hoe de RAID-controller reageert in deze situatie maar er kunnen twee dingen gebeuren: hij pakt gewoon de data van schijf 1 (dus corrupte data) of hij neemt de data die hij berekent uit schijf 2 en 3 (even grofweg gezegd), hij zal echter niet weten wát nu de goede data is en zan dus gewoon corrupte data doorsturen. Pas wanneer een harde schijf in 1 klap uitvalt heb je geen gevaar. Dit is ook mogelijk in RAID 1, als er 1 schijf brak is weet de controller niet welke (als SMART dus ook faalt in dit geval). Je zal dan handmatig moeten kijken welke schijf het nog goed doet, en oppassen in dit geval: je controller kan dus de corrupte schijf over de goede schijf heen kopieëren.

Beveiliging tegen brakke hd's: 3 hd's in RAID 1, maarja dat is vrijwel onbetaalbaar.

[ Voor 8% gewijzigd door LauPro op 19-08-2003 22:40 ]

[Devian]

LauPro schreef op 19 augustus 2003 @ 22:21:
[...]
Dat was toch helemaal niet het uitgangspunt, teminste niet de mijne? We zitten op het moment dat de RAID-array het prima doet, er is alleen data beschadigd op het volume (en dus het FS en dus de bestanden). In dat geval is het beter om die data gespreid op dat volume te zetten imo (van tevoren natuurlijk).

hoe kun jij op het moment zitten dat de raid controller goed werkt maar de data beschadigd is?

ik zat eigenlijk op het moment dat de raid controller defecten ging vertonen en daardoor de data fout wegschreef/beschadigde...

[LauPro]

Devian schreef op 19 augustus 2003 @ 22:41:
[...]
hoe kun jij op het moment zitten dat de raid controller goed werkt maar de data beschadigd is?

Wanneer er een harde schijf bijv beschadigd is (hierboven aangegeven als 'brak') door een head-crash. Volgens mij wordt dit niet geregistreerd door SMART.

ik zat eigenlijk op het moment dat de raid controller defecten ging vertonen en daardoor de data fout wegschreef/beschadigde...

Dat moment is ook goed . Alleen een paar pagina's terug waren we al tot de conclusie gekomen dat dat niet zo vaak voorkomt. En in dit geval is de RAID-controller prima in orde.

[elevator]

LauPro schreef op 19 augustus 2003 @ 22:35:
[...]
Jij hebt blijkbaar helemaaal niet je huiswerk gedaan. Stel je dit even voor: Je hebt een RAID 5 configuratie met 3 schijven. Schijf 1 raakt brak (niet stuk dus, brak). Nu moet ik je bekennen dat ik niet exact weet hoe de RAID-controller reageert in deze situatie maar er kunnen twee dingen gebeuren: hij pakt gewoon de data van schijf 1 (dus corrupte data) of hij neemt de data die hij berekent uit schijf 2 en 3 (even grofweg gezegd), hij zal echter niet weten wát nu de goede data is en zan dus gewoon corrupte data doorsturen. Pas wanneer een harde schijf in 1 klap uitvalt heb je geen gevaar. Dit is ook mogelijk in RAID 1, als er 1 schijf brak is weet de controller niet welke (als SMART dus ook faalt in dit geval). Je zal dan handmatig moeten kijken welke schijf het nog goed doet, en oppassen met RAID 1: je controller kan dus de corrupte schijf over de goede schijf heen kopieëren.

En dit los je *hoe* ook al weer op door je files te verspreiden over het filesystem?

Want laten we heel eventjes terug gaan naar de basis, je wijkt namelijk nogal veel af van de discussie, waardoor je standpunten niet kan verdedigen, en dat is jammer:


• 1. In deze post geeft ACM aan dat het systeem corrupt is door een corrupte control.
• 2. Ook in deze post, geef jij aan, dat er een filesystem moet zijn wat hier tegen bestand is. (voor de oplettende lezer. Let op - hier gaat het nergens over logisch corrumperende disken!)
• 3. Ook in deze post, geef jij aan, dat een mogelijke oplossing zou zijn om de data te verspreiden over de disk.
• 4. In deze post, geef jij nogmaals aan, dat bij het verspreiden van data fysiek over een disk het probleem zou kunnen verminderen.
• 5. In deze post geef jij aan, dat je graag zou zien dat er parity gebruikt zou worden om missende data te kunnen herconstrueren.
• 6. Ook in deze post, geef je aan dat je dit op filesystem niveau zou willen regelen.
• 7. In deze geef je overigens ook nog aan graag disken dubbel te willen uitvoeren.
• 8. Hier geef je aan, de data op het volume graag redudant te maken.
• 9. Hier geef je aan redudante data te krijgen, die losstaand van een RAID controller, toch integriteit kan behouden, en ook nog eens nooit weggeschreven hoeft te worden.
• 10. Hier geef je aan dat er eigenlijk niets aan de hand is, er is alleen logische corruptie.
• 11. En vervolgens kom je hier met een zeer theoretisch voorbeeld dat eventueel een zelfstandige disk fysieke corruptie zou kunnen veroorzaken.

Je zwerft nogal heen en weer van punten

[LauPro]

Met alle respect, maar daar word ik toe gedwongen .

Even punt 5: ik heb er duidelijk onder gezet dat het om een voorbeeld gaat.

Maar vergeet niet: alle oplossingen waar ik het over heb daar gaat het over het redundant maken van data op een volume. En dat kan op verschillende mannieren.

Laat ik het even op een rij zetten zoals het nu is (grofweg, ik weet dat sommige dingen niet zijn te vergelijken):
Fysiek: Schijven > [RAID-controller - Volume] > Partitie > FS > Clusters (of hoe het ook heet)

Op dat Filesystem staan bestanden. Als er een schijf weg valt dan dekt de RAID controller dat met een andere schijf. Maar we hebben het nu dus over verkeerde data die door de RAID-controller wordt overgedragen. Het beslaat echter een klein stukje van het volume.

Je maakt mij niet wijs dat je dan niet blij bent als er elders op het volume nog een keer die data staat. Of dat nu is opgeslagen in een extra Partitie, in het FS of in een bestand of in een pariteit van een bestand doet er niet toe. Het gaat erom dat de data redundant op het volume staat.

[ Voor 3% gewijzigd door LauPro op 19-08-2003 23:08 ]

[Snow_King]

en weer doet LauPro zijn ondertitel eer aan, sjees man, als je alles beter weet, waarom zet je dan niet een eigen Tweakers.net op?

Sorry hoor, maar zelfs de beste maken fouten......
Ik weet zeker dat ze alles hebben gedaan om dit soort dingen te voorkomen!
Shit happenedes, life goes on

Ze hebben hun best gedaan en door samenloop van problemen liep het helemaal aan gort, accepteer dat en ga slapen..

* Snow_King kan zo slecht tegen zulke personen

[ Voor 11% gewijzigd door Snow_King op 19-08-2003 23:10 ]

[elevator]

LauPro schreef op 19 August 2003 @ 23:04:
Op dat Filesystem staan bestanden. Als er een schijf weg valt dan dekt de RAID controller dat mete en andere schijf. Maar we hebben het nu dus over verkeerde data die door de RAID-controller wordt overgedragen. Het beslaat echt een klein stukje van het volume.

Dan is je RAID controller dus /wel/ kapot? Toenet nog niet namelijk

Je maakt mij niet wijs dat je dan niet blij bent er elders op het volume nog een keer die data staat.

*Welke* data dan ?
Want ik heb zeg maar de data van gisteren 2 x staan. Maar is die eigenlijk wel goed? Nee, ik heb liever de data van 3 dagen geleden. Of die van 4 dagen. Of die van 18 dagen geleden. En dat plaatje wat ik 3 jaar geleden gewist heb, had ik eigenlijk ook moeten houden

Wanneer is data integer en wanneer niet? We komen hiermee weer op punt 9 uit - je wil data dubbel hebben ("Je zou niet blij zijn als die data ergens anders op de disk staat.."), terwijl je aan de andere kant de RAID controller foute informatie wegschrijft.

Lees mijn post over dependencies nou nog eens goed door, en begrijp dat het maken van redudantie op een niveau hoger dan waar de corruptie optreed, volledig zinloos is.

Of dat nu is opgeslagen in een extra Partitie, in het FS of in een bestand of in een pariteit van een bestand doet er niet toe. Het gaat erom dat de data redundant op het volume staat.

En voor redudantie, hebben we dus RAID.

[LauPro]

Snow_King: Even goed het topic volgen, ik heb het hier niet tegen de crew van t.net, maar meer in het algemeen over backupmogelijkheden (lees backup in de ruimste zin van het woord).

En daarnaast is t.net toppie hor, ik klaag ook niet over t.net? Dat het topic in LA staat betekend niet automatisch dat ik het tegen t.net zelf heb dat er een discussie gaat over het maken van een backup-systeem betekend niet automatisch dat ik het tegen t.net zelf heb.

Als iemand anders dit was over gekomen en er was een topic over gekomen had ik precies hetzelfde gereageerd.

[Snow_King]

LauPro schreef op 19 augustus 2003 @ 23:15:
Snow_King: Even goed het topic volgen, ik heb het hier niet tegen de crew van t.net, maar meer in het algemeen over backupmogelijkheden (lees backup in de ruimste zin van het woord).

En daarnaast is t.net toppie hor, ik klaag ook niet over t.net? Dat het topic in LA staat betekend niet automatisch dat ik het tegen t.net zelf heb dat er een discussie gaat over het maken van een backup-systeem betekend niet automatisch dat ik het tegen t.net zelf heb.

Als iemand anders dit was over gekomen en er was een topic over gekomen had ik precies hetzelfde gereageerd.

ja, maar het komt wel zo over, misschien bedoel je het niet zo......

[LauPro]

elevator schreef op 19 augustus 2003 @ 23:11:
Dan is je RAID controller dus /wel/ kapot? Toenet nog niet namelijk

Dat is toch niet relevant? Of de controller nu stuk is en manipuleert de data of hij neemt foute data van een harde schijf af. Er zal niet de goede data op het volume verschijnen.

*Welke* data dan ?
Want ik heb zeg maar de data van gisteren 2 x staan. Maar is die eigenlijk wel goed? Nee, ik heb liever de data van 3 dagen geleden. Of die van 4 dagen. Of die van 18 dagen geleden. En dat plaatje wat ik 3 jaar geleden gewist heb, had ik eigenlijk ook moeten houden

Alle? Dus bijvoorbeeld twee partities in RAID 1, software-RAID dus ja.

Lees mijn post over dependencies nou nog eens goed door, en begrijp dat het maken van redudantie op een niveau hoger dan waar de corruptie optreed, volledig zinloos is.

Waar ligt dat hogere niveau volgens jou?

En voor redudantie, hebben we dus RAID.

Voor de honderste keer: RAID maakt harde schijven redundant, niet de data.

edit:
Snow_King: mag ik dan bij deze zeggen dat ik dat dus niet zo bedoel?

[ Voor 4% gewijzigd door LauPro op 19-08-2003 23:21 ]

[elevator]

LauPro schreef op 19 August 2003 @ 23:20:
Dat is toch niet relevant? Of de controller nu stuk is en manipuleert de data of hij neemt foute data van een harde schijf af. Er zal niet de goede data op het volume verschijnen.

Precies, zoals je zelf al zegt. Er gaat niet de goede data op het volume komen. Je

Alle? Dus bijvoorbeeld twee partities in RAID 1, software-RAID dus ja.

Je snapt me duidelijk niet.

Ik leg je uit dat:
- Redudantie op software niveau niet nuttig is als je hardware niveau corrupt is (aangezien je hardware systeem dan alsnog corrupte data wegschrijft, hij schrijft die dan alleen dubbel weg)
- Jij zegt vervolgens dat je als er iets kapot gaat, dat je dan blij moet zijn dat er nog iets nuttigs op disk staat.
- Ik vraag aan jou hoe je "nuttig" differentieert van "niet nuttig", en hoe je corrupte (zowel logisch als fysieke corruptie) gaat onderscheiden van niet-corrupte data.
- Jij geeft als antwoord "alle".

Dit betekent dus concreet, dat als ik dit doe:
- Ik verwijder de search database
- Ik hergenereer hem.

Dat doordat volgens het LauPro(tm) systeem, ik elk moment terug kan naar de oude database, en die database staat ook op 10 plekken over de disken verspreid, en is altijd integer, ook al is de raid controller of de disk zelf dat niet. Hoe dat precies werkt, ga je me in de reply hierop vast uitleggen:

Waar ligt dat hogere niveau volgens jou?

Zie eerder aangehaald plaatje - software is afhankelijk van hardware om integere data op schijf te krijgen.

Voor de honderste keer: RAID maakt harde schijven redundant, niet de data.

Voor de 100e keer, de discussie ging over het spreiden door het filesystem alvorens de impact van een corrupte raid controller te minimaliseren.

[LauPro]

Er is een kleine miscommunicatie opgetreden: Ik ga ervan uit dat er een stuk/deel van het volume beschadigd is (dus niet het hele volume, als dat niet goed is overgekomen mijn excuses). Dus precies hoe het bij t.net het geval was. En hoé dat kan gebeuren is bekend.

Nu willen we graag de data terug die in dat beschadigde stuk stond, de enige oplossing is een externe backup óf een redundante opslag van data. Simpeler kan ik het niet uitleggen.

[ Voor 6% gewijzigd door LauPro op 19-08-2003 23:34 ]

[elevator]

LauPro schreef op 19 August 2003 @ 23:32:
Er is een kleine miscommunicatie opgetreden: Ik ga ervan uit dat er een stuk/deel van het volume beschadigd is (dus niet het hele volume, als dat niet goed is overgekomen mijn excuses). En hoé dat kan gebeuren is bekend.

Nu willen we graag de data terug die in dat beschadigde stuk stond, de enige oplossing is een externe backup óf een redundante opslag van data. Simpeler kan ik het niet uitleggen.

Daar was dan ook geen discussie over. De discussie gaat over het feit dat jij beweerd dat door middel van een beter filesystem, je dit probleem volledig kan oplossen.

Kunnen we het erover eens zijn dat die opmerking van jou niet correct was, en dat de juiste oplossing voor data-corruptie wel degelijk een RAID systeem is, met een eventuele backup (en ofdat die backup nu op disk of op tape getrokken wordt is een detail) ?

[LauPro]

elevator schreef op 19 augustus 2003 @ 23:35:
[...]
Daar was dan ook geen discussie over. De discussie gaat over het feit dat jij beweerd dat door middel van een beter filesystem, je dit probleem volledig kan oplossen.

Zie hier de miscommunicatie

Kunnen we het erover eens zijn dat die opmerking van jou niet correct was, en dat de juiste oplossing voor data-corruptie wel degelijk een RAID systeem is, met een eventuele backup (en ofdat die backup nu op disk of op tape getrokken wordt is een detail) ?

Dat ligt eraan wát voor een RAID systeem meer kan ik er niet over zeggen. Alleen RAID 1 met 2 schijf of RAID 5 met 3 is imo niet voldoende om corrupte data op het volume tegen te gaan. Een kant en klare oplossing waarbij er nóóit data verloren kan gaan is imo RAID 15 c.q. 51. Totdat natuurlijk de controller stuk gaat maar dat staat hier los van.

[HunterPro]

LauPro schreef op 19 August 2003 @ 23:42:
[...]
Zie hier de miscommunicatie
[...]
Dat ligt eraan wát voor een RAID systeem meer kan ik er niet over zeggen. Alleen RAID 1 met 2 schijf of RAID 5 met 3 is imo niet voldoende om corrupte data op het volume tegen te gaan. Een kant en klare oplossing waarbij er nóóit data verloren kan gaan is imo RAID 15 c.q. 51. Totdat natuurlijk de controller stuk gaat maar dat staat hier los van.

Ja. En op elke vierkante meter ter wereld een server neerzetten is nóg veiliger. Allemaal verbinden. Alleen er is _nog steeds_ geen sprake van 100% garantie. Al plant je de maan vol. nog stééds niet! waarom? Kans.

[Anoniem: 21103]

Hallo wat lopen jullie allemaal te mierenneuken..
De discussie gaat geheel offtopic door aan te geven waar wat eventueel fout zou gaan..
Gewoon troubleshooten en oplossen die handel, en ga niet op detail in. Als jullie dat graag willen, kunnen jullie zo 30% van m'n klanten tevreden stellen...

[ACM]

LauPro schreef op 19 August 2003 @ 23:32:
Er is een kleine miscommunicatie opgetreden: Ik ga ervan uit dat er een stuk/deel van het volume beschadigd is (dus niet het hele volume, als dat niet goed is overgekomen mijn excuses). Dus precies hoe het bij t.net het geval was. En hoé dat kan gebeuren is bekend.

Nu willen we graag de data terug die in dat beschadigde stuk stond, de enige oplossing is een externe backup óf een redundante opslag van data. Simpeler kan ik het niet uitleggen.

Dan heb je blijkbaar over mijn posting heengelezen waar ik zei dat de data over de verschillende disks wordt verspreid door de raidcontroller.

Stel je hebt drie disks die resp A, B en C opslaan en ook steeds een stukje van B en C, A en C, etc, dus:
Abc
aBc
abC

Stel nu dat A, B en C samen een bestand vormen. In theorie kan dat bestand niet corrupt raken door de uitval van een enkele disk, maar als om wat voor reden dan ook een te groot deel van B weggegooid wordt (en dus inclusief een b) dan heb je gewoon geen bestand meer of een die corrupt is en ook afgeschreven kan worden.

Het is allemaal nogal zinloze speculatie, want we _weten_ niet of er een deel van het volume beschadigd is of dat het hele volume beschadigde op "willekeurige" (of regelmatige) verschillende posities.

Er van uit gaande dat _elk_ bestand evenveel risico liep beschadigd te raken, dit neem ik maar aan omdat ik geen beeld heb en ook nooit zal krijgen van de fysieke positie van een file op onze disks, heeft het geen nut een parityfile bij te houden.
Want zodra de parityfile beschadigd is moet je ofwel tot de conclusie komen dat je file die je controleert corrupt is ofwel dat je parityfile waardeloos geworden is en je dus ook je gewone files niet meer kan repareren...
Je idee met twee partities op dezelfde schijfarray is leuk, maar ook die is om dezelfde reden gevoelig voor fouten. Gezien het feit dat je _beide_ partities dan willekeurig corrupte/veranderde bestanden hebben kan je niet eenvoudig zien welke file correct is en welke niet als je er twee versies van hebt.

Verder is het een enorme verspilling van ruimte en een gigantische domper op je performance als je alles dubbel gaat lopen doen, zeker gezien het feit _dat_ er al redundantie is en semi-garantie van correctheid.
Ten eerste probeert de raidcontroller een continue werking van het volume te garanderen, wat in de meeste gevallen ook best zal lukken alleen nu om voor ons allen onbekende redenen niet.
Ten tweede omdat het OS en het FS dat erbovenop werken dmv journaling garanderen dat een gewijzigde file ook op het volume zal komen mits het volume werkt (en daar zorgt punt 1 al voor).

Misschien is er een minieme kans dat jouw ideeen beter werken dan wat er nu aanwezig is, maar gezien het feit dat ook jouw oplossingen geen perfecte bescherming tegen dataverlies leveren en je achteraf alsnog dezelfde moeizame procedure moet doorlopen om de boel weer terug te krijgen, denk ik dat het daardoor zeker in combinatie met de andere nadelen totaal niet geschikt is voor ons.
Een simpele backupprocedure op orde helpen en ervoor zorgen dat er dagelijks een goede backup afgewerkt wordt op een andere server en/of ander diskarray, levert waarschijnlijk ruim voldoende, _veel_ beter te controleren redundantie op die ook nog eens minder nadelig is voor de performance en als bijkomend voordeel heeft dat ie je ook tegen nadelige gevolgen van beheers- en gebruikersfouten beschermt.

LauPro schreef op 19 August 2003 @ 23:42:
Totdat natuurlijk de controller stuk gaat maar dat staat hier los van.

Misschien had je het nog niet gelezen hoor, maar ik meen dat dat een van de oorzaken van het probleem was... Hoe precies weten we allemaal niet, maar dat ie er een rol in speelde is wel vrij zeker.

[ Voor 5% gewijzigd door ACM op 20-08-2003 00:11 ]

[Kees]

Goed.. ik denk dat het meeste wel gezegt is, LauPro wil een redundant filesystem en redundante hardware, de rest heeft al redenen genoeg gegeven waarom zij dat niet zien zitten.

Als gevolg hiervan past de discussie allang niet meer in LA, gelieven hem dan ook voort te zetten in OM als je de behoefte voelt om eindeloos langs elkaar heen te praten of eindeloos de ander van jouw gelijk proberen te overtuigen.