Fejl i supercomputers backup-system sletter 77 terabyte forskningsdata

Jeg kan egentlig ikke huske, at jeg har set problemet omtalt i de (ret få) bøger om UNIX, jeg har læst (jeg arbejder ikke med UNIX-lignende systemer). Er det noget, der udtrykkeligt bliver nævnt, når man lærer om den slags OS'er?

Hvis man skulle nævne alle de tekniske detaljer og faldgruber i standardværktøjerne på Unix, så ville et sådan kursus ikke have tid til så meget andet. Man kan dog godt udlede denne opførsel af følgende principper:

• Unix låser (næsten) aldrig filer.
• Hvis en proces har en fildeskriptor svarende til en fil åben, og denne fil ændres, da vil processen se ændringen.

Derfor er det f.eks. potentielt farligt at ændre i kørende binaries og biblioteker, afhængigt af hvordan de har mappet filerne (mmap med MAP_PRIVATE giver desværre ikke garanti for fuld isolation). I stedet for at ændre en fil kan man også slette den og lave en ny med samme navn - det vil ikke påvirke processer der har den gamle fil åben.

Det usædvanlige ved specifikt shell script er at filens indhold bliver ved med at have betydning under hele kørslen. Alle andre fortolkede sprog jeg kan komme i tanke om læser hele filen fra starten af for at konstruere et syntakstræ i hukommelsen. Der findes sikkert undtagelser, men jeg håber jeg aldrig får behov for at lære om dem.

Sådan har det været siden unix/msdos blev udviklet (pre 1985).

Jeg kan egentlig ikke huske, at jeg har set problemet omtalt i de (ret få) bøger om UNIX, jeg har læst (jeg arbejder ikke med UNIX-lignende systemer). Er det noget, der udtrykkeligt bliver nævnt, når man lærer om den slags OS'er?

Ja. Det er uheldigt at shell-scripts og native programmer fungerer forskelligt på dette punkt.

Sådan har det været siden unix/msdos blev udviklet (pre 1985). Hvorfor fortaber sig i historien, men at et filnavn og et linjenr fylder mindre i hukommelsen end hele scriptet, det er svært at komme uden om.

Der er mere præstige i at udvikle nyt end i ar vedligeholde legacy, det er langt fra nyt.

At det kan være nyttigt at kunne stoppe en process (script eller image), så man kan ændre i programmet, inden det kører videre, skal man nok have prøvet for at vide.

Jeg fatter ikke at shells stadigvæk fungerer sådan, da jeg ikke kan tænke mig at der findes nogen brug af denne "feature" i godhedens tjeneste.

Bemærk at maskinen har 19PB effektiv storage! Data-tab skal naturligvis ikke ske, men backup af 19PB er ikke trivielt og race-conditions kan ske (det lyder til at være tilfældet her).

En sjov race condition: Man redigerede i et shell script mens det kørte, og da Unix shells ikke læser scripts ind i hukommelsen før de afvikles, men derimod læser linje-for-linje fra filen, så kan det gå galt. Jeg fatter ikke at shells stadigvæk fungerer sådan, da jeg ikke kan tænke mig at der findes nogen brug af denne "feature" i godhedens tjeneste.

Sådan kan det gå når man ikke trækker backup ud til proper tapes... og/eller ikke bruger en rigtig backup suite og/eller de rigtige specialister.. Tough shit...

Det var backupsystemet der fejlede og slettede kildefilerne. Det er svært at designe sig ud af netop denne fejlkilde (i hvert fald hvis man gerne vil have kildefilerne på et dyrt og meget hurtigt filsystem, så man ikke bare kan gemme alle skrivninger i ubegrænset tid).

Sådan kan det gå når man ikke trækker backup ud til proper tapes... og/eller ikke bruger en rigtig backup suite og/eller de rigtige specialister.. Tough shit...

Imponerende, under en 0,5% datatab.

Men der er nok nogle, som lige vil overveje næste opdatering af scriptet en ekstra gang.

HP Japan har taget det fulde ansvar for data-tabet som følge af en fejl i en opdatering af deres backup-script: https://www.iimc.kyoto-u.ac.jp/services/comp/pdf/file_loss_insident_20211228.pdf

Mon ikke der er lagt op til et par kasser kvaje-Sapporo :-)

Bemærk at maskinen har 19PB effektiv storage! Data-tab skal naturligvis ikke ske, men backup af 19PB er ikke trivielt og race-conditions kan ske (det lyder til at være tilfældet her).

Da der ikke findes en ældre backup er der tale om nye data og dermed formodeligt resultatet af kørsler der kan laves om. Der ryger noget tid og CO2 men derudover behøver det ikke være så katastrofalt.

Bemærk forøvrigt at Japanerne faktisk er temmeligt aggresive i og med at de lave backup af hele systemet, det er temmeligt normalt at man kun laver backup af bruger-kataloger og det er op til brugerene at sikre at data der ikke trivielt kan genskabes bliver placeret et sted hvor der laves backup.

Kyoto Universitets supercomputer-installation er opbygget i flere omgange, se Bleeping Computer (BC) artiklen.

Som de fleste af nutidens supercomputere kører de muligvis en dialekt af Linux (har ikke tjekket). BC skriver ikke meget om sammenkobling og BU (backup) og HP er nok ikke glade for opmærksomheden.

Der er nok ikke så mange af os, som nogensinde kommer i nærheden af samme kompleksitet. Man kan forestille sig, at en taperobot har taget sig af BU og at den ikke har været vedligeholdt til opgaven.

Læring af denne hændelse er nok begrænset til de involverede. Så vi kan næppe begynde at lege med vores romantiske forestillinger om ITHK (IT-haverikomission) her; selvom her sikkert er flere, der vil/kan "kloge" sig på emnet.

Er det mon en fejl i selve backup-systemet? Eller en menneskelig fejl i opsætningen? Eller er det brugt til noget, det ikke burde? Jeg mener at huske en historie om et RAID-system, der blev brugt som "backup". Det er ikke nogen strålende ide.

Hvis man nu bruger et system, hvor diske, foldere eller filer skal tilmeldes en backup, så kan man sove meget længe, før man opdager det. Det skulle så imødegås med en periodisk kørsel, der laver en opgørelse over, hvad der ikke er omfattet af backup. Og det skal folk så tage stilling til.

En uddybning ville være rar. Så vi ikke laver samme fejl andre steder.

I øvrigt er computere fantastiske. Tænk på hvor lang tid det ville have taget en hær af ildgerningsmænd at udslette så mange data, hvis der var tale om bøger. Man skal huske, at når noget går galt, så kan det gå meget galt meget hurtigt.

Jeg undre mig over at de ikke kan genskabe en del af de data, normale backup procedure har data gemt i uger, måneder og år.

Nogen havde ikke ansat de rette (eller nok af dem og ignoreret at de har sagt de ikke var nok ansat til at løse de opgaver der burde løses :)