Forsida

Temaer

Sjangere

fsck er farlig

Tema: Programvare; sjanger: Meninger
Skrevet av Andreas Nordal den 7. oktober 2011 kl 16:13:45; Kommentarer: 0

Hvis korrupsjon i filsystemet skyldes maskinvarefeil, så vil fsck gjøre vondt verre. Det er min erfaring etter å ha mista 1,4 TB.

Fsck er programmet som skal «fikse» eventuelle feil i filsystemer, typisk i det man skrur en datamaskin på. Det skumle er at fsck er et idiotisk program som har 0 forutsetning for å gjøre de riktige valgene. Tenk deg et stavekontrollprogram som bare sletter alle setninger som ikke er grammatisk korrekte. Før du slipper fsck løs på livsverket ditt, bør du være sikker på at det er feilfritt...

Det skulle vise seg at jeg hadde en feil i SATA-koblinga mellom harddisk og hovedkort. Det hjalp ikke et fnugg å ha RAID1, for feilen skjedde selvfølgelig samtidig for koblingene til begge harddsikene, eller mer sannsynlig, at det fins en felles komponent på hovedkortet som kunne svikte. Det er statisk redundans i praksis, det.

Smartctl avslører feilen. Utklipp (min utheving):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   147   145   021    Pre-fail  Always       -       9633
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       32
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   073   073   000    Old_age   Always       -       19734
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       22
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       4
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       28
194 Temperature_Celsius     0x0022   121   110   000    Old_age   Always       -       31
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       38935
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

Ifølge smartctl er kommunikasjonen med denne harddsiken upålitelig, mens selve harddisken fungerer utmerket. I praksis merkes feilen ved at filene kan være litt forskjellige hver gang, spesielt store filer. Det betyr at dataene kan reddes hvis man kjenner sjekksummen; det er bare å lese dem om igjen til det stemmer. Men tror du fsck leser om igjen når noe ikke stemmer? Etter første runde med fsck fikk jeg ikke engang montert filsystemet.

Hva er verst:

  1. helt tapte data
  2. korrupte data
  3. data som du ikke vet om er korrupt eller ikke
Jeg har stort sett endt opp med det siste. En lærdom er at sjekksummen kan være like verdifull som dataene selv!

Man tror at «maskinvarefeil rammer ikke meg». Enda mindre hadde jeg fantasi til å mistenke denne feilkilden tilfeldigvis midt i en oppgradering av filsystemet fra ext3 til ext4, når det er minst et par andre ting som kan gå galt. Så jeg rapporterte det som en programvarefeil. Der står hendelsesforløpet utførlig beskrevet.

Hele katastrofen hadde vært en bagatell hvis jeg hadde forstått problemet med en gang. Det dummeste jeg kunne gjøre var å følge siste punkt på prosedyren, nemlig fsck. Som med de fleste katastrofer: Det er når man har uhell i uhellet at det går galt. I'm fsck'd.


Ikke partisjoner harddisken

Tema: Programvare; sjanger: Artikler
Skrevet av Andreas Nordal den 5. april 2011 kl 21:10:23; Kommentarer: 0

Hvis man likevel bare skal ha én partisjon på en harddisk, hvorfor ikke gjøre det enkelt?

Bortsett fra operativsystem-partisjonen, som faktisk være en partisjon (for at BIOS og oppstartlaster skal funke), så er det ikke nødvendig å partisjonere eventuelle andre harddisker i datamaskinen.

Eksempel

I Linux kan man:

mkfs.ext4 /dev/sdd

I stedet for:

mkfs.ext4 /dev/sdd1

Da skriver man i /etc/fstab:

/dev/sdd        /mnt/d  ext4    defaults 1 2

Framfor:

/dev/sdd1       /mnt/d  ext4    defaults 1 2

Dette funker faktisk: Denne nettsiden er lagra på to uformaterte harddisker i raid1.

Forklaring

Mens vanlig prosedyre er å formatere enkelt-partisjoner av harddisken, er det selvsagt også mulig å formatere selve harddisken. Det resulterende filsystemet vil da spenne absolutt hele harddisken, uten plass til partisjonstabell og alt det der.

Fordeler

Ulempe

Konklusjon

Skal man først ha en ekstra harddisk, typisk for å få et stort filsystem til ren datalagring, så er man ikke interessert i å partisjonere harddisken i biter. Det er heller ikke vits i å lage den ene partisjonen for BIOS eller oppstartslasterens skyld. Dessuten skaper det bare trøbbel. Teknisk sett er det veldig smart å ikke partisjonere harddisken.


Fisk i fjæra

Tema: Diverse; sjanger: Prosjekter
Skrevet av Andreas Nordal den 26. mars 2011 kl 22:53:20; Kommentarer: 0

Jeg kom i skade for å lage en film. Den heter «Fisk i fjæra». Den er i samme sjanger som Nattkjole med urin og Hatten är din. Jeg håper ingen blir provosert av den.

Det jeg har gjort er å legge på norsk tekst på en somalsk musikkvideo. Ja, også litt grafikk da.

Bare så det er sagt, så er det faktisk mulig å redigere film på Linux også. Det var ikke fryktelig vanskelig. Jeg brukte disse programmene:

Krita var egentlig uegnet til mitt formål, som var å gjøre bakgrunnen av grafikkbildene gjennomsiktig. Det hadde vært 100 ganger lettere hvis «inverter utvalg»-funksjonen hadde funka. Jeg kunne sikkert brukt Gimp.


PHP duger ikke til interaktiv skripting

Tema: Programmering; sjanger: Meninger
Skrevet av Andreas Nordal den 24. februar 2011 kl 12:31:25; Kommentarer: 0

Hvorfor monger ssh-klienten når den startes fra PHP? Ikke gjør dette hjemme:

#!/usr/bin/php
<?php
system('ssh meg@domene');
?>

Det som tilsynelatende skjer da er at ssh bufrer unna all interaktivitet. Du får ikke se hva du skriver i kommandolinja før du har trykka enter, men da er det jo for seint. Og skal du redigere tekst over ssh? Da er du kjørt...

Slik skal det gjøres:

#!/usr/bin/python
import subprocess

subprocess.call(['ssh', 'meg@domene'])
Nyttige orientalske middagsretter