[sissel]

• 0

År inte sunt förnuft/självbevarelsedrift lösningen på allt problem med bitröta. Har jag filer som jag inte vill förlora så ser jag till att kopiera till olika lagringsmedier både en och två gånger....

Oh nej! Jag har ett problem som inte påverkar mig!

...De filer som faktiskt är värda något borde vidare redan ha säkerhetskopier annorstädes för mer reella problem som kan drabba hårddiskar.

Jag kan vidare räkna antalet krasher hos min hemdator varje år på en hand. Tror jag hellre tar en extra krash eller så per år än att behöva lägga tid på att hitta passande ECC-minnen (fann inga senast)...

Ok, så man bara säkerhetskopierar, så slipper man bitröta? Det låter som en enkel och bra lösning? En fråga bara, det verkar som att ni tror att originalet skyddas mot bitröta genom att ta en säkerhetskopia. Hur vet man att inte säkerhetskopian råkar ut för bitröta om ett tag? Ta ytterligare säkerhetskopior på kopiorna? Nja, det låter ju ganska osäkert, håller ni inte med?

Jag påstår att enda sättet att vara säker att man inte råkat ut för bitröta är att lagra en checksumma tillsammans med varje fil, t.ex. MD5 checksumma. Och sen kör man en MD5 checksumma med jämna mellanrum på varje fil på disken. Då kan man vara säker på att inte råka ut för bitröta. När man väl fått bitröta, så får man kopiera tillbaka filen från en backup. Det är så här, man får göra i princip. Orkar man inte göra detta manuellt, så får man använda ett system som är designat för detta och gör det automatiskt.

Problemet är att du blandar fel som upptäcks när man läser datat med tysta fel. Det andra antagandet är att problemet inte existerat tidigare eftersom vi haft för små hårddiskar....Risken för att de ska finnas någon skadad fil ökar om vi lagrar mer...

Problemet med datakorruption existerar inte på små diskar, eftersom risken är så liten att få ett bitfel, risken är ju 1 per 10^16 lästa bitar.. Ju fler bitar vi lagrar, desto större är risken att det uppkommer något bitfel någonstans. Om vi lagrar 10^16 bitar, så har vi ett bitfel nånstans i genomsnitt. Vi verkar säga samma saker, vi är alltså överens om detta.

Att det finns många av världens toppforskare på CERN innebär inte att deras IT-avdelning behöver ha högre kompetens.

Återigen, CERN har många datorforskare som bl.a. forskar på lagra stora mängder av data. Det är alltså inte vanliga driftskillar som forskar på bitröta och andra okända problem. Här har vi en av CERN forskarna som studerat datakorruption, han har en doktorsexamen i fysik, men börjat forska mer mot IT, bl.a. datalagring och har författat flera av CERNs studier i datakorruption.
http://videolectures...anzer_steindel/

Normala hemanvändare har inte någon större mängd data som är känslig när man tar bort filmer och bilder och det är därför fortfarande väldigt osannolikt att drabbas av problemet.

Ja, det osannolikt, men det händer. Det är inte bara diskarna som är en felkälla, det finns många andra felkällor. Power supply, lösa kablar, etc. Därför inträffar felen mycket oftare än 1 per 10^16.

Mot alla andra fel än tysta fel kan man skydda sig genom att ha bra backup.

Och hur skyddar du backupen från bitröta? Över tid så ruttnar datat, bitar börjar flippa helt spontant. Hur hindrar du denna fysikaliska process att inträffa på backupen?

ehh, nej inte det minsta, det jag oroar mig för med felaktig firmware & kontroller är totalt tappade sektorer, rent felaktigt skriven data, inkompabillitet med sata kontrollers, dålig lpm implementering etc etc etc... Bitröta är inte riktigt på den nivån...

Du har helt rätt. Jag borde vara tydligare med att skilja mellan bitröta och silent data corruption. Silent data corruption är ett vitt begrepp, däri ingår bitröta (data ruttnar över tid). Så när du pratar om buggar i firmware, så kanske de inte orsakar bitröta. Men du oroar dig helt klart för data korruption. Så låt oss prata om datakorruption istället. Om du skulle ta en checksumma på varje fil, så kan du upptäcka om du har buggar i firmware eller inte. Checksumman detekterar alla typer av datakorruption, bl.a. buggar i firmware. Du är alltså helt immun mot data korruption om du tar checksummor av varje fil. Och, det är helt rätt att fundera på buggar i firmware, därför att 5-10% av all datakorruption orsakas av buggar i firmware, enligt en stor studie.

Redigerat av sissel, 05 February 2012 - 00:19.

[Unregisteredc96d6be8]

• 0

@Sissel

Släng in zfs om du är orolig så har du ju löst problemet, det ska ju vara betydligt mer tåligt, jag anser det är klart overkill för hemmabruk. Förutom lite foton så har jag inga filer som inte går att återskapa.

[sissel]

• 0

@Sissel

Släng in zfs om du är orolig så har du ju löst problemet, det ska ju vara betydligt mer tåligt, jag anser det är klart overkill för hemmabruk. Förutom lite foton så har jag inga filer som inte går att återskapa.

Jojo, det är ju allmänt känt att zfs löser dessa problem. Det finns ju t.om forskningsartiklar kring zfs och silent data corruption som säger att zfs löser detta problem, och det är därför CERN går över till zfs nu.
http://en.wikipedia....#Data_Integrity

Men frågan är, känner folk till att detta är ett problem? Fast alla kanske inte sitter med flera TB lagringsutrymme? Om de har 1TB disk totalt, för system och data, så är de inte i farozonen än. Men ju mer data de har, desto större är risken. Är detta helt okänt?

[BitterMelon]

• 0

Jojo, det är ju allmänt känt att zfs löser dessa problem. Det finns ju t.om forskningsartiklar kring zfs och silent data corruption som säger att zfs löser detta problem, och det är därför CERN går över till zfs nu.
http://en.wikipedia....#Data_Integrity

Men frågan är, känner folk till att detta är ett problem? Fast alla kanske inte sitter med flera TB lagringsutrymme? Om de har 1TB disk totalt, för system och data, så är de inte i farozonen än. Men ju mer data de har, desto större är risken. Är detta helt okänt?

Ja, det är ganska okänt, och ja, det är inget folk i gemen behöver oroa sig för. Deras data är helt enkelt vare sig tillräckligt stort eller tillräckligt viktigt. Har man inte ens backup på sina grejer (vilket 90% antagligen inte har) så är bitröta det minsta av deras problem, oavsett hur mycket lagring man har.

Det är, än sålänge, bara i riktigt stora miljöer med kritisk data (ex. CERN) som det är relevant att titta på problemet. Är det icke-kritisk data spelar det ingen roll hur stor miljön än, det är ändå inte katastrof om lite data pajar. Jämför ex. korrupt data från ett partikelkollissionstest som kostar multum att göra om med att en del av ett Word-dokument hos något företag bli korrupt. Det går att skriva om i värsta fall.

[Unregisteredc96d6be8]

• 0

Jojo, det är ju allmänt känt att zfs löser dessa problem. Det finns ju t.om forskningsartiklar kring zfs och silent data corruption som säger att zfs löser detta problem, och det är därför CERN går över till zfs nu.
http://en.wikipedia....#Data_Integrity

Men frågan är, känner folk till att detta är ett problem? Fast alla kanske inte sitter med flera TB lagringsutrymme? Om de har 1TB disk totalt, för system och data, så är de inte i farozonen än. Men ju mer data de har, desto större är risken. Är detta helt okänt?

Som sagt var så är det andra saker jag oroar mig mer för än silent data corruption, men inte ens det är tillräckligt stora problem för att jag ska vara beredd att skaffa en lika stor server till för att kunna ta backup, förutom en del bilder så kan all min data återskapas, bilder lagrar jag därför även i molnet, men all musik och alla filmer har jag även på skiva så det går alltid att fixa igen.
Det värsta som kan hända är att en hel disk går åt skogen och att jag då får fixa alla data som ligger på den disken, det är tidskrävande men inte nån katastrof.

För mig är det viktigare med användarvänlighet, att lagringsytan är lätt att bygga ut mm. Jag kör inte raid men jag kör diskpool i amahi. Musik och bilder ligger alltid på minst 2 fysiska diskar och bilder som sagt var även i molnet.

[Unregisteredd0294629]

• 0

Ok, så man bara säkerhetskopierar, så slipper man bitröta? Det låter som en enkel och bra lösning? En fråga bara, det verkar som att ni tror att originalet skyddas mot bitröta genom att ta en säkerhetskopia. Hur vet man att inte säkerhetskopian råkar ut för bitröta om ett tag? Ta ytterligare säkerhetskopior på kopiorna? Nja, det låter ju ganska osäkert, håller ni inte med?

Jag påstår att enda sättet att vara säker att man inte råkat ut för bitröta är att lagra en checksumma tillsammans med varje fil, t.ex. MD5 checksumma. Och sen kör man en MD5 checksumma med jämna mellanrum på varje fil på disken. Då kan man vara säker på att inte råka ut för bitröta. När man väl fått bitröta, så får man kopiera tillbaka filen från en backup. Det är så här, man får göra i princip. Orkar man inte göra detta manuellt, så får man använda ett system som är designat för detta och gör det automatiskt.

Den ger inte 100% skydd. Men risken att både drabbas är ju nu ^2. Dessutom så är risken att samma bit drabbas ännu mycket mindre än så, så även om båda filerna utsätts för bitröta är det en väldigt liten risk att man inte kan återskapa orginalet från dem (givet att det faktiskt är värt jobbet).

[tyve]

• 0

Ok, så man bara säkerhetskopierar, så slipper man bitröta? Det låter som en enkel och bra lösning? En fråga bara, det verkar som att ni tror att originalet skyddas mot bitröta genom att ta en säkerhetskopia. Hur vet man att inte säkerhetskopian råkar ut för bitröta om ett tag? Ta ytterligare säkerhetskopior på kopiorna? Nja, det låter ju ganska osäkert, håller ni inte med?

Nej, vi håller inte med eftersom samma fil måste vara trasig i både original och kopia. Det är extremt osannolikt.

Problemet med datakorruption existerar inte på små diskar, eftersom risken är så liten att få ett bitfel, risken är ju 1 per 10^16 lästa bitar.. Ju fler bitar vi lagrar, desto större är risken att det uppkommer något bitfel någonstans. Om vi lagrar 10^16 bitar, så har vi ett bitfel nånstans i genomsnitt. Vi verkar säga samma saker, vi är alltså överens om detta.

Sannolikheten att en fil på 10 MB är felaktig är precis lika stort med små diskar! Precis som du säger är sannolikheten större att träffa på ett fel om man lagrar mer information men den data som ökat för vanliga användare är media-filer som inte är känsliga för bitröra. Om den vanliga användare fortfarande har 1GB känslig data spelar det ingen roll om den ligger på en 1GB disk eller en 1TB disk.

Återigen, CERN har många datorforskare som bl.a. forskar på lagra stora mängder av data. Det är alltså inte vanliga driftskillar som forskar på bitröta och andra okända problem. Här har vi en av CERN forskarna som studerat datakorruption, han har en doktorsexamen i fysik, men börjat forska mer mot IT, bl.a. datalagring och har författat flera av CERNs studier i datakorruption.
http://videolectures...anzer_steindel/

Okej, de kanske inte är de vanliga IT-snubbarna på den avdelningen men det är fortfarande en studie som är gjord för deras behov och inte tänkt som en allmän studie av dataintegritet.

Har du länkar till fler studier med tanke på att det gått några år sedan den studien där en stor del av deras problem berodde på fel i firmware? Hur gick det med de åtgärder de försökte få pengar till i rapporten? Har de gjort nya mätningar?

Du har helt rätt. Jag borde vara tydligare med att skilja mellan bitröta och silent data corruption. Silent data corruption är ett vitt begrepp, däri ingår bitröta (data ruttnar över tid). Så när du pratar om buggar i firmware, så kanske de inte orsakar bitröta. Men du oroar dig helt klart för data korruption. Så låt oss prata om datakorruption istället. Om du skulle ta en checksumma på varje fil, så kan du upptäcka om du har buggar i firmware eller inte. Checksumman detekterar alla typer av datakorruption, bl.a. buggar i firmware. Du är alltså helt immun mot data korruption om du tar checksummor av varje fil. Och, det är helt rätt att fundera på buggar i firmware, därför att 5-10% av all datakorruption orsakas av buggar i firmware, enligt en stor studie.

Nu blandar du begrepp på alla möjliga sätt. Du säger att Silent data corruption är ett vitt begrepp, i det ingår bitröta. I bitröta ingår enligt dig buggar i firmware.

Tittar vi ovan har du använt måttet 1 fel på 10^16 (unrecoverable read error) som ett mått på bitröta. Som jag skrev tidigare är det ett mått på fel som upptäcks och rapporteras till operativsystemet. Det är inte "silent" och kan därför inte ingå i begreppet Silent Data Corruption!

När data lagras på en hårddisk läggs det med checksummor (ECC). Eftersom man vet att magnetiska media är osäkra och att man kan få bitfel. Därför läser man en sektor från disk, kontrollerar mot ECC. Om det är fel försöker man läsa sektorn ett antal gånger till. Går inte det läser man så mycket man kan och använder sedan ECC för att rätta det som saknas. Funkar inte det, skickas ett URE till operativsystemet och då får man hoppas att man har backup på den fil som inte gick att läsa.

Man har liksom tänkt på att bitröta uppstår.

Liknande kontroller finns i flera led vilket CERN-rapporten visar. Det som kan hända är att kontrollerna missar ett fel men jag kan inte hitta någon uppdelning på fel som rapporterats av systemet och vilka som varit bara upptäckts av deras egen checksummekontroll. Det är Robin Harris som sedan dragit slutsatsen att allt är Silent data corruption. Samme Harris som ropat "Vargen kommer!" i flera år http://www.zdnet.com...ing-in-2009/162 Du och han får väl fortsätta med domedagsprofetsiorna men jag tror jag lägger ner den här diskussionen nu.

Det är inget problem jag är orolig för och som andra inte behöver oroa sig för om de inte har liknande behov av korrekt data som CERN.

Se bara till att ha backup på det viktiga datat!

[Vapo]

• 0

MS hade en studie om detta och pratade om vikten av ECC RAM till Vista
http://www.tgdaily.c...emory-for-vista

Så min nästa dator ska använda ECC RAM, och dessutom köra en lösning som eliminerar bitröta och Silent Data Corruption.

Bitröta var inget problem för 5 år sen, när diskarna var små. Men idag har många flera TB stora raid, och det är först nu man börjar få så mycket data att det märks.

Först hänvisar du till att "30% av Win krashar är bitröta" och presenterar det som fakta? Det roliga är ju att artikeln är ganska exakt 5 år gammal - trots att du sen säger att bitröta inte var problematisk för 5 år sedan trots att det är ett av dina första huvudargument.
Sen om man läser länken du hänvisar till så handlar den om pre-Vista men där inga % presenteras, låt mig citera;

This "breakage" apparently is caused by sub-quality memory that does not meet general specifications and can crash software.

If Microsoft's concern is especially sub-quality memory than, at least in theory, higher quality memory from manufacturers such as Corsair, Crucial or OCZ could be another option and a potentially cheaper memory solution than ECC.

Lärdom tagen: använd kvalitets-RAM så undviker gemene man domedagsprofetior och konspirationsteorier som trollas och bollas i forum...

[sissel]

• 0

Nej, vi håller inte med eftersom samma fil måste vara trasig i både original och kopia. Det är extremt osannolikt.
....
Se bara till att ha backup på det viktiga datat!

Visst håller jag med om att det är extremt osannolikt att både originalet och backupen är trasiga, detta scenario kan vi bortse ifrån. Men jag vill påstå att en backup inte hjälper vidare mycket, det räcker inte. Här är det en databas administratör som pratar om backup och pekar ut problemet som jag försöker förmedla, men inte lyckas.
http://jforonda.blog...corruption.html
Jag försöker igen. Antag att du backuppar med jämna mellanrum precis som alla vi rekommenderar. Sen upptäcker du efter ett halvår, fel på en fil. Så du går till backuppen för att återställa filen. Men... tänk om datakorruptionen inträffade för ett år sen? Då är även din backup korrupt. Så du tvingas ha flera olika backupper som går olika långt tillbaka i tiden. En backup för ett halvår sen. En backup för ett helt år sen. För två år sen. etc. Hur långt tillbaka ska du gå bland dina backupper för att vara säker på att filen är intakt? Räcker halvårsbackupen? Måste du gå till ett årsbackuppen? Eller två årsbackuppen? Du vet inte vilken tidpunkt som filen korruptades. Därför räcker inte att ha EN backup. Du måste ha många backupper, som går olika långt tillbaka i tiden. Räcker detta då?

Tänk om du fick en fil av en kompis som var bra. Du kopierar den (och då vid kopieringen korruptades filen). Sen så backuppar du den vid olika tider och tror att i alla fall en av backupperna ska vara ok. Men i själva verket är ALLA dina backupper korrupta på just den filen. Du fick en korrupt fil från första början. Vissa media filer kan jag inte öppna idag. Vissa rar filer kan jag inte öppna. Hur långt tillbaka i tiden måste jag gå? Vet inte. Jag har inte femtioelva backuper som går olika långt tillbaka i tiden.

Det ENDA som hjälper, är att använda ett system som beräknar checksummor. Då behöver jag inte femtioelva backuper. Man måste beräkna MD5 checksummor med jämna mellanrum för att se om datat ruttnar över tiden. Och om datat ruttnat, så går jag till backuppen och återställer filen.

Mao, en backup räcker inte. Blev det tydligare nu? Länken ovan berättar mera om detta. Fast han är ju databas administratör, så på företag är det extremt viktigt att allt funkar väl. Vi är ju bara hemmapulare så det är inte lika viktigt för oss.

Sannolikheten att en fil på 10 MB är felaktig är precis lika stort med små diskar! Precis som du säger är sannolikheten större att träffa på ett fel om man lagrar mer information men den data som ökat för vanliga användare är media-filer som inte är känsliga för bitröra. Om den vanliga användare fortfarande har 1GB känslig data spelar det ingen roll om den ligger på en 1GB disk eller en 1TB disk.

Det här håller jag med om.

Okej, de kanske inte är de vanliga IT-snubbarna på den avdelningen men det är fortfarande en studie som är gjord för deras behov och inte tänkt som en allmän studie av dataintegritet.

Varför är det inte en allmän studie i dataintegritet? CERN har författat flera allmäna forskningsrapporter om dataintegritet. T.ex. denna som är lite mera omfattande om dataintegritet:
http://w3.hepix.org/...Corruptions.pdf

Har du länkar till fler studier med tanke på att det gått några år sedan den studien där en stor del av deras problem berodde på fel i firmware? Hur gick det med de åtgärder de försökte få pengar till i rapporten? Har de gjort nya mätningar?

Flera studier, se ovan. Hur det gick? Ja, CERN byter nu till ZFS på långtidslagring av data:
http://blogs.oracle....g_science_means
"Having conducted testing and analysis of ZFS, it is felt that the combination of ZFS and Solaris solves the critical data integrity issues that have been seen with other approaches. They feel the problem has been solved completely with the use of this technology. There is currently about one Petabyte of Thumper [ZFS] storage deployed across Tier1 and Tier2 sites. That number is expected to rise to approximately four Petabytes by the end of this summer. "

Nu blandar du begrepp på alla möjliga sätt. Du säger att Silent data corruption är ett vitt begrepp, i det ingår bitröta. I bitröta ingår enligt dig buggar i firmware

Nej, det är inte riktigt så jag menar. Data corruption är ett vitt begrepp. Där ingår bitröta (data ruttnar med tiden), silent data corruption (datorn märker inte att datat förvanskats). Buggar i firmware har inget med bitröta att göra.

Först hänvisar du till att "30% av Win krashar är bitröta" och presenterar det som fakta? Det roliga är ju att artikeln är ganska exakt 5 år gammal - trots att du sen säger att bitröta inte var problematisk för 5 år sedan trots att det är ett av dina första huvudargument.
...
Lärdom tagen: använd kvalitets-RAM så undviker gemene man domedagsprofetior och konspirationsteorier som trollas och bollas i forum...

Jag har inte lyckats vara klar och tydlig nog. Jag provar igen. När det gäller RAM, så behövs ECC därför att MS säger att 30% av alla krascher beror på RAM utan ECC.

När det gäller diskar, så har vi haft små diskar fram till nyligen, så data korruption har inte varit ett problem. Men nu är det ett problem, om man har stora raid. Skilj på RAM och disk. Jag försöker bara säga att datakorruption inträffar på både disk eller på RAM.

Med RAM kunde man läsa många bitar väldigt snabbt även förr i tiden, RAM är ju så snabbt, så man hinner läsa många bittar tills man statistiskt träffar på datakorruption. Därför behövdes ECC RAM även förr i tiden - för man hann läsa många bitar från RAM. Med diskar var det inget problem, de var så långsamma och små. Men idag är de stora/snabba och man hinner läsa många bitar idag - så först nu behövs ECC på filsystemen.

Blev det klarare nu?

[somoene2]

• 0

Snacka om att göra en höna av en fjäder.
Har själv suttit med massor av datorer med stora diskar och tusentals filer i alla dess olika storlekar och typer och aldrig upplevt eller drabbats av bekymmer med "bitröta"
Filkopiering mellan datorer sker konstant på 4 olika datorer i hemmet och dessa stressas hårt varje dag med all möjlig belastning. inte ens när diskar har gått sönder har jag förlorat data då det är tämligen enkelt att få igång disken igen så pass att man kan återvinna datan på den och kopiera den till annan media/disk. Kör även raid 0 som system diskar på 2 maskiner (en med ssd diskar och den andra med vanliga mekaniska diskar) och där prioriteras prestanda framför säkerhet. Vissa kanske tycker det är att chansa, själv anser jag dock att med en OS backup och aldrig viktiga filer på system disken så är Raid 0 värt det för prestandans skull
det är lätt 99% större risk att drabbas av hårdvaru problem en "bitröta" (vilket jäkla ord dessutom)

[Vapo]

• 0

Jag har inte lyckats vara klar och tydlig nog. Jag provar igen. När det gäller RAM, så behövs ECC därför att MS säger att 30% av alla krascher beror på RAM utan ECC.


Blev det klarare nu?

Det blir nog klart som korvspad när du kan påvisa de 30%:en som fakta...

[Unregisteredc96d6be8]

• 0

Hur man än ser på det så kan man inte jämföra sin lilla hemmalagring utan större värde med cerns lagring, där en fil kan innehålla resultat från forskning som kostat multum och ta fram. I deras fall så är det billigt och de har folk som kan sköta och utöka systemet. De flesta här tror jag inte riktigt har kompetensen och behovet även om det givetvis finns de med stora kunskaper. Jag sätter som sagt användarvänlighet långt högre upp än säkerheten eftersom att allt mitt material kan återanskaffas enkelt

[sissel]

• 0

Det blir nog klart som korvspad när du kan påvisa de 30%:en som fakta...

Den siffran får stå för Microsoft. De har analyserat krasch dumpar från WinXP, och kommit fram till att ca 30% av alla krascher kunde undvikits om folk använt ECC RAM istället. Det kan vara så att jag inte kommer ihåg siffran exakt, det kanske var 27.73% eller så, men risken var kring 30%. Enligt MS.

Faktum är att MS tycker detta med data korruption är ett stort problem, och har vidtagit kraftfulla åtgärder för att försöka lösa detta. Om datakorruption inte vore ett seriöst problem, så skulle ingen bry sig. Men fler och fler har fått upp ögonen för datakorruption.

[masse70]

• 0

Den siffran får stå för Microsoft. De har analyserat krasch dumpar från WinXP, och kommit fram till att ca 30% av alla krascher kunde undvikits om folk använt ECC RAM istället.

Länk till detta påstående?

Redigerat av masse70, 06 February 2012 - 13:53.

[Unregistered277056c3]

• 0

Tråkigt att en potentiellt intressant tråd mest mynnat ut i pajkastning, ingen nämnd och ingen glömd...

Man kan väl bara konstatera att cern-folket kommit fram till att just deras data riskerar att förstöras på lång sikt, och att de därför försöker hitta vägar att eliminera problemen.

Samtidigt framstår det ganska klart att ingen som frekventerar forumet anser sig ha råkat ut för dataförlust i modern tid pga "bitröta", och det finns inget vettigt sätt att klura ut huruvida det beror på att folks filer i allmänhet är av den typ där enstaka bitfel inte spelar någon roll eller om de faktiskt varit förskonade från fenomenet.

Helt klart är åtminstone att det givetvis är bra att "skydda sig" med ecc-ram och filsystem med verifiering, periodisk självkontroll osv, men samtidigt kan det mycket väl vara så att merkostnaden för dylikt jox hade varit vettigare att lägga på bättre nätaggregat eller andra komponenter.

Enstaka bitfel kommer man ALDRIG ifrån eftersom t o m elbolagen har en större sannolikhet att korrumpera våra lagrade datamängder än diskar och raidkontrollers mm tillsammans ställer till med....

Kommer vi mycket längre i diskussionen?

[Vapo]

• 0

Den siffran får stå för Microsoft. De har analyserat krasch dumpar från WinXP, och kommit fram till att ca 30% av alla krascher kunde undvikits om folk använt ECC RAM istället. Det kan vara så att jag inte kommer ihåg siffran exakt, det kanske var 27.73% eller så, men risken var kring 30%. Enligt MS.

Faktum är att MS tycker detta med data korruption är ett stort problem, och har vidtagit kraftfulla åtgärder för att försöka lösa detta. Om datakorruption inte vore ett seriöst problem, så skulle ingen bry sig. Men fler och fler har fått upp ögonen för datakorruption.

Som Masse säger, en länk hade ju förvandlat ditt påstående till fakta...

Vad jag kan hitta är det mest egna tolkningar och tredjehandsuppgifter som florerar. Här är en som iaf verkar lite saklig, men dock inte purfärsk som kan relatera till dagens eventuella problem...

For about four years Microsoft has been collecting data through its Online Crash Analysis (OCA) tool that reports system crashes to a Microsoft Web site.

About 18 months ago it began sharing OCA data and the white paper with systems and chip makers. According to one source, the report said single-bit error rates in DRAM are now among the top ten causes of systems failures.

Microsoft admits the data is still inconclusive because OCA does not provide enough detail about the types of systems that crash and the memory they use.

De fyra åren är 2003-2007.
Det framgår tyvärr inte om det finns 9 andra fel som ligger före på top-tio listan, eller fördelningen av dessa.
Sista meningen: inconclusive = ofullständig...

Som sagt var. En länk borde väl kunna påvisas?

Såg nu att du skrev "risken var kring 30%". Så nu är det alltså inte påstådda fakta, utan bara ett andrahands teoretiskt påstående?

"the risk of encountering system crash without ECC is 30% higher" << min påhittade mening som konspirationsteoretiker-wannabe...

[tyve]

• 0

Tänk om du fick en fil av en kompis som var bra. Du kopierar den (och då vid kopieringen korruptades filen). Sen så backuppar du den vid olika tider och tror att i alla fall en av backupperna ska vara ok. Men i själva verket är ALLA dina backupper korrupta på just den filen. Du fick en korrupt fil från första början. Vissa media filer kan jag inte öppna idag. Vissa rar filer kan jag inte öppna. Hur långt tillbaka i tiden måste jag gå? Vet inte. Jag har inte femtioelva backuper som går olika långt tillbaka i tiden.
...
Mao, en backup räcker inte. Blev det tydligare nu? Länken ovan berättar mera om detta. Fast han är ju databas administratör, så på företag är det extremt viktigt att allt funkar väl. Vi är ju bara hemmapulare så det är inte lika viktigt för oss.

Jag förstår problemet med att man gör kopia på en redan felaktig fil. Det du misslyckats med att övertyga mig om är att det här sker tillräckligt ofta för att man ska behöva oroa sig för det. Du har själv skrivit att det bara är aktuellt nu för att man har så stora hårddiskar och kan ha så mycket data. Jag hävdar att risken inte har ökat nämnvärt eftersom det fortfarande inte är några stora datamängder som är känsliga.

De här mediafilerna och RAR-filerna som du inte kan använda. Fungerar det att använda dem från backuper?

Varför är det inte en allmän studie i dataintegritet? CERN har författat flera allmäna forskningsrapporter om dataintegritet. T.ex. denna som är lite mera omfattande om dataintegritet:
http://w3.hepix.org/...Corruptions.pdf

Det är en presentation där de berättar vad de kom fram till i den studie som tidigare länkats till. Det är stor skillnad på att göra en studie där man allmänt undersöker ett problems omfattning eller på att göra en studie där man kontrollerar tillförlitligheten i det egen systemet.

Flera studier, se ovan. Hur det gick? Ja, CERN byter nu till ZFS på långtidslagring av data:
http://blogs.oracle....g_science_means
"Having conducted testing and analysis of ZFS, it is felt that the combination of ZFS and Solaris solves the critical data integrity issues that have been seen with other approaches. They feel the problem has been solved completely with the use of this technology. There is currently about one Petabyte of Thumper [ZFS] storage deployed across Tier1 and Tier2 sites. That number is expected to rise to approximately four Petabytes by the end of this summer. "

OK, de går över till ZFS för att det uppfyller deras behov.

Nej, det är inte riktigt så jag menar. Data corruption är ett vitt begrepp. Där ingår bitröta (data ruttnar med tiden), silent data corruption (datorn märker inte att datat förvanskats). Buggar i firmware har inget med bitröta att göra.

Du skrev tidigare "En studie utav 39.000 lagringslösningar, visar att 5-10% av alla fel beror på firmware buggar. Så man kan inte bortse från såna källor till bitröta". Det går inte att argumentera sakligt om du ska ändra begreppen.

[sissel]

• 0

Tråkigt att en potentiellt intressant tråd mest mynnat ut i pajkastning, ingen nämnd och ingen glömd...

Samtidigt framstår det ganska klart att ingen som frekventerar forumet anser sig ha råkat ut för dataförlust i modern tid pga "bitröta",

Enstaka bitfel kommer man ALDRIG ifrån eftersom t o m elbolagen har en större sannolikhet att korrumpera våra lagrade datamängder än diskar och raidkontrollers mm tillsammans ställer till med....

Jag tycker som du, att detta är en intressant fråga. Problemet börjar uppmärksammas på senare tid, men tydligen tror många att datakorruption inte är ett problem. Dock finns det ju folk här på forumet som fått datakorruption:

Jag visste inte vad bitrot var, men nu när jag tänker efter så tror jag att jag fått det. I somras var min bovärd här, och han drog ut proppen när min dator stod och tuggade under en filöverförning till extern disk. Visade sig senare att nästan alla rararkiv på de två diskarna hade blivit korrupta i en eller flera filer och fick kasseras.

Men absolut, visst är frågan intressant, och man bör vara medveten om problemet. Speciellt om man driftar datorer på ett företag. Tycker jag.

Som Masse säger, en länk hade ju förvandlat ditt påstående till fakta...

Vad jag kan hitta är det mest egna tolkningar och tredjehandsuppgifter som florerar. Här är en som iaf verkar lite saklig, men dock inte purfärsk som kan relatera till dagens eventuella problem...
Som sagt var. En länk borde väl kunna påvisas?

Såg nu att du skrev "risken var kring 30%". Så nu är det alltså inte påstådda fakta, utan bara ett andrahands teoretiskt påstående?

"the risk of encountering system crash without ECC is 30% higher" << min påhittade mening som konspirationsteoretiker-wannabe...

Jag hittar inte länken från MS igen. Men jag visade en länk där MS säger att frånvaron av ECC RAM bidrar till många krascher på Vista.

Här är några länkar om data korruption i RAM:
http://lambda-diode....nion/ecc-memory
"the probability of having at least one bit error in 4 gigabytes of memory at sea level on planet Earth in 72 hours is over 95% "

http://en.wikipedia...._on_electronics
"Studies by IBM in the 1990s suggest that computers typically experience about one cosmic-ray-induced error per 256 megabytes of RAM per month"

http://en.wikipedia....wiki/Soft_error

Men just studien av MS, hittar jag inte igen. Jag hoppas dock att det är tydligt och klart, att man får datakorruption i RAM på datorer. Att det finns ett skäl att man använder ECC RAM. Och varför skulle inte hårddiskar råka ut för samma problem?

Jag förstår problemet med att man gör kopia på en redan felaktig fil. Det du misslyckats med att övertyga mig om är att det här sker tillräckligt ofta för att man ska behöva oroa sig för det. Du har själv skrivit att det bara är aktuellt nu för att man har så stora hårddiskar och kan ha så mycket data. Jag hävdar att risken inte har ökat nämnvärt eftersom det fortfarande inte är några stora datamängder som är känsliga.

Jag håller med dig om att problemet inte är så viktigt för hemanvändare. Men jobbar man på ett företag bör man vara medveten om problemet, och använda ECC RAM på alla sina servrar. Och helst även en lagringslösning som motverkar datakorruption på diskar.

De här mediafilerna och RAR-filerna som du inte kan använda. Fungerar det att använda dem från backuper?

Dessa filer var så gamla att jag inte hade några andra backupper. Det var de filer jag hade.

Det är en presentation där de berättar vad de kom fram till i den studie som tidigare länkats till. Det är stor skillnad på att göra en studie där man allmänt undersöker ett problems omfattning eller på att göra en studie där man kontrollerar tillförlitligheten i det egen systemet.

CERN undersökte många olika lagringssystem med avseende på datakorruption. De skriver att även dyra Enterprise lösningar råkar ut för datakorruption. Att man bör använda checksummor. CERN skrev kontinuerligt ett känt bitmönster på sina lagringsservrar, och efter 3 veckor, undersökte de sina lagringsservrar (Linux rackservrar med hårdvaruraid) och upptäckte att bitmönstret var inte konsistent. Det var fel i bitmönstret.

OK, de går över till ZFS för att det uppfyller deras behov.

Japp. De undersökte flera lösningar, och känner att ZFS uppfyller deras krav på säkerhet. Jag tror CERN har höga krav. Det som duger åt CERN, duger nog även åt mig.

Du skrev tidigare "En studie utav 39.000 lagringslösningar, visar att 5-10% av alla fel beror på firmware buggar. Så man kan inte bortse från såna källor till bitröta". Det går inte att argumentera sakligt om du ska ändra begreppen.

Ah, jag hade lite bråttom. Men bitröta är när data ruttnar över tiden. Buggar i firmware har inget med tid att göra:
http://en.wikipedia.org/wiki/Bit_rot

En fråga som dök upp i mitt huvud med anslutning till den här tråden.
Finns det något filsystem som windows kan hantera som är tåligt mot den här typen av problem. Om problemet är så stort så vore de det konstigt om inte ms hade en lösning på det då många företag använder tex windows server.

Faktum är att MS observerat detta problem och försöker nu göra något åt detta. Precis som flera andra OS. T.ex. Linux bygger nu btrfs som är en kopia av zfs, med checksummor precis som zfs. MS snickrar på ReFS i Windows 8 som är zfs inspirerat med checksummor för att stävja datakorruption. freebsd har portat zfs. mac os x har också portat zfs i projektet "z-410".

Dock säger CERN att det inte räcker att lägga på checksummor för att få en säker lösning, det är alltså svårt att göra. Men forskning visar att zfs lösning verkar säker. Så frågan är om MS lösning är säker? Problemet är att MS nya "superfilsystem" inte har checksummor överallt, det bara checksummar metadata, men själva datat kan vara korrupt:
http://blogs.msdn.co...ndows-refs.aspx

"As mentioned previously, one of our design goals was to detect and correct corruption. This not only ensures data integrity, but also improves system availability and online operation. Thus, all ReFS metadata is check-summed at the level of a B+ tree page, and the checksum is stored independently from the page itself. This allows us to detect all forms of disk corruption, including lost and misdirected writes and bit rot"

Så det verkar som att både jag och många andra än MS tar datakorruption på allvar, även om många här hånar mig för att uppmärksamma folk på det. Fler och fler ser behovet av zfs liknande filsystem.

[Unregisteredc96d6be8]

• 0

@Sissel

Tror inte att nån här direkt hånar dig, men det är nog kanske inte bästa forumet för de här frågorna, även om de givetvis är intressanta. Jag kollade också på zfs när jag byggde min nya server men kom fram till att det är alldeles för låg hanterbarhet för mig. Tex så är det problem att addera diskar till lagringen när man utökar. Freenas rekommenderar 6gb ram för att köra zfs vilket skulle betyda nytt moderkort i mitt fall.

[Unregistered277056c3]

• 0

Jag tycker som du, att detta är en intressant fråga. Problemet börjar uppmärksammas på senare tid, men tydligen tror många att datakorruption inte är ett problem. Dock finns det ju folk här på forumet som fått datakorruption:

maximm 03 February 2012 - 23:39 skrev:

Jag visste inte vad bitrot var, men nu när jag tänker efter så tror jag att jag fått det. I somras var min bovärd här, och han drog ut proppen när min dator stod och tuggade under en filöverförning till extern disk. Visade sig senare att nästan alla rararkiv på de två diskarna hade blivit korrupta i en eller flera filer och fick kasseras.

...både jag och många andra än MS tar datakorruption på allvar, även om många här hånar mig för att uppmärksamma folk på det. Fler och fler ser behovet av zfs liknande filsystem.

Det som maximm råkat ut för är ju ett typexempel på "nätstörning"/skrivfel och har inget med bitröta att göra.

Tycker nog inte att någon hånar dig, men du går på ganska hårt när folk säger att de inte alls märkt av problemet.

Själv har jag funderat ett par varv kring mina serverlösningar och om det finns anledning att förändra något.
Har inte kommit fram till något resultat än, men tack för att du så idogt påpekat problemet. Det är alltid nyttigt!

[sissel]

• 0

Det som maximm råkat ut för är ju ett typexempel på "nätstörning"/skrivfel och har inget med bitröta att göra.

Jag tror du har rätt, det har antagligen inget med bitröta att göra. Men däremot råkade han ut för data korruption, och en bra lösning ska fånga alla datakorrutionsfel, inklusive bitröta. zfs hade detekterat och korrigerat problemet omedelbart.

Tycker nog inte att någon hånar dig, men du går på ganska hårt när folk säger att de inte alls märkt av problemet.

Ja, då får jag be om ursäkt. Jag tror vi alla kan enas om att datakorruption inträffar, men inte i så hög grad att det är ett problem för en hemanvändare. Där är vi alla överens. Dock kommer problemet att öka än mer, och det är väl därför fler börjar bygga filsystem som liknar zfs.

Själv har jag funderat ett par varv kring mina serverlösningar och om det finns anledning att förändra något.Har inte kommit fram till något resultat än, men tack för att du så idogt påpekat problemet. Det är alltid nyttigt!

Jag var inte medveten om detta problem förrän nyligen. Nu ska jag köra ECC RAM och zfs. Speciellt som jag har flera TB data. Det som är bra med zfs, är att man inte behöver något raidkort, man behöver alltså inte köpa ny hårdvara, såsom t.ex. raidkort eller nåt sånt. Kör man vanliga sata diskar så kan man köra zfs, dvs samma lösning som CERN har valt efter mycket efterforskningar. Duger det åt CERN, så duger det åt mig.

Tror inte att nån här direkt hånar dig, men det är nog kanske inte bästa forumet för de här frågorna, även om de givetvis är intressanta. Jag kollade också på zfs när jag byggde min nya server men kom fram till att det är alldeles för låg hanterbarhet för mig. Tex så är det problem att addera diskar till lagringen när man utökar. Freenas rekommenderar 6gb ram för att köra zfs vilket skulle betyda nytt moderkort i mitt fall.

Visst är det intressant att få en stabilare dator med ECC RAM och tillförlitligare diskar!

När det gäller att öka antalet diskar i zfs, så går det utmärkt dock. När man bygger ett raid i zfs, så använder man kanske 6 diskar till att bygga det. Man kan utöka sitt raid, genom att lägga till ett gäng diskar till. Man kan alltså lägga till t.ex. 6 diskar till, så raidet består av 12 diskar. Men man kan inte ändra från 6 till 7 diskar. Man lägger till hela grupper av diskar. Alternativt byter man t.ex. 1TB disk mot 2TB disk och reparerar raidet. Sen upprepar man för varje disk, och då har raidet växt.

Man behöver inte heller 6GB RAM. Folk har kört zfs med 1GB RAM, med pentium 4 cpuer. Man kan ju prova att installera freebsd/opensolaris i virtualbox och skapa ett raid mha filer. Skapar man 5st tomma 100MB filer, så kan man skapa en zfs raid utav dem. Sen kan man lägga till 5 filer till, för att öka raidet.

[Unregisteredc96d6be8]

• 0

@Sissel

Visst är det intressant att få en stabilare dator med ECC RAM och tillförlitligare diskar!

När det gäller att öka antalet diskar i zfs, så går det utmärkt dock. När man bygger ett raid i zfs, så använder man kanske 6 diskar till att bygga det. Man kan utöka sitt raid, genom att lägga till ett gäng diskar till. Man kan alltså lägga till t.ex. 6 diskar till, så raidet består av 12 diskar. Men man kan inte ändra från 6 till 7 diskar. Man lägger till hela grupper av diskar. Alternativt byter man t.ex. 1TB disk mot 2TB disk och reparerar raidet. Sen upprepar man för varje disk, och då har raidet växt.


Man behöver inte heller 6GB RAM. Folk har kört zfs med 1GB RAM, med pentium 4 cpuer. Man kan ju prova att installera freebsd/opensolaris i virtualbox och skapa ett raid mha filer. Skapar man 5st tomma 100MB filer, så kan man skapa en zfs raid utav dem. Sen kan man lägga till 5 filer till, för att öka raidet.

Går säkert, jag har bara kollat freenas 8 att installera en ren freebsd/opensolarius är inte aktuellt, räcker med att jag försöker lära mig linux. Vill heller inte låsa upp mig till att vara tvungen att sätta i flera lika diskar samtidigt, min server består av ett gytter av storlekar och modeller på diskar. Vet inte ens om mitt moderkort stödjer ecc, står inget om det i handboken iaf.

[Unregistered277056c3]

• 0

Jag tror du har rätt, det har antagligen inget med bitröta att göra. Men däremot råkade han ut för data korruption, och en bra lösning ska fånga alla datakorrutionsfel, inklusive bitröta. zfs hade detekterat och korrigerat problemet omedelbart.

Det finns bara EN lösning som har en chans att klara att man bryter strömmen till burken. UPS...

[tyve]

• 0

Men just studien av MS, hittar jag inte igen. Jag hoppas dock att det är tydligt och klart, att man får datakorruption i RAM på datorer. Att det finns ett skäl att man använder ECC RAM. Och varför skulle inte hårddiskar råka ut för samma problem?

För att hårddiskar använder ECC? Sen vet jag att du inte anser att det räcker eftersom man faktiskt kan få fel ändå men risken är så liten att det finns många andra fel som är mycket mer relevanta för de allra flesta.

Jag håller med dig om att problemet inte är så viktigt för hemanvändare. Men jobbar man på ett företag bör man vara medveten om problemet, och använda ECC RAM på alla sina servrar. Och helst även en lagringslösning som motverkar datakorruption på diskar.

Jag jobbar på ett företag. Vi har ECC minnen på alla servrar. Vi använder enterprise diskar. Vi har ett backupsystem som verifierar backuper mot checksummor. Däremot gör vi ingen kontroll av datat (uppåt 10 TB) som ligger i lagringssystemet på RAID-50. Därför har jag funderat vad ett eller ett par tysta bitfel skulle ställa till med. Det jag har kommit fram till är att skadan skulle bli mycket liten. De flesta system har olika sätt att reparera sig eller så körs det konsistenskontroller i själva systemet. I annat fall är det data som inte är så känslig för bitfel.

Dessa filer var så gamla att jag inte hade några andra backupper. Det var de filer jag hade.

Jaha, då var det inga bra exempel. Att man kan förlora data på olika sätt är ingen nyhet. Det du har sagt är att vi ska vara oroliga trots att vi har backuper.

CERN undersökte många olika lagringssystem med avseende på datakorruption. De skriver att även dyra Enterprise lösningar råkar ut för datakorruption. Att man bör använda checksummor. CERN skrev kontinuerligt ett känt bitmönster på sina lagringsservrar, och efter 3 veckor, undersökte de sina lagringsservrar (Linux rackservrar med hårdvaruraid) och upptäckte att bitmönstret var inte konsistent. Det var fel i bitmönstret.

Enligt den CERN-rapport du länkat till har de undersökt tillförlitligheten i sina miljö, inte många olika lagringssytem. De har troligen så stora datamängder att de inte kan ha backup på allt. De nämner inte backuper i rapporten. De måste alltså ha väldigt hög tillförlitlighet på sitt data men vi som har backup kan återställa felaktig data.

Japp. De undersökte flera lösningar, och känner att ZFS uppfyller deras krav på säkerhet. Jag tror CERN har höga krav. Det som duger åt CERN, duger nog även åt mig
...
Så det verkar som att både jag och många andra än MS tar datakorruption på allvar, även om många här hånar mig för att uppmärksamma folk på det. Fler och fler ser behovet av zfs liknande filsystem.

Bra att det kommer fler alternativ för de som har dessa behov. Det jag "hånar" är att du blandar ihop alla möjliga fel som kan uppstå i någon form av försök att göra det här till ett större problem än vad det är.

[sissel]

• 0

Vet inte ens om mitt moderkort stödjer ecc, står inget om det i handboken iaf.

Det är bara Intel Xeon server cpuer som stödjer ECC RAM, när vi pratar Intel. AMD har flera cpuer som stödjer ECC RAM, som inte är server cpuer. Tillförlitlighet kostar. Men det kanske beror på att det är främst företagen som är beroende av tillförlitlighet, och företag har råd att betala.

Det finns bara EN lösning som har en chans att klara att man bryter strömmen till burken. UPS...

zfs klarar av strömavbrott utan problem. Antag att du ändrar på en fil. När zfs skriver data så ligger all gammal data kvar, helt orörd. Det nya ändrade datat, skrivs ned på ett helt nytt ställe på disken. Som absolut sista steg i skrivningen, flyttas diskens pekare att peka om på det nya datat. Det gamla datat och det nya datat, samexisterar alltid på disken. Därför kan du backa tillbaka i tiden, om du vill. Detta kallas Copy-On-Write.

Antag nu att strömmen går, mitt i en skrivning. Då har inte pekaren hunnit peka om på det nya datat, den pekar fortfarande på det gamla datat. Så disken är konsistent, och allt är bra. Därför har inte zfs något som heter fsck, eller chskdsk. zfs behöver inget sånt. Disken är alltid intakt och konsistent.

Antag att du istället kör ntfs, och strömmen går mitt i en ändring. Då har halva filen uppdaterats, men andra halvan är original. ntfs försöker ju uppdatera originalfilen på plats. Då blir det problem med disken, den är inkonsistent och man måste köra chkdsk, eller fsck för att kolla journalloggen och försöka ställa allt till rätta. Detta kan inte inträffa med zfs, eftersom den alltid jobbar med en kopia. Typ.

För att hårddiskar använder ECC? Sen vet jag att du inte anser att det räcker eftersom man faktiskt kan få fel ändå men risken är så liten att det finns många andra fel som är mycket mer relevanta för de allra flesta.

Som vi konstaterat så korrigerar inte diskens ECC alla fel. Det är bara att se på specifikationerna på valfri Enterprise server disk, typiskt är 1 fel per 10^16 bitar. Men visst finns det många andra felkällor än disken själv. T.ex. höga ljud. Om du väsnas tillräckligt högt bredvid en hårddisk så får disken läsproblem, detta är ju egentligen självklart. Höga ljud är ju vibrationer, och vibrationer är inte bra för diskar, vilket alla känner till.

Men det spelar egentligen ingen roll hur bra diskars ECC mekanism är, eller hur hög musik man spelar bredvid diskar - det viktiga är att det skadar inte att köra en lösning som fångar ALLA typer av datakorruption; ECC problem, höga ljud, bitröta, buggar i firmware, sata kabeln glappar lite lite lite grand, strömspikar, etc. zfs detekterar omedelbart alla dessa fel, och även alla andra typer. Detta är skälet att CERN valde zfs, efter utvärdering av massor av lagringslösningar (även tokdyra Enterpriselösningar)

Jag jobbar på ett företag. Vi har ECC minnen på alla servrar. Vi använder enterprise diskar. Vi har ett backupsystem som verifierar backuper mot checksummor. Däremot gör vi ingen kontroll av datat (uppåt 10 TB) som ligger i lagringssystemet på RAID-50. Därför har jag funderat vad ett eller ett par tysta bitfel skulle ställa till med. Det jag har kommit fram till är att skadan skulle bli mycket liten. De flesta system har olika sätt att reparera sig eller så körs det konsistenskontroller i själva systemet. I annat fall är det data som inte är så känslig för bitfel.

Att ni använder ECC är ju bra, och visar att ni är seriösa med era servrar. Att ni använder Enterprise diskar är ju också bra. Men det är ju inte riktigt korrekt att tro att de flesta system har olika sätt att reparera sig eller att de kör konsistenskontroller. Som jag visat med många länkar, så stämmer inte det. Problemet är att systemen kan inte ens detektera alla typer av fel. De kan reparera vissa fel, men inte ens detektera alla felen. De detekterar bara en strikt delmängd av alla fel som kan uppkomma. Detta trodde jag vi var överens om? T.ex. hårdvaruraid brister fullständigt när det gäller konsistenskontroller - vilket jag visat länkar om.

Sen är det förstås så att företag har olika verksamheter. Vissa kanske inte bryr sig om några bitar flippas. Andra kanske är nojiga och bryr sig väldigt mycket om det. Det beror på vad ens företag sysslar med. T.ex. Amazons molntjänst S3, rapporterade om datakorruption nyligen. Så man kanske ska vara lite försiktig med att lägga upp sina filer i molnet.

Jaha, då var det inga bra exempel. Att man kan förlora data på olika sätt är ingen nyhet. Det du har sagt är att vi ska vara oroliga trots att vi har backuper.

Ja, om man bryr sig om data korruption.

Enligt den CERN-rapport du länkat till har de undersökt tillförlitligheten i sina miljö, inte många olika lagringssytem. De har troligen så stora datamängder att de inte kan ha backup på allt. De nämner inte backuper i rapporten. De måste alltså ha väldigt hög tillförlitlighet på sitt data men vi som har backup kan återställa felaktig data.

Jag har läst en annan CERN rapport där de utvärderade flera olika lagringslösningar, och de kom fram till att data korruption uppkommer i alla system "oavsett pris". Dvs, även mycket dyra high end lösningar får datakorruption. Därför valde de zfs som "löser alla dessa problem".

Bra att det kommer fler alternativ för de som har dessa behov. Det jag "hånar" är att du blandar ihop alla möjliga fel som kan uppstå i någon form av försök att göra det här till ett större problem än vad det är.

Du får håna mig hur mycket du vill. Om ni på erat företag inte har en affärskritisk verksamhet, så kanske data korruption inte är så viktigt för er. T.ex. jobbar man i grafik branschen så kanske det inte gör så mycket om man lite bitar flippas i råfilm. Och som folk påpekat, så kommer råfilmen ta upp det mesta av lagringsutrymmet, så när det väl inträffar bitflippar, så är chansen stor att det är råfilmen som påverkas. Men jobbar man t.ex. i finansbranschen så kanske man har andra prioriteringar.

Angående att jag varit lite otydlig när jag skriver stora mängder text, du drar alltså slutsatsen att alla forskningsrapporter kan man inte ta på allvar? Om min grammatik är felaktig, drar du då slutsatsen att man inte kan lita på de forskare, som jag länkar vidare till?

Redigerat av sissel, 07 February 2012 - 10:17.

[Unregistered277056c3]

• 0

...zfs klarar av strömavbrott utan problem. Antag att du ändrar på en fil. När zfs skriver data så ligger all gammal data kvar, helt orörd. Det nya ändrade datat, skrivs ned på ett helt nytt ställe på disken. Som absolut sista steg i skrivningen, flyttas diskens pekare att peka om på det nya datat. Det gamla datat och det nya datat, samexisterar alltid på disken. Därför kan du backa tillbaka i tiden, om du vill. Detta kallas Copy-On-Write.

Antag nu att strömmen går, mitt i en skrivning. Då har inte pekaren hunnit peka om på det nya datat, den pekar fortfarande på det gamla datat. Så disken är konsistent, och allt är bra. Därför har inte zfs något som heter fsck, eller chskdsk. zfs behöver inget sånt. Disken är alltid intakt och konsistent...

En ren kopiering/modifiering av fil på ett och samma diskkluster funkar bra ja, men om det exempelvis är ett nytt dokument, databaskörning med flera källor eller nåt, dvs NY, unik data som inte redan finns på diskarna... Slocknar burken så dör delar av informationen i minnet/cachen och du har lik förbannat en halv fil på disk... Inte ens zfs hjälper då, men en UPS gör såklart...

Man måste tänka lite kritiskt...

Redigerat av Unregistered277056c3, 07 February 2012 - 10:33.

[sissel]

• 0

Ah, jo det förstås. Jag trodde vi pratade om datakorruption och hur bra zfs klarar av att hantera t.ex. strömavbrott. Men självklart klarar inte zfs att hålla datorn igång om strömmen upphört. Däremot, andra filsystem kommer ju ha problem med dataintegritet och korrupt state på disken (förutom att de inte kan hålla igång datorn när strömmen upphört).

Däremot är ju inte UPS en garanti för att data korruption upphör.

Redigerat av sissel, 07 February 2012 - 11:35.

[tyve]

• 0

Jaha, då var det inga bra exempel. Att man kan förlora data på olika sätt är ingen nyhet. Det du har sagt är att vi ska vara oroliga trots att vi har backuper.

Ja, om man bryr sig om data korruption.

Men det kokar ner till att den enda data korruption som man behöver vara orolig för är den som drabbar alla kopior jag har av en fil. Den filen måste dessutom vara känslig för datakorruption. Jag anser att sannolikheten för att båda dessa villkor ska vara uppfyllda är för liten för att den ska vara relevant.

Jag tycker inte du lyckats visa, trots alla länkar och påståenden, att det är tillräckligt troligt att det inträffar så att man ska oroa sig för det. Det beror till stor del på att du blandar in datakorruption som man kan skydda sig mot med bra backuprutiner med datakorruption som inte märks och kommer med på kopiorna.

Ett exempel på sammanblandning är felvärdet på 1 bit per 10^16 som är ett värde som upptäcks av ECC och rapporteras till operativsystemet. Får man det läsfelet kan man hämta filen från backup.

[Unregistered277056c3]

• 0

Ah, jo det förstås. Jag trodde vi pratade om datakorruption och hur bra zfs klarar av att hantera t.ex. strömavbrott. Men självklart klarar inte zfs att hålla datorn igång om strömmen upphört. Däremot, andra filsystem kommer ju ha problem med dataintegritet och korrupt state på disken (förutom att de inte kan hålla igång datorn när strömmen upphört).

Däremot är ju inte UPS en garanti för att data korruption upphör.

Hum...

Jag påpekade att inte ens zfs kan skriva data korrekt om kraften försvinner, och att man då blir av med grejor om det är ny eller modifierad data som alltså inte redan "finns på disken". Undantaget är "ren kopiering", då det funkar som du beskrivit.

Ibland tror jag att du inte förstår vad jag skriver, eller möjligtvis läser lite för fort...

[sissel]

• 0

Jag tycker inte du lyckats visa, trots alla länkar och påståenden, att det är tillräckligt troligt att det inträffar så att man ska oroa sig för det. Det beror till stor del på att du blandar in datakorruption som man kan skydda sig mot med bra backuprutiner med datakorruption som inte märks och kommer med på kopiorna.

Jag tycker inte det är så viktigt vilken typ av datakorruption som inträffar, om det är bitröta, buggar i firmware, höga ljud, strömspikar, etc. Huvudsaken är att det är datakorruption. Det kommer alltid bli datakorruption, det finns många felkällor. Det spelar ingen roll hur väl man klassificerar felen. Det är väl oväsentligt om du förlorar data pga bitröta eller pga höga ljud? Det viktiga är att du förlorat data. Därför bör man använda en lösning som skyddar mot ALLA sorters datakorruption, och inte välja en lösning som bara skyddar mot t.ex. strömspikar. Här är det en kille som skriker högt bredvid några hårddiskar, och de störs kraftigt (vilket man kan se eftersom servern kör zfs och dtrace som detekterar alla problem)
http://www.youtube.com/watch?v=tDacjrSCeq4

Angående om jag lyckats visa att datakorruption förrekommer i högre grad, eller inte. Ja, du får avfärda alla forskningsartiklar om du vill, det är helt ok. MS anser detta vara ett så stort problem att de bygger ett helt nytt filsystem i Windows 8, ntfs duger inte längre. btrfs tar också detta på allvar. Och freebsd folk, och Mac, etc. Vanligtvis brukar det vara så att forskningsartiklar väger ganska tungt.

Vad skulle övertyga dig att datakorruption är ett begynnande problem? Forskningartiklar? Nej, det duger inte. Studier från CERN? Nej det duger inte heller. Studier från företag såsom NetApp och Oracle? Nej, det duger inte heller. Jag vet faktiskt inte vad för typ av bevis du efterfrågar? Du verkar svår att övertyga?

Jag påpekade att inte ens zfs kan skriva data korrekt om kraften försvinner, och att man då blir av med grejor om det är ny eller modifierad data som alltså inte redan "finns på disken". Undantaget är "ren kopiering", då det funkar som du beskrivit.

Ibland tror jag att du inte förstår vad jag skriver, eller möjligtvis läser lite för fort...

Nu förstår jag faktiskt inte vad du menar. Jag har läst ditt inlägg flera ggr. Kan du försöka förklara igen?

Om strömmen går mitt i en skrivning, så kan inte zfs skriva klart. Det är ju självklart. Men disken blir inte förstörd, inte heller får den korruptionsproblem. Allt är bra och datat är intakt, det är bara det att den senaste skrivningen inte kom med på disken. Man får alltså skriva ned filen igen, när man bootat om.

Om vi pratar om andra lagringslösningar så kan disken bli korrupt, om vi pratar hårdvaruraid så kan du t.om. tappa alla dina data på hela raidet (write-hole-error), det är därför man måste använda batteri på hårdvaruraid kort. Därför behövs fsck/chkdsk. Men självklart kan inte heller dessa andra lösningar skriva klart, om strömmen går mitt i en skrivning.

Eller menar du att ingen lagringslösning är immun mot strömavbrott? Ja, det är ju sant och det har du rätt i. För att gardera sig mot strömavbrott bör man använda UPS, helt korrekt anmärkning.

Redigerat av sissel, 07 February 2012 - 15:51.

[Unregisteredc96d6be8]

• 0

Jag tycker inte det är så viktigt vilken typ av datakorruption som inträffar, om det är bitröta, buggar i firmware, höga ljud, strömspikar, etc. Huvudsaken är att det är datakorruption. Det kommer alltid bli datakorruption, det finns många felkällor. Det spelar ingen roll hur väl man klassificerar felen. Det är väl oväsentligt om du förlorar data pga bitröta eller pga höga ljud? Det viktiga är att du förlorat data. Därför bör man använda en lösning som skyddar mot ALLA sorters datakorruption, och inte välja en lösning som bara skyddar mot t.ex. strömspikar. Här är det en kille som skriker högt bredvid några hårddiskar, och de störs kraftigt (vilket man kan se eftersom servern kör zfs och dtrace som detekterar alla problem)

Det är väl ganska viktigt att veta vilken typ av fel som skapar problemet, även om zfs skyddar mot dataförlust, så kan det ju ge upphov till andra problem och om det är strömspikar, ljud vibrationer så kan man eliminera felkällorna och därmed ytterliggare säkra upp sitt system och få ökad prestanda, särskilt om det är återkommande fel. Strömspikar kan ju tex i värsta fall skada hårdvara och det kan ge större dataförlust än ett bitfel

[Unregistered277056c3]

• 0

Om strömmen går mitt i en skrivning, så kan inte zfs skriva klart. Det är ju självklart. Men disken blir inte förstörd, inte heller får den korruptionsproblem. Allt är bra och datat är intakt, det är bara det att den senaste skrivningen inte kom med på disken. Man får alltså skriva ned filen igen, när man bootat om.

Eller menar du att ingen lagringslösning är immun mot strömavbrott? Ja, det är ju sant och det har du rätt i. För att gardera sig mot strömavbrott bör man använda UPS, helt korrekt anmärkning.

Om man bryter strömmen till en disk medan den håller på att skriva så kan ungefär vad som helst hända, t ex att den pajar ett gäng sektorer på samma eller intilliggande cylinder. Detta alldeles oavsett filsystem, raidlösning osv. Enda lösningen är UPS, vilket i princip medför att vilket skruttigt filsystem som helst inte riskerar att paja ens vid strömavbrott, eftersom disksystemet hinner "avsluta" skrivningen på ett korrekt sätt, även om all data kanske inte hinner med...

[sissel]

• 0

så kan man eliminera felkällorna och därmed ytterliggare säkra upp sitt system

Jag påstår att det inte går att eliminera alla felkällor. Det torde vara omöjligt eftersom det finns så många olika felkällor. Somliga av felkällorna är okända också, somliga tänker du inte ens på. T.ex problemet med höga ljud. Antag att du har ups, skydd mot firmware, etc - så kanske du inte tänker på att det är en högtalare precis bredvid dina diskar. Man kan inte tänka på allting, det går inte. Men zfs har checksummor, så det spelar ingen roll vilka typer av fel som inträffar, både kända och okända, zfs detekterar omedelbart alla felen ändå.

Om man bryter strömmen till en disk medan den håller på att skriva så kan ungefär vad som helst hända, t ex att den pajar ett gäng sektorer på samma eller intilliggande cylinder.

Ja, om det är som du säger: att när strömmen upphör så kan disken förstöras rent fysiskt. Om detta kan inträffa så hjälper inte ens zfs.

Men frågan är om det kan inträffa. Jag har aldrig hört talas om nåt sånt. Har du länkar eller nåt sånt, så kan man få lära sig lite mera om detta? Detta verkar vara ett problem jag inte känt till. Många byter ju diskar under drift, via hot swap, så många diskar är gjorda för att strömmen ska brytas plötsligt - det borde inte leda till fysisk förstöring av disken. Det låter ytterst märkligt. Jag har aldrig hört disktillverkare säga att disken kan förstöras fysiskt om man inte använder UPS. Kan du återge nån anekdot, länk eller helst; forskningsartikel?

[Unregisteredc96d6be8]

• 0

@Sissel

Här står lite om strömproblem och diskar

http://www.dtidata.c...urge-brown-out/

[tyve]

• 0

Jag tycker inte det är så viktigt vilken typ av datakorruption som inträffar, om det är bitröta, buggar i firmware, höga ljud, strömspikar, etc. Huvudsaken är att det är datakorruption. Det kommer alltid bli datakorruption, det finns många felkällor. Det spelar ingen roll hur väl man klassificerar felen. Det är väl oväsentligt om du förlorar data pga bitröta eller pga höga ljud? Det viktiga är att du förlorat data.

Återigen, jag har backup och förlorar därför ingen data.

Därför bör man använda en lösning som skyddar mot ALLA sorters datakorruption, och inte välja en lösning som bara skyddar mot t.ex. strömspikar.

Du menar att zfs skyddar mot allt? Att zfs kan reparera en hårddisk oavsett hur många bitar eller sektorer som inte går att läsa?

...
Du verkar svår att övertyga?

Japp och jag tror jag måste byta taktik och istället förklara för dig vad zfs inte klarar av t.ex. stöld, brand, användarfel, virusangrepp.

[sissel]

• 0

Här står lite om strömproblem och diskar
http://www.dtidata.c...urge-brown-out/

Oj, detta visste jag inte! Tack som f-n att du delar med dig av din kunskap. Jag vet att om blixten slår ned i huset, så förstörs hela datorn. Det finns ingen UPS som skyddar mot ett riktigt blixtnedslag. Ett strömskydd kanske skyddar mot spikar uppemot 4000 joule. En blixt innehåller flera miljoner joule. Så detta är välkänt. Jag visste dock inte att om strömmen går, så kan disken förstöras rent fysiskt.

Det finns flera kommentarer om att de använde fel voltantal, strömmen slog ned, etc - och då förstördes disken. Detta är inget konstigt. Men, det finns några få som berättar att när strömmen gick, så förstördes disken - detta var nytt för mig. Dock verkar det väldigt sällsynt, jag har sysslat med datorer i många år, men aldrig hört talas om detta tidigare.

Jag håller nu på att designa en lösning med zfs, ECC ram, och trodde det räckte. Men nu måste jag designa om min hemma lösning. Undrar hur man ska göra nu? Hmmm.... Jag tänkte använda Intel Xeon Ivy Bridge, ECC RAM, vanliga sata diskar med zfs. Strömmen måste jag tänka lite på... Hur ska man skydda sig mot det? Nån som har förslag?

Återigen, jag har backup och förlorar därför ingen data.

Hur vet du att din backup inte har råkat ut för bitröta?

Du menar att zfs skyddar mot allt? Att zfs kan reparera en hårddisk oavsett hur många bitar eller sektorer som inte går att läsa?

Normalt kör man zfs i raid. Så om en disk går sönder, så byter man till en ny disk och alla data repareras automatiskt.

Japp och jag tror jag måste byta taktik och istället förklara för dig vad zfs inte klarar av t.ex. stöld, brand, användarfel, virusangrepp.

Självklart skyddar inte zfs mot t.ex. inbrottstjuvar, blixtnedslag, jordbävningar, brand, etc. Dvs, zfs skyddar inte mot yttre faror som hör till den fysiska världen. Faror inom IT skyddar zfs mot, t.ex. virusangrepp, användarfel, etc - allt detta hör till faror inom IT, och såna faror är inga problem för zfs.

Redigerat av sissel, 09 February 2012 - 10:20.

[BitterMelon]

• 0

Självklart skyddar inte zfs mot t.ex. inbrottstjuvar, blixtnedslag, jordbävningar, brand, etc. Dvs, zfs skyddar inte mot yttre faror som hör till den fysiska världen. Faror inom IT skyddar zfs mot, t.ex. virusangrepp, användarfel, etc - allt detta hör till faror inom IT, och såna faror är inga problem för zfs.

Hur gör ZFS det hade du tänkt dig?

ZFS är inte universalmedicin, den skyddar mot en hel hoper saker, men definitivt inte mot allt. De du nämner ovan är typiska saker som det inte skyddar mot (om du inte har automatisk snapshotting uppsatt möjligen, om ens då).

[Unregisteredc96d6be8]

• 0

@sissel

Börja med att göra en analys, dels vilka hot som kan finnas mot din lagring, dels vad din data är värt kontra pris för att skydda den och dels användarvänlighet.

Grundläggande saker du kan göra.
Ups (finns billiga) som skyddar mot vanliga strömspikar och kortare bortfall av ström.
Gummiupphängda diskar för att i möjligaste mån skydda mot vibrationer minskar även ljudet från servern om det behövs
Placering så du dels har kylning, dels skyddar i möjligaste mån mot andra yttre faktorer
Zfs
Se till att diskarna och har kylning osv

[tyve]

• 0

Hur ska man skydda sig mot det? Nån som har förslag?

UPS som är av typen "

Online Double Conversion"

skyddar mycket väl mot blixtnedslag men även billigare UPS:er klarar blixtnedslag i ledningsnätet bara de inte är direkt i ditt eget hus men då hamnar blixten oftast i TV-antennen...

Hur vet du att din backup inte har råkat ut för bitröta?

Ja, det var ju inte helt oväntat att du skulle svara så och som jag skrev tidigare "Men det kokar ner till att den enda data korruption som man behöver vara orolig för är den som drabbar alla kopior jag har av en fil. Den filen måste dessutom vara känslig för datakorruption. Jag anser att sannolikheten för att båda dessa villkor ska vara uppfyllda är för liten för att den ska vara relevant."

Normalt kör man zfs i raid. Så om en disk går sönder, så byter man till en ny disk och alla data repareras automatiskt.

Men om en disk går sönder och en annan samtidigt har felaktiga sektorer?

Självklart skyddar inte zfs mot t.ex. inbrottstjuvar, blixtnedslag, jordbävningar, brand, etc. Dvs, zfs skyddar inte mot yttre faror som hör till den fysiska världen. Faror inom IT skyddar zfs mot, t.ex. virusangrepp, användarfel, etc - allt detta hör till faror inom IT, och såna faror är inga problem för zfs.

Okej, ett scenario som jag faktiskt råkat ut för: En användare fick virus som skrev sönder alla jpg-bilder på filservern. Det upptäcktes efter ett par dagar. Hur räddar zfs jpg-bilderna?

Ett annat scenario jag haft: En användare kommer in och önskar få tillbaka en fil som tagits bort för 2 månader sedan.

[sissel]

• 0

UPS som är av typen "

Online Double Conversion"

skyddar mycket väl mot blixtnedslag men även billigare UPS:er klarar blixtnedslag i ledningsnätet bara de inte är direkt i ditt eget hus men då hamnar blixten oftast i TV-antennen...

Jag har kollat runt lite nu, efter att läst era inlägg här. Jag tittade på detta överspänningsskydd
http://www.komplett....aspx?sku=301107
den skyddar upp emot 4000 joule. En blixt har flera miljoner joule, så det räcker inte vid en direktträff. Inget överspänningskydd hjälper mot en direktträff. Menar du att en UPS skyddar mot en direktträff av blixten? Det låter o-troligt?

Ja, det var ju inte helt oväntat att du skulle svara så och som jag skrev tidigare "Men det kokar ner till att den enda data korruption som man behöver vara orolig för är den som drabbar alla kopior jag har av en fil. Den filen måste dessutom vara känslig för datakorruption. Jag anser att sannolikheten för att båda dessa villkor ska vara uppfyllda är för liten för att den ska vara relevant."

Jag håller med dig om detta.

Men om en disk går sönder och en annan samtidigt har felaktiga sektorer?

Man kör raidz2 (dvs raid-6) så två diskar kan gå sönder utan problem. Men jag kommer att köra raidz3, dvs tre diskar kan gå sönder utan problem. Det visar sig att med stora hårddiskar så tar det lång tid att reparera ett raid.

Antag att en 3TB disk går sönder i ditt raid, och du ska reparera raidet. Så du byter ut disken mot en ny och låter den repareras. Då kan det ta lång tid, kanske 1-2 dagar. Under tiden stressas de andra diskarna mycket. Om du då får läsfel på en disk, så har du tappat alla dina data i hela raidet. I framtiden, när vi har 5TB diskar eller 8TB diskar, så kan det ta uppemot en vecka kanske. Problemet är att diskarna blivit mycket större, men inte mycket snabbare. Ju större diskarna är, desto längre tid tar det att reparera raidet. Därför bör man undvika raid-5 (dvs endast en disk kan gå sönder). Eftersom man inte har några marginaler när en disk strular. Därför bör man köra raid-6 eller ännu hellre, raidz3 som tillåter tre diskar att krascha. Att tillåta tre diskar att krascha, finns bara i zfs. Ingen annan lösning stödjer tre kraschade/läsfel diskar. Detta är skälet att en del säger att raid-5 är förlegat och bör undvikas. Det är inte mycket säkrare än raid-0. Mao, om man har stora diskar så ska man undvika raid-5 och istället köra på raid-6, eller raidz3.
http://www.zdnet.com...ing-in-2009/162

Okej, ett scenario som jag faktiskt råkat ut för: En användare fick virus som skrev sönder alla jpg-bilder på filservern. Det upptäcktes efter ett par dagar. Hur räddar zfs jpg-bilderna?

Ett annat scenario jag haft: En användare kommer in och önskar få tillbaka en fil som tagits bort för 2 månader sedan.

Enkelt. zfs har Copy-On-Write. Om du gör en liten ändring av en fil, så sparas ändringen som ett par nya block på ett annat ställe på disken. Den gamla filen ligger kvar. Så om du t.ex. har råfilm på 50GB, och gör tio små ändringar efter varandra, där varje ändring tar 10MB styck, så behöver du inte spara hela filen 10 ggr med zfs. Med ntfs måste du spara filen 10 ggr, och det tar upp 50GB x 10 = 500GB totalt diskutrymme. Med zfs så tar det 50GB + 10 x 10MB = 50,1GB diskutrymme. Endast ändringarna sparas. Detta sker helt automatiskt, och i full hastighet - förutsatt att du gör en snapshot mellan varje sparning.

En snapshot säger till zfs, att låsa den gamla filen mot ändringar och börja skriva på ett nytt ställe på disken. Detta är tokgrymt om man använder det på systemdisken. Innan en uppgradering/patch av min Solaris installation så gör jag en snapshot. När jag bootar så får jag en meny i GRUB med alla snapshots, då kan jag välja vilken snapshot jag vill boota från. Antag att min patch skiter sig, eller jag råkat få virus eller radera en viktig fil. Då bootar jag om till en tidigare snapshot och raderar det senaste snapshotet - så blir jag av med viruset. Jag bootar alltså om till ett känt och testat och stabilt state, som jag väljer ifrån vid boot. Jag har en snapshot direkt efter installationen, helt ren. Om jag vill ominstallera, så kan jag radera alla nya snapshots istället.

Men jag kan även snapshotta användarkataloger när jag vill. En snubbe tog automatiska snapshots varje 10 sekund, och hade typ 30.000 snapshots. De tog totalt 4GB utrymme, eftersom endast ändringarna lagrades. Snapshots funkar precis som i Time Machine, jag kan gå fram och tillbaka i tiden. Så om en användare vill ha en gammal fil, så backar han bara i tiden genom att gå till rätt katalog (varje snapshot visas som en katalog i windows för användaren) och kopierar tillbaka rätt fil.

Jag har t.ex. skapat en virtuell maskin som är testad och uppsatt och klar. Den gör jag en snapshot på, varje klon sparar endast ändringarna. Så jag har en Master och klonar den. Min tjej arbetar i sin klon, och jag i min samtidigt. Så jag sparar utrymme. Att klona kan man även göra i t.ex. VirtualBox eller VMware, men jag har hört att det går långsamt efter ett tag. I zfs går det med full hastighet, och jag kan klona vad jag vill. Inte bara VMs. Jag kan deploya en klon på någon sekund. Om 10 personer vill ha en testad miljö, så klonar jag bara en master.

NACKDELEN, är att varje snapshot tar diskutrymme. Om en person har gjort en snapshot och senare raderar en 10GB fil, så kommer filen inte försvinna från disken. Den finns kvar, pga snapshoten. Om man raderar snapshoten, så kommer filen försvinna och utrymme frigöras. Men, diskutrymme är billigt, och dessutom lagras inte så mycket, då endast ändringarna lagras.

Hur gör ZFS det hade du tänkt dig?

ZFS är inte universalmedicin, den skyddar mot en hel hoper saker, men definitivt inte mot allt. De du nämner ovan är typiska saker som det inte skyddar mot (om du inte har automatisk snapshotting uppsatt möjligen, om ens då).

Jag använder automatisk snapshotting, precis som du listat ut.

@sissel

Börja med att göra en analys, dels vilka hot som kan finnas mot din lagring, dels vad din data är värt kontra pris för att skydda den och dels användarvänlighet.

Grundläggande saker du kan göra.
Ups (finns billiga) som skyddar mot vanliga strömspikar och kortare bortfall av ström.
Gummiupphängda diskar för att i möjligaste mån skydda mot vibrationer minskar även ljudet från servern om det behövs
Placering så du dels har kylning, dels skyddar i möjligaste mån mot andra yttre faktorer
Zfs
Se till att diskarna och har kylning osv

Ok, får fundera på det. Men mina data är inte värda mycket, det är mest bara lite privata foton. Men jag vill ha det säkert. Varför? Jo, det kostar inte mycket att säkra upp sina data. ECC RAM är billigt. zfs är gratis. Jag behöver inget hårdvaruraid kort, såna stör zfs och ska undvikas. Så det kostar knappt något att i princip få en lika säker lösning som CERN har valt. Varför ska jag inte göra mig det lilla omaket extra? Man kan bygga en zfs server med några sata diskar och lite ECC RAM, det räcker.

Dessutom är zfs helt OS agnostiskt. Dvs, om jag har ett zfs raid, så kan jag byta OS hur mycket jag vill. zfs är skapat för att funka på alla OS, det är helt endian neutralt. Om jag tröttnar på Solaris, så kan jag byta till FreeBSD, eller till Mac OS X, eller till Linux (via Fuse). Alla dessa OS kan läsa mitt zfs raid utan problem. Om jag hade använt hårdvaruraid kort (som inte skyddar mot datakorruption), så hade det varit jobbigt. Då kan jag inte byta OS hur jag vill, det måste finnas drivrutiner. Det behövs inte när man använder zfs, ifall bara OSet kan läsa SATA diskar så räcker det.

UPS ska jag fundera på. Nån som vet om såna skyddar mot blixtnedslag? En kul grej jag hörde, folk påstår att ljudet på deras stereo har blivit bättre efter att skaffat ett överspänningsskydd som slätar ut strömmen. Det blir inga spikar, och strömmen blir renare och ljudet förbättras. Nån som vet mera om detta? Är det bara snack? JAg har inte sett några forskningsartiklar om detta, eller läst in mig.

[Unregistered277056c3]

• 0

...om det är som du säger: att när strömmen upphör så kan disken förstöras rent fysiskt. Om detta kan inträffa så hjälper inte ens zfs.

...Detta verkar vara ett problem jag inte känt till. Många byter ju diskar under drift, via hot swap, så många diskar är gjorda för att strömmen ska brytas plötsligt - det borde inte leda till fysisk förstöring av disken...

Lugn i trasorna!

Ingen har påstått att disken "kan förstöras rent fysiskt". Dina slutsatser går en smula för fort...

Det som kan hända är att huvudet fortsätter skriva en liten stund trots att levererad data inte är tillförlitlig, servo för huvudposition tappar låsningen, varvtalet sjunker osv.

Nuförtiden är det ganska ovanligt att huvudet plöjer fåror i diskytan, men att bryta strömmen vid skrivning till disken är absolut inte bra...

Hoppas det blev lite tydligare nu, eller?

[Unregisteredf2a7f9fd]

• 0

Jag skulle då inte offra så mycket diskutrymme som tex raidz3 för att ett error upstår efter 67GB.
Lite väl overkill och finns mycket viktigare faktorer att tänka på innan detta blir aktuellt i min mening.
De tär klart har du viktiga ritningar på hur man konstruerar en tidsmaskin så kanske det kan vara värt det.
I övrigt så kan man tex på alla moderna NASar tex säkerhetskopiera datat till ytterligare en NAS, extern lagring i diverse molntjänster (risken att alla dessa "backuper" ska vara korrupta är försumbar.

[tyve]

• 0

Jag har kollat runt lite nu, efter att läst era inlägg här. Jag tittade på detta överspänningsskydd
http://www.komplett....aspx?sku=301107
den skyddar upp emot 4000 joule. En blixt har flera miljoner joule, så det räcker inte vid en direktträff. Inget överspänningskydd hjälper mot en direktträff. Menar du att en UPS skyddar mot en direktträff av blixten? Det låter o-troligt?

Fast det skrev jag inte. Det normala är en träff i ledningsnätet och att spänningen sprids ut till en massa fastigheter och att belastningen på ditt uttag inte blir så stor.

Jag håller med dig om detta.

Trevligt, då kan jag och de allra flesta företag fortsätta som tidigare.

Man kör raidz2 (dvs raid-6) så två diskar kan gå sönder utan problem. Men jag kommer att köra raidz3, dvs tre diskar kan gå sönder utan problem. Det visar sig att med stora hårddiskar så tar det lång tid att reparera ett raid.
...

Enkelt. zfs har Copy-On-Write. Om du gör en liten ändring av en fil, så sparas ändringen ...

Mycket bra svarat, kom faktiskt fram till samma lösning när jag funderade lite mer men jag visste inte att det gick att sätta upp zfs så smidigt mot en Windowsklient. Egentligen blir det lite tokigt att argumentera mot zfs eftersom jag tycker zfs är en fantastiskt produkt. Med enkla medel kan man få en lösning med funktioner som tidigare bara funnits i enterprise lösningar i miljonklassen.

Vi byter till ett Dell/Compellent SAN på jobbet till sommaren och det kommer kosta en hel del men det vi betalar mest för är hårdvaran och supporten. Där blir det RAID-10, RAID-5 eller RAID-6 beroende på diskarnas storlek. Compellent är lite speciellt eftersom det kan mixa raid-nivåer på samma diskar. Läs gärna på om hur de virtualiserat lagringen http://www.compellen...ed-Storage.aspx

UPS ska jag fundera på. Nån som vet om såna skyddar mot blixtnedslag? En kul grej jag hörde, folk påstår att ljudet på deras stereo har blivit bättre efter att skaffat ett överspänningsskydd som slätar ut strömmen. Det blir inga spikar, och strömmen blir renare och ljudet förbättras. Nån som vet mera om detta? Är det bara snack? JAg har inte sett några forskningsartiklar om detta, eller läst in mig.

Kan tänkta mig det om man har dålig stabilitet på strömmen. Framför allt brusnivåer borde gå att få ner en del men det är mer en fråga för en annan del av forumet.

[tyve]

• 0

Lite andra intressanta saker jag hittade: Dels varför Harris uträkning bör tas med en nypa salt http://www.raidtips.com/raid5-ure.aspx sen en länk till några som testat tider för att reparera felande RAID-5 grupper om 6 st. 500 GB diskar http://wikibon.org/w...ce_Implications. Varje återbyggnad måste läsa 2,5 TB (5*0,5TB) och har gjorts minst 24 gånger. Totalt ha alltså minst 60 TB lästs och trots det har de inte misslyckats någon gång med att reparera diskarna. Enligt Harris matematik borde någon ha misslyckats och det är den som ligger till grund till en massa andra antaganden.

[spelevinken]

• 0

Tråden är intressant men har det inte spårat ur?, är inte risken för ett kometnedslag och att jordens befolkning försvinner lika stor?

[dunde]

• 0

Tråden är intressant men har det inte spårat ur?, är inte risken för ett kometnedslag och att jordens befolkning försvinner lika stor?

Den började väl lika utspårat med "bit-röta"...

[spelevinken]

• 0

Den började väl lika utspårat med "bit-röta"...

...tycker ändå att frågan i grunden är intressant men de senast inläggen känns helt absurda.... Vad händer om ohmen överstiger watten när brödrosten är igång och datorn är under nersläckning samtidigt som TV:n är igång och grannens katt mjauar och fullmånen lyser rakt på chassit?....om ni förstår mig rätt.

Som sagt vill på intet sätt avfärda frågeställningen men återigen, har det inte spårat ur?

[Unregistered577c6879]

• 0

Dr. Strangelove or: How I Learned to Stop Worrying and Love the Disk

[Unregisteredc96d6be8]

• 0

...tycker ändå att frågan i grunden är intressant men de senast inläggen känns helt absurda.... Vad händer om ohmen överstiger watten när brödrosten är igång och datorn är under nersläckning samtidigt som TV:n är igång och grannens katt mjauar och fullmånen lyser rakt på chassit?....om ni förstår mig rätt.

Som sagt vill på intet sätt avfärda frågeställningen men återigen, har det inte spårat ur?

Det beror ju på hur man ser det, jag har blivit av med en hel del prylar när blixten slagit ner i kopplingsstationen utanför huset. Så kunde jag hitta ett sätt att komma runt det som inte kostar en förmögenhet så skulle jag vara glad. Dock har mina diskar klarat sig, men lite moderkort, swichar, routrar, datorer och 2 förstärkare har gått åt skogen

[Unregistered277056c3]

• 0

...Självklart skyddar inte zfs mot t.ex. inbrottstjuvar, blixtnedslag, jordbävningar, brand, etc. Dvs, zfs skyddar inte mot yttre faror som hör till den fysiska världen. Faror inom IT skyddar zfs mot, t.ex. virusangrepp, användarfel, etc - allt detta hör till faror inom IT, och såna faror är inga problem för zfs.

Det finns massor av problem och felkällor som zfs i sig inte har någon påverkan alls på, men det är givetvis en god idé att försöka optimera säkerheten om man anser sig ha känslig data som är "värd att skyddas".

Sen är det inte alls särskilt givet vilken ände av tekniken det är vettigast att lägga krutet på för att förbättra säkerheten. Det är givetvis prio 1 att i första hand angripa de problem som statistiskt sett oftast orsakar dataförlust, och det är inte alltid disksystemen...

...tycker ändå att frågan i grunden är intressant men de senast inläggen känns helt absurda.... ...Som sagt vill på intet sätt avfärda frågeställningen men återigen, har det inte spårat ur?

Spårat ur vet jag inte, men ibland är det nog lätt att snöa in på komplexa problem och glömma bort de mest grundläggande frågorna och hur man löser dem...