GoT heeft kuren... picserver en search plat.

[LauPro]

ACM schreef op 17 August 2003 @ 19:01:
[...]
Je bedoelt dus eigenlijk dat wij ons er ook via de AV tegen hadden moeten indekken, zodat we alle klachten in het vervolg makkelijker kunnen afwimpelen?

Nou dat hoeft nog nieteens, maar waar het mij om ging is dat er de indruk werd gewekt dat Tweakers.net gratis zou zijn.

* ACM vindt het altijd zo jammer dat mensen haast wel lijken te denken dat we dit expres en wekelijks doen.

Ik volg je even niet .

De vorige crash met serieus data verlies (sterker nog, nu is het nog steeds relatief minder dan toen) was iets van drie jaar terug, das toch niet helemaal wekelijks he??

Ik heb het helemaal niet over wekelijks? Maar krijg ik nu de indruk dat een jaarlijkse of drie-jaarlijke crash 'mag' ofzo Ik hoop het niet .

Verder denk ik niet dat er nog enige bestanden die nu niet opgedoken zijn nog terugkomen, dus inderdaad, als je nu nog iets kwijt bent is de kans klein dat wij het op de harddisks terug kunnen vinden

Als dat zo is dan lijkt het mij wel redelijk om iig de abo's even een persoonlijk mailtje te sturen met daarin uitleg van zaken. Zoals ik net al aangaf: als Chello dit zou overkomen dan worden er ook meteen overhaaste conclusies getrokken, dit hoort gewoon bij het vak. Een duidelijk bericht over wat er precies is gebeurd verheldert de boel al een stuk beter. Imo zijn de .plans met berichten van een alinea die snel worden opgezet met hier en daar een technische kreet niet voldoende.

Wellicht een idee om het backup systeem via de website te kunnen monitoren, en als er dus een back-up mislukt dat er een kruisje komt te staan, altijd wel iemand die daar op let.

[ Voor 5% gewijzigd door LauPro op 17-08-2003 19:25 . Reden: grmbl, stukje dubbel ]

[Erkens]

LauPro schreef op 17 August 2003 @ 19:20:
Ik heb het helemaal niet over wekelijks? Maar krijg ik nu de indruk dat een jaarlijkse of drie-jaarlijke crash 'mag' ofzo Ik hoop het niet .

het gaat erom dat als je het verlies aan data bekijkt dat dat nagenoeg niets is
tuurlijk het "mag" niet kunnen, maar het gebeurt nu eenmaal, bad luck

Als dat zo is dan lijkt het me wel redelijk om iig de abo's even een persoonlijk mailtje te sturen met daarin uitleg van zaken.

lijkt me dat een topic in het aboforum toch voldoende is ipv een massa-mail te sturen (geen idee hoeveel abo's er zijn )

[LauPro]

Erkens schreef op 17 augustus 2003 @ 19:25:
het gaat erom dat als je het verlies aan data bekijkt dat dat nagenoeg niets is
tuurlijk het "mag" niet kunnen, maar het gebeurt nu eenmaal, bad luck

lijkt me dat een topic in het aboforum toch voldoende is ipv een massa-mail te sturen (geen idee hoeveel abo's er zijn )

Dat is over het geheel gezien misschien zo, maar je zult maar net zien dat iemand zijn stageverslag kwijt is oid, nou ik weet zeker dat die persoon zo'n persoonlijk mailtje met duidelijke uitleg waardeerd.

Waarom op een online storage vertrouwen? Zie ook deze post.

[ Voor 14% gewijzigd door LauPro op 17-08-2003 19:30 ]

[ACM]

LauPro schreef op 17 August 2003 @ 19:20:
Nou dat hoeft nog nieteens, maar waar het mij om ging is dat er de indruk werd gewekt dat Tweakers.net gratis zou zijn.

Toch niet door een of ander t.net-crew lid he?

Ik volg je even niet .

Af en toe heb ik dat gevoel gewoon, dat mensen denken dat we hier hardstikke hard zitten te lachen om al die reacties enzo. Maar misschien is dat wel niet zo hoor, dat men dat denkt

Ik heb het helemaal niet over wekelijks? Maar krijg ik nu de indruk dat een jaarlijkse of drie-jaarlijke crash 'mag' ofzo Ik hoop het niet .

Nee, natuurlijk zeg je dat nergens, lees mijn reactie nog eens, _ik_ zeg ook niet dat dat gezegd wordt. Maar sommige reacties lijken zoiets te suggereren. We hebben een stel database servers met meer dan 300 dagen uptime, maar dat wordt natuurlijk vergeten, het enige wat men onthoudt is dat er "alwéér" een crash met dataverlies was (de vorige was tenslotte slechts zo'n 3 jaar terug...)

Imo zijn de .plans met berichten van een alinea die snel worden opgezet met hier en daar een technische kreet niet voldoende.

Daar heb je iig een goed punt, ik zal eens zien wat we daar aan kunnen doen.

Wellicht een idee om het backup systeem via de website te kunnen monitoren, en als er dus een back-up mislukt dat er een kruisje komt te staan, altijd wel iemand die daar op let.

Nou, de ervaring leert dat als het een jaar lang achtereen goed draait dat je die jaar+1dag niet meer kijkt en dus niet ziet dat het mis gaat. Dat was overigens dit keer niet het geval, maar het is wel zo.

[LauPro]

ACM schreef op 17 augustus 2003 @ 20:10:
Toch niet door een of ander t.net-crew lid he?

Nee dat klopt .

Af en toe heb ik dat gevoel gewoon, dat mensen denken dat we hier hardstikke hard zitten te lachen om al die reacties enzo. Maar misschien is dat wel niet zo hoor, dat men dat denkt

Nou denk niet dat dit het geval is hor, iig bij mij niet.

Nee, natuurlijk zeg je dat nergens, lees mijn reactie nog eens, _ik_ zeg ook niet dat dat gezegd wordt. Maar sommige reacties lijken zoiets te suggereren. We hebben een stel database servers met meer dan 300 dagen uptime, maar dat wordt natuurlijk vergeten, het enige wat men onthoudt is dat er "alwéér" een crash met dataverlies was (de vorige was tenslotte slechts zo'n 3 jaar terug...)

Met alle respect, maar daar ga je weer . Als je zegt dat de laatste crash 3 jaar geleden was dan geef je aan dat er om de zoveel tijd er een crash is. En daarmee dus automatisch aan wilt geven dat het vaker voorkomt en dat men daarom over zo'n relatief kleine 'crash' gewoon maar niet moet zeuren.

offtopic:
Dit doet mij denken aan Freek de Jonge over dat stukje met die slachtsoffers van de Bijlmerramp: er komen nu nog slachtoffers bij zo'n psychiater en die laat dat dat filmpje zien van New York en zegt dan: en nu HËËL snel wegwezen

Maargoed dat ligt eraan hoe je (ik) de zin interpreteer. Maar wat ik dus wil zeggen is dat je een kleinere crash niet moet proberen goed te praten met een grotere van een tijdje geleden.

Nou, de ervaring leert dat als het een jaar lang achtereen goed draait dat je die jaar+1dag niet meer kijkt en dus niet ziet dat het mis gaat. Dat was overigens dit keer niet het geval, maar het is wel zo.

Okay, dat begrijp ik. Komt ook bekend voor . Maar het is natuurlijk interessante informatie en zeker als je het nog een beetje aankleed.

[ Voor 4% gewijzigd door LauPro op 17-08-2003 20:44 ]

[Grrrrrene]

LauPro schreef op 17 August 2003 @ 20:43:
[...]
Nee dat klopt .
[...]
Nou denk niet dat dit het geval is hor, iig bij mij niet.
[...]
Met alle respect, maar daar ga je weer . Als je zegt dat de laatste crash 3 jaar geleden was dan geef je aan dat er om de zoveel tijd er een crash is. En daarmee dus automatisch aan wilt geven dat het vaker voorkomt en dat men daarom over zo'n relatief kleine 'crash' gewoon maar niet moet zeuren.

Nou, ik snap je niet echt helemaal, wat je nou wil. Ik snap dat je er niet blij mee bent, ik ook niet, ben 100-en plaatjes kwijt, maar so be it. Dan leer je zelf ook te backuppen.

Bovendien zegt ACM nergens dat 3-jaarlijkse crashes mogen, maar meer dat het niet ondenkbaar dat dit ooit weer gebeurt. Ik zou haast zeggen: ik teken ervoor dat er over 6 jaar (?) pas weer een grote crash is, dat ligt nml wel in de verwachting, toch?

[ACM]

LauPro schreef op 17 August 2003 @ 20:43:
Met alle respect, maar daar ga je weer . Als je zegt dat de laatste crash 3 jaar geleden was dan geef je aan dat er om de zoveel tijd er een crash is. En daarmee dus automatisch aan wilt geven dat het vaker voorkomt en dat men daarom over zo'n relatief kleine 'crash' gewoon maar niet moet zeuren.

Dan begrijp je me verkeerd.

Wat ik zeg is niet dat het nou ineens niet erg is, maar dat het onzin is om te suggereren dat we "vaker" dataverlies hebben, want de vorige echt serieuze keer was drie jaar terug.

Maar het zou onrealistisch zijn om er van uit te gaan dat dit nooit meer voorkomt, de schade tot een minimum beperken en zoveel mogelijk proberen te voorkomen (oa door backups) is natuurlijk verstandig.

Kortom, wat ik ermee bedoel is niet het goedpraten van deze crash, maar het ontkrachtigen dat het "heel vaak voorkomt".

[Verwijderd]

mOrPhie schreef op 17 August 2003 @ 16:40:
Ten tweede. Ik had het wel op prijs gesteld als alle abo's netjes een mailtje zouden krijgen met de excuses voor het feit dat de fotoalbums compleet verloren zijn gegaan. Ik ben echt niet moeilijk in dat soort dingen, maar zeker als je betaald voor een service verwacht ik op z'n minst zo'n mailtje.

Mag ik dit nogmaals onder de bende mogelijkheden trappen? Ik zou dit op zich ook wel netjes vinden eigenlijk... Niet dat die paar gare foto's nou zo boeien, maar 't is een teken van netheid, imo...

Voor de rest zelfde verhaal als morphie. . Ohja, en \o/ @ kees/ACM. .

[ Voor 5% gewijzigd door Verwijderd op 17-08-2003 21:59 ]

[Grrrrrene]

Daar ben ik het mee eens Beelzebubu, denk dat dat ook wel een van de lessen is die zijn geleerd

[Kees]

Verwijderd schreef op 17 August 2003 @ 21:59:
[...]


Mag ik dit nogmaals onder de bende mogelijkheden trappen? Ik zou dit op zich ook wel netjes vinden eigenlijk... Niet dat die paar gare foto's nou zo boeien, maar 't is een teken van netheid, imo...

Voor de rest zelfde verhaal als morphie. . Ohja, en \o/ @ kees/ACM. .

Daar hebben we het in een privaat forum al over, de belangrijkste reden waarom we zo 'lang' wachten met dat mailtje is dat we eerst zelf een overzicht van de schade willen hebben voordat we gebruikers dingen melden die later achterhaald worden.

[Azrael]

Maarre, komen die 16 icons uit m'n profiel nog weer terug of kan ik alvast een nieuwe gaan uploaden? (excuse me als dit al gemeld is in de thread, dan heb ik er overheen gelezen)

[ Voor 3% gewijzigd door Azrael op 17-08-2003 23:02 ]

[Hahn]

Azrael schreef op 17 augustus 2003 @ 23:01:
Maarre, komen die 16 icons uit m'n profiel nog weer terug of kan ik alvast een nieuwe gaan uploaden? (excuse me als dit al gemeld is in de thread, dan heb ik er overheen gelezen)

Het kan zijn dat icons verloren zijn gegaan bij de fout gegane backup, maar voor hetzelfde geld is dat niet zo. Aangezien nog niet alles helemaal gefixt is zou ik gewoon nog even wachten, zo dringend is een icoon toch niet?

Hoe krijg jij trouwens 16 icons in je profiel? 10 is toch het maximum?

[ACM]

ACM schreef op 17 August 2003 @ 19:01:
Verder denk ik niet dat er nog enige bestanden die nu niet opgedoken zijn nog terugkomen, dus inderdaad, als je nu nog iets kwijt bent is de kans klein dat wij het op de harddisks terug kunnen vinden

Voor de duidelijkheid nog een keertje dan.

[Opi]

ACM schreef op 17 August 2003 @ 23:15:
[...]

Voor de duidelijkheid nog een keertje dan.

Maar in m'n profile kan ik helemaal geen icons zien; ook m'n huidige niet. En dat terwijl ik hem wel in mijn posts kan zien.
[code]
Je hebt nog 100.00 kb, en 10 iconslots vrij.
De maximale icongrootte is 10.00 kb (10240 bytes).
[/]

Laat maar; icons stonden nog in m'n cache.

[ Voor 9% gewijzigd door Opi op 17-08-2003 23:19 ]

[Hahn]

ACM schreef op 17 augustus 2003 @ 23:15:
[...]

Voor de duidelijkheid nog een keertje dan.

Mijn excuses, dat had ik niet gezien

Dus mijn vorige post geldt niet meer Laat ik mijn verloren gegane icoon in m'n profiel dan ook maar weer eens een keertje opzoeken.

[Boss]

Ik heb 't hele verhaal hier gelezen over de problemen. Ik begrijp dat er een hele hoop data kwijt is, maar dat de problemen voorlopig opgelost zouden moeten zijn?

De private file storage is in ieder geval nog defect, volgens mij. Ik kan wel bestanden uploaden, waarna ze keurig in mijn lijstje met files komen te staan. Echter, bij het downloaden ervan hebben ze allemaal grootte 0. (terwijl ze in de lijst met de goede grootte erbij staan).

Ik weet het nu, dus ik kan er rekening mee houden. Ik wist niet of het al bekend was, dus ik meld het nog maar een keer. Ook voor anderen die (een beetje) afhankelijk zijn van de PFS.

[Freakertje]

Ik vind dit helemaal niet kunnen, ik eis nu dit en dat en het is allemaal hun fout!

Goh, ze hebben een probleempje, gelukkig heb ik al mijn bestanden zelf gebackupt, hoef ik het alleen maar terug te zetten. Succes met oplossen en hopelijk zijn we er voorlopig weer van verlost

Welk berichtje zou JIJ graag krijgen als één van jouw diensten een hapering vertoonde waar jij weinig aan kon doen?

Ik ben van mening dat ieder nog zelf verantwoordelijk is voor zijn of haar bestanden. Ook jouw PC kan crashen, zorg gewoon dat je een goeie brander (DVD? ) of streamer en druk om de zoveel tijd alles ff derop wat je echt belangrijk vind.

@ GoT en vooral Kees / ACM in dit geval: Hulde en ga vooral zo door!

[LauPro]

Grrrrrene schreef op 17 August 2003 @ 20:58:
[...]
Nou, ik snap je niet echt helemaal, wat je nou wil. Ik snap dat je er niet blij mee bent, ik ook niet, ben 100-en plaatjes kwijt, maar so be it. Dan leer je zelf ook te backuppen.

En het fotoalbum was dus niet te backuppen, vandaar dat ik het heb gemeld in de dev-track. En ik weet niet wat jij vind, maar 100-en plaatjes download en upload je niet zo 1-2-3, ik heb teminste geen ftp-toegang gezien oid.

@ACM: oke, dan snap ik het .

Oja, ik wil nog even wat anders melden: er zijn ook veel tumbnails verdwenen maar het originele formaat bestaat nog wel, misschien ff een scriptje maken die alles langsfietst.

edit:
@Freakertje: lees even deze post van mij door dan lees je waarom ik in dit geval niet helemaal vind dat je zelf verantwoordelijk bent.

[ Voor 13% gewijzigd door LauPro op 18-08-2003 00:51 ]

[Azrael]

MaRc0 schreef op 17 August 2003 @ 23:12:
Hoe krijg jij trouwens 16 icons in je profiel? 10 is toch het maximum?

Bij een eerder foutje had ik icons teruggekregen die ik allang verwijderd had (das pas een goeie backup, zelfs dingen die er niet meer zijn ), ik had er dus meer dan 10

Maar ok, ik upload wel weer een nieuwe, kan gebeuren

[Red]

Je hebt nog 96.00 kb, en 10 iconslots vrij.
De maximale icongrootte is 10.00 kb (10240 bytes).

Kan iemand mij daar opheldering over geven. Ik dacht nl. dat de maximale ruimte 100 kb is. ?! Bovendien had ik mijn icon nog in de cache staan, dus die kan ik zo weer opladen

[ Voor 17% gewijzigd door Red op 18-08-2003 02:12 ]

[Kees]

4k voor de directory zelf

[blackd]

Vreemd dan:

Je hebt nog 100.00 kb, en 10 iconslots vrij.
De maximale icongrootte is 10.00 kb (10240 bytes).

@ mijn profiel..

[i2Paq]

Mijne is dus foetsie
Maar misschien ergens nog in een cache?
Op mijn Pc, maar waar moet ik zoeken?

_{n00b vraag ik weet t, maar mag ik ook eens?}

[Spider.007]

i2Paq schreef op 18 augustus 2003 @ 09:14:
Mijne is dus foetsie
Maar misschien ergens nog in een cache?
Op mijn Pc, maar waar moet ik zoeken?

_{n00b vraag ik weet t, maar mag ik ook eens?}

Als je je eigen icoon nu nog ziet zit hij in je cache... anders kun je het volgens mij wel vergeten (maar je hebt natuurlijk je backup nog )

[i2Paq]

Spider.007 schreef op 18 augustus 2003 @ 09:18:
[...]


Als je je eigen icoon nu nog ziet zit hij in je cache... anders kun je het volgens mij wel vergeten (maar je hebt natuurlijk je backup nog )

Zag m niet meer maar had nog een backup
Nu is hij er weer

[Sir_Killalot]

Lekker, denk je 5 euro per maand te betalen voor een betrouwbare service, ben je alsnog 200 fotos kwijt door een crash

Waarom worden dit soort belangrijke dingen niet op SCSI schijven gezet, ook al zijn de IDE Maxtors zo betrouwbaar ? (de pics stonden toch op IDE schijven?)

(en nee, ik had niet van alles een back up, en veel foto's stonden gelinkt op een forum dus daar werkt ook niks meer, alles voor niks geupload )

[ Voor 24% gewijzigd door Sir_Killalot op 18-08-2003 10:32 ]

[Boss]

Volgens mij waren het niet de schijven maar de controller en een HD bracket die de problemen veroorzaakte.

[Sir_Killalot]

Boss schreef op 18 augustus 2003 @ 10:39:
Volgens mij waren het niet de schijven maar de controller en een HD bracket die de problemen veroorzaakte.

Ah, was ff in de war omdat er nogal veel verschillende dingen worden gezegt op GoT en T.net

[Freakertje]

LauPro schreef op 18 August 2003 @ 00:48:
edit:
@Freakertje: lees even deze post van mij door dan lees je waarom ik in dit geval niet helemaal vind dat je zelf verantwoordelijk bent.

Prima, maar ff een wedervraagje, (en een tip? ):
Zijn USB sticks (van die sleutelhangerdingen) niet iets voor jou? Ideaal spul hoor, gaat behoorlijk wat op en de kans op crashen of andere vormen van dataloss is behoorlijk klein. Tevens heb je altijd een opslagmedium bij je en al je belangrijke bestanden.

[ Voor 3% gewijzigd door Freakertje op 18-08-2003 10:56 ]

[--MeAngry--]

Nou, ik weet niet wat jullie ermee doen, maar ik vond het vergaan van de avators e.d. wel een mooi moment om een nieuwe avator voor mezelf te ontwerpen Ik heb hem zelfs geupload en ik kan mijn spiksplinternieuwe avator zelfs in mijn posts al zien Je gaat me toch niet vertellen dat deze uit de cache komt wel? Dat lijkt me onmogelijk als dit een nieuw plaatje is... Zien jullie van mij nu ook mijn nieuwe of evt. een oude uit de cache?

Owja, volgens mijn profile zijn die icons ook gewoon goed overgekomen. Dit staat er namelijk:

Je hebt nog 88.00 kb, en 8 iconslots vrij.
De maximale icongrootte is 10.00 kb (10240 bytes).

Met de 2 icons erboven, en dat zijn beide nieuwe. Wie verheldert dit?

[ Voor 25% gewijzigd door --MeAngry-- op 18-08-2003 11:29 ]

[Boss]

--MeAngry--: ik zie geen icon bij je naam staan. Komt 'ie misschien toch uit je cache?

[ACM]

Sir_Killalot schreef op 18 August 2003 @ 10:17:
Waarom worden dit soort belangrijke dingen niet op SCSI schijven gezet, ook al zijn de IDE Maxtors zo betrouwbaar ? (de pics stonden toch op IDE schijven?)

Nee, dat waren gewoon (nieuwe!) Seagate SCSI schijven in een raid-5 opstelling op een LSI raid-controller.

Maar als het goed is heb jij, als abonnee zijnde, ondertussen een mail met wat meer uitleg ontvangen.

[P_de_B]

Wellicht ten overvloede, maar ik krijg elke morgen een mailtje van de backup software of de backup procedure gelukt is of welke dingen er fout zijn gegaan.

Ik neem aan dat de backup software die T.Net gebruikt dit ook kan, anders zou het een goed idee zijn zulke software aan te schaffen IMHO.

Wat er ook gezegd wordt, T.Net biedt een commerciele dienst aan (immers je krijgt beschikking over de dataopslag etc. als je een betaald abonnement neemt) en heeft m.i. een inspanningsverplichting. Ook al worden de serveradmins niet betaald, het valt wel onder de verantwoording van T.Net bv.

Tweakers probeert (logisch!) andere inkomsten aan te boren, daar horen ook verantwoordelijkheden bij. Een servercrash kun je niet voor zijn, controleren of de backup gelukt is kan natuurlijk wel.

Begrijp me goed, ik denk dat tweakers een geweldige community is, en dit is ook zeker niet als flame bedoeld maar ik denk dat dit wel een punt is.

[Sir_Killalot]

ACM schreef op 18 August 2003 @ 12:45:
[...]

Nee, dat waren gewoon (nieuwe!) Seagate SCSI schijven in een raid-5 opstelling op een LSI raid-controller.

Maar als het goed is heb jij, als abonnee zijnde, ondertussen een mail met wat meer uitleg ontvangen.

Nope, heb nog niks in me inbox staan

[LauPro]

Freakertje schreef op 18 August 2003 @ 10:56:
[...]
Prima, maar ff een wedervraagje, (en een tip? ):
Zijn USB sticks (van die sleutelhangerdingen) niet iets voor jou? Ideaal spul hoor, gaat behoorlijk wat op en de kans op crashen of andere vormen van dataloss is behoorlijk klein. Tevens heb je altijd een opslagmedium bij je en al je belangrijke bestanden.

offtopic:
Die ga ik van de week ook aanschaffen, ware het niet dat die dingen imo nog gevoeliger zijn dan diskettes. Je prikt ze overal in, af en toe moet 'ie een 115 V AC overleven en je weet maar nooit wat anderen met zo'n USB-poort hebben gedaan. Ik kom echt de gekste dingen tegen als het gaat om sloperijen e.d.. Daarnaast zul je maar net zien dat in 90% van de gevallen die USB-poort aan de achterkant zit, en je dus helemaal zo'n kast in moet duiken en dan nog erger: dan hebben ze in het systeembeleid ingesteld dat je helemaal geen externe opslagmedia (oid) mag gebruiken. Lang verhaal kort: ik ga er wel een aanschaffen, maar niet voor school.

[mutsje]

blackd schreef op 17 augustus 2003 @ 12:50:
[...]

Ik had nog wat pics van jouw guides, die heb ik inmiddels naar SH007 gemailed.

Heb inmiddels alle pics opnieuw geschoten van DNS forwarding. Ben nu ziek thuis dus zit zweterig achter de machine plaatjes met bloed zweet en tranen te maken wat je al niet voor GOT overheb hihihihi

pics HOWTO: dns forwarding

ga andere pics nog wel maken.

[ Voor 16% gewijzigd door mutsje op 18-08-2003 15:03 ]

[Exirion]

P_de_B schreef op 18 August 2003 @ 13:28:
Wellicht ten overvloede, maar ik krijg elke morgen een mailtje van de backup software of de backup procedure gelukt is of welke dingen er fout zijn gegaan.

Een mailtje van de harddisk voordat ie gaat crashen zou ook leuk zijn

[Sir_Killalot]

Zo zien pics eruit na een crash: Sir_Killalot in "Het grote Gran Turismo topic"

Net alsof ze verkeerd gescanned zijn

[Attilla]

Exirion schreef op 18 August 2003 @ 15:00:
[...]

Een mailtje van de harddisk voordat ie gaat crashen zou ook leuk zijn

Zelfs dat kan.

Tenminste met compaq insight manager, maar ik denk niet dat deze gebruikt wordt. Deze geeft als meestal 2 weken voordat hij gaat crashen het aan, hoe dit technisch in elkaar zit weet ik niet exact, maar dat kan iemand anders vast wel vertellen.

[wildhagen]

[Airwolf] schreef op 18 August 2003 @ 15:15:
[...]


Zelfs dat kan.

Tenminste met compaq insight manager, maar ik denk niet dat deze gebruikt wordt. Deze geeft als meestal 2 weken voordat hij gaat crashen het aan, hoe dit technisch in elkaar zit weet ik niet exact, maar dat kan iemand anders vast wel vertellen.

Gewoon SMART. Als die"Failure is imminent" aangeeft, kan je d'r maar beter alvast een nieuwe in proppen, of er iig één in voorraad hebben.

[mOrPhie]

wildhagen schreef op 18 August 2003 @ 15:17:
[...]

Gewoon SMART. Als die"Failure is imminent" aangeeft, kan je d'r maar beter alvast een nieuwe in proppen, of er iig één in voorraad hebben.

SMART stuurt volgens mij geen emails.

Echter is smart doorgaans niet altijd de meest betrouwbare. Het is gewoon een feit dat je in veel gevallen een harddisk-crash niet aan kan zien komen. Daar is niemand op aan te spreken. Een crash kun je voorkomen middels goeie koeling en goed onderhoud, maar nooit voor 100%. Je kan er zelfs gewoon van uit gaan dat in zo'n drukke omgeving als t.net de harddisk (die het dus ook druk heeft) het kan begeven.

[wildhagen]

mOrPhie schreef op 18 August 2003 @ 15:21:
[...]


SMART stuurt volgens mij geen emails.

Nee, maar een béétje goed managementpakket (á la Compaq Insight Manager of Dell OpenManage, HP OpenView etc) kan die traps opvangen en die kan dan wel een mail sturen.

Echter is smart doorgaans niet altijd de meest betrouwbare. Het is gewoon een feit dat je in veel gevallen een harddisk-crash niet aan kan zien komen. Daar is niemand op aan te spreken. Een crash kun je voorkomen middels goeie koeling en goed onderhoud, maar nooit voor 100%. Je kan er zelfs gewoon van uit gaan dat in zo'n drukke omgeving als t.net de harddisk (die het dus ook druk heeft) het kan begeven.

Precies, 100 procent zekerheid heb je nooit, óók niet als je hem goed koelt en goed onderhoud. Het is nu eenmaal een (deels) mechanisch onding, en alle mechanische ondingen hebben de onhebbelijkheid een keer stuk te gaan.

[ripexx]

Als ik alles goed gelezen heb is het probleem ontstaan door eerst een falend HDD waarna ook nog eens de controller over de zeik is gegaan. Daarbij nog eens dat de backups niet helemaal oke waren. Als dan iets misgaat en komt Murphy ook nog eens langs en het gevolg is duidelijk. Helaas, verder heeft t.net geloof ik nu genoeg maatregelen genomen om in ierdergeval een HDD crash goed op te vangen en is er iets veranderd in de backup procedure.

Voor de rest keep up the good work!

[Kix@$$]

Verwijderd schreef op 17 August 2003 @ 01:15:
[...]


Misschien wordt het tijd voor een betere airco of andere hosting service? Zoals het de laatste paar dagen gaat, heb ik er weinig vertrouwen meer in. Sorry voor deze harde woorden, maar zo denk ik er wel over....

Volgens mij heeft dit probleem niet echt veel te maken met Trueserver/Telecity of wat dan ook. Er is trouwens ook Airco in het cabinet (en goeie ook, al genoeg schroeven in verloren ).

Het is zo dat HDD's nogsteeds meganisch zijn en bewegende onderdelen hebben. Zolang iets beweegd kan iets kappot gaan (ook als het niet beweegd trouwens maar das meer statische elektriciteit e.d.)

HDD's vallen zoizo vergeleken met andere dingen best vaak uit, gewoon omdat er bewegende onderdelen inzitten o.a.

[ACM]

wildhagen schreef op 18 August 2003 @ 15:24:
Nee, maar een béétje goed managementpakket (á la Compaq Insight Manager of Dell OpenManage, HP OpenView etc) kan die traps opvangen en die kan dan wel een mail sturen.

Kunnen die pakketten ook draaien als je in het BIOS (van de raidcontroller) zit?
Kunnen ze een hdd/controller probleem voorspellen op het moment dat je de hdd erin drukt?

In dit geval zou het dus compleet niets afgevangen hebben, sterker nog het is prima mogelijk dat de gefaalde scsi-drive tot het moment dat ie ermee uitschee gewoon via SMART "alles is ok" riep...

Kix@$$ schreef op 18 augustus 2003 @ 16:58:
Er is trouwens ook Airco in het cabinet (en goeie ook, al genoeg schroeven in verloren ).

Das niet goed voor zo'n airco hoor

[ Voor 16% gewijzigd door ACM op 18-08-2003 17:02 ]

[curry684]

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

[Kix@$$]

ACM schreef op 18 August 2003 @ 17:01:
[...]

Kunnen die pakketten ook draaien als je in het BIOS (van de raidcontroller) zit?
Kunnen ze een hdd/controller probleem voorspellen op het moment dat je de hdd erin drukt?

In dit geval zou het dus compleet niets afgevangen hebben, sterker nog het is prima mogelijk dat de gefaalde scsi-drive tot het moment dat ie ermee uitschee gewoon via SMART "alles is ok" riep...
[...]

Das niet goed voor zo'n airco hoor

Moet tie maar niet zo hard zuigen


Om ff over HDD's door te gaan. Je kan nog zeggen wat je wilt over IDE HDD's, Maxtor, of WD of wat dan ook maar ze hebben geen van alle garantie als je ze 24/7 gebruikt. Alleen de high-end SCSI schrijven hebben garantie als je ze 24/7 gebruikt, staat ook duidelijk in de voorwaarden.

[Sir_Killalot]

Kix@$$ schreef op 18 augustus 2003 @ 17:20:
[...]

Moet tie maar niet zo hard zuigen


Om ff over HDD's door te gaan. Je kan nog zeggen wat je wilt over IDE HDD's, Maxtor, of WD of wat dan ook maar ze hebben geen van alle garantie als je ze 24/7 gebruikt. Alleen de high-end SCSI schrijven hebben garantie als je ze 24/7 gebruikt, staat ook duidelijk in de voorwaarden.

Hoe willen ze dat gaan controleren dan?

[Verwijderd]

Zo megaraar is dat niet, meestal als het mis gaat, dan heb je ook alle pech v/d wereld, en gaat ook alles mis wat er mis kan gaan.

[Kix@$$]

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

Mjep, volgens mij is de beste backup strategie om naar een andere pc te backupen op een andere locatie met een ander(e) merk/serie HDD erin.
Maarja... dit is bijna onbetaalbaar...

[André]

Oftewel: Shit happens, and never happens alone....

[Kix@$$]

Sir_Killalot schreef op 18 August 2003 @ 17:21:
[...]


Hoe willen ze dat gaan controleren dan?

Mja ligt er maar net aan waar je woont, in Amerika moet jij bewijzen dat hij niet 24/7 aanstaat. In europa is dit stuk lastiger, maar de HDD's zijn tegenwoordig zo slim dat er vast een log in zal zitten ofzo.

[LauPro]

Het probleem lag in dit geval dus aan het filesystem? Betekend dat niet dat er moet worden gekeken naar een ander filesystem dat wél bestand is tegen dit soort wisselingen? Welk filesystem werd er overigens gebruikt?

[ACM]

Kix@$$ schreef op 18 August 2003 @ 17:20:
Om ff over HDD's door te gaan. Je kan nog zeggen wat je wilt over IDE HDD's, Maxtor, of WD of wat dan ook maar ze hebben geen van alle garantie als je ze 24/7 gebruikt. Alleen de high-end SCSI schrijven hebben garantie als je ze 24/7 gebruikt, staat ook duidelijk in de voorwaarden.

Ja, maar hoe is dat voor ons van toepassing dan

LauPro schreef op 18 August 2003 @ 17:30:
Het probleem lag in dit geval dus aan het filesystem? Betekend dat niet dat er moet worden gekeken naar een ander filesystem dat wél bestand is tegen dit soort wisselingen? Welk filesystem werd er overigens gebruikt?

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...

Maar aangezien we geen technische details weten van de exacte oorzaak van het dataverlies heeft het weinig zin om om _die_ reden een goed FS te vervangen door eentje die we nog nooit gebruikt hebben.

[tweakduke]

Zo zien we maar weer hoe het belangerijk is om goeie backups te hebben, maar jah hoe goed je backup systeem ook is kan altijd mis gaan ....

[enriqueeeee]

dur is toch een camera waar je de tweaker servers kan zien bestaat dat nog en wat is de url kunnen we zien wat er gedaan word zo'n beetje

[ACM]

Er wordt echt niks gedaan om deze tijd hoor... En sowieso gebeurt het grootste deel remote, dus ik zou niet weten waarom je naar die cam zou willen kijken

[Verwijderd]

tweakduke schreef op 18 August 2003 @ 19:43:
Zo zien we maar weer hoe het belangerijk is om goeie backups te hebben, maar jah hoe goed je backup systeem ook is kan altijd mis gaan ....

Ja, maar dan gaat er dus 2x iets mis. Én je origineel is pleite én je backup is pleite, dat is al dubbel-op.

[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.

[Verwijderd]

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 Verwijderd 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]

Verwijderd 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.

[Verwijderd]

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 Verwijderd 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.

[Verwijderd]

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.