01UnixVersiuniStructuri

Unix: versiuni, structura, structuri interne 1

1 STRUCTURA SO UNIX................................................................................................................ 2

1.1 EVOLUłIE ŞI VERSIUNI ............................................................................................................... 2

1.1.1 Scurt istoric....................................................................................................................... 2

1.1.2 DescendenŃa şi relaŃiile dintre diverse SO Unix .............................................................. 3

1.1.3 Standarde.......................................................................................................................... 5

1.2 STRUCTURA SISTEMULUI DE OPERARE UNIX.............................................................................. 6

1.2.1 Principalele caracteristici ................................................................................................ 6

1.2.2 Structura şi principalele componente............................................................................... 6

1.3 SISTEMUL DE FIŞIERE UNIX...................................................................................................... 10

1.3.1 Structura arborescentă şi legături suplimentare............................................................ 10

1.3.1.1 Tipuri de fişiere şi sisteme de fişiere .......................................................................... 10

1.3.1.2 Legături hard şi legături simbolice ............................................................................. 11

1.3.2 Conceptul de montare..................................................................................................... 14

1.3.3 ProtecŃia fişierelor Unix................................................................................................. 16

1.3.3.1 Drepturi de acces ........................................................................................................ 16

1.3.3.2 BiŃii setuid şi setgid........................................................................................... 17

1.3.3.3 Drepturi implicite: umask ........................................................................................ 18

1.3.4 Principalele directoare ale unui sistem de fişiere Unix ................................................. 19

1.4 STRUCTURA INTERNĂ A DISCULUI UNIX .................................................................................. 22

1.4.1 PartiŃii şi blocuri ............................................................................................................ 22

1.4.2 Directori şi inoduri ......................................................................................................... 23

1.4.3 Schema de alocare a blocurilor disc pentru un fişier .................................................... 24

1.4.4 Accesul proceselor la fişiere........................................................................................... 26


1 Structura SO Unix

1.1 EvoluŃie şi versiuni

1.1.1 Scurt istoric

Acest SO are poate cea mai interesantă evoluŃie, de la apariŃie şi până în prezent. In 1968, Ken

Thompson de la Bell Telephone Laboratories (BTL) provenit de la University California Berkeley

(UCB), făcea parte dintr-un grup de cercetători de la Massachusetts Institute of Technology (MIT), de

la General Electric (GE), de la UCB şi de la BTL. Scopul lor era să implementeze SO MULTICS

(MULTiplexed Information and Computing Service), SO celebru la ora aceea. Thompson, care avea la

dispoziŃie un DEC PDP-7 cu 4Ko RAM, şi-a pus problema elaborării unui sistem simplu de

manipulare a fişierelor la acest SC. Imprumutând câteva elemente de MULTICS, a pus mai întâi

bazele unui sistem arborescent de fişiere (dealtfel primul în istoria SO). Curând, la acest mic proiect

aderă şi Dennis M. Ritchie. Tot în joacă, Brian Kernighan numeşte sistemul celor doi UNICS

(UNiplexed Information and Computing Service). Din cauza scrierii mai comode, acest nume devine

Unix. In 1969 apare prima versiune a lui, mult mai dezvoltat şi mai performant decât îşi propusese

Thompson cu un an mai devreme. Practic, acesta era un SO mic, dar foarte eficient.

Istoria, în sumar poate fi găsită la (http://virtual.park.uga.edu/humcomp/unixhistory.html. O descriere

detaliată a descendenŃelor Unix până în prezent se poate găsi la adresa: http://www.levenez.com/unix/.

Prima lui versiune a fost scrisă în limbajul BCPL (Basic Combined Programming Language), la

vremea aceea un instrument elegant de scriere a compilatoarelor şi a programelor de sistem. In 1970

apare versiunea a doua de Unix. Pentru ea, Ritchie crează un nou limbaj, B, obŃinut prin simplificarea

majoră a BCPL, din raŃiuni de eficienŃă. In 3 nov. 1971 apare primul manual de Unix: “Unix

Programmer’s Manual”, având ca şi autori pe cei doi. Intre 1970-1972, acelaşi Dennis M. Ritchie

extinde B cu un mecanism de tipuri de date, obŃinând limbajul NB (new B), din care apoi crează limbajul de programare C, (rămas în vogă până în zilele noastre!). Tot din această perioadă datează - mulŃumită lui K. Thompson care l-a creat - conceptul de pipe, foarte folosit in teoria sistemelor de

operare. Conceptul de pipe a reprezentat o piatră de temelie pentru noul sistem de operare, apariŃia sa

impulsionând puternic noul SO numit Unix. In 1973 apare versiunea a treia de Unix, scrisă aproape

exclusiv în C. Practic, textul sursă al SO conŃine 10000 - 5000 linii sursă C, deci într-un limbaj de

programare de nivel înalt, cu o portabilitate ridicată, şi cel mult 1000 linii necesare a fi scrise în

limbajul de asamblare al maşinii pe care se implementează Unix. Versiunea a fost implementată pe un

minicalculator PDP-11/20 cu 56K RAM şi două discuri de câte 2.4Mb fiecare, apoi pe PDP-11/45. In

iulie 1974 apare, de aceiaşi doi autori, un articol devenit celebru: “The Unix time-sharring System”, în

care este descrisă versiunea a 5. Până în 1977 Unix nu a avut o răspândire prea mare, fiind operaŃional

doar în 500 de locuri şi acestea datorate distribuŃiei libere a lui în universităŃi.

Prima implementare industrială a lui se face pe un PDP-11/45. Firma Bell (AT&T Bell Laboratories)

obŃine dreptul de licenŃă asupra lui Unix. Il livrează aproape gratuit la toate universităŃile care i-l cer

(substratul comercial este clar) şi îl fac operaŃional pe cele mai variate tipuri şi modele de calculatoare:

Interdata, VAX, SC bazat pe microprocesorul Motorola 68000 şi multe altele. Un moment important al

evoluŃiei este anul 1978, când apare Unix versiunea 7, îmbunătăŃită prin contribuŃia UniversităŃii Berkeley-California.


Multe firme au încercat apoi să realizeze mediul Unix pe propriile maşini. In primul rând AT&T Bell

şi-a continuat cercetările, scoŃând în 1984 Unix SYSTEM V, o adevărată performanŃă în domeniu. In

al doilea rând, Firma Microsoft a cumpărat licenŃa sistemului de la AT&T, fără însă a avea dreptul să folosească numele de Unix în acŃiunile ei publicitare. Microsoft a numit această implementare XENIX.

In ultimii ani, au apărut tot mai multe implementări de reŃele de calculatoare care funcŃionează sub

Unix. Utilizând protocoale care sunt standarde de facto, ca de exemplu protocolul TCP/IP sau

TELNET, reŃelele de IBM-PC pot să funcŃioneze excelent sub mediul Unix. Cu trecerea anilor, Unix

şi-a câştigat o tot mai mare popularitate. La început a fost folosit în mediul universitar, apoi în

laboratoarele de cercetări şi treptat a pătruns tot mai mult în domeniul industrial şi financiar-bancar.

SO Unix este la această oră element de referinŃă în sistemele de operare. Practic, orice SO nou apărut,

sau orice SO care trebuie studiat şi analizat, trebuie comparat cu SO Unix. De exemplu, celebrul "cub"

al lui Steve Jobs, calculatorul NEXT care a apărut cu mare pompă în 1987, are la bază un SO

compatibil Unix SYSTEM V şi este elaborat în limbajul C++. In 1988, mai multe firme de prim rang

(cu IBM în cap de listă), creează fundaŃia OSF (Open Software Fundation). Aceasta urmăreşte crearea

unui standard pornind de la Unix SYSTEM V versiunea 2.

InvăŃământul informatic nu se mai poate lipsi practic de Unix. Toate universităŃile mari ale lumii sunt

dotate cu mini şi microcalculatoare, legate în reŃea, ce folosesc ca SO gazdă Unix. Predarea

disciplinelor informatice conexe cu sistemele de operare este intim legată (teoretic şi practic) de

conceptele Unix. De exemplu, între 1978 şi 1985, Anrew S. Tanenbaum, profesor la universitatea

Wrije din Amsterdam, a publicat specificaŃiile sistemului de operare MINIX. Acesta este compatibil cu

Unix versiunea 6, iar scopul lui este de a-i învăŃa pe studenŃi cum să proiecteze un sistem de operare.

In sfârşit, nici "duşmanii" lui Unix nu pot face abstracŃie de acesta. De exemplu, există o lucrare

extrem de valoroasă având numele "Operating System Design - XINU Approach". In prefaŃă autorii

spun că XINU nu este Unix. Dar însuşi denumirea XINU este palindrom al cuvântului “Unix”!

Romania a cochetat şi ea cu Unix. Astfel, în perioada 1984-1989, la ITCI au existat preocupări serioase pentru o implementare Unix. Astfel, filiala Cluj a ITCI a implementat Unix pe

minicalculatoarele compatibile PDP sub numele de SO "U". De asemenea, un laborator de la ITCI

Bucureşti a elaborat SO U/micro, operaŃional pe microcalculatoarele de 16 biŃi.

Cu siguranŃă, în actuala explozie de sisteme de operare, Unix a jucat şi va mai juca încă multă vreme

rolul de moderator. Datorită marii lui portabilităŃi, el va deveni, suntem siguri, operaŃional pe toate

tipurile de calculatoare.

1.1.2 DescendenŃa şi relaŃiile dintre diverse SO Unix

Cele mai semnificative versiuni sunt prezentate în fig. ?.?. Aici am reŃinut strict cele mai semnificative

momente Unix, deoarece graful descendenŃelor este mult mai mare. De exemplu, la adresa

http://www.levenez.com/unix/ (una dintre sursele noastre de inspiraŃie) este descris arborele

genealogic aproape complet al descendenŃelor Unix cu cele mai importante versiuni ale lor. Este de

reŃinut faptul că imaginea grafului de descendenŃe se întinde pe 14 (patrusprezece) pagini format A4!


Figura ? DescendenŃe Unix

Chiar dacă anticipăm puŃin unele concepte, dorim să enumerăm câteva dintre diferenŃele dintre unele

versiuni de Unix. Astfel,

Versiunea 7 este prima versiune larg răspândită înafara AT&T, în primul rând în universităŃi.

System III este prima versiune comercială disponibilă. Aici apare conceptul de pipe cu nume (FIFO).

System V include multe îmbunătăŃiri ale performanŃelor şi facilităŃi de comunicare interprocese IPC. Se

introduc în acest sens conceptele de semafor, coadă de mesaje şi memorie partajată.

Varianta System V R2 introduce funcŃii de blocare a accesului la fişiere şi înregistrări.

SVR3 include îmbunătăŃiri ale semnalelor, flexibilitatea sistemului de fişiere. In particular introduce şi partajarea sistemelor de fişiere între mai multe maşini Unix.

SVR4 aduce multe caracteristici noi faŃă de SVR3. Printre aceste caracteristici amintim:

• Legături simbolice – folosite pentru legări de fişiere din sisteme de fişiere diferite, chiar la nivel de

directori.

• Sisteme de fişiere virtuale (VFS).

• Sisteme de fişiere Berkeley (ufs).

• Fişiere mapate în memorie.

Versiunea 7

BSD 3.0System

III

System

VXENIX III

XENIX

V

System V

R2

System V

R3.2

System V

R4

SOLARISLINUX

BSD 4.1

BSD 4.2

BSD 4.3

SunOS 4.x

Versiuni

necomerciale


• Fişiere pipe bidirecŃionale.

• Suport de timp real sau de timp partajat.

• Alinierea la specificaŃiile POSIX.

Linux. Una dintre implementările Unix folosite masiv la ora actuală este sistemul de operare Linux.

Dezvoltarea lui a fost demarată şi coordonată (inclusiv în prezent) de Linus Benedict Torvalds.

Sistemul a fost iniŃial conceput pentru pentru platforme i386, în prezent fiind răspândit pe toate

platformele din familia Intel, dar şi pe alte platforme remarcabile. Este un sistem de operare free. (In

timp ce majoritatea celorlalte sisteme clasice Unix sunt comerciale, costă relativ mult iar utilizarea lor

oficială trebuie făcută pe bază de licenŃă). Linux a fost scris tocmai pentru a se permite utilizarea lui

fără nici un fel de plată. Practic, setul de comenzi Linux, privit din exterior arată ca şi orice set de

comenzi similare de pe orice alt Unix. Se apreciază că 95% din funcŃionalităŃile Unix şi Linux coincid.

Aşa că orice utilizator care ştie un Unix oarecare poate utiliza imediat un Linux şi reciproc -

cunoscătorii de Linux pot utiliza fără probleme orice alte sisteme Unix. Deosebirile apar numai la

nivelele de configurare a sistemelor şi parŃial de administrare a lor.

1.1.3 Standarde

Cu toate că aplicaŃiile Unix au fost portate între versiuni de Unix, diversitatea şi diferenŃele dintre

versiuni au determinat grupurile mari de utilizatori să impună o standardizare. în prezent există mai multe

astfel de încercări: ANSI C, IEEE POSIX şi X/OPEN XPG3.

In 1989 ANSI (American National Standard Institute) a impus standardul limbajului C la principalele

sisteme de operare existente. Prin standard se defineşte nu numai sintaxa plus semantica, ci şi bibliotecile standard care se pot folosi. Aceasta induce automat un anumit nivel de standardizare sub

Unix, ştiut fiind că versiunile noi de Unix definesc rutinele de bibliotecă ca şi cele din C.

IEEE (Institute of Electrical and Electronic Engineers) a definit standardul POSIX (Portable Operating

System Interface for Computer Interface), în 1988 (modificat în 1990) defineşte serviciile pe care un

SO trebuie să le realizeze pentru a fi compatibil POSIX. Standardul este bazat pe Unix.

POSIX specifică o interfaŃă, nu o implementare, motiv pentru care nu se face distincŃie între apeluri

sistem şi funcŃii de bibliotecă.

X/Open XPG3. X/Open este un grup internaŃional de comercianŃi de calculatoare. Ei au publicat un

ghid de portabilitate numirt “X/Open Portability Guide” versiunea 3, în 1989, care este bazat pe

POSIX.

AVERTISMENT:

Pe parcursul utilizării Unix pot să apară o serie de greutăŃi. Utilizatorul nu trebuie să intre neapărat în

panică, ci trebuie să verifice (cel puŃin) următoarele:

- Care este versiunea de Unix de care se dispune? Sunt precizate (eventual pe Internet) eventuale

incompatibilităŃi?

- Care este versiunea de shell folosită?


- Este necesară cumva modificarea unui nume de cale datorită posibilităŃii existenŃei unui anumit

element în altă parte în sistemul de fişiere?

- Lipseşte cumva vreun drept de acces la fişier? Este necesar ca utilizatorul să fie superuser?

1.2 Structura sistemului de operare Unix

1.2.1 Principalele caracteristici

Unix este un sistem interactiv, multiutilizator, de uz general. Proiectat iniŃial pentru minicalculatoarele

din familia PDP, el este astăzi disponibil pe o mare gamă de calculatoare, începând cu

microcalculatoarele şi terminând cu cele medii-mari. Scopurile lui principale, la origini, au fost două: dezvoltarea de programe şi elaborarea de documentaŃii. In prezent este un SO universal, element de

referinŃă pentru toate celelalte SO. Unix este un SO relativ mic, însă primitivele lui au fost astfel alese

încât să-i confere o mare putere de exprimare, combinată cu o mare simplitate în utilizare. Structura lui

este dată în fig.?

Unix, din punct de vedere al utilizatorilor, are trei calităŃi: • este un sistem interactiv, deoarece toate comenzile le primeşte de la terminale, în regim

conversaŃional;

• este un sistem multiuser, deoarece lucrează în acelaşi timp cu mai mulŃi utilizatori simultan.

Disciplina de servire a lor este timp partajat;

este un sistem multitasking, datorită faptului că fiecare utilizator poate, în mod conştient, să-şi lanseze

simultan mai multe programe în execuŃie. Dacă un utilizator doreşte acest lucru, atunci el va proceda

astfel: când dă o comandă şi ştie că după ea va da o alta înainte ca prima să se termine de executat,

linia de pe terminal cu care lansează prima comandă trebuie să se încheie cu caracterul “&”. Prin acest

caracter shell este anunŃat că ea (comanda respectivă) va fi executată în regim background (ascuns).

După lansare, shell tipăreşte pe terminal un număr care este numărul procesului respectiv. După aceasta, utilizatorul poate da următoarea comandă. Evident, cele două comenzi nu pot fi lansate dacă folosesc resurse în comun. Spre exemplu, nu pot fi lansate în acelaşi timp două programe dacă ambele

afişează câte un fişier text pe terminal. Dacă totuşi are loc o astfel de lansare, sistemul are grijă să le

execute secvenŃial, în ordinea în care au fost lansate (deci nu se obŃine nici un câştig de timp). Aşa cum

este şi firesc, numărul de programe lansate în acelaşi timp de la un terminal nu este limitat.

1.2.2 Structura şi principalele componente

După cum se vede în fig. ?, Unix este structurat în două părŃi: user (servicii) şi kernel (nucleu, control).

Userul (utilizatorul) poate să acceseze Unix pe trei căi: 1) folosind interpretorul de comenzi shell; 2)

prin intermediul programelor proprii scrise, compilate şi completate cu subprograme din biblioteca

Unix; 3) cu ajutorul comenzilor standard oferite de interfaŃa exterioară Unix, aşa cum am vazut deja în

cap. 1. Comenzile standard pot fi clasificate, în funcŃie de destinaŃia lor, aşa cum reiese din fig. ?

Manipularea de fişiere generale. Permite rezumatele unor directori, copierea şi concatenarea unor

fişiere, ştergerea sau schimbarea poziŃiei unui fişier în structura arborescentă etc. In cap. 1 am

prezentat câteva comenzi de manipulare a fişierelor.


Figura ? Arhitectura SO Unix

Filtre şi manipularea fişierelor text. Acest tip de fişiere este extrem de mult folosit în Unix. Astfel,

există comenzi care caută într-un fişier linii cu un anumit conŃinut, detectează fişiere care înglobează în

ele un anumit conŃinut, ordonează alfabetic liniile unui fişier text, determină într-un fişier numărul de

linii, cuvinte etc. Unele dintre aceste comenzi au fost deja prezentate.

Editoarele de texte au funcŃiile cunoscute. Să remarcăm faptul că Unix a fost printre primele SO dotate

cu un editor de texte video (vi).

Manipulare fisiere generale: ls, cd, cat, mv, rm, ...

Filtre si manipulari fisiere text: sort, awk, grep, sed, ...Editoare de texte: ed, ex, vi, sed, joe, ...Preparatoare de documente: troff, nroff, tbl, equ, pic, ...Comunicatii intre utilizatori: write, who, mail, mesg, pine, ftp, telnetDezvoltare de programe: C, C++, java, fortran, pascal, ar, dbx, ...

JocuriAdministrare sistem: passwd, chmod, chown, tar, fsck, mkfs, cpio,

shell Unixbibliotecautilizator biblioteca de

comenzi Unix

Interfata de apeluri sistem

Subsistemul de fisiereSubsistemul de procese:

Inter Process Communication

Planificarea proceselor

Memory Management

Cachediscuri

Cdev Bdev

drivere periferice

Controlul intreruperilor hardware

HARDWARE

init (1)

swapper (0)

User

Kern

el


Preparatoarele de documente au fost, credem noi, utilitarele cu care Unix şi-a câştigat marea

popularitate în primii ani. Aceste utilitare permit punerea în pagină a manualelor şi cărŃilor din toate

domeniile. Se permite scrierea comodă a tabelelor, a expresiilor matematice, fizice şi chimice, desenele

şi graficele (cele rezonabile) pot fi descrise pentru a fi elaborate automat etc. FaŃă de primele două decenii de existenŃă Unix, azi maniera de lucru a preparatoarelor de documente Unix este comparabilă, ca stil, cu ceea ce oferă SO Windows.

ComunicaŃii. Unix este la ora actuală cel mai răspândit SO care facilitează integrarea în reŃele, atât

LAN, cât şi MAN sau WAN. In aceste reŃele sunt oferite toate facilităŃile cunoscute de integrare în

reŃea la toate nivelele, începând cu sisteme de fişiere în reŃea (NFS) şi terminând cu conexiuni

client/server la mare distanŃă, comunicare Internet etc. Nu trebuie uitat faptul că Unix a oferit suport

pentru poşta electronică încă de la origini. Conceptul fundamental cu care operează poşta electronică este acela de căsuŃă poştală. Aceasta este o zonă în memoria internă sau (mai degrabă) pe disc, proprie

fiecărui utilizator, unde acesta depune mesajele lui pentru diverşi destinatari şi unde le primeşte pe cele

ce-i sunt adresate. Periodic, sistemul expediază mesajele spre destinatari. Tot periodic, sau la cerere,

utilizatorul este informat asupra "corespondenŃei" lui.

Dezvoltarea de programe. Sistemul oferă compilatoare pentru cele mai moderne limbaje de

programare existente astăzi. Cel mai folosit este limbajul C, dar sunt disponibile compilatoare şi pentru

celelalte principale limbaje, inclusiv ultimele versiuni de Java.

Administratorul sistemului are ca sarcină întreŃinerea fişierelor de parole, de evidenŃă a utilizatorilor

sistemului etc. De asemenea, el întreŃine sistemele de fişiere existente pe discurile şi benzile magnetice

ale sistemului, face periodic salvări şi restaurări etc.

Shell este interpretorul de comenzi Unix. El nu face parte în mod expres din sistem, ci este mai

degrabă o parte din ceea ce i se oferă în mod direct utilizatorului. Shell are în principal două sarcini:

• supraveghează fiecare terminal în parte, şi este gata în orice moment să preia, să decodifice şi să transmită nucleului comenzile date de utilizatorii de la terminale;

• oferă utilizatorului posibilitatea să controleze succesiuni de comenzi adresate nucleului. Aceste

posibilităŃi de control sunt comparabile cu posibilităŃile de control a succesiunii instrucŃiunilor din

limbajele de programare C şi Pascal. De fapt shell este realmente un limbaj de programare,

instrucŃiunile lui de bază fiind comenzi Unix.

Shell, ca legătură directă între utilizator şi nucleu, oferă o serie de facilităŃi despre care vom vorbi în

secŃiunile care urmează. Printre altele este vorba de posibilitatea redirectării intrării şi ieşirii standard

şi de posibilitatea legării pipe a mai multor programe.

Kernel este nucleul SO. El este scris în limbajul C şi necesită un număr relativ mic de linii sursă (10.000 - 12.000 linii pentru versiunile ceva mai vechi). Nucleul propriu-zis este practic independent

de maşina pe care operează. Este partea din sistem relativ ascunsă utilizatorului obişnuit, dar asupra ei

lucrează de regulă administratorul sistemului. Prin el se realizează legătura cu toate resursele

sistemului: periferice, linii de comunicaŃie, memorie, timp etc. Are în principal două sarcini:

• gestiunea proceselor;

• gestiunea perifericelor, inclusiv a nivelului inferior pentru fişiere.


In nucleu se află inclusiv componenta de planificare, care în Unix are o importanŃă deosebită. O

caracteristică importantă la Unix este faptul că utilizează conceptul de proces inclusiv la nivel de

utilizator obişnuit.

InterfaŃa de apeluri sistem este componenta din nucleu care realizează interfaŃa cu exteriorul. Ea este

formată dintr-o multitudine de funcŃii apelabile în mod natural din limbajul C. Practic orice cerere de

serviciu din exterior către nucleul Unix presupune cel puŃin un astfel de apel sistem. Vom dedica o

mare parte din prezentarea Unix apelurilor sistem.

Sistemul de fişiere (File System) este componenta care organizează şi gestionează toate datele care se

vehiculează în sistem. Această componentă este cea mai importantă parte a SO Unix, deoarece el

priveşte conceptul de fişier într-un sens mai larg decât la alte SO. Mecanismele lui permit organizări începând cu cele mai simple şi ajungând până la cele mai complexe. Vom dedica o secŃiune specială acestei componente Unix. Pentru moment este suficient să reŃinem faptul că Unix este primul SO care

a utilizat structura arborescentă a directoarelor de fişiere. Sistemele Unix actuale extind structura

arborescentă la structura de graf aciclic, după cum vom vedea în continuare. De asemenea, este SO

care suportă simultan mai multe tipuri de sisteme de fişiere. Toate sistemele de fişiere existente la un

moment dat pe un sistem, fie că sunt pe partiŃii disc, sau pe discuri diferite pe acelaşi sistem, fie că aparŃin altor SO (Unix, DOS, Windows etc.), cu care sistemul este legat în reŃea, sunt integrate într-un

sistem de fişiere virtual unic.

Cache discuri este o componentă menită să optimizeze accesul la perifericele de tip disc. Pe scurt spus,

ea implementează un mecanism prin care se reŃin în memorie şi sunt servite de acolo porŃiunile de pe

disc folosite mai recent sau mai des solicitate.

Cdev şi Bdev sunt două componente de legătură indirectă între echipamentul hard şi nucleul

sistemului. Primul, Cdev este un ansamblu de rutine, dependente de maşină, prin care se realizează legătura dintre perifericele de tip caracter şi sistem. Bdev este, de asemenea, un ansamblu de rutine

dependente de maşină, destinat legăturii cu perifericele de tip bloc. Acestea sunt singurele componente

care trebuie scrise în limbajul de asamblare al maşinii concrete pe care se lucrează. Practica a

demonstrat că pentru aceste două pachete de rutine sunt necesare aproximativ 1000 (una mie) linii,

sursă în limbaj de asamblare.

Subsistemul de procese este a doua mare componentă a nucleului. In sens Unix un proces este un

program în execuŃie. El îşi desfăşoară activitatea pe baza unui şir de instrucŃiuni, executate de către

procesor, iar efectul execuŃiei afectează în principal mediile de memorare internă şi externă. Cele mai

importante sarcini ale componentei se referă la comunicarea între procese şi la planificarea

procesorului (procesoarelor) pentru servirea proceselor active. Vom dedica un capitol special lucrului

cu procese sub Unix.

In Unix procesele sunt identificate prin numere de ordine. Fiecare astfel de număr îl vom numi în

continuare PID (Process IDentification). Cercurile punctate din fig. ? indică acele componente care

operează în mod direct cu procese.

Procesul cu PID-ul 0 este procesul swapper, care are drept sarcină extinderea virtuală a spaŃiului de

memorie internă. In acest scop păstrează pe disc pagini de memorie internă temporar nefolosite. La

nevoie evacuează temporar pe disc alte pagini interne, în locul cărora depune pagini solicitate, care au


fost salvate în prealabil pe disc. El (swapperul) se află permanent în memoria internă şi, natural, nu va

fi niciodată evacuat!

Procesul cu PID = 1 este procesul init, părintele tuturor proceselor utilizatorilor. El este permanent

activ şi plecând de la el se crează un şir de procese la intrarea în sistem a fiecărui utilizator. Vom

reveni cu detalii asupra acestui subiect.

1.3 Sistemul de fişiere Unix

1.3.1 Structura arborescentă şi legături suplimentare

1.3.1.1 Tipuri de fişiere şi sisteme de fişiere

In cadrul unui sistem de fişiere, Unix gestionează opt tipuri de fişiere:

1. Normale (obişnuite)

2. Directori

3. Legături hard (hard links)

4. Legături simbolice (symbolic links)

5. Socketuri (sockets)

6. FIFO - pipe cu nume (named pipes)

7. Periferice caracter

8. Periferice bloc

Fişierele obişnuite sunt privite ca şiruri de octeŃi, accesul la un octet putându-se face fie secvenŃial, fie

direct prin numărul de ordine al octetului.

Fişierele directori. Un fişier director se deosebeşte de un fişier obişnuit numai prin informaŃia

conŃinută în el. Un director conŃine lista de nume şi adrese pentru fişierele subordonate lui. Uzual,

fiecare utilizator are un director propriu care punctează la fişierele lui obişnuite, sau la alŃi subdirectori

definiŃi de el.

Fişierele speciale. In această categorie putem include, pentru moment, ultimele 6 tipuri de fişiere. In

particular, Unix priveşte fiecare dispozitiv de I/O ca şi un fişier de tip special. Din punct de vedere al

utilizatorului, nu există nici o deosebire între lucrul cu un fişier disc normal şi lucrul cu un fişier

special.

Fiecare director are două intrări cu nume speciale şi anume:

"." (punct) care punctează spre însuşi directorul respectiv;

".." (două puncte succesive), care punctează spre directorul părinte.

Fiecare sistem de fişiere conŃine un director principal numit root sau /.

In mod obişnuit, fiecare utilizator foloseşte un director curent, ataşat utilizatorului la intrarea în sistem.

Utilizatorul poate să-şi schimbe acest director (cd), poate crea un nou director subordonat celui curent,


(mkdir), să şteargă un director (rmdir), să afişeze calea de acces de la root la un director sau fişier

(pwd) etc.

ApariŃia unui mare număr de distribuitori de Unix a condus, inevitabil, la proliferarea unui număr oarecare de "sisteme de fişiere extinse" proprii livratorilor. De exemplu:

• Solaris utilizează sistemul de fişiere ufs;

• Linux utilizează sistemul de fişiere ext2 şi mai nou, ext3;

• IRIX utilizează xfs

• etc.

Actualele distribuŃii de Unix permit utilizatea unor sisteme de fişiere proprii altor sisteme de operare.

Printre cele mai importante amintim:

• Sistemul FAT, FAT32 de sub DOS şi Windows 9x;

• Sistemul NTFS propriu Windows NT şi 2000.

Din fericire, aceste extinderi sunt transparente pentru utilizatorii obişnuiŃi. Totuşi, se recomandă prudenŃă atunci când se efectuează altfel de operaŃii decât citirea din fişierele create sub alte sisteme de

operare decât sistemul curent. De exemplu, modificarea sub Unix a unui octet într-un fişier de tip doc

creat cu Word sub Windows poate uşor să compromită fişierul aşa încât el să nu mai poată fi exploatat

sub Windows!

Administratorii sistemelor Unix trebuie să Ńină cont de sistemele de fişiere pe care le instalează şi de

drepturile pe care le conferă acestora vis-a-vis de userii obişnuiŃi.

Principiul structurii arborescente de fişiere este acela că orice fişier sau director are un singur părinte.

Automat, pentru fiecare director sau fişier există o singură cale (path) de la rădăcină la directorul

curent. Legătura între un director sau fişier şi părinte o vom numi legătură naturală. Evident ea se

crează odată cu crearea directorului sau fişierului respectiv.

1.3.1.2 Legături hard şi legături simbolice

In anumite situaŃii este utilă partajarea unei porŃiuni a structurii de fişiere între mai mulŃi utilizatori. De

exemplu, o bază de date repertorizată printr-o parte a structurii de fişiere trebuie să fie accesibilă mai

multor utilizatori. Unix permite o astfel de partajare prin intermediul legăturilor suplimentare. O

legătură suplimentară permite referirea la un fişier pe alte căi decât pe cea naturală. Legăturile

suplimentare sunt de două feluri: legături hard şi legături simbolice (soft).

Legăturile hard sunt identice cu legăturile naturale şi ele pot fi create numai de către administratorul

sistemului. O astfel de legătură este o intrare într-un director care punctează spre o substructură din

sistemul de fişiere spre care punctează deja legătura lui naturală. Prin aceasta, substructura este văzută ca fiind descendentă din două directoare diferite! Deci, printr-o astfel de legătură un fişier primeşte

efectiv două nume. Din această cauză, la parcurgerea unei structuri arborescente, fişierele punctate prin

legături hard apar duplicate. Fiecare duplicat apare cu numărul de legături către el.

De exemplu, dacă există un fişier cu numele vechi, iar administratorul dă comanda:

#ln vechi linknou


atunci în sistemul de fişiere se vor vedea două fişiere identice: vechi si linknou, fiecare dintre ele

având marcat faptul că sunt două legături spre el.

legăturile hard pot fi făcute numai în interiorul aceluiaşi sistem de fişiere (detalii puŃin mai târziu).

Legăturile simbolice sunt intrări speciale într-un director, create spre a indica un punct oarecare în

structura de directori. Această intrare se comportă ca şi un subdirector al directorului în care s-a creat

intrarea. Fişierul spre care punctează (nu şi intrarea specială din director) va fi marcat cu o legătură în

plus.

In forma cea mai simplă, o legătură simbolică e crează prin comanda:

ln - s caleInStructuraDeDirectori numeSimbolic

După această comandă, caleInStructuraDeDirectori va avea marcată o legătură în plus, iar

numeSimbolic va indica (numai) către această cale.

Figura ? O structură arborescentă cu legături

Legăturile simbolice pot fi utilizate şi de către userii obişnuiŃi. De asemenea, ele pot puncta şi înafara

sistemului de fişiere (detalii puŃin mai târziu).

ArborescenŃa împreună cu legăturile simbolice conferă sistemului de fişiere Unix o structură de graf

aciclic.

In fig. ?.? este prezentat un exemplu simplu de structură de fişiere. Prin literele mari A, B, C, D, E, F,

G am indicat nume de fişiere obişnuite, nume de directori şi nume de legături simbolice. Este evident

posibil ca acelaşi nume să apară de mai multe ori în structura de directori, graŃie structurii de directori

A B . AC -

D E . AF ..D E . AG ..

E .G ..F .G ..

C:

D:

C:B:A:

E: D: E: F:

F: G: G:

/:


care elimină ambiguităŃile. Fişierele obişnuite sunt reprezentate prin cercuri, iar fişierele directori prin

dreptunghiuri.

Legăturile sunt reprezentate prin săgeŃi de trei tipuri:

• linie continuă – legăturile naturale;

• linie întreruptă – spre propriul director şi spre părinte;

• linie punctată – legături simbolice.

In fig. ? există 12 noduri - fişiere obişnuite sau directori. Privit ca un arbore, deci considerând numai

legăturile naturale, el are 7 ramuri şi 4 nivele.

Crearea celor două legături simbolice se poate face, de exemplu, prin succesiunea de comenzi:

cd /A

ln -s /A/B/D/G G Prima legătură cd /A/B/D

ln -s /A/E E A doua legătură

Pentru comoditate, am notat legătura simbolică cu ultima literă din specificarea căii.

Să presupunem acum că directorul curent este B. Vom parcurge arborele în ordinea director urmat de

subordonaŃii lui de la stânga spre dreapta. Următoarele 12 linii indică toate cele 12 noduri din

structură. Pe aceeaşi linie apar, atunci când este posibil, mai multe specificări ale aceluiaşi nod.

Specificările care fac uz de legături simbolice sunt subliniate. Cele mai lungi 7 ramuri vor fi marcate

cu un simbol # în partea dreaptă.

/ ..

/A ../A

/A/D ../A/D #

/A/E ../A/E D/E ./D/E

/A/E/F ../A/E/F D/E/F ./D/E/F #

/A/E/G ../A/E/G D/E/G ./D/E/G #

/B .

/B/D D ./D

/B/D/G D/G ./D/G /A/G ../A/G #

/B/E E ./E #

/B/F F ./F #

/C ../C #

Ce se întâmplă cu ştergerea în cazul legăturilor multiple? De exemplu, ce se întâmplă când se execută una dintre comenzile?

rm D/G sau

rm /A/G ?


Este clar că fişierul trebuie să rămână activ dacă este şters numai de către una dintre specificări.

Pentru aceasta, în descriptorul fişierului respectiv există un câmp numit contor de legare. Acesta are

valoarea 1 la crearea fişierului şi creşte cu 1 la fiecare nouă legătură. La ştergere, se radiază legătura

din directorul părinte care a cerut ştergerea, iar contorul de legare scade cu 1. Abia dacă acest contor a

ajuns la zero, fişierul va fi efectiv şters de pe disc şi blocurile ocupate de el vor fi eliberate.

1.3.2 Conceptul de montare

Spre deosebire de alte sisteme de operare DOS, Windows etc. în specificarea fişierelor Unix nu apare

zona de periferic. Acest fapt nu este întâmplător, ci este cauzat de filozofia generală de acces la

fişierele Unix. Conceptul esenŃial prin care se rezolvă această problemă este cunoscut în Unix prin

termenii de montare şi demontare a unui sistem de fişiere.

OperaŃia de montare constă în conectarea unui sistem de fişiere, de pe un anumit disc, la un director

existent pe sistemul de fişiere implicit. Administratorul lansează comanda de montare sub forma:

# mount [ optiuni ] sistemDeFisiere directorDeMontare

Efectul este conectarea indicată prin sistemDeFisiere la directorDeMontare existent pe

sistemul implicit de fişiere. OpŃiunile pot să indice caracteristicile montării. De exemplu opŃiunea rw

permite atât citirea, cât şi scrierea în subsistemul montat, în timp ce opŃiunea ro permite numai citirea

din subsistemul montat. OpŃiunea -t indică tipul sistemului de fişiere care se montează, şi în funcŃie de

tip argumentul sistemDeFisiere poate fi /dev/periferic sau dev/dsk/periferic sau

/root/periferic ş.a.m.d. Pentru detalii se va putea consulta manualul mount al sistemului de

operare curent.

OperaŃia de demontare are efectul invers şi ea se face cu comanda:

#/etc/unmount directorDeMontare

Să urmărim cele ilustrate în fig. ?. In fig. ?a este dată structura sistemului de fişiere activ. Directorul B

este vid (nu are descendenŃi). In fig ?b este dată structura de fişiere de pe un disc aflat (să zicem) pe

unitatea de disc nr. 3, cu care intenŃionăm să lucrăm. Pentru aceasta, se va da comanda privilegiată

Unix:

#/etc/mount /dev/fd3 /B

Prin ea se indică legarea discului al cărui fişier special (driver) poartă numele /dev/fd3 (şi care se

referă la discul nr. 3), la directorul vid /B Urmare a legării, se obŃine structura de fişiere activă din fig.

?c.

Cu scuzele de rigoare faŃă de cititorul pe care-l plictisim, vom face câteva precizări. Deşi ele sunt

fireşti, practica arată că sunt de multe ori încălcate, ceea ce provoacă neplăceri (şi nu numai atât).

-Nu se va cere accesul la un fişier de pe un disc decât dacă acesta este montat în structura de fişiere

implicită. -Nu se va cere demontarea unei substructuri decât dacă a fost montată în prealabil.


Figura ? OperaŃie de montare

-Scoaterea unui suport montat de pe o unitate şi înlocuirea lui cu un alt suport poate provoca pagube

mari. Să presupunem, spre exemplu, că s-a montat o structură existentă pe o anumită dischetă. Dacă înaintea demontării se scoate discheta din unitate şi se introduce alta în loc, atunci este posibil să se

piardă informaŃii de pe noua dischetă, şi, în unele cazuri, este posibilă blocarea întregului sistem!. De

altfel, sistemele Unix mai nou nici nu permit scoaterea din unitate a unui suport până când nu se

efectuează operaŃia unmount.

-Nu este posibilă legarea multiplă a unui fişier la un director părinte, decât dacă cele două se află pe

acelaşi suport fizic. (Deşi pe unele sisteme s-ar putea ca o astfel de legare să fie posibilă, însă nu o

recomandăm :(

C:

A:

D:

/: A B . . .

C D . . .. . .

B:

. . .

a) Sistem implicit inainte de montare

C:

A:

D:

/: A B . . .

C D . . .. . .

B:

. . .

c) Sistem implicit dupa montare

X: Y:

X Y . . .

. . .

b) Sistem de montat

X: Y:

/: X Y . . .

. . .


In practica implementărilor Unix, la încărcarea SO se fac automat o serie de operaŃii de montare, în

conformitate cu configurarea sistemului. IndicaŃiile de montare automată sunt trecute în fişierul

/etc/fstab. Acesta este un fişier text, având pe fiecare linie câte o montare, in care se specifică: • partiŃia Unix (periferic, sistemDeFisiere) care se montează; • directorDeMontare sub care este montată partiŃia;

• tipul sistemului de fişiere conŃinut;

• diverse opŃiuni.

Iată, spre exemplu, o porŃiune din acest fişier:

/dev/hda2 / ext3 defaults 1 1

/dev/hda7 /home ext3 defaults,nosuid,nodev,noexec

/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0

/dev/fd0 /mnt/floppy auto noauto,owner 0 0

/dev/hda3 /usr ext3 defaults,nodev 1 2

/dev/hda5 /usr/local ext3 defaults,nodev 1 2

/dev/hda6 /var ext3 defaults,nosuid,nodev,noexec

/dev/hda1 swap swap defaults 0 0

De asemenea, operaŃia de montare este practicată înglobarea SO Unix într-o reŃea de calculatoare.

Cele mai cunoscute astfel de sisteme care dirijează montările de fişiere în reŃele Unix (şi nu numai)

sunt NFS (Network File System a firmei Sun Microsystems), RFS (Remote File System a firmei

AT&T), SAMBA (produs open source). Sistemul care montează o structură de directoare de pe o altă maşină poartă numele de client (NFS, RFS, SAMBA etc.). Maşina care oferă structura spre montare

(exportă) se numeşte server (NFS, RFS, SAMBA etc.).

Montările pentru NFS sunt specificate, de asemenea, în fişierul /etc/fstab, prin linii de forma:

server1:/export/home /home nfs rw,bg,intr 0 0

server1:/export/usr/local /usr/local nfs rw,bg,intr 0 0

server2:/export/var/spool/mail /var/spool/mail nfs rw,bg,intr 0 0

In acest context se poate da o nouă caracterizare a diferenŃelor dintre legăturile hard şi cele simbolice:

legăturile hard funcŃionează numai în interiorul aceluiaşi sistem de fişiere, în timp ce legăturile

simbolice pot puncta şi spre noduri ale altui sistem de fişiere montat împreună cu sistemul de fişiere ce

conŃine legătura limbolică.

1.3.3 ProtecŃia fişierelor Unix

1.3.3.1 Drepturi de acces

Vis a vis de un fişier sau de un director, utilizatorii se împart în trei categorii:

• proprietarul fişierului (u - user).

• grupul de utilizatori (g - group), de exemplu o grupă de studenŃi participă la un acelaşi proiect,

motiv pentru care administratorul poate constitui un astfel de grup, cu drepturi specifice – de regulă mai slabe decât ale proprietarului dar mai puternice decât ale restului utilizatorilor.

• restul utilizatorilor (o – others) cei care nu sunt în primele două categorii.


Nucleul SO Unix identifică utilizatorii prin numere naturale asociate unic, numite UID-uri (User

IDentifications). De asemenea, identifică grupurile de utilizatori prin numere numite GID-uri (Group

IDentifications).

Un utilizator aparte, cu drepturi depline asupra tuturor fişierelor este root sau superuserul.

Pentru fiecare categorie de utilizatori, sunt permise maximum trei drepturi

• dreptul de citire (r – read)

• dreptul de scriere (w – write) care include crearea de subdirectori, stergerea de subdirectori,

adăugarea sau ştergerea de intrări în director etc.

• dreptul de execuŃie (x - execution) care permite lansarea în execuŃie a unui fişier. Acest drept,

conferit unui director, permite accesul în directorul respectiv (cd).

Drept urmare, pentru specificarea drepturilor de mai sus asupra unui fişier sau director sunt necesari 9

(nouă) biŃi. Reprezentarea externă a acestei configuraŃii se face printr-un grup de 9 (nouă) caractere:

rwxrwxrwx în care absenŃa unuia dintre drepturi la o categorie de useri este indicată prin – (minus).

1.3.3.2 BiŃii setuid şi setgid

Există încă doi biŃi importanŃi relativ la drepturile de acces, aşa numiŃii bit setuid (set-user-id) şi bitul setgid, care conferă un statut similar pentru grupul de utilizatori.

Dacă pentru un fişier executabil bitul setuid este 1, atunci un utilizator care lansează în execuŃie

acest fişier (evident dacă are dreptul să-l lanseze) primeşte, pe timpul execuŃiei, aceleaşi drepturi de

acces la resurse (fişiere, semafoare, zone de memorie etc.) ca şi proprietarul fişierului executabil.

Să vedem o situaŃie concretă în care este utilă folosirea bitului setuid. Un utilizator cu numele

profesor întreŃine un fişier note al cărui proprietar este. Din raŃiuni lesne de înŃeles, drepturile

fişierului note sunt fixate la rw-------. Utilizatorul profesor doreşte să permită utilizatorilor

din grupul studenti să vadă unele informaŃii din fişierul note.

Pentru aceasta, profesor creează un fişier executabil examen (proprietarul lui examen este

profesor) care permite citirea (eventual selectivă) de informaŃii din fişierul note. Proprietarul

atribuie pentru examen drepturile rwx--x- —x şi pune bitul setuid al lui examen pe 1. Noile

drepturi afişate ale lui examen sunt: rws--x- —x

Utilizatorii studenti, în momentul lansării programului examen, primesc aceleaşi drepturi de

acces la fişiere ca şi profesor. In particular programul examen poate accesa fişierul note (vezi

drepturile acestui fişier) chiar dacă el nu a fost lansat în execuŃie de către profesor. In absenŃa lui

setuid pentru examen, acesta poate fi, totuşi lansat în execuŃie, însă nu poate să acceseze fişierul

note.

Nucleul SO Unix identifică utilizatorii prin numere naturale asociate unic, numite UID-uri (User

IDentifications). De asemenea, identifică grupurile de utilizatori prin numere numite GID-uri (Group

IDentifications).


Pe parcursul execuŃiei programului examen acestuia i se mai asociază în plus identificatorul EUID

(effective UID), care coincide cu UID-ul lui prof, prin care asigură accesul la resurse.

Mecanismul set-uid permite o foarte elastică manevrare a fişierelor. In schimb, dacă superuserul

gestionează prost acest mecanism, atunci potenŃialii infractori au un câmp larg de acŃiune. Să considerăm, din raŃiuni evidente, doar un scenariu simplu: Presupunem ca root este proprietar al unui

fişier executabil cu bitul setuid setat şi cu drept de scriere pentru alŃii. In această situaŃie, un

răuvoitor poate să modifice acest fişier executabil aşa încât să aibă o acŃiune malefică ce presupune

acces la resurse ale superuserului!. AcŃiunea se va putea executa deoarece EUID-ul este UID-ul lui

root!

Modificarea drepturilor de acces la fişiere se poate face numai de către proprietarul fişierului (sau de

către superuser), folosind comanda chmod. Modificarea proprietarului sau a grupului se poate face, în

aceleaşi condiŃii folosind comanda chown.

Un exemplu tipic în care se foloseşte setuid este comanda /usr/bin/passwd. Aceasta este

lansată de către fiecare utilizator atunci când doreşte să-şi schimbe parola. Efectul ei se răsfrânge

asupra fişierului /etc/shadow. In acest scop, se stabilesc drepturile:

-r-s--x--x 1 root root 22312 Sep 25 18:52 /usr/bin/passwd

-r-------- 1 root root 10256 Mar 2 14:40 /etc/shadow

Deci passwd are setuid, ceea ce permite accesul la /etc/shadow numai prin programul

/usr/bin/passwd.

1.3.3.3 Drepturi implicite: umask

In momentul intrării unui user în sistem, acestuia i se vor acorda nişte drepturi implicite. Toate fişierele

şi directoarele create de user pe durata sesiunii de lucru îl vor avea ca proprietar, iar drepturile vor fi

cele primite implicit. Fixarea drepruriloe implicite sau aflarea valorii acestora se poate face folosind

comanda umask. Drepturile implicite sunt stabilite scăzând (octal) masca definită prin umask din

777.

Pentru a se afla valoarea măştii se lansează: umask

Rezultatul este afişarea măştii, care este de regulă 022. Deci drepturile implicite vor fi: 777-022=755,

adică userul are toate drepturile, iar grupul şi restul vor avea doar drepturi de citire şi de execuŃie.

Dacă se doreşte schimbarea acestei măşti pentru a da userului toate drepturile, grupului de citire şi execuŃie iar restului nici un drept, adică drepturile implicite 750, fiindcă 777-027=750. Deci se va da

comanda:

umask 027

Efectul ei va rămâne valabil până la un nou umask sau până la încheierea sesiunii.


1.3.4 Principalele directoare ale unui sistem de fişiere Unix

De-a lungul evoluŃiei sistemelor din familia Unix, partea superioară a structurii sistemului de fişiere a

avut mai mult sau mai puŃin o formă standard. De fapt, fiecare versiune Unix şi-a fixat o structură specifică a părŃii superioare din sistemul de fişiere. DiferenŃele între aceste structuri nu sunt prea mari.

Mai mult, din raŃiuni de compatibilitate, versiunile mai noi definesc legături suplimentare hard (nu

legături simbolice), pentru a asigura compatibilitatea cu sistemele de fişiere mai vechi. Din această cauză este cel mai nimerit să se studieze o reuniune a celor mai răspândite structuri. O astfel de

structură este prezentată de noi în fig. ?.?

Figura ?.? Structura superioară a unui sistem de fişiere Unix

home

etc

usr

bin

sbin

lib

include

share

ucb

ccs

src

sbin

bin

dev

lib

stand

mnt

spool

tmp

var

export

preserve

adm

tmp

opt

cron

mail

news

uucp

saf

spool


Directorul /etc conŃine informaŃii specifice maşinii necesare întreŃinerii sistemului. Acestea sunt de

fapt datele restrictive şi periculoase din sistem. Un exemplu de fişier ce conŃine informaŃii specifice

maşinii este, spre exemplu, /etc/rc2.d care este un director ce conŃine programe shell executate de

procesul init la schimbarea stării. Tot aici sunt plasate fişierele /etc/passwd, /etc/group,

/etc/shadow care sunt folosite pentru administrarea utilizatorilor.

Directorul /home este folosit pentru directorii gazdă ai utilizatorilor. In momentul intrării în sistem,

fiecare utilizator indică directorul lui, care este fixat ca director curent (home directory) in /etc/passwd.

Deşi se poate trece uşor de la un director la altul, în mod normal fiecare utilizator rămâne în propriul

lui director, unde îşi dezvoltă propria lui structură arborescentă de directori.

Directorul /usr este folosit în mod tradiŃional pentru a stoca fişiere ce pot fi modificate. La primele

versiuni de Unix conŃinea şi fişierele utilizatorilor. In prezent este punctul de montare pentru partiŃia ce

conŃine usr. In prezent, el contine programe executabile dependente şi independente de sistemul de

fişiere, precum şi fişiere necesare acestora, dar care nu cresc dinamic. Asupra conŃinutului de

subdirectoare ale lui /usr vom reveni puŃin mai târziu.

Directorul /bin conŃine programele principalelor comenzi standard Unix: compilatoare, asambloare,

editoare de texte, utilitare etc. Versiunile mai noi de Unix plasează acest director în /usr/bin.

Directorul /sbin (super-utilizator bin) conŃine comenzi critice pentru procedura de încărare a

sistemului. Orice comenzi administrative care necesită lucrul mono-utilizator sunt în acest director.

Copii ale acestor comenzi se află în directoarele /usr/bin şi /usr/sbin astfel încât el (/sbin)

poate fi refăcut dacă este necesar.

Directorul /lib conŃine diverse biblioteci şi baze de date necesare apelurilor sistem. Doar versiunile

mai vechi de Unix plasează acest director în /, cele actuale îl plasează în /usr/lib.

Directorul /dev este folosit pentru memorarea fişierelor speciale (fişierele devices). Practic, fiecare

tip de terminal şi fiecare tip de unitate de disc trebuie să aibă asociat un astfel de fişier special.

Incepând cu SVR4 se permite ca în dev să existe şi subdirectoare care să grupeze astfel de device-uri.

Directorul /stand conŃine informaŃiile necesare încărcării sistemului.

Directorul /mnt este folosit pentru a monta un sistem de fişiere temporar. De exemplu, un sistem de

fişiere de pe un disc flexibil poate fi montat în /mnt pentru a verifica fişierele de pe această dischetă.

Directorul /spool este plasat în / doar în versiunile mai vechi de Unix. In el sunt memorate fişierele

tampon temporare destinate prelucrărilor asincrone: listări asincrone de fişiere (/spool/lpd) şi execuŃia la termen a unor comenzi (/spool/at).

Directorul /export este folosit ca punct implicit de montare pentru un arbore de sistem de fişiere

exportat pentru fişierele în reŃea gestionate prin pachetul NFS (network file system).

Directorul /var este folosit pentru memorarea fişierelor care cresc dinamic. In particular, multe dintre

versiunile de Unix Ńin în acest director fişierele INBOX cu căsuŃele poştale ale utilizatorilor. Structura

de subdirectoare a lui /var le vom descrie ceva mai încolo.


Directorul /tmp este folosit pentru a memora fişiere temporare pentru aplicaŃii. In mod normal aceste

fişiere nu sunt salvate şi sunt şterse după o perioadă de timp.

In continuare vom descrie pe scurt conŃinutul directorului /usr. După cum se poate vedea, unele

dintre subdirectoare sunt plasate (şi au fost descrise) la nivel de rădăcină /. Versiunile mai noi de

Unix, începând cu SVR4, le-au coborât din rădăcină ca subdirectoare ale lui /usr. Este cazul

directoarelor bin, sbin, lib.

Directorul /usr/include conŃine fişierele header (*.h) standard ale limbajului C de sub Unix.

Directorul /usr/share conŃine o serie de directoare partajabile în reŃea. In multe dintre sistemele

noi, în el se află directoarele: man cu manualele Unix, src cu sursele C ale nucleului Unix şi lib mai

sus prezentat.

Directorul /usr/ucb conŃine programele executabile compatibile Unix BSD.

Directorul /usr/src conŃîne textele sursă C ale nucleului Unix de pe maşina respectivă.

Directorul /usr/ccs conŃine instrumentele de dezvoltare a programelor C oferite de Unix: cc, gcc,

dbx, cb, indent etc.

In continuare vom descrie conŃinutul directorului /var. Ca şi mai sus, unele subdirectoare de la

nivelele superioare au fost mutate aici de către versiunile mai noi de Unix. Este vorba de directoarele

spool şi tmp.

Directorul /var/saf conŃine fişiere jurnal şi de contabilizare a serviciilor oferite.

Directorul /var/uucp conŃine programele necesare efectuării de copieri de fişiere între sisteme Unix

(Unix to Unix CoPy). Acest gen de servicii este primul pachet de comunicaŃii instalat pe sisteme Unix,

este operaŃional încă din 1978 şi este utilizat şi astăzi atunci când nu există alt mijloc mai modern de

comunicaŃii. Un astfel de sistem permite, de exemplu, apelul telefonic între două sisteme Unix, iar

după luarea contactului cele două sisteme îşi schimbă între ele o serie de fişiere, ca de exemplu

mesajele de poştă electronică ce le sunt destinate.

Directorul /var/news conŃine fişierele necesare serviciului de noutăŃi (news) care poate fi instalat pe

maşinile Unix.

Directorul /var/mail conŃine căsuŃele poştale implicite ale utilizatorilor (INBOX). Pe unele sisteme,

ca de exemplu pe LINUX, acestea se află în /var/spool/mail.

Directorul /var/cron conŃine fişierele jurnal necesare serviciilor executate la termen.

Directorul /var/opt constituie un punct de montare pentru diferite pachete de aplicaŃii.

Directorul /var/preserve conŃine, la unele implementări Unix (SVR4) fişiere jurnal destinate

refacerii stării editoarelor de texte “picate” ca urmare a unor incidente.


Directorul /var/adm conŃine fişiere jurnal (log-uri) de contabilizare şi administrare a sistemului.

După cum se poate vedea uşor, structura de directori Unix începând de la rădăcină este relativ

dependentă de tipul şi versiunea de Unix. De fapt, este vorba de “Unix vechi” şi “Unix noi”. De

asemenea, multe dintre directoare au fost înlocuite sau li s-a schimbat poziŃia în structura de directori.

Tabelul de mai jos prezintă câteva corespondenŃe între vechile şi noile plasări de fişiere.

Nume vechi Nume nou

/bin /usr/bin

/lib /usr/lib

/usr/adm /var/adm

/usr/spool /vsr/spool

/usr/tmp /var/tmp

/etc/termcap /usr/share/lib/termcap

/usr/lib/terminfo /usr/share/lib/terminfo

/usr/lib/cron /etc/cron.d

/usr/man /usr/share/man

/etc/<programe> /usr/bin/<programe>

/etc/<programe> /sbin/<programe>

1.4 Structura internă a discului Unix

1.4.1 PartiŃii şi blocuri

Un sistem de fişiere Unix este găzduit fie pe un periferic oarecare (hard-disc, CD, dischetă etc.), fie pe

o partiŃie a unui hard-disc. PartiŃionarea unui hard-disc este o operaŃie (relativ) independentă de

sistemul de operare ce va fi găzduit în partiŃia respectivă. De aceea, atât partiŃiilor, cât şi suporturilor

fizice reale le vom spune generic, discuri Unix.

Blocul 0 - bloc de boot

Blocul 1 - Superbloc

Blocul 2 - inod

- - - - - - - - - - - -

-

Blocul n - inod

Blocul n+1 zona fişier

- -- - - - - - - - - - -

Blocul n+m zona fişier

Figura ? Structura unui disc Unix

Un fişier Unix este o succesiune de octeŃi, fiecare octet putând fi adresat în mod individual. Este permis

atât accesul secvenŃial, cât şi cel direct.


Unitatea de schimb dintre disc şi memorie este blocul. La sistemele mai vechi acesta are 512 octeŃi, iar la

cele mai noi până la 4Ko, pentru o mai eficientă gestiune a spaŃiului.

Un sistem de fişiere Unix este o structură de date rezidentă pe disc. Aşa după cum se vede din fig. ?, un

disc este compus din patru categorii de blocuri.

Blocul 0 conŃine programul de încărcare al SO. Acest program este dependent de maşina sub care

se lucrează.

Blocul 1 este numit şi superbloc. In el sunt trecute o serie de informaŃii prin care se defineşte

sistemul de fişiere de pe disc. Printre aceste informaŃii amintim:

-numărul n de inoduri (detaliem imediat);

-numărul de zone definite pe disc;

-pointeri spre harta de biŃi a alocării inodurilor;

-pointeri spre harta de biŃi a spaŃiului liber disc;

-dimensiunile zonelor disc etc.

Blocurile 2 la n, unde n este o constantă a formatării discului. Un inod (sau i-nod) este numele, în

terminologia Unix, a descriptorului unui fişier. Inodurile sunt memorate pe disc sub forma unei liste

(numită i-listă). Numărul de ordine al unui inod în cadrul i-listei se reprezintă pe doi octeŃi şi se numeşte

i-număr. Acest i-număr constituie legătura dintre fişier şi programele utilizator.

Partea cea mai mare a discului este rezervată zonei fişierelor. Alocarea spaŃiului pentru fişiere se

face printr-o variantă elegantă de indexare. InformaŃiile de plecare pentru alocare sunt fixate în inoduri.

1.4.2 Directori şi inoduri

Structura unei intrări într-un fişier director este ilustrată în fig. ?.

Numele fişierului (practic oricât de lung) inumăr Figura ? Structura unei intrări în director

Deci, în director se află numele fişierului şi referinŃa spre inodul descriptor al fişierului.

Un inod are, de regulă, între 64 şi 128 de octeŃi şi el conŃine informaŃiile din tabelul următor:

mode Drepturile de acces şi tipul fişierului.

link count Numărul de directoare care conŃin referiri la acest inumăr, adică numărul de legături spre acest fişier.

user ID Numărul (UID) de identificare a proprietarului.

group ID Numărul (GID) de identificare a grupului.

size Numărul de octeŃi (lungimea) fişierului.

access time Momentul ultimului acces la fişier.

mod time Momentul ultimei modificări a fişierului.

inode time Momentul ultimei modificări a structurii inodului.


block list Lista adreselor disc pentru primele blocuri care aparŃin fişierului.

indirect list ReferinŃe către celelalte blocuri care aparŃin fişierului.

1.4.3 Schema de alocare a blocurilor disc pentru un fişier

Fiecare sistem de fişiere Unix are câteva constante proprii, printre care amintim: lungimea unui bloc,

lungimea unui inod, lungimea unei adrese disc, câte adrese de prime blocuri se înregistrează direct în inod

şi câte referinŃe se trec în lista de referinŃe indirecte. Indiferent de valorile acestor constante, principiile de

înregistrare / regăsire sunt aceleaşi.

Pentru fixarea ideilor, vom alege aceste constante cu valorile întâlnite mai frecvent la sistemele de fişiere

deja consacrate. Astfel, vom presupune că un bloc are lungimea de 512 octeŃi. O adresă disc se reprezintă pe 4 octeŃi, deci într-un bloc se pot înregistra 128 astfel de se adrese. In inod trec direct primele 10 adrese

de blocuri, iar lista de adrese indirecte are 3 elemente. Cu aceste constante, în fig. ? este prezentată structura pointerilor spre blocurile ataşate unui fişier Unix.

Figura ? Structura unui inod şi accesul la blocurile unui fişier

1 2 . . . 10 11 12 13Identificare 9Inod:

. . .Regasire

directa:

1 128. . .

. . .

Indirectare simpla:

1 128. . .

. . .

Indirectare dubla:

1 128. . .

. . .

1 128. . .

. . .

Indirectare tripla:

1 128. . .

. . .1 128. . .

. . .

1 128. . .

. . .

1 128. . .

. . .1 128. . .

. . .

1 128. . .

. . .

1 128. . .

. . .1 128. . .

. . .

1 128. . .

. . .. . .

. . .

. . .


In inodul fişierului se află o listă cu 13 intrări, care desemnează blocurile fizice aparŃinând fişierului.

• Primele 10 intrări conŃin adresele primelor 10 blocuri de câte 512 octeŃi care aparŃin fişierului.

• Intrarea nr. 11 conŃine adresa unui bloc, numit bloc de indirectare simplă. El conŃine adresele

următoarelor 128 blocuri de câte 512 octeŃi, care aparŃin fişierului.

• Intrarea nr. 12 conŃine adresa unui bloc, numit bloc de indirectare dublă. El conŃine adresele a 128

blocuri de indirectare simplă, care la rândul lor conŃin, fiecare, adresele a câte 128 blocuri, de 512

octeŃi fiecare, cu informaŃii aparŃinând fişierului.

• Intrarea nr. 13 conŃine adresa unui bloc, numit bloc de indirectare triplă. In acest bloc sunt

conŃinute adresele a 128 blocuri de indirectare dublă, fiecare dintre acestea conŃinând adresele a

câte 128 blocuri de indirectare simplă, iar fiecare dintre acestea conŃine adresele a câte 128

blocuri, de câte 512 octeŃi, cu informaŃii ale fişierului. .

In fig. ? am ilustrat prin cercuri blocurile de informaŃie care aparŃin fişierului, iar prin dreptunghiuri

blocurile de referinŃe, în interiorul acestora marcând referinŃele.

Numărul de accese necesare pentru a obŃine direct un octet oarecare este cel mult 4. Pentru fişiere mici

acest număr este şi mai mic. Atât timp cât fişierul este deschis, inodul lui lui este prezent în memoria

internă. Tabelul următor dă numărul maxim de accese la disc pentru a obŃine, în acces direct orice octet

dintr-un fişier, în funcŃie de lungimea fişierului.

Lungime

maximă

(blocuri)

Lungime

maximă

(octeŃi)

Accese

indirecte

Accese

la

informaŃie

Total

accese

10 5120 - 1 1

10+128 = 138 70656 1 1 2

10+128+128^2 = 16522 8459264 2 1 3

10+128+128^2+128^3=

2113674

1082201088 3 1 4

La sistemele Unix actuale lungimea unui bloc este de 4096 octeŃi care poate înregistra 1024 adrese, iar în

inod se înregistrează direct adresele primelor 12 blocuri. In aceste condiŃii, tabelul de mai sus se

transformă în:

Lungime

maximă

(blocuri)

Lungime

maximă

(octeŃi)

Accese

indirecte

Accese

la

informaŃie

Total

accese

12 49152 - 1 1

12+1024 = 1036 4243456 1 1 2

12++1024+1024 ^2

= 1049612

4299210752 2 1 3

12+1024+1024 ^2+1024^3

= 1073741824

4398046511104

(peste 5000Go)

3 1 4

Practic, orice fişier actual, indiferent de mărimea lui, poate fi reprezentat printr-o astfel de schemă.


1.4.4 Accesul proceselor la fişiere

Unix priveşte conceptul de fişier într-un sens ceva mai larg decât o fac alte sisteme de operare. Aşa cum

am mai arătat mai sus, există opt tipuri de fişiere:

• normale,

• directori,

• legături hard,

• legături simbolice,

• FIFO, (pipe cu nume),

• socketuri,

• periferice caracter,

• periferice bloc.

Pe lângă acestea, nucleul mai gestionează, într-o semantică similară fişierelor, următoarele patru tipuri

de comunicaŃii între procese:

• pipe anonime (a se deosebi de FIFO - pipe cu nume);

• segmente de memorie partajată; • cozi de mesaje;

• semafoare.

Suporturile fizice pentru aceste 12 tipuri de fişiere sunt, în ultimă instanŃă: • Zona fişierelor pe disc, pentru fişierele normale, directori, legături hard şi simbolice, FIFO şi

socket din familia Unix.

• Perifericul respectiv pentru perifericele caracter şi bloc.

• Zone rezervate de nucleu în memoria internă, pentru pipe, memorie partajată, cozi de mesaje şi semafoare.

• InterfaŃa de comunicaŃie prin reŃea, pentru socket din familia Internet.

Pentru a putea asigura o tratare uniformă a fişierelor în această diversitate, traseul accesului unui proces la

un fişier trece prin mai multe nivele: proces, sistem, inod, fişier, aşa cum se vede în fig. ?

Nivelul proces. Fiecare proces îşi întreŃine o tabelă proprie în care înregistrează toate fişierele lui deschise.

In fig. ? am notat cu a-j câteva intrări de pe acest nivel.

Nivelul sistem întreŃine o tabelă unică cu toate fişierele deschise de către toate procesele din sistem. In

fig. ? am notat prin k-r câteva intrări din această tabelă.

Nivelul inod este de fapt zona (zonele) de inoduri de pe disc. Pentru fişierele deschise, se păstrează în

memoria internă copii ale inodurilor corespunzătoare. In fig. ? am notat prin s-w câteva astfel de intrări.

Nivelul fişier este reprezentat de blocurile disc ce aparŃin fişierului. In fig. ? am notat F1-F4 astfel de

fişiere.

Tabela de fişiere la nivel proces are intrările numerotate începând de la 0. Primele trei intrări sunt

rezervate astfel:

• intrarea 0 este rezervată intrării standard a procesului (vezi în fig. ? intrările a din procesul A şi g

din procesul C);


• intrarea 1 este rezervată ieşirii standard (vezi intrările b, e, h din fig. ?);

• intrarea 2 este rezervată fişierului standard de erori (unde suistemul afişează mesajele de eroare

pentru proces - vezi intrările c, i din fig. ?).

După cum se va vedea în secŃiunile următoare, toate apelurile sistem de lucru cu fişiere folosesc pentru

identificare un număr întreg numit handle sau descriptor de fişier. Acest întreg este chiar indexul intrării fişierului în tabela procesului respectiv.

Figura ? CorespondenŃa Unix între procese şi fişiere

In gestiunea fişierelor deschise pe aceste patru nivele, marea majoritate a fişierelor au exact câte o singură intrare pe fiecare nivel, corespunzătoare fişierului respectiv. De exemplu, procesul A din fig. ? vede

fişierul F1 prin intermediul intrărilor b, k, s din cele trei tabele. De asemenea, procesul C vede

fişierul F4 prin intermediul intrărilor g, p, v.

In Unix este posibil ca mai multe procese să deschidă, în acelaşi timp, un acelaşi fişier -multiacces la

fişiere. Acest lucru este posibil prin faptul că două intrări de fişiere din două procese pot puncta spre

a

b

c

d

Fisiere

proces A

---

g

h

i

j

Fisiere

proces C

--

-

e

f

Fisiere

proces B

---

-

--

k

l

m

Tabela fisierelor

deschise in sistem

---

---

n

p

r

---

q

o

---

s

t

Tabela de inoduri

---

---

u

v

w

---

F1

F2

F3

F4

Fisiere

NucleuAlt SO


aceeaşi intrare din tabela sistem. In fig. ? intrarea c de la procesul A şi intrarea f de la procesul B folosesc

în comun acelaşi fişier, cel localizat de intrarea l din tabela sistem.

De regulă, fiecare intrare din tabela sistem punctează spre un inod, iar intrări diferite punctează spre

inoduri diferite. Aşa sunt, de exemplu, legăturile k-s, l-u, p-v, q-w.

Sunt interesante abaterile de la regula de mai sus. Astfel, spre exemplu avem legăturile m-t şi n-t.

Această corespondenŃă este posibilă în cazul în care cel puŃin una dintre intrările m sau n se referă la o

legătură simbolică.

Legăturile din o şi din r nu punctează spre nici un inod. Legătura o este un canal de tip pipe, memorie

partajată, coadă de mesaje sau semafor, acestea fiind găzduite în nucleu. Legătura r este un socket, prin

care se realizează legătura prin reŃea cu un alt sistem de operare.

In fine, în marea majoritate a cazurilor există o corespondenŃă biunivocă între inoduri şi fişierele

corespunzătoare. In fig. ? avem corespondenŃele s-F1, t-F2, v-F3.

Abaterea de la această regulă este făcută doar de legăturile hard. Fiecare astfel de legătură crează un

nou inod pentru acelaşi fişier. In fig. ? avem corespondenŃele u-F3 şi w-F3, cel puŃin una dintre u şi w fiind o legătură hard.

01UnixVersiuniStructuri

Documents