Løsningsforslag, eksamen våren 2009 Operativsystemer og Unix

Oppgave 1 - Bash (10%) oppgave 1

a) Kommandoen tar filen /etc/passwd og sender den til cut, som kun skriver ut første kolonne basert på ":" (kolon). Resultatet er en liste over alle brukernavn som finnes på systemet.

b) Her har man brukt omdirigering >> som om det var en pipe |. Riktig kommando ville vært:

ls /home | grep group > group_users.txt

c) cat /etc/passwd | wc -l

d) enklest: ps aux | grep calc.pl
vanskeligere: if ps aux | grep calc.pl | grep -v grep; then echo "calc.pl finnes"; fi

e) Kommandoen sjekker om det er noen filer i mappen /home/ola/.trash og sletter dem dersom det er tilfellet.

Oppgave 2 - Prosesser (20%)

a) Det kan stoppes ved å taste CTRL-C. Alternativt å finne PID med ps eller top og stoppe det med kill PID.

b) Et moderne OS fordeler CPU-tid mellom alle prosessene på systemet ved å dele opp tiden i deler eller timeslices og sette alle kjørende prosesser inn i en Round Robin-kø. Museklikk i browseren sender interrupts som gjør at input kan behandles hurtig. Dermed er det mulig å surfe på nettet samtidig som programmet kjører.

c) Å kjøre en nettleser er stort sett ikke særlig CPU-krevende og det vil i liten grad påvirke hvor lang tid den CPU-intensive beregningen vil ta.

d) En vanlig prosess vil kun kunne utnytte é CPU av gangen. Det er ikke mulig for OS å fordele instruksjonene i et vilkårlig sekvensielt program mellom to CPU'er. OS kan ikke vite i hvor stor grad kommende instruksjoner avhenger av de tidligere og de kan derfor ikke kjøres parallelt. Dermed utføres hele programmet på en av CPU'ene mens den andre står uvirksom.

e) Samme program startes to ganger med forskjellige parametere. Resultatet lagres i en fil med navn resTALL.txt der TALL er tall-argumentet. Tegnet & gjør at kommandoen legges i bakgrunnen, dermed vil begge jobbene startes opp og kjøre samtidig. Da vil det være mulig for OS å sette i gang jobbene på hver sin CPU hvor disse gjennomføres uavhengig av hverandre. Dermed vil det bare ta 10 minutter før begge resultatene er klare.

f)

#! /bin/bash
if [ $# -lt 1 ]; then
   echo "Oppgi minst ett argument! "
fi

for tall in $*
do
   ./regn $tall > res$tall.txt&
done

Oppgave 3 - Threads/tråder (20%)

a) En "single core" CPU har kun é n prosessorenhet med ALU og registere mens en "dual core" CPU har to prosessorenheter eller kjerner med hver sin ALU og sett av registere integrert på samme brikke. De to ALU'ene kan prosessere helt uavhengig av hverandre. De to prosessorenhetene har felles cache på brikken.

b) Threads eller tråder er et begrep som betegner utføringen av et program. Flere tråder kan eksistere innenfor samme prosess, eksekvere samme kode og dele felles data. OS schedulerer typisk trådene uavhengig av hverandre. Hyperthreading foregår på et lavere nivå, inne i selve prosessorenheten. For OS oppfattes det som om to prosesser(eller to tråder) kjøres samtidig. Men en hyperthreading CPU har kun en ALU og de to prosessene må bytte på å bruke denne. De har derimot hvert sitt sett med registere og CPU'en kan da lynhurtig switche mellom de to prosessene/trådene.

c) Generelt kan ikke et Java-program utnytte to uavhengige CPU-kjerner. Dette er fordi instruksjonene utføres sekvensielt og at kommende instruksjoner bygger på resultatene av de instruksjonene som har blitt utført. Alle instruksjonene må derfor utføres i rekkefølge og kan dermed ikke utføres i parallell uavhengig av hverandre på to forskjellige prosesseringsenheter.

d) Programmet behandler fire store tekstfiler av gangen og arbeidet med en fil er uavhengig av de andre. Dermed kan man enkelt implementere programmet med to uavhengige Java-tråder som behandler to filer hver. For eksempel kan man skrive en Java-thread som tar to filnavn som argument og utfører alle beregninger på disse filene når den startes. Hovedprogrammet starter opp to slike tråder, de vil da starte samtidig og OS vil schedulere dem på hver sin CPU-kjerne.

e) De to trådene jobber fullstendig uavhengig av hverandre på hver sin like raske CPU-kjerne og dermed halveres prosesseringstiden. Tydligvis er ikke bruken av disk så intensiv at dette går ut over tiden det tar å bli ferdig, noe som potensielt kunne vært en flaskehals.

f) Det er nå enkelt å skrive om programmet slik at det starter fire threads i starten som hver jobber på sin egen fil. OS hvil da schedulere to tråder på hver CPU-kjerne. Siden CPU-kjernene er hyperthreading, vil de switche hurtig mellom de to tildelte trådene hver gang den ene må hente noe fra disk, slik at den andre i mellomtiden kan utnytte ALU-tiden.

g) De to trådene som jobber på samme hyperthreading-CPU har bare en ALU å dele på og prosesserings jobben er tydligvis så CPU-avhengig at prosesseringen er den største flaskehalsen. Dermed må de to trådene som hyperhtreades vente noe på hverandre og den totale tiden blir ikke halvert.

Oppgave 4 - Minne (30%)

a) Scriptet kjører en grep på ps aux, vi får altså alle linjer i ps aux som matcher argumentet som ble gitt med. Ved Ola sin kjøring gir han med "firefox", som matcher både selve prosessen som scriptet startet samt firefox.

b)

#!/usr/bin/perl

my $process = $ARGV[0];
my $sum_rss;
my $sum_vsz;
open(PS,"ps aux |");

# fjern header linjen
<PS>;

while (my $line = <PS>){
    my @array =  split /\s+/, $line;
    if ( $array[10] =~ /$process/ ){
        $sum_rss += $array[4];
        $sum_vsz += $array[5];
    }
}
close(PS);
print "Sum RSS: $sum_rss\n";
print "Sum VSZ: $sum_vsz\n";

c) Som kommando (oppdateres hvert 5 sekund) :

watch -n 5 ./memwatch.pl firefox

Som perl kode:

#!/usr/bin/perl

my $process = $ARGV[0];

while ( true ){
    my $sum_rss;
    my $sum_vsz;
    open(PS,"ps aux |");

# fjern header linjen
    <PS>;

    while (my $line = <PS>){
        my @array =  split /\s+/, $line;
        if ( $array[10] =~ /$process/ ){
            $sum_rss += $array[4];
            $sum_vsz += $array[5];
        }
    }
    close(PS);
    print "Sum RSS: $sum_rss\n";
    print "Sum VSZ: $sum_vsz\n";
    sleep 5;
}

d) Munin er et web-basert overvåkingssystem som er enkelt å utvide ved hjelp av plugins. Man kunne f.eks laget et munin plugin som ville vist disse to tallene som en graf.

e) Pluginet ville bestått av to deler: en konfigurasjonsdel og en verdidel. Konfigurasjonsdelen blir aktivert når man kjører pluginet med "config" som argument. Her ville man deklarert de to variablene som "rss" og "vsz".

I selve verdi-delen ville memwatch.pl scriptet blitt kjørt og tallene blitt hentet ut og presentert med hhv. "rss.value" og "vsz.value" foran seg. Her er et perl-eksempel på verdi-delen av scriptet:

@memwatch = `memwatch.pl firefox`;
# RSS:
@RSS_array = split /\s+/,$memwatch[0];
# VSZ:
@VSZ_array = split /\s+/,$memwatch[1];
# Utskrift:
print "rss.value $RSS_array[2]\n";
print "vsz.value $VSZ_array[2]\n";

Denne løsningen forutsetter at man ikke gjorde perl endringen i oppgave c).

f) Utsagnet er riktig. VSZ gir ikke et korrekt bildet av minneallokeringen til en prosess, men snarere hvor mye virtuelt minne denne prosessen har. Dersom mange prosesser har allokert mye minne kan dette overskride de faktiske fysiske ressursene. Operativsystemet vil da alltid prøve å holde de delene av minne som faktsik er i bruk i RAM ved hjelp av paging og swap.

Oppgave 5 - Nettverk (20%)

a) Med NAT benytter man såkalte private adresser i sitt interne nettverk. Disse adressene er ikke routbare på Internett. NAT gatewayen/routeren for det private nettverket har en offentlig IP-adresse og den oversetter mellom private og offentlige adresser slik at man kan kommunisere med Internett fra de private nodene. NAT (Network Adress Translation) ble funnet opp fordi det begynte å bli mangel på IP-adresser (til tross for at det finnes $2^{32} = 4$ milliarder adresser).

b) Dette er vanlig NAT, masquerading eller source NAT/SNAT. Ved dette oppnår man at klienter i det private nettet kan kommunisere med servvere på Internett. Hver del av kommandoen betyr:

Kommando	Virkning
iptables	bruk iptables
-t nat	Bruk NAT-tabellen (dvs lag en NAT-regel)
-A POSTROUTING	Legg til denne regelen i POSTROUTING-chain i NAT-tabellen
-o eth0	regelen gjelder pakker på vei ut (o = out) av eth0 (her: mot Internett)
-j MASQUERADE	Maskerer den private IP'en ved å bytte til NAT-gatewayens egen IP

c)

d)

e) Det er kun IP-adressene som endres. Avsender IP i pakken fra client og mottager IP i pakken fra server som vist i figuren. Mellom client og NAT-gateway er avsender på vei ut, mottager på vei inn 10.0.0.2. Ute på internett er avsender/mottager 128.39.73.197. Begge istedet for 158.36.84.110. Alt annet er uendret.