Estudi sistema fitxers ext2 -...

Abstract Aquest treball pretén estudiar en profunditat els sistemes de fitxers Linux centrant-nos en el sistema de fitxers Ext2. L’estudi no pretén donar una visió superficial d’Ext2 sinó que s’estudiarà en detall el seu funcionament intern (visió de programador). Per tal de reafirmar els coneixements assolits en l’estudi teòric d’aquest sistema de fitxers, s’implementarà una aplicació docent que pretén ajudar als alumnes de l’assignatura de Sistemes Operatius a la comprensió general dels sistemes de fitxers Linux. Això, s’aconseguirà mitjançant una interfície intuïtiva i amigable que facilitarà en gran mesura la comprensió del que es pretén explicar.

Estudi del sistema de fitxers Ext2

1

Resum En aquest treball, es pretén fer un estudi dels sistemes de fitxers Linux centrant-nos en el que fins fa poc va ser el sistema de fitxers de referència de Linux, Ext2. Aquest treball pretén trencar amb la tònica d’alguns llibres que es limiten a descriure Ext2 de forma superficial donant a entendre al lector que Ext2 únicament està basat en Inodes. Com veurem més endavant Ext2 té altres estructures de dades importants com són el cas del Superbloc, el Group Descriptor etc. L’estudi pretén donar una doble visió al lector. Per una banda purament didàctica, basada en l’estudi dels principals elements d’una partició Ext2 així com el seu funcionament general, i per altre banda pretén donar una visió de programador descrivint detalladament la posició dels camps més rellevants. El treball per tant, no es tracta únicament d’un manual del funcionament intern d’Ext2 sinó que un cop vist aquest es passa a descriure com s’executarien internament un conjunt de comandes bàsiques com és el cas de mostrar el contingut d’un fitxer, accedir a un directori, esborrar el contingut d’un directori etc. Per tal de desenvolupar la part pràctica del projecte, analitzarem diverses eines similars a la creada, per tal d’extreure’n els punts forts i intentar millorar els punts dèbils. D’aquesta forma ens assegurem de crear una eina que representi una millora (en quan a la funció pedagògica) respecte les altres eines existents en el mercat. Finalment entrarem a detallar l’eina docent creada específicament per els alumnes de l’assignatura de Sistemes Operatius. L’eina es tracta d’un lector d’imatges Ext2. L’objectiu de l’eina és que sigui útil per als alumnes, i per aquest motiu s’ha preferit donar més importància a les explicacions de com accedeix l’eina a la imatge Ext2 que al nombre de funcionalitats d’aquesta. L’eina permet que els alumnes entenguin d’on (la posició dins de la imatge Ext2) s’extreuen certes dades així que com es realitzen certs càlculs previs a la presentació de les dades.


2

Índex 1. Introducció .......................................................................................................... 6 1.1. Enfocament del treball ................................................................................. 6 1.2. Objectius ...................................................................................................... 6 1.3. Estructura de la memòria ............................................................................. 7

2. Descripció de l’entorn ......................................................................................... 8 2.1. Introducció als sistemes de fitxers ............................................................... 8 2.2. Origen d’Ext2 ............................................................................................. 11 2.3. Noves funcionalitats d’Ext2 ........................................................................ 12 2.4. Nous sistemes de fitxers ............................................................................ 13

3. Estructura física de dades ................................................................................ 15 3.1. Superblock ................................................................................................. 16 3.2. Group descriptor ........................................................................................ 19 3.3. Block bitmap............................................................................................... 21 3.4. Inode bitmap .............................................................................................. 22 3.5. Inode table ................................................................................................. 22 3.6. Data blocks ................................................................................................ 26 3.6.1. Directoris ............................................................................................. 28 3.6.1.1. Carpeta Lost + Found ................................................................... 28

3.6.2. Fitxers .................................................................................................. 29 3.6.3. Links .................................................................................................... 31

4. Explicació comandes bàsiques ......................................................................... 33 4.1. Llistat root .................................................................................................. 33 4.2. Arbre de directoris ...................................................................................... 33 4.3. Mostrar el contingut d’un fitxer ................................................................... 34 4.4. Creació d’una carpeta ................................................................................ 34 4.5. Creació d’un link ......................................................................................... 35 4.6. Creació d’un fitxer ...................................................................................... 35 4.7. Esborrat d’un fitxer ..................................................................................... 36 4.8. Esborrat d’un directori ................................................................................ 36

5. Aplicacions similars .......................................................................................... 38 5.1. Explore2fs .................................................................................................. 38 5.2. Ltools ......................................................................................................... 39 5.3. Ext2ifs ........................................................................................................ 40 5.4. Altres .......................................................................................................... 41

6. Aplicació E2_rdr................................................................................................ 42 6.1. Introducció ................................................................................................. 42 6.2. Anàlisi requisits .......................................................................................... 42 6.2.1. Requisits funcionals ............................................................................. 42 6.2.2. Requisits usabilitat ............................................................................... 43

6.3. Decisions disseny ...................................................................................... 43 6.3.1. Entorn execució ................................................................................... 43 6.3.2. Entorn programació ............................................................................. 44

6.4. Anàlisi funcional ......................................................................................... 45 6.4.1. Modelat estàtic .................................................................................... 45 6.4.1.1. Diagrama de casos d’ús ................................................................ 45 6.4.1.2. Diagrama de classes..................................................................... 51

6.4.2. Modelat dinàmic .................................................................................. 61


3

6.5. Evolució projecte ........................................................................................ 63 6.6. Proves realitzades ...................................................................................... 64 6.7. Posada en explotació ................................................................................. 65

7. Manual de funcionament de l’aplicació ............................................................. 66 7.1. Prerequisits ................................................................................................ 66 7.1.1. Creació partició Ext2 ........................................................................... 66 7.1.2. Muntar partició Ext2 ............................................................................. 66

7.2. Execució aplicació ...................................................................................... 67 7.2.1. Superbloc ............................................................................................ 67 7.2.2. Group Descriptor ................................................................................. 68 7.2.3. Inode Bitmap ....................................................................................... 68 7.2.4. Block Bitmap ........................................................................................ 69 7.2.5. Arbre de directoris ............................................................................... 70

8. Cost realització projecte ................................................................................... 72 9. Conclusions ...................................................................................................... 73 10. Línies de futur ................................................................................................. 76 11. Bibliografia ...................................................................................................... 78 12. Annex ............................................................................................................. 80 12.1. Notació usada .......................................................................................... 80 12.2. Unix Time ................................................................................................. 80


4

Índex de figures Figura 1. Captura dels camps més rellevants del Superbloc ................................ 18 Figura 2. Captura dels camps més rellevants del Group Descriptor ..................... 20 Figura 3. Captura del Block Bitmap ...................................................................... 21 Figura 4. Captura inode bitmap ............................................................................ 22 Figura 5. Estructura Inode .................................................................................... 25 Figura 6. Captura d’un inode corresponent a un fitxer de text .............................. 25 Figura 7. Captura inode que conté un link ............................................................ 26 Figura 8. Captura datablock corresponent al root de la partició ........................... 27 Figura 9. Captura informació Superbloc i de fitxer ................................................ 38 Figura 10. Captura Ltools ..................................................................................... 39 Figura 11. Captura Ext2ifs .................................................................................... 41 Figura 12. Diagrama casos ús .............................................................................. 45 Figura 13. Diagrama de classes ........................................................................... 51 Figura 14. Classe Program ................................................................................... 51 Figura 15. Classe form_ppal ................................................................................. 52 Figura 16. Classe Ext2 ......................................................................................... 53 Figura 17. Classe inode ........................................................................................ 53 Figura 18. Classe super_bloc ............................................................................... 54 Figura 19. Classe group_desc .............................................................................. 54 Figura 20. Classe form_superbloc ........................................................................ 55 Figura 21. Classe form_groupdesc ....................................................................... 56 Figura 22. Classe form_inode_bitmap .................................................................. 57 Figura 23. Classe form_block_bitmap .................................................................. 57 Figura 24. Classe form_tree ................................................................................. 58 Figura 25. Classe tree_aux ................................................................................... 59 Figura 26. Classe form_exporta_fitxer .................................................................. 59 Figura 27. Classe form_imatge ............................................................................. 60 Figura 28. Classe func_aux_tree .......................................................................... 60 Figura 29. Classe form_ajuda ............................................................................... 61 Figura 30. Diagrama de seqüència Obrir imatge Ext2 .......................................... 61 Figura 31. Diagrama de seqüència Mostrar imatge jpg ........................................ 62 Figura 32. Diagrama de seqüència Exportar fitxer ............................................... 62 Figura 33. Captura Superbloc ............................................................................... 67 Figura 34. Captura Group Descriptors .................................................................. 68 Figura 35. Captura Inode Bimap ........................................................................... 69 Figura 36. Captura Block Bitmap .......................................................................... 70 Figura 37. Captura Arbre Directoris ...................................................................... 71


5

Índex de taules Taula 1. Estructura d’una Partició Ext2 ................................................................. 15 Taula 2. Estructura d’un block group .................................................................... 15 Taula 3. Càlcul de la mida de bloc ........................................................................ 16 Taula 4. Càlcul de la mida del fragment ............................................................... 16 Taula 5. Estructura del Group Descriptor ............................................................. 19 Taula 6. Càlcul per posicionar-nos a l’inici dels Group Descriptors ...................... 19 Taula 7. Càlcul per posicionar-nos a un block bitmap donat ................................ 21 Taula 8. Càlcul per posicionar-nos a un inode bitmap donat ................................ 22 Taula 9. Càlculs per posicionar-nos a un inode donat .......................................... 23 Taula 10. Exemple posicionament a partir d’un inode donat ................................ 23 Taula 11. Representació directoris en un datablock ............................................. 28 Taula 12. Limitacions Ext2 .................................................................................... 30 Taula 13. Contingut d’un inode que conte un link ................................................. 32 Taula 14. Especificació cas d’ús mostrar ajuda .................................................... 46 Taula 15. Especificació cas d’ús obrir imatge ....................................................... 46 Taula 16. Especificació cas d’ús mostrar Superbloc ............................................ 47 Taula 17. Especificació cas d’ús mostrar group descriptors ................................. 47 Taula 18. Especificació cas d’ús mostrar block bitmap......................................... 48 Taula 19. Especificació cas d’ús mostrar inode bitmap ........................................ 48 Taula 20. Especificació cas d’ús mostrar arbre de directori .................................. 49 Taula 21. Especificació cas d’ús exportar fitxer .................................................... 49 Taula 22. Especificació cas d’ús mostrar imatge .................................................. 50 Taula 23. Estimació del cost de realització de cada etapa ................................... 72


6

1. Introducció

1.1. Enfocament del treball

Aquest treball està basat en els sistemes de fitxers que formen part del temari de l’assignatura de sistemes operatius que es cursa a 3r d’informàtica.

Inicialment no ens limitarem a descriure tot el funcionament intern del sistema de fitxers que ens ocupa (Ext2) sinó que definirem que s’entén per sistema de fitxers, veurem els diferents tipus d’accés a la informació, els diferents mètodes d’assignació, de gestió de l’espai lliure etc.

Posteriorment veurem una breu història d’Ext2, estudiant el seus orígens ja que aquests ens permetran entendre la “filosofia” que segueix Ext2.

Més endavant ens fixarem amb algunes millores d’Ext2 com és el cas del Directory Indexing que ha permès millorar notablement el rendiment d’aquest sistema de fitxers.

Seguidament analitzarem els nous sistemes de fitxers que avui en dia ja estan substituint a Ext2 com són el cas d’Ext3, Reiserfs etc.

Vist això el lector estarà preparat per endinsar-se a veure els detalls interns d’Ext2. Dintre d’aquest apartat es detallaran les principals regions d’un sistema de fitxers Ext2 com són el cas del Superbloc, el Group descriptor, el Block bitmap, l’Inode bitmap i finalment els Data blocks.

Posteriorment passarem a descriure com es portarien a cap internament un conjunt de comandes senzilles com són el cas de mostrar el contingut d’un fitxer, entrar a un directori, esborrar un fitxer etc.

Seguidament es veuran algunes aplicacions similars a la realitzada per tal de veure’n els avantatges i inconvenients de cadascuna d’elles per tal de no limitar-nos a fer el mateix que fa una altre eina sinó a millorar-ne alguns dels seus aspectes. Els aspectes que més tindrem en compte seran la usabilitat de l’eina així com també que sigui realment útil per als alumnes.

Finalment passarem a detallar tot el procés de creació de la nostra eina docent començant per l’anàlisi de requisits, passant per les decisions de disseny així com l’anàlisi funcional per tal d’acabar finalment en la fase de proves i la posterior posada en explotació de l’aplicació.

1.2. Objectius

Els objectius que es pretenen aconseguir amb aquest treball són:

• Entendre què és un sistema de fitxers així com la funció que desenvolupa en tot sistema operatiu.

• Entendre el funcionament intern del sistema de fitxers Ext2.

• Aplicar els coneixements teòrics assolits en la implementació d’una eina de caire docent.


7

1.3. Estructura de la memòria

La memòria d’aquest TFC està dividida en 3 parts:

• Descripció dels sistemes de fitxers i introducció a Ext2.

• Estudi del funcionament intern d’Ext2.

• Disseny, implementació i posada en explotació de l’aplicació docent


8

2. Descripció de l’entorn

2.1. Introducció als sistemes de fitxers

Un sistema de fitxers és el mecanisme propi de qualsevol sistema operatiu que proporciona les eines adequades per a l’accés a la memòria secundària. El sistema de fitxers permet als usuaris d’un sistema operatiu crear col·leccions de dades (fitxers) que compliran amb les següents propietats:

• No volàtils: El seu contingut no desapareix en apagar el sistema operatiu.

• Compartibles entre processos: Tot fitxer ha de ser compartible entre processos diferents, a no ser que els permisos associats a aquest ho impedeixin de forma explícita.

• Tenen estructura: Els fitxers es poden organitzar en estructures jeràrquiques que ens permetran establit relacions entre aquests.

• Diversos continguts: En un fitxer s’hi poden emmagatzemar diferents tipus d’informació com són :

o Programes objecte

o Programes executables

o Dades numèriques

o Text

o Imatges

o ...

Tot sistema de fitxers proporciona un conjunt de funcions per al tractament de fitxers com són :

• Creació : Crea un nou fitxer i el posiciona dins l’estructura de fitxers.

• Esborrat : Elimina el fitxer de l’estructura de fitxers.

• Obertura : Declara el fitxer obert per un procés, permetent així operacions de lectura / escriptura

• Tancament : Declara el fitxer com a tancat impedint així realitzar operacions de lectura / escriptura.

• Lectura : Operació que permet a un procés llegir tot o una part d’un fitxer.

• Escriptura : Operació que permet a un procés escriure sobre un fitxer.

Tot fitxer té un conjunt d’atributs que el fan diferent de la resta. Típicament s’usa el nom d’un fitxer per diferenciar-lo de la resta, però com veurem tot seguit hi han d’altres atributs que el fan diferenciable :

• Nom : Nom simbòlic del fitxer.

• Tipus : Informació necessària per aquells sistemes de fitxers que suporten diferents tipus de fitxer.

• Ubicació : Apuntador a la ruta on es troba el fitxer.

• Mida : Mida actual i màxima d’un fitxer.


9

• Permisos : Permisos de lectura, escriptura i execució de diferents usuaris sobre un fitxer.

• Data : Tot fitxer tindrà emmagatzemades les dates de creació, última modificació i últim ús.

Existeixen diversos mètodes per a l’accés a la informació que contenen els fitxers. Els mètodes més rellevants són :

• Accés seqüencial : L’accés a la informació es produeix de forma lineal.

• Accés indexat : L’accés a la informació es fa mitjançant un índex que actuarà com a punter dels diversos blocs de dades.

• Accés directe o hash : S’accedeix directament a qualsevol bloc a partir d’una direcció coneguda que es calcularà fent ús d’una funció de hash. Aquest mètode explota la capacitat dels discs per a l’accés a dades de forma aleatòria.

Trobem 3 mètodes d’assignació de la informació. Com veurem cada mètode té avantatges i inconvenients en funció del tipus d’arxiu i per aquest motiu existeixen sistemes que donen suport a tots els mètodes d’assignació.

• Assignació contigua : Consisteix en assignar la informació d’un arxiu en blocs de dades contigus. L’assignació contigua comporta un seguit d’avantatges i inconvenients :

o Fàcil accés a la informació. o Comporta fragmentació externa : Nom que rep el fenomen que provoca

que no tinguem suficients blocs contigus per assignar a un mateix fitxer. � Solució : Un solució per a la fragmentació externa passa per aplicar

un algorisme de compactació dels espais buits. Comporta un alt cost temporal

o El creixement d’un fitxer pot comportar problemes d’assignació de la nova informació.

• Assignació enllaçada : Consisteix en assignar els blocs fent ús d’apuntadors que

ens apuntaran al següent bloc que conté informació. El conegut sistema de fitxers FAT utilitza aquest tipus d’assignació. L’assignació enllaçada comporta un seguit d’avantatges i inconvenients :

o No existeix fragmentació externa. o Podem usar qualsevol bloc lliure per assignar-hi informació. o Baix rendiment en l’accés directe a fitxers : Això es així perquè per

desplaçar-nos fins al bloc n, haurem de recórrer la llista enllaçada fins a trobar el bloc que buscàvem.

o Pèrdua d’espai per l’ús d’apuntadors : Tot apuntador ocupa un espai de disc.

� Solució : Per tal de minimitzar el percentatge de disc que utilitzen els apuntadors s’estructura la informació en clústers. Els clústers ens permetran agrupar diversos blocs de dades i així un mateix apuntador passarà d’apuntar a un únic bloc a un conjunt de blocs.

• Assignació indexada : Consisteix en assignar els blocs fent ús d’un bloc índex.

Aquest tipus d’assignació soluciona els problemes de l’assignació contigua així com també de l’enllaçada. L’assignació indexada però també té problemes referents a la mida del bloc índex :

o Fitxers petits � Desaprofitament bloc índex. o Fitxers grans � Necessitem més blocs d’índex


10

Per tal de donar solució als problemes assenyalats trobem diverses variants de l’assignació indexada com són :

o Esquema enllaçat : Consisteix en enllaçar diversos blocs d’índex en cas de necessitat.

o Índex de múltiples nivells : És una millora de l’esquema enllaçat. Consisteix en definir diversos nivells d’índex. Amb això podem establir una mida màxima de fitxer determinada.

o Esquema combinat : És el que usa Ext2. Consisteix en definir :

� Blocs directes : Contenen la adreça de blocs de dades. Útils per fitxers petits ja que eviten fer ús de blocs indirectes estalviant així espai a disc.

� Blocs indirectes : Són equivalents a l’esquema d’índex de múltiples nivells. Com major sigui un fitxer més n’usarem. Es defineixen 3 nivells de blocs indirectes :

• Blocs indirectes

• Blocs doblement indirectes

• Blocs triplement indirectes

L’espai lliure que es troba en un disc s’ha de gestionar perquè no seria òptim recorre tot el disc cada vegada que vulguem afegir un nou fitxer. Trobem diferents opcions per fer-ho:

• Vector de bits: Consisteix en un array de bits on cada bit indica si un determinat bloc de dades està ocupat (1) o lliure (0). Ext2 utilitza aquest mètode per gestionar l’estat en que es troben els diferents inodes i blocs de dades. Aquest mètode presenta un conjunt d’avantatges i inconvenients:

o Resulta senzill i eficient trobar el 1r bloc lliure.

o Ineficient treballar amb grans vectors de bits.

• Llista enllaçada: Consisteix en enllaçar tots els blocs lliures mitjançant punters. Aquest mètode segueix la mateixa filosofia que l’assignació enllaçada i per tant tindrà els mateixos problemes com que resulta lent recórrer la llista de blocs però afortunadament aquesta és una opció poc utilitzada pels SO.

• Agrupació: Consisteix en utilitzar un bloc de dades lliure com a índex per n blocs lliures. El darrer bloc que contingui el bloc d’índex contindrà la posició del següent bloc d’índex.

• “Conteig”: Consisteix en aprofitar el fet que els blocs es tendeixen a assignar / alliberar de forma contigua. Partint d’aquest fet resulta fàcil pensar que una possible optimització del vector de bits seria mantenir un vector amb 2 valors un referent a la posició on es troba un bloc lliure i l’altre valor referent al nombre de blocs lliures contigus que trobem. D’aquesta forma s’aconsegueix reduir la mida del vector sempre i quan el nombre de bocs contigus sigui elevat.

La implementació de directoris és una part important d’un sistema de fitxers. Una bona implementació dels directoris ens permetrà obtenir un bon temps de resposta amb directoris amb gran nombre de fitxers. Trobem 2 possibles solucions:


11

• Llista lineal: Consisteix en l’ús d’una llista lineal de noms de fitxer / directori amb els seus corresponents punters a blocs de dades. Aquesta solució es fàcil d’implementar però lenta en directoris amb molts fitxers ja que cada cop que es crea un nou fitxer / directori haurem de desplaçar-nos al llarg de tota la llista per comprovar si aquest existeix o no.

• Taula de hash: Millora de la llista lineal que consisteix en fer ús d’una funció de hash juntament amb una llista lineal. Aquesta funció de hash s’aplicarà al nom de fitxer / directori i ens donarà una posició de la llista. D’aquesta forma es redueix substancialment el cost temporal que suposa realitzar una cerca lineal per la llista.

2.2. Origen d’Ext2

L’origen de Linux i per tant del seus sistemes de fitxers no depèn directament de Unix (com s’acostuma a pensar ) sinó que Linux es podria considerar l’evolució natural de Minix que a la vegada es pot considerar l’evolució natural de Unix. Minix, era un sistema basat en Unix, dissenyat per a fins educatius. L’objectiu de Minix era que fos molt fàcil d’aprendre i per fer-ho es va decidir retallar funcionalitats de Unix. El nom de Minix deriva de Minimal Unix. Quan Linus Torvalds va començar a escriure el kernel de Linux l’any 1991 va basar-se en gran part amb Minix malgrat Minix es tractava d’un sistema operatiu basat amb un micro-kernel i en canvi Linux es basava amb un kernel monolític. Inicialment Linux usava el mateix sistema de fitxers que Minix però aquest tenia un gran nombre de limitacions com són un màxim de 64 MB per partició, i un nom de fitxer de com a màxim 14 caràcters. Arribats en aquest punt es va decidir dissenyar un sistema de fitxers natiu per Linux. El nou sistema de fitxers va rebre el nom d’ext (extended file system) i va ser creat per Rémy Card a l’abril del 1992. Aquest sistema de fitxers també es va veure ràpidament desfasat degut a que tenia força limitacions. Algunes d’aquestes limitacions eren que no es podien modificar els inodes, ni les dates de creació / modificació de fitxers. Arribats en aquest punt van aparèixer 2 nous sistemes de fitxers que van entrar “en competició” per arribar a esdevenir el sistema de fitxers estàndard de Linux. Aquest 2 nous sistemes de fitxers eren Xiafs (creat per Frank Xia i basat en Minix) i Ext2 (creat novament per Rémy Card al gener de 1993 i basat en UFS[Unix File System] també conegut com BSD Fast File System). Ambdós sistemes van ser inclosos en el kernel de Linux, però finalment es va imposar Ext2 degut a que Xiafs seguia tenint massa limitacions com una mida màxima de fitxer de 64 MB i una mida de màxima de partició de 2GB. Posteriorment Ext2 va seguir evolucionant, millorant la seva estabilitat, i el seu rendiment. Finalment Ext2 es va convertir en el sistema de fitxers estàndard de Linux, i Xiafs va ser suprimit del kernel de Linux.


12

2.3. Noves funcionalitats d’Ext2

Ext2 va ser dissenyat per tal de posteriorment poder afegir noves funcionalitats i millores. Degut a la gran popularitat d’Ext2 s’han desenvolupat un gran nombre de millores respecte al sistema de fitxers original. Algunes d’aquestes millores són POSIX ACL’S, extended attributes, directory indexing, taula nodes extensible, “redimensió” del sistema de fitxers on-line, expansió de l’inode etc. Tot seguit detallarem les noves funcionalitats més rellevants:

• Extended attributes: permeten associar certs fitxers o directoris amb metadades. El seu objectiu és emmagatzemar informació relativa a l’autor d’un document, la codificació de caràcters usada etc. Trobem 4 àmbits d’aplicació (namespaces) dels extended atributes que són d’usuari, trusted, sistema i seguretat. Algunes de les aplicacions dels extended attributes són les ACL’s, el SELinux (Security Enhanced Linux), MAC Security Labels etc.

• ACL’s: permeten la limitació d’accés a certs objectes per part de certs usuaris o

grups d’usuaris. Això també inclou les operacions que es poden realitzar sobre un objecte, típicament lectura, escriptura i execució. Les restriccions sobre un objecte donat s’emmagatzemaran en una estructura de dades denominada ACE (Access Control Entries) que contindrà tots els usuaris o grups i els relacionarà amb una ACL.

• Directory Indexing: sorgeix de la necessitat d’obtenir un millor rendiment del

sistema de fitxers. Tradicionalment quan l’usuari necessitava un fitxer s’havia de localitzar aquest fent ús d’algorismes de cerca lineal. Aquests algorismes funcionaven bé amb directoris amb pocs fitxers, però a mesura que el nombre de fitxers creix (milers de fitxers en un mateix directori) el temps de cerca d’un fitxer també creix. Com a solució a aquest problema es va proposar una indexació de fitxers fent ús de funcions de hash.

La solució passa per construir un arbre indexat. Aquest arbre contindrà 3 tipus de blocs:

• Blocs d’índex: Contenen el hash de 512 blocs de dades • Bloc d’índex root: Similar als blocs d’índex però conté una capçalera que

defineix dades importants de l’arbre. Aquestes dades són: o Longitud capçalera o Tipus d’indexació o Versió del hash o Profunditat de l’arbre

• Blocs de dades: Contenen 32 bits de hash i dades El bloc 0 serà un bloc d’índex, en cas que la partició tingui més de 512 blocs de dades, s’usarà un 2n nivell de blocs d’índex. Aquest 2n nivell estarà format pels blocs de l’1 al 511. Els blocs a partir del 512 seran blocs de dades.

El procés de cerca d’un fitxer a través de l’arbre consisteix en:

• Aplicar una funció de hash sobre el nom del fitxer. • Llegir el bloc d’índex root per tal de cercar quin bloc d’índex o de dades pot

contenir el fitxer.


13

• Continuar la cerca fins arribar al nivell més baix de l’arbre. • Un cop localitzat el bloc de dades, s’ha de comprovar que realment el bloc

que hem trobat sigui el que buscàvem. En cas contrari la funció de hash ens ha provocat una col·lisió i haurem de seguir buscant per l’arbre.

• Redimensió del sistema de fitxers on-line: Tradicionalment per tal de

redimensionar una partició Ext2 s’havia de fer ús de l’eina reseize2fs que permet la redimensió d’una partició prèviament desmuntada.

Posteriorment calia comprovar que aquesta redimensió no havia causat problemes a la partició fent ús de l’eina e2fsck. Degut a que aquest és un procés lent i que no es pot portar a cap en calent (sense desmuntar la partició prèviament) va sorgir la necessitat de la redimensió automàtica. Amb l’aparició dels LVM (Logical Volume Manager) per Linux, la redimensió automàtica va passar a ser una realitat. La redimensió es produeix en blocs de 256 MB (BlockSize =1KB), 2GB (BlockSize =2KB) o 16 GB (BlockSize =4KB).

2.4. Nous sistemes de fitxers

Com ja hem vist, Ext2 es va convertir en un sistema de fitxers robust i àmpliament usat. L’únic gran problema que tenia Ext2 era que no garantia redundància. Ext3 va sorgir (Febrer 1999) per cobrir els inconvenients d’Ext2 ja siguin els coberts (per algunes de les millores anteriorment assenyalades) com els no coberts (journaling). Les principals característiques d’Ext3 són:

• Journaling: permet garantir redundància de dades. Trobem 3 nivells diferents:

o Journal: baix rendiment, alta seguretat. Consisteix en guardar dades i metadades en la regió de journal. Aquest tipus de journaling garanteix una gran fiabilitat a canvi d’un baixa velocitat ja que qualsevol modificació que es fa d’un fitxer implica escriure en la regió de dades així com també en la regió de journal.

o Ordered: rendiment mig, seguretat mitja. Consisteix en un jouranling tipus writeback (el veurem tot seguit) però que soluciona els problemes d’escriptures fora d’ordre ja que es força l’escriptura dels fitxers abans de fer un commit de les metadades associades al fitxer (que es troben a la regió de journal).

o WriteBack: alt rendiment, baixa seguretat. Consisteix en guardar únicament les metadades en la regió de journal. Això fa que sigui una opció ràpida però que no contempla els problemes que puguin causar les escriptures fora d’ordre.

• Redimensió automàtica del sistema de fitxers

• Directory Indexing

Ext3 té alguns inconvenients:

• No permet la comprovació del sistema de fitxers en calent. • No permet l’assignació dinàmica d’inodes. • No permet l’assignació de blocs de dades de mida variable • No permet la defragmentació en calent.


14

• No permet la compressió transparent de dades. • No es garanteix que totes les dades s’esborrin completament. • Més lent i menys escalable que altres sistemes de fitxers com JFS2, Reiserfs,

XFS. Malgrat el gran nombre d’inconvenients Ext3 té un gran nombre d’avantatges respecte d’altres sistemes de fitxers equivalents (com són el cas JFS2, Reiserfs, XFS). Aquests avantatges són:

• La conversió d’Ext2 a Ext3 és directa i ràpida evitant així, fer còpies de dades, i canvis en el sistema.

• Les metadades d’Ext3 es troben en posicions fixes i conegudes el que suposa un gran avantatge respecte d’altres sistemes de fitxers amb estructures més complexes (sistemes amb dades estructurades en arbre) ja que en cas de que la partició es danyi Ext3 garanteix que les dades es puguin recuperar, fet que contrasta amb el fet que sistemes de fitxers més moderns (en quan a tècniques per millorar el rendiment) no puguin recuperar aquestes dades.

Recentment ha aparegut Ext4 (octubre de 2006) que suposa un conjunt important de millores respecte el seu antecessor com són:

• Permet grans particions: màxim d’1Exabyte=1024PetaBytes. • Permet l’ús d’extents: en cas de que un arxiu creixi es garanteix que tota la

informació del fitxer estarà contigua en disc eliminant així la fragmentació. • Completament compatible amb ext3.


15

3. Estructura física de dades

La informació s’estructura en blocs de mida fixa. La mida de bloc ve condicionada per la mida de la partició. Per exemple, la mida de bloc d’un disquet sempre serà d'1KB en canvi el mida de bloc d’una partició més gran serà típicament de 2KB o 4KB. Malgrat això es pot forçar que un disquet tingui una mida de bloc de 4KB i viceversa. La informació s’estructura de la següent forma:

Boot Sector

Block Group 1

Block Group 2

Block Group 3

... Block Group n

Taula 1. Estructura d’una Partició Ext2

El nombre de Block Groups d’una partició vindrà directament condicionat per la mida d’aquesta. Cada Block group contindrà les següents regions:

Superblock Group Descriptors

Block Bitmap

Inode Bitmap

Inode Table

Data Blocks

Taula 2. Estructura d’un block group

Aquestes regions les podríem classificar en 2 grups segons el nivell de replicació de les dades que contenen:

o Regions replicades: SuperBlock i Group Descriptors o Regions no replicades: Block Bitmap, Inode Bitmap, Inode Table, Data Blocks

Les dades replicades tenen sentit perquè són dades crítiques que si es perden el disc queda inservible. Per aquest motiu es copien a “tots” (sovint es dona el cas que només es copien en alguns blocks groups) els blocks groups, i en cas de perdre el superblock d’un d’aquests block groups aquest es pot recuperar fàcilment d’un altre block group. Descripció de les regions que conformen un block group:

o Superblock: conté informació sobre les característiques del sistema de fitxers, com mida del bloc, numero d'inodes, numero de blocs ocupats etc...

o Group Descriptor: defineix la posició on es troben Block Bitmap, Inode Bitmap, etc

o Block Bitmap: senyala quins blocks estan ocupats (1) o lliures (0) dintre d’un mateix block group.

o Inode Bitmap: actua igual que el Block Bitmap però en aquest cas amb Inodes. Cada bit representa 1 Inode.

o Inode Table: conté informació relativa a 1 fitxer, entenent fitxer com directori, link, arxiu etc...

o Data Blocks: regió on es guarda el contingut de cada fitxer/directori.


16

3.1. Superblock

Regió de 1024 Bytes que es troba al principi de cada block group. Conté informació essencial per muntar i accedir a la partició. El superblock sempre començarà al Byte 1024 (0x400). Els camps més rellevants del superblock són:

• s_inodes_count (offset 0, mida 4 bytes): camp que conté el nombre total d’inodes que hi ha a la partició.

• s_blocks_count (offset 4, mida 4 bytes): camp que conté el nombre total de blocks que hi ha a la partició.

• s_r_block_count (offset 8, mida 4 bytes): camp que conté el nombre de blocs reservats pel root.

• s_free_blocks_count (offset 12, mida 4 bytes): camp que conté el nombre de blocs lliures incloent els blocs reservats pel root.

• s_free_inodes_count (offset 16, mida 4 bytes): camp que conté el nombre d’inodes lliures.

• s_first_data_block (offset 20, mida 4 bytes): camp que conté la posició del primer datablock (bloc que contindrà la estructura del superblock). Aquest camp sempre serà 1 per particions de mida de bloc d’1KB i sempre 0 per mides de bloc superiors a 1KB (2KB, 4KB, 8KB).

• s_log_block_size (offset 24, mida 4 bytes): indica el nombre de bits que hem de shiftar a esquerra 1024 per tal d’obtenir la mida del bloc. La mida obtinguda estarà expressada en Bytes.

Taula 3. Càlcul de la mida de bloc

• s_log_frag_size (offset 28, mida 4 bytes): Nombre de bits que hem de shiftar

1024 a esquerra. El signe és important.

Taula 4. Càlcul de la mida del fragment

• s_blocks_group (offset 32, mida 4 bytes): Nombre total de blocs per grup.

• s_frags_group (offset 36, mida 4 bytes): Nombre total de fragments per grup. Indica la mida del block bitmap.

block_size = 1024 << s_log_block_size

if (s_log_frag_size>0) { fragment_size = 1024 << s_log_frag_size; } else { fragment_size = 1024 >> -s_log_frag_size; }


17

• s_inodes_group (offset 40, mida 4 bytes): Nombre total d’inodes per grup. Indica la mida de l’inode bitmap.

• s_mtime (offset 44, mida 4bytes): Data de l’últim muntatge (data expressada en format Unix time, veure Annex).

• s_wtime (offset 48, mida 4 bytes): Data de l’última escriptura (data expressada en format Unix time).

• s_mnt_count (offset 52, mida 2 bytes): Nombre de vegades que s’ha muntat la partició des de l’última comprovació.

• s_max_mnt_count (offset 54, mida 4 bytes): Nombre de vegades que es pot muntar la partició fins que es forci la comprovació del sistema de fitxers.

• s_magic (offset 56, mida 2 bytes): Magic number que ens permet identificar que un determinat fitxer es tracta d’una imatge Ext2 (0xEF53).

• s_last_check (offset 64, mida 4 bytes): Data de la darrera comprovació d’estat del sistema de fitxers.

• s_check_interval (offset 68, mida 4 bytes): Període màxim de temps que ha de transcorre entre revisions del sistema de fitxers.

• s_creator_os (offset 72, mida 4 bytes): Identificador del sistema operatiu que ha creat la imatge Ext2. Trobem diversos identificadors que són:

o 0: Linux

o 1: Hurd

o 2: Massix

o 3: FreeBSD

o 4: Lites

• s_rev_level (offset 76, mida 4 bytes): Indica la revisió de la imatge Ext2. Identificador que podrà agafar els següents valors:

o 0: Format original.

o 1: Nova revisió (inodes dinàmics).

• s_first_ino (offset 84, mida 4 bytes): Primer inode usable per fitxers estàndard. Típicament és 11, però amb la introducció de la revisió dinàmica del sistema de fitxers aquest nombre pot variar.

• s_inode_size (offset 88, mida 2 bytes): Mida d’un inode.

• s_block_group_nr (offset 90, mida 2 bytes): Indica el block number que conté el superblock. Útil en cas de necessitar restaurar el sistema de fitxers d’un backup.

• s_feature_compat (offset 92, mida 4 bytes): Bitmask que indica les funcionalitats que suporta el sistema de fitxers. Nota: Llistat noves funcionalitats suportades per Ext2 a l’apartat 2.3.

• s_feature_incompat (offset 96, mida 4 bytes): Bitmask que indica les funcionalitats que no suporta el sistema de fitxers. Nota: Llistat noves funcionalitats suportades per Ext2 a l’apartat 2.3.

• s_feature_ro_compat (offset 100, mida 4 bytes): Bitmask que indica les funcionalitats que suporta el sistema de fitxers amb mode read-only. Nota: Llistat noves funcionalitats suportades per Ext2 a l’apartat 2.3.


18

• s_uuid (offset 104, mida 16 bytes): El Uuid (Universally Unique Identifier) es tracta del ID del Volum. Tèoricament cada partició formatada amb Ext2 tindrà un uuid diferent.

• s_volume_name (offset 120, mida 16 bytes): Nom del volum. Ha d’estar format per caràcters ISO-Latin-1.

Figura 1. Captura dels camps més rellevants del Superbloc

Tot seguit detallarem cadascun dels punts assenyalats en la captura del Superbloc:

1. Nombre d’inodes: Podem observar que apareix un 40 que passat a decimal ens dóna un total de 64 inodes.

2. Nombre de Blocs: Podem observar que apareix un 00 02. Això passat a big endian (02 00) i posteriorment a decimal ens dóna un total de 512 blocs.

3. Blocs lliures: Podem observar que apareix un D7 01. Això passat a big endian (01 D7) i posteriorment a decimal ens dóna un total de 471 blocs lliures.

4. Inodes lliures: Podem observar que apareix un 26 que passat a decimal ens dóna un total de 38 inodes lliures.

5. Mida Blocs: Aquest camp no ens dóna directament la mida de blocs sinó que ens diu el nombre de bits que hem de shiftar a esquerra 1024. Degut a que apareix un 0, no shiftarem cap bit, per tant la mida de bloc d’aquesta partició és de 1024 bytes o el que és el mateix 1Kb.

6. Blocs per grup: Podem observar que apareix un 00 20. Això passat a big endian (20 00) i posteriorment a decimal ens dóna un total de 8192 blocs per grup.

7. Mida inode: Podem observar que apareix un 80 que passat a decimal ens dóna una mida d’inode de 128 bytes.

8. Nom partició: Podem observar que apareixen 13 bytes. En aquest cas aquests bytes estan codificats com a char. El nom d’aquesta partició és “ext2fs_prova1”.


19

3.2. Group descriptor

El group descriptor es tracta d’una regió de 1024 bytes que conté un array de group_desc cadascun dels quals defineix les característiques d’un block group diferent.

group_desc 0

group_desc 1

group_desc 2

... group_desc n

Taula 5. Estructura del Group Descriptor

Caldria deixar clar que cada group descriptor conté la mateixa informació en diferents block groups. Això és així per garantir integritat de dades. La posició del group descriptor la podem conèixer fent ús d’una petita formula:

Taula 6. Càlcul per posicionar-nos a l’inici dels Group Descriptors

Cada group_desc contindrà la següent informació:

• bg_block_bitmap (offset 0, mida 4 bytes): ID del block bitmap corresponent al grup actual.

• bg_inode_bitmap (offset 4, mida 4 bytes): ID de l’inode bitmap corresponent al grup actual.

• bg_inode_table (offset 8, mida 4 bytes): ID de l’inode table corresponent al grup actual.

• bg_free_blocks_count (offset 12, mida 2 bytes): Nombre blocs lliures corresponent al grup actual.

• bg_free_inodes_count (offset 14, mida 2 bytes): Nombre inodes lliures corresponent al grup actual.

• bg_used_dirs_count (offset 16, mida 2 bytes): Nombre de directoris corresponents al grup actual.

• bg_pad (offset 18, mida 2 bytes): Bytes de farciment.

• bg_reserved (offset 20, mida 12 bytes): Bytes reservats per futures millores.

if (block_size == 1024) { off = block_size * 2; } else { off = block_size; }


20

Figura 2. Captura dels camps més rellevants del Group Descriptor

En la captura apareix ressaltat en lila el Group Descriptor 0, en verd apareix el Group Descriptor 1, i en groc el Group Descriptor 2. Tot seguit detallarem cadascun dels punts assenyalats que corresponen al Group Descriptor 0:

1. Block Bitmap: Podem observar que apareix un 52 que passat a decimal ens dóna 82. Aquest valor multiplicat per la mida de bloc ens donarà la posició on es troba el block bitmap.

2. Inode Bitmap: Podem observar que apareix un 53 que passat a decimal ens dóna un 83. A l’igual que en el block bitmap, fent ús d’aquest valor obtindrem la posició de l’inode bitmap.

3. Inode Table: Podem observar que apareix un 54. Aquest valor passat a decimal ens dóna 84. A l’igual que els anteriors casos, fent ús d’aquest valor obtindrem la posició de l’inode table.

4. Blocs lliures: Podem observar que apareix un C9 03. Aquest valor passat a big endian (03 C9) i posteriorment a decimal ens dóna un total de 969 blocs lliures.

5. Inodes lliures: Podem observar que apareix un A2 06. Aquest valor passat a big endian (06 A2) i posteriorment a decimal ens dóna un total de 1698 inodes lliures.

6. Directoris Usats: Podem observar que apareix un 02. Aquest valor passat a decimal ens dóna un total de 2 directoris usats.

7. Altres: Agrupa els bits de padding (farciment) més els reservats. No ens interessen.


21

3.3. Block bitmap

Es tracta d’un array de bits, que indicarà si un bloc donat està ocupat (1) o lliure (0). La seva ubicació la podem conèixer llegint el camp bg_block_bitmap i aplicant el següent càlcul:

Taula 7. Càlcul per posicionar-nos a un block bitmap donat

La seva longitud, la podrem conèixer llegint el camp s_frags_grup. Aquesta regió serà útil alhora d’escriure sobre la partició ja que ens permetrà saber quins blocs estan lliures i per tant sobre quins blocs podem escriure la nova informació.

Figura 3. Captura del Block Bitmap

En aquesta captura a diferència de les anteriors (superbloc, group descriptors) totes les dades que hi apareixen són “equivalents”, entenent equivalents com que totes les dades fan referència a l’estat (ocupat o lliure ) dels blocs de dades. Tot seguit detallarem cadascun dels punts (bytes) assenyalats, tenint en compte que cada byte fa referència a l’estat (ocupat o lliure) de 8 blocs:

1. Apareix un 03. Si això ho passem a binari ens donarà 11 que voldrà dir que els primers 2 blocs estan ocupats i els 6 restants estaran lliures.

2. Apareix un 18. Això passat a binari ens donarà 11000 que voldrà dir que els blocs 4 i 5 estan ocupats.

3. Apareix un 70. Passant-t’ho a binari obtenim 1110000 que voldrà dir que els blocs 5, 6 i 7 estan ocupats

off=bg_block_bitmap*block_size


22

3.4. Inode bitmap

Regió similar al block bitmap però en aquest cas ens indicarà quins inodes estan ocupats i quins lliures. La seva ubicació la podem conèixer llegint el camp bg_inode_bitmap i aplicant el següent càlcul:

Taula 8. Càlcul per posicionar-nos a un inode bitmap donat

La seva longitud, la podrem conèixer llegint el camp s_inodes_group. Es tracta d’un array de bits, que indicaran si un inode donat està ocupat (1) o lliure (0). Quan es crea una inode table, tots els bits de reserva es posaran a 1. A l’igual que passa amb el block bitmap, aquesta regió serà útil alhora d’escriure sobre la partició ja que ens permetrà saber sobre quins inodes podem escriure la nova informació.

Figura 4. Captura inode bitmap

A l’igual que passa amb el block bitmap, totes les dades que apareixen a l’inode bitmap son “equivalents” ja que fan referència a l’estat (ocupat o lliure) dels inodes. Tot seguit detallarem cadascun dels punts (bytes) assenyalats, tenint en compte que cada byte fa referència a l’estat (ocupat o lliure) de 8 inodes:

1. Apareix un FF. Sense necessitat de passar a binari podem afirmar que els 8 inodes estan ocupats.

2. Apareix un 3F. Això passat a binari ens donarà 0011 1111 que voldrà dir que els 6 primers inodes estan ocupats i els altres 2 lliures.

3. Apareix un 00. Sense necessitat de passar a binari podem afirmar que els 8 inodes estan lliures.

3.5. Inode table

Regió on s’emmagatzemarà tota la informació associada amb fitxers i directoris com pot ser mida, permisos d’accés / escriptura, posició física del datablock associat etc. La seva ubicació la podem conèixer llegint el camp bg_inode_table de cada group descriptor (aplicant el següent càlcul: bg_inode_table*block_size). La seva longitud la podrem conèixer llegint el camp s_inode_size. Típicament ens trobarem amb la necessitat de trobar la informació associada a un inode del qual únicament en sabem el seu número. Per tal de localitzar aquest inode a la partició inicialment se’ns podria acudir de fer una cerca lineal d’aquest inode a través de la partició, però aquesta solució tindria un rendiment pèssim. Per a solucionar això usarem unes senzilles fórmules que ens donaran la posició exacta de l’inode amb un cost mínim.

off= bg_inode_bitmap*block_size


23

Taula 9. Càlculs per posicionar-nos a un inode donat

Línia 1: es calcula el group_descriptor que tindrà la informació relativa a l’inode que li passem. Línia 2: es calcula la posició concreta on es troba l’inode passat dintre del group_descriptor que hem calculat en la anterior fórmula. Línia 3: es calcula la posició inicial del group_desc que hem calculat anteriorment (primera línia) Línia 4: es calcula la posició concreta de l’inode dintre del group_desc. Línia 5: Finalment sumem el resultat obtingut en les línies 3 i 4 obtenint així la posició exacta de la informació associada a un inode donat.

Taula 10. Exemple posicionament a partir d’un inode donat

Cada Inode Table contindrà la següent informació:

• I_mode (Offset 0, Mida 2B): Descriu el format del fitxer (directori, fitxer, link, etc) així com també els permisos d’aquest (lectura, escriptura, execució etc).

Format del fitxer:

o 0xC000: socket o 0xA000: symbolic link o 0x8000: regular file o 0x6000: block device o 0x4000: directory o 0x2000: character device o 0x1000: FIFO

/* 1 */ int grup = (num_inode - 1) / inodes_grup; /* 2 */ int index_grup = (num_inode - 1) % inodes_grup; /* 3 */ int offset1= block_size * GD[group_desc].inode_bitmap; /* 4 */ int offset2=(index_grup) *s_inode_size /* 5 */ int offset=offset1+offset2;

Ex: Suposem una partició de 20MB, que sabem que té 3 group_desc, una mida de bloc d’1KB, 1712 inodes per Grup, i una mida de 128 bytes per inode. Ens demanen de calcular la posició on es troba la informació relativa a l’inode 1738. group_desc= (num_inode - 1) / s_inodes_grup=(1738-1)/1712=1 index_grup = (num_inode - 1) % s_inodes_grup=(1738-1)%1712=25 offset1 = block_size * GD[group_desc].inode_bitmap = 1024*GD[1].inode_bitmap = 8473600 offset2=(index_grup) *s_inode_size=25*128=3200 offset=offset1+offset2=8473600+3200= 8477824=0x815C80 Nota: Suposem que GD[1].inode_bitmap és 8275.


24

Permisos:

o Altres

• Execució: 0x0001

• Escriptura: 0x0002

• Lectura: 0x0004

o Grup



• Lectura: 0x0020

o Usuari



• Lectura: 0x0100

o Suid: 0x0800

o Sgid: 0x0400

o Sticky Bit: 0x0200

• i_uid(offset 2, mida 2B): Id usuari associat amb el fitxer.

• i_size(offset 4, mida 4B): Mida del fitxer en bytes.

• i_atime (offset 8, mida 4B): Últim accés fitxer (en format Unix Time, veure Annex).

• i_ctime (offset 12, mida 4B): Data creació fitxer (en format Unix Time).

• i_mime (offset 16, mida 4B): Data modificació Fitxer (en format Unix Time).

• i_gid (offset 24, mida 2B): Id del grup propietari del fitxer

• i_links_count (offset 26, mida 2B): Nombre de cops que l’inode és linkat.

• i_blocks (offset 28, mida 4B): Nombre blocs de dades usats i reservats.

• i_block (offset 40, mida 60B): Es tracta d’un array de blocs de dades. Aquest array està format per 15 Punters de 4 bytes cadascun d’ells. El contingut de cadascun d’aquests punters serà un nombre de bloc. Trobem diversos tipus de punters:

o 12 Punters Directes: Punters que apunten directament a un bloc de dades. El contingut dels punters es un nombre de bloc, que contindrà directament la informació associada amb l’inode al qual ens trobem.

o 1 Punter Indirecte: Punter que apunta a un bloc de dades que alhora tindrà punters a altres blocs de dades.

o 1 Punter Doblement Indirecte: Punter que apunta a un bloc de dades on trobem punters a blocs indirectes.

o 1 Punter Triplement Indirecte: Punter que apunta a un bloc de dades on trobem punters a blocs doblement indirectes.


25

Figura 5. Estructura Inode

[SILBERSCHATZ 2006]

• I_link(offset 40, mida n): Aquest camp només existirà en cas de que l’inode contingui

un link, fet que implica que no hi hauran blocs de dades. Aquest camp conté la ruta completa al fitxer que estem linkant. Com es pot veure aquest camp esta sobreposat al camp i_block (es troben en la mateixa posició). La longitud d’aquest camp es indeterminada, ja que vindrà condicionada per la longitud de la ruta.

• i_file_acl (offset 104, mida 4B): Indica el nombre de bloc que conté informació extra del fitxer (acl’s).

Figura 6. Captura d’un inode corresponent a un fitxer de text

Tot seguit detallarem cadascun dels punts assenyalats:

1. Mode: Apareix un A4 81. Passat a big endian obtenim 81 A4, amb el que podem assegurar que es tracta d’un fitxer ja que compleix el patró 0x8000 assignat al fitxers. Per tal de calcular els permisos associats en aquest a la carpeta realitzarem els següents càlculs:

• Permisos altres: Multiplicarem per 0x0001 (execució), 0x0002 (escriptura), 0x0004 (lectura).

• Permisos grup: Multiplicarem per 0x0008 (execució) , 0x0010 (escriptura), 0x0020 (lectura).


26

• Permisos usuari: Multiplicarem per 0x0040 (execució), 0x0080 (escriptura), 0x0100 (lectura).

2. Mida fitxer: Apareix un 5D 2F 00 00. Passat a big endian i a decimal obtenim 12125 bytes

3. Data últim accés: Data codificada en format Unix time (veure Annex).

4. Data creació: Data codificada en format Unix time (veure Annex).

5. Data modificació: Data codificada en format Unix time (veure Annex).

6. Nombre blocs usats: Apareix un 18. Passat a big endian i a decimal obtenim un total de 24 blocs usats.

7. Punters a Blocs Directes: Marcats en taronja apareixen els 12 punters a blocs directes, en aquest cas i degut a que tenim un fitxer relativament gran es pot observar que s’usen els 12 punters a blocs directes. El primer punter té el valor 3E 00 00 00 que passat a big endian i a decimal ens dóna 62. Valor que multiplicat per la mida de bloc ens donarà la posició del bloc de dades que conté part de la informació d’aquest fitxer.

8. Punter a Bloc Indirecte: Marcat en verd apareix el punter a bloc indirecte. En aquest cas no usem aquest punter (perquè el seu valor és 0).

9. Punter a Bloc Doblement Indirecte: Marcat en groc apareix el punter doblement indirecte. En aquest cas no usem aquest punter (perquè el seu valor és 0).

10. Punter a Bloc Triplement Indirecte: Marcat en blau cel apareix el punter triplement indirecte. En aquest cas no usem aquest punter (perquè el seu valor és 0).

Nota: En cas de tenir un link no tindrem punters a blocs sinó que en el seu lloc tindrem la ruta del link, com mostra la següent captura.

Figura 7. Captura inode que conté un link

Ressaltat en lila apareix la codificació hexadecimal del path del link i a la dreta en ressaltat en verd apareix la codificació en ASCII.

3.6. Data blocks

Els blocs de dades, com bé diu el seu nom contenen dades, però podríem classificar aquestes en 2 tipus:

• Definició: Datablocks que ens permeten definir altres datablocks. Ex: Directoris • Contingut: Datablocks que únicament contenen text. Ex: Fitxers


27

Els blocs de dades defineixen directoris, fitxers, etc. El camp file_type ens permetrà classificar aquests blocs. Els blocs de dades complementen la informació que ens dóna un inode. Per tant, per cada inode (excepte en el cas de tenir un link) tindrem un bloc de dades que complementarà la informació que aquest ens dóna. Per tal de relacionar un inode amb el seu bloc de dades corresponent usarem el numero d’inode. Un data bloc de definició tindrà la següent estructura: • Inode (offset 0, mida 4): Conté el numero d’inode.

• Rec_len (offset 4, mida 2): Abreviació de record length. Ens dóna el nombre de caràcters fins al següent data bloc.

• Name_len (offset 6, mida 1): Ens dóna la longitud del nom del directori/fitxer.

• File_type (offset 7, mida 1): Ens defineix el tipus de fitxer:

o Ext2_FT_UNKNOWN 0 Fitxer desconegut o Ext2_FT_REG_FILE 1 Fitxer regular o Ext2_FT_DIR 2 Directori o Ext2_FT_CHRDEV 3 o Ext2_FT_BLKDEV 4 o Ext2_FT_FIFO 5 o Ext2_FT_SOCK 6 Socket o Ext2_FT_SYMLINK 7

• Name (offset 8, mida “name_len”): Conté el nom del directori, fitxer etc.

Figura 8. Captura datablock corresponent al root de la partició

En la captura d’aquest datablock podem observar que aquest conté un conjunt de directoris ressaltats en colors, aquests són:

• En lila: Directori “.” . El tindran tots els directoris. • En Verd: Directori “..” . El tindran tots els directoris. • En Taronja: Directori “lost+found”. El tindran totes les particions al root. • En groc: Directori “carpeta1” • En blau fosc: Directori “carpeta2” • En rosa: Directori “carpeta3”

En la captura també apareixen uns nombres que corresponen als diversos camps que componen un data block. Aquests són:

1. Numero Inode: En aquest cas apareix un 2. Això es així perquè el Directori “.” sempre tindrà el mateix numero d’inode el qual ens trobem i degut a que ens trobem al root tindrem l’inode 2.


28

2. Record Length: En aquest cas apareix un 0C, que indica que la definició del

següent directori (el Directori ..) es troba a 12 caràcters. 3. Longitud nom: En aquest cas apareix un 01. Això és així perquè el Directori “.”

Només té 1 caràcter. 4. Tipus Fitxer: En aquest cas apareix un 2. Això vol dir que aquest fitxer es tracta

d’un directori. 5. Nom: En aquest cas el nom del directori és “.”

3.6.1. Directoris Per tal de representar directoris i com ja s’ha esmentat, usarem inodes i blocs de dades. Però com s’estructura la informació de forma jeràrquica? Per tal de poder definir l’estructura jeràrquica dels diversos directoris d’un disc s’usen els nombres dels inodes, fent que el punter “.” sigui l’inode al qual ens trobem actualment i el “..” l’inode d’un nivell superior al qual ens trobem actualment. Suposem que tenim els següents directoris: . .. Lost+Found carpeta1 carpeta2 carpeta_dades La representació en disc d’aquesta estructura seria:

Inode: 2 Rec_len: 12 Name_len: 1 File_type: 2 Name: .

Inode: 12 Rec_len: 16 Name_len: 8 File_type: 2 Name: carpeta1

Inode: 2 Rec_len: 12 Name_len: 2 File_type: 2 Name: ..

Inode: 13 Rec_len: 16 Name_len: 8 File_type: 2 Name: carpeta2

Inode: 11 Rec_len: 20 Name_len: 10 File_type: 2 Name: Lost+Found

Inode: 14 Rec_len: 21 Name_len: 13 File_type: 2 Name: carpeta_dades

Taula 11. Representació directoris en un datablock

3.6.1.1. Carpeta Lost + Found Aquesta carpeta apareix en qualsevol partició que es crea. La finalitat d’aquesta carpeta és la de garantir integritat de dades en cas de caiguda del sistema. Quan el sistema operatiu detecta que aquest no s’ha tancat correctament la darrera vegada, s’executarà una revisió del sistema (fsck) de fitxers que tindrà per objectiu cercar i recuperar fitxers danyats. Els fitxers que puguin arribar a ser recuperats es mouran en aquesta carpeta, però no es garanteix que aquests estiguin complets o s’hagin pogut recuperar correctament.


29

Degut a que aquesta carpeta es crea en crear la partició, sempre se li assignarà el primer inode disponible per dades estàndards. El numero d’aquest inode apareixerà en el camp “s_first_ino” del superbloc.

3.6.2. Fitxers El contingut d’un fitxer no es troba ni en l’inode ni en el bloc de dades associat, on es troba per tant? Com ja és ben sabut un inode conté una zona de punters a blocs de dades (directes, indirectes, doblement indirectes i triplement indirectes). Aquests punters, apuntaran als diversos blocs que contindran la informació del fitxer. Com major sigui un fitxer major nombre de punters tindrà. Els punters sempre s’usaran de menor a major ordre (començant sempre pels punters directes i acabant pels triplement indirectes). Per tal d’accedir al contingut d’un fitxer, anirem accedint als blocs de dades on apunten els diversos punters, però com ho fem? Arribats en aquest punt podríem distingir diversos casos (en funció dels blocs que ocupi un fitxer donat).

• 1 Bloc Directe: Per tal d’accedir al contingut d’un fitxer d’aquestes característiques haurem de desplaçar-nos a la posició num_bloc*block_size. Un cop allà llegirem el contingut del fitxer.

• Menys de 12 Blocs Directes: Aquest cas és similar al anterior ja que seguim

accedint als punters directes a blocs, però en aquest cas en tenim més d’un. L’única diferència amb el cas anterior, serà que haurem de repetir el procés anterior n vegades (on n es el nombre de blocs que tenim).

• Bloc Indirecte: Aquest cas és substancialment diferent als anteriors ja que

arribats en aquest punt s’usen els punters a blocs directes i alhora s’usarà el punter indirecte. Per tal de llegir els primers 12 Blocs (directes) seguirem el mateix procediment anteriorment assenyalat.

Per tal llegir el contingut del bloc indirecte seguirem el següent procediment. Inicialment llegirem el contingut del punter indirecte. Aquest nombre serà un nombre de bloc que anomenarem num_bloc_ind. Tot seguit haurem d’accedir al contingut d’aquest bloc, per fer-ho haurem de desplaçar-nos a la posició num_bloc_ind*block_size. En aquesta posició trobarem un array de nombres de bloc. La longitud d’aquest array vindrà donada per la següent formula:

Bytes

SizeBlock

PunterMida

SizeBlockIndirectesBlocsArrayLongitud

4

_

_

____ ≡≡

Un cop haguem localitzat l’array de nombres de bloc, anirem llegint els diferents blocs de dades fins que en trobem un que sigui igual a 0, que implicarà que ja no hi ha més blocs de dades per aquell inode.


30

• Bloc doblement indirecte: Aquest cas és molt similar al anterior ja que el bloc doblement indirecte contindrà un array de blocs indirectes que haurem d’anar llegint progressivament tal i com hem assenyalat anteriorment.

• Bloc triplement indirecte: Aquest bloc contindrà un array de blocs doblement

indirectes, que haurem d’anar llegint com ja s’ha explicat anteriorment.

Mida Bloc

Mida Màx. Fitxer

Mida Màx. FS

1KB 16GB 2.047GB 2KB 256GB 8.192GB 4KB 2.048GB 16.384GB 8KB 2.048GB 32.768GB

Taula 12. Limitacions Ext2

En aquesta taula podem observar que la mida del bloc determina en gran mesura les característiques del sistema de fitxers. Una consideració sobre aquesta taula és que el kernel 2.4 limitava la mida d’un fitxer a 2.048 GB. Amb l’aparició del kernel 2.6 aquesta limitació va desaparèixer. Una mida de block de 8KB només es implementable en plataformes alpha. Ex 1: Suposem un fitxer de text que ocupa 1 bloc directe (el bloc numero 242), i una mida de bloc d’1KB. Per saber la posició a la que ens hem de desplaçar farem el següent càlcul: 242*1024Bytes=247.808 (Byte) Ens hem de desplaçar a la posició 247.808. Típicament s’expressaran les posicions dintre d’una partició en hexadecimal. Per tant passarem la posició a hexadecimal obtenint 0x3C800.

Ex 2: Suposem una mida de bloc = 1KB i un fitxer de 11 KB. Quants punters s’usaran i de quin tipus seran?

PuntersKB

KB

blocMida

fitxerMidapuntersNum 11

1

11

_

__ ===

Usarem els 11 Primers Punters directes. Ex 3: Mida Bloc=1KB. Ara suposem un fitxer de 163328 Bytes. Quants punters s’usaran i de quin tipus seran?

BlocsKbBytes

Bytes

blocMida

fitxerMidapuntersNum 1605,159

1024

163328

_

__ ≈===

160Blocs – 12 Blocs Directes=148 Blocs Indirectes Sabem que un punter indirecte tindrà com a màxim Mida_Bloc/Mida_Punter blocs. La mida del punter es sempre la mateixa (4 bytes). La mida del bloc pot ser variable. En aquest cas tindrem 1KB/4 bytes que ens dóna que 1 punter indirecte té capacitat per a 256 Blocs de dades.


31

Aquests 160 Blocs seran: • 12 Blocs Directes • 1 Punter Indirecte=148 Blocs Indirectes

Ex 4: Mida Bloc=1KB. Suposem un fitxer de 10MB. Quants punters s’usaran i de quin tipus seran?

BlocsKB

KB

KB

MB

blocMida

fitxerMidapuntersNum 240.10

1

240.10

1

10

_

__ ====

10.240Blocs – 12 Blocs Directes=10.228 Blocs Indirectes

Com es veia a l’exemple anterior i degut a que la mida de bloc es la mateixa en ambdós exemples sabem que el punter a bloc indirecte ens dóna capacitat per a un total de 256 Blocs de dades. 10.228 Blocs – 256 Blocs Indirectes=9.972 Blocs Arribats en aquest punt ja tenim els blocs directes i indirectes plens. Passem al punter doblement Indirecte. El punter doblement indirecte tindrà 256 punters a blocs indirectes cadascun d’ells contenint 256 punters a blocs. Ara necessitem respondre 2 preguntes:

1.- En tindrem suficient amb el punter doblement indirecte? 256 punters a Bl. Ind * 256 punters a blocs/Bloc Ind=65.536 Podem veure que tindrem suficient espai amb el punter doblement indirecte. Ja que 65.536 >> 9.972. 2.- Quants punters a blocs Indirectes usarem? 9.972Blocs/256Blocs per cada Bloc Ind.= 38,953125≈39Blocs Ind. Resumint, els 10.240Blocs es repartiran de la següent forma:

• 12 Punters a Blocs Directes • 1 Punter Indirecte= 256 Punters a Blocs • Part del punter doblement Indirecte=39 Punters a Blocs Indirectes=9.972Blocs

3.6.3. Links

Els links o més coneguts com soft links trenquen amb el concepte que teníem fins ara que tot inode te uns punters a blocs directes que contenen la informació. Un link no tindrà data blocs, ja que aquests no tenen cap contingut.


32

Un inode que contingui un link per tant, no tindrà blocs però en el seu lloc tindrem la ruta completa al fitxer que linka.

Taula 13. Contingut d’un inode que conte un link

INODE Num_Inode 53 I_size 26 I_link /mnt/dir1/fitxer_petit.txt

... ...


33

4. Explicació comandes bàsiques Un cop entès tot el funcionament intern d’un sistema de fitxers Ext2 passarem a l’explicació de com es porten a cap un conjunt de comandes bàsiques.

4.1. Llistat root

Descripció: Consisteix en realitzar un llistat de tots els fitxers / directoris que es troben a la partició arrel de la partició. Prerequisits:

• Mida de Bloc: L’obtindrem del Superbloc. • Posició de la taula d’inodes. L’obtindrem del Group Descriptor 0

Explicació:

• S’accedeix al inode root (2) aquest tindrà 1 o més punters a blocs. • Accedim al contingut d’aquests punters a blocs. • Anem llegint i mostrant la informació que trobem en aquests blocs • La comanda finalitzarà un cop haguem llegit tot el contingut dels blocs esmentats.

4.2. Arbre de directoris

Descripció: Per tal de mostrar tot l’arbre de directoris que conté la partició ens farà falta la implementació d’un procés recursiu que té com a cas trivial links i fitxers (ja que d’aquests no “pengen” altres dades) i com a cas general els directoris. Prerequisits:

• Mida de Bloc: L’obtindrem del superblock. • Posició de la taula d’inodes. L’obtindrem dels diversos group descriptors.

Explicació:

• S’accedeix al inode root (2) aquest tindrà 1 o més punters a blocs. • Accedim al contingut d’aquests punters a blocs. • En cas de que trobem un fitxer o un link estarem en un cas trivial i no farem res. • En cas de que trobem un directori s’inicia un procés recursiu fent ús del nou inode

associat amb el directori.


34

4.3. Mostrar el contingut d’un fitxer

Descripció: Per tal de mostrar el contingut d’un fitxer es van recorrent tots els blocs de dades associats a un fitxer donat fins que arribem a un bloc que contingui el nombre 0. Prerequisits:

• Mida de Bloc: L’obtindrem del Superbloc. • Posició de la taula d’inodes. L’obtindrem dels diversos group descriptors.

Explicació:

• S’accedeix al inode root (2) aquest tindrà 1 o més punters a blocs. • Accedim al contingut d’aquests punters a blocs. • En cas de que trobem el fitxer que busquem el mostrem i seguim cercant fins

arribar a final de la partició. • Per mostrar el contingut del fitxer anirem accedint als punters a blocs fins que

arribem al final d’aquests.

4.4. Creació d’una carpeta

Descripció: Per tal de crear una carpeta haurem de comprovar que no existeixi una carpeta amb el mateix nom en el mateix path així com que tinguem espai en disc. Prerequisits:

• Mida de Bloc: L’obtindrem del Superbloc. • Posició inode bitmap. L’obtindrem dels diversos group descriptors. • Posició block bitmap. L’obtindrem dels diversos group descriptors. • Posició de la Taula d’inodes. L’obtindrem dels diversos group descriptors.

Explicació:

• S’accedeix a l’inode de la carpeta on es trobem per tal d’extreure’n el seu bloc de dades associat.

• Ens desplacem fins el bloc de dades esmentat i comprovem que el nom de la carpeta no existeix, alhora comprovem si el nom del directori cap en el bloc de dades actual.

• En cas de que el nom de directori no càpiga en el bloc de dades actual (bloc de definició) ens desplacem fins el block bitmap i busquem el primer bloc lliure.

• Ens desplacem fins l’inode bitmap i busquem el primer inode lliure. • En cas de que hi hagin blocs lliures i inodes lliures actualitzarem la informació en

l’inode (haurem d’actualitzar les data d’escriptura i el nombre blocs que usa) i en el bloc de dades corresponent (haurem d’afegir el nom de la carpeta).


35

4.5. Creació d’un link

Descripció: Per tal de crear un link haurem de comprovar que no existeixi un link amb el mateix nom en el mateix path. Prerequisits:

• Mida de Bloc: L’obtindrem del Superbloc. • Posició de la Taula d’inodes. L’obtindrem dels diversos group descriptors. • Posició inode bitmap. L’obtindrem dels diversos group descriptors.

Explicació:

• Ens desplacem fins l’inode bitmap i busquem el primer inode lliure. • Ens desplacem fins l’inode lliure i hi afegim el path en la zona de punters a blocs

de dades. Alhora afegim la resta de dades complementàries com dates mida de l’inode etc.

4.6. Creació d’un fitxer

Descripció: Per tal de crear un fitxer haurem de comprovar que no existeixi un fitxer amb el mateix nom en el mateix path així com que tinguem suficient espai en disc. Prerequisits:

• Mida de Bloc: L’obtindrem del Superbloc. • Posició inode bitmap. L’obtindrem dels diversos group descriptors. • Posició block bitmap. L’obtindrem dels diversos group descriptors. • Posició de la Taula d’inodes. L’obtindrem dels diversos group descriptors. • Mida del fitxer que volem pujar

Explicació:

• Comprovem que la mida del fitxer no superi l’espai lliure. • Calculem el nombre de blocs de dades que ocuparà. • Ens desplacem fins l’inode bitmap i busquem el primer inode lliure. • Ens desplacem fins el block bitmap i busquem el numero de blocs de dades lliures

(de contingut) que hem calculat anteriorment. Fet això anem escrivint el contingut del fitxer sobre els blocs de dades lliures que hem trobat.

• Escrivim en l’inode lliure els blocs de dades que hem usat així com la resta d’informació necessària com dates, nombre blocs que ocupa etc.

• Actualitzem l’inode pare (haurem d’actualitzar la data d’escriptura i el nombre de blocs que usa) així com el seu bloc de dades associat (haurem d’afegir el nom del fitxer).


36

4.7. Esborrat d’un fitxer

Descripció: Consisteix en eliminar un fitxer de la partició. Trobem diverses tècniques d’esborrat. La més usada per la majoria de sistemes de fitxers consisteix en marcar un fitxer com esborrat però en realitat el contingut del fitxer segueix físicament en disc fins que la seva informació és matxucada per un nou fitxer / carpeta. És decisió de l’administrador del sistema escollir una o altre tècnica ja que un esborrat total òbviament és més segur però té un cost computacional que pot ser elevat en cas que treballem amb grans fitxers. Tot seguit descriurem com realitzar un esborrat “superficial”. Prerequisits:


Explicació:

• Anem recorrent la zona de punters a blocs de l’inode associat amb el fitxer que volem esborrar i anem marcant com lliures els blocs de dades usats en el block bitmap corresponent.

• Ens desplacem fins l’inode bitmap i marquem com lliure l’inode al qual ens trobem. • Ens desplacem fins l’inode pare per actualitzar-lo i per recuperar el bloc de dades

(de definició) associat. • Ens desplacem fins el bloc de dades i n’eliminem el fitxer.

4.8. Esborrat d’un directori

Descripció: Consisteix en eliminar un directori de la partició. A l’igual que passa amb l’eliminació del fitxer podrem escollir entre un esborrat superficial (només marcant com esborrat) o un de total eliminant completament el contingut del directori. L’esborrat del directori alhora ens plantejarà una nova decisió. Donat que un directori pot contenir altres fitxers i directoris podem optar per realitzar un esborrat recursiu (esborrarà tot el que contingui el directori) o un esborrat no recursiu (només esborrarà els directoris que no continguin altres directoris o fitxers). Per tal de realitzar un esborrat recursiu i superficial descendirem per l’arbre de directoris del directori que volem esborrar i anirem marcant tots els fitxers i directoris que conté com a lliures.


37

Prerequisits:


Explicació:

• Anem recorrent la zona de punters a blocs de l’inode associat amb el directori que volem esborrar. A partir d’aquests blocs de dades realitzarem el procés recursiu esmentat.

• Descendim fins al 1r nivell de l’arbre de directoris i marquem fitxers i directoris que hi hagi com esborrats. Per fer-ho seguirem amb el mateix procediment que per esborrar un fitxer.

• Descendim fins al nivell n. Aturarem aquest procés quan no hi hagin més directoris.


38

5. Aplicacions similars

5.1. Explore2fs

Software que es distingeix de la resta que hem usat (que es limiten a mostrar el contingut dels fitxers) perquè es dóna informació específica del Superbloc, de l’inode que conté la informació, dels punters a blocs etc. Aquest programa presenta un conjunt important de funcions interessants, aquestes són:

• Interfície amigable • Mostra particions Ext2 / Ext3 que es trobin en el mateix ordinador on està corrent

l’aplicació • Permet exportar fitxers de text i de dades • Permet exportar fitxers de mida gran • Permet exportar directoris • Es dóna informació detallada del sistema de fitxers

Aquest programa presenta alguns inconvenients com:

• No es mostra informació dels group descriptors • No es mostra informació de l’inode bitmap • No es mostra informació del block bitmap • No permet eliminar fitxers • No permet crear carpetes ni fitxers

Figura 9. Captura informació Superbloc i de fitxer


39

5.2. Ltools

Software que permet l’accés a les particions Ext2, Ext3 i Reiserfs que es trobin en el mateix ordinador on estem corrent l’aplicació. Alhora permet l’accés a discs remots.

L’objectiu d’aquest software és el de permetre l’accés a dades que tinguem en un Linux des de Windows.

Les funcions més interessants d’aquest programa són:

• Interfície amigable

• Fàcil transferència de fitxers Linux a Windows i viceversa

• Permet la creació de carpetes i sym links

Alguns dels inconvenients més destacables són:

• No permet muntar particions externes (des de fitxers)

• No dóna informació detallada del sistema de fitxers

Figura 10. Captura Ltools


40

5.3. Ext2ifs

Es tracta d’un driver que permet l’accés a particions Ext2 / Ext3 des del mateix explorador de Windows.

Resulta fàcil d’instal·lar ja que té un instal·lador i no requereix cap configuració tret de l’assignació d’una lletra a la unitat.

Tot seguit assenyalarem el conjunt de funcionalitats que ens dóna aquest driver:

• Lectura / Escriptura de fitxers i directoris.

• Permet executar funcions d’I/O típiques pròpies de Windows com:

o Byte Range Locks: Tècnica que consisteix en serialitzar els accessos a una regió concreta d’un fitxer. Això es fa per tal de garantir accés exclusiu de lectura / escriptura del fitxer així com també per permetre un accés compartit al fitxer.

o Directory Notfication: Actualitza l’Explorador de Windows quan estem visualitzant una carpeta i s’efectuen canvis sobre aquesta.

o Oplocks (Opportunistic Locks): Es tracta d’una característica del LAN Manager de Windows que permet incrementar el rendiment d’una aplicació de xarxa. Es tracta d’una garantia del servidor per tal de compartir un volum lògic al seus clients. Aquesta garantia consisteix en informar als clients que un fitxer no pot ser modificat pel servidor, o si el canvi es imminent informar als clients abans de que aquest es produeixi.

Altres funcionalitats no cobertes pel driver fins el moment són:

• No es mantenen els permisos d’usuaris: Qualsevol usuari pot accedir a tot el contingut del disc sense cap mena de restricció.

• “Normalització” dels fitxers ocults: Els fitxers amb un punt davant (fitxers ocults de Unix) es tractaran igual que la resta. No com a fitxers ocults

• No es permet l’accés a tipus de fitxers especials: El driver no permet l’accés a fitxers especials com són Sockets, Pipe’s, Soft Links etc.

• Code page únic: El únic code page vàlid és el mateix que utilitza Windows.


41

Figura 11. Captura Ext2ifs

5.4. Altres Linux ens ofereix multitud d’eines per “tunejar” particions Ext2. Algunes de les utilitats més conegudes són:

• E2tools: Composat per les següents eines: o e2cp: Permet copiar fitxers a una partició Ext2 ja creada o e2mv: Permet copiar fitxers a una partició Ext2 ja creada o e2rm: Permet esborrar fitxers d'una partició Ext2 ja creada o e2mkdir: Permet crear Directori o e2ln: Permet crear hard links o e2ls: Permet llistar fitxers/directoris o e2tail: Mostra la darrera part d'un fitxer.

• E2fsprogs: Composat per les següents eines: o mke2fs: Permet crear sistema de fitxers Ext2/Ext3 o e2fsck: Verifica sistema de fitxers Ext2/Ext3 o debugfs: Debugga sistema de fitxers Ext2/Ext3. o dumpe2fs: Mostra informació del sistema de fitxers Ext2/Ext3. o tune2fs: Permet afegir/modificar funcionalitats d'un sistema de fitxers

Ext2/Ext3.


42

6. Aplicació E2_rdr

6.1. Introducció

E2_rdr es tracta d’una eina docent orientada a l’estudi i aprenentatge dels sistemes de fitxers de Linux i més concretament del sistema de fitxers Ext2.

Com ens suggereix el seu nom es tracta d’una eina que permet la lectura de particions Ext2 fent especial èmfasi en com s’accedeix a la informació que s’està mostrant.

A continuació veurem com està dissenyada i implementada l’eina i en detallarem el seu funcionament tant des d’una visió d’usuari com de programador.

6.2. Anàlisi requisits

Com ja s’ha comentat anteriorment aquesta és una eina orientada a l’estudi del sistema de fitxers Ext2 i per tant l’aplicació lluny de ser una eina de propòsit general es tracta d’una eina enfocada a estudiants de l’assignatura de Sistemes Operatius on es realitza un estudi dels sistemes de fitxers.

Aquest estudi fins el moment estava basat en gran part en l’estudi del sistema de fitxers FAT (12/16/32) ja que era el sistema de fitxers de qual se’n tenia més informació. Aquesta eina te per objectiu trencar amb aquesta dinàmica apropant a professorat i alumnes un sistema de fitxers del qual fins el moment s’aprofundia poc amb el seu funcionament, degut a que la documentació sobre aquest era escassa.

La definició dels objectius es va fer tenint en compte tot l’esmentat.

6.2.1. Requisits funcionals

• S’oferirà a l’usuari la possibilitat de veure petites ajudes sobre el que s’està veient.

• L’usuari podrà carregar qualsevol imatge i mostrar-ne els detalls de forma pràcticament immediata.

• L’usuari podrà veure informació relacionada amb:

o Superbloc: En aquest apartat es mostrarà el contingut dels camps més rellevants com la mida de bloc, d’inode, el nombre d’inodes etc.

o Group Descriptors: En aquest apartat es mostrarà el contingut dels diversos group descriptors mostrant informació relativa a les posicions de:

� Block Bitmap

� Inode Bitmap

� Inode Table

� ...

o Inode Bitmap: En aquest apartat es mostrarà el contingut de l’inode bitmap.

o Block Bitmap: En aquest apartat es mostrarà el contingut del block bitmap

o Arbre de directoris: En aquest apartat es mostrarà el contingut de les dades que conté la partició analitzada. L’usuari podrà visualitzar un conjunt de dades que desglossarem en els següents punts:


43

� Arbre: Permetrà a l’usuari veure tots els directoris / fitxers de forma ràpida i intuïtiva. Es podrà anar desplegant per tal de mostrar informació relativa a fitxers / directoris / links etc. El que es pretén es no limitar-nos a mostrar la informació típica que ens dona un sistema operatiu com mida, data i extensió sinó informació interna com el nombre d’inodes que ocupa, quins són i la posició que ocupen dins de la partició.

� Fitxer en ASCII: Permetrà mostrar el contingut del fitxer al qual estiguem accedint en format ASCII. Per tal de facilitar la visualització de fitxers de grans dimensions es disposarà d’opcions per la visualització d’aquests a trams.

� Fitxer en Hexadecimal: Permetrà mostrar el contingut del fitxer al qual estiguem accedint en format hexadecimal.

� Inode en Hexadecimal: Permetrà mostrar el contingut de l’inode dotant a l’usuari de la possibilitat de poder explorar l’inode camp a camp.

� Exportar Fitxer: Permetrà guardar en disc el contingut d’algun fitxer prèviament seleccionat. En cas de seleccionar una imatge l’usuari podrà exportar-la i alhora s’oferirà la possibilitat de visualitzar-la sense necessitat de guardar-la a disc.

6.2.2. Requisits usabilitat Apart de les funcionalitats anteriorment esmentades, l’eina havia de ser usable. Per aquest motiu, l’eina havia de complir amb un seguit de requisits que tot seguit assenyalarem:

• L’aplicació com a eina didàctica ha de tenir una interfície amigable i intel·ligible.

• Es comptarà en tot moment amb una ajuda que permetrà a l’usuari entendre què fa l’aplicació.

• Es tractarà de minimitzar el nombre de clics que hagi de fer l’usuari per tal d’accedir a una determinada informació.

6.3. Decisions disseny

6.3.1. Entorn execució

Una de les primeres decisions que varem prendre va ser com volíem que l’usuari final (alumnes / professors) treballés amb el programa.

Des d’un primer moment teníem clar que l’aplicació havia de tenir un interfície amigable i senzilla i per aquest motiu vàrem descartar interfícies tipus consola.

Arribats en aquest punt varem estudiar les diverses alternatives que teníem. Aquestes eren un entorn web i un entorn d’execució local.

L’entorn web tenia forces avantatges com que no necessita de cap software addicional per funcionar tret del navegador i que la seva execució és independent de la màquina i del sistema operatiu. Però alhora també presenta forces desavantatges com que l’accés a fitxers locals és complex i per aquest motiu varem descartar aquesta opció.

En el següent apartat detallarem l’entorn de programació usat.


44

6.3.2. Entorn programació Un cop escollit l’entorn d’execució varem valorar les diverses opcions existents en el mercat actual com són Java, Delphi i la família .NET.

Java és un entorn àmpliament usat, amb una bona documentació i multi plataforma però varem descartar aquest entorn pel fet de ser un llenguatge interpretat (més lent) i perquè no en teníem l’experiència desitjada.

Delphi també es un entorn potent i d’actualitat però, no s’estudia en cap assignatura de la carrera i per por a trobar-nos sense suport per part del professorat varem decidir descartar-lo.

Finalment varem valorar l’entorn .NET. Aquest és àmpliament usat avui en dia, disposa de bona documentació i és usat en diversos departaments de l’escola. Malgrat no tenir experiència prèvia amb .NET, havíem treballat amb C i C++ anteriorment i això ens va animar a treballar amb aquest entorn.

Un cop decidit usar l’entorn .NET varem optar per fer ús de Visual C++, però aquest ens va donar forces problemes i això juntament amb una manca de documentació del tractament de fitxers binaris ens va fer decidir per fer ús del Visual C#.


45

6.4. Anàlisi funcional

6.4.1. Modelat estàtic

6.4.1.1. Diagrama de casos d’ús L’aplicació presenta un conjunt de funcionalitats que veurem tot seguit en el diagrama de casos d’ús:

Figura 12. Diagrama casos ús


46

Tot seguit detallarem l’objectiu / funcionament de cadascun dels casos d’ús assenyalats:

Cas ús: Mostrar ajuda ID CU1 Objectiu Mostrar manual d’ajuda Actors A1 Usuari

Precondició -

CU Relacionats Tots Activació A discreció de l’usuari Flux Principal 1. L’usuari clica sobre la opció d’ajuda.

2. S’escull sobre quina opció es desitja rebre ajuda Variacions - Excepcions - Postcondició - Comentaris -

Taula 14. Especificació cas d’ús mostrar ajuda

Cas ús: Obrir Imatge ID CU2 Objectiu Obrir una imatge Ext2 vàlida Actors A1 Usuari

Precondició -

CU Relacionats - Activació A discreció de l’usuari Flux Principal 1. Obrir una imatge Ext2 vàlida

2. Guardar a memòria informació relativa al Superbloc

3. Guardar a memòria informació relativa als group descriptors.

Variacions - Excepcions La imatge no sigui vàlida. Postcondició Imatge resta oberta per tal de poder realitzar altres

operacions. Comentaris -

Taula 15. Especificació cas d’ús obrir imatge


47

Cas ús: Mostrar superbloc ID CU3 Objectiu Mostrar informació rellevant superbloc Actors A1 Usuari Precondició Haver obert una imatge Ext2 vàlida. CU Relacionats - Activació A discreció de l’usuari Flux Principal 1. L’usuari clica sobre la opció mostrar superbloc Variacions - Excepcions - Postcondició - Comentaris -

Taula 16. Especificació cas d’ús mostrar Superbloc

Cas ús: Mostrar group descriptors ID CU4 Objectiu Mostrar contingut dels group descriptors Actors A1 Usuari Precondició Haver obert una imatge Ext2 vàlida. CU Relacionats - Activació A discreció de l’usuari Flux Principal 1. L’usuari clica sobre la opció mostrar group

descriptors 2. L’usuari pot clicar sobre els diversos controls per mostrar el contingut d’un group descriptor concret.

Variacions - Excepcions L’usuari intenta accedir a un Group Descriptor

Inexistent Postcondició - Comentaris -

Taula 17. Especificació cas d’ús mostrar group descriptors


48

Cas ús: Mostrar block bitmap ID CU5 Objectiu Mostrar contingut d’un block bitmap en format hex. Actors A1 Usuari Precondició Haver obert una imatge Ext2 vàlida. CU Relacionats - Activació A discreció de l’usuari Flux Principal 1. L’usuari clica sobre la opció mostrar block

bitmap. 2. L’usuari pot clicar sobre els diversos controls per mostrar un block bitmap concret.

Variacions - Excepcions - Postcondició - Comentaris -

Taula 18. Especificació cas d’ús mostrar block bitmap

Cas ús: Mostrar inode bitmap ID CU6 Objectiu Mostrar contingut d’un inode bitmap en format hex. Actors A1 Usuari

Precondició Haver obert una imatge Ext2 vàlida.

CU Relacionats - Activació A discreció de l’usuari Flux Principal 1. L’usuari clica sobre la opció mostrar inode bitmap.

2. L’usuari pot clicar sobre els diversos controls per mostrar un inode bitmap concret.


Taula 19. Especificació cas d’ús mostrar inode bitmap


49

Cas ús: Mostrar arbre de directoris ID CU7 Objectiu Navegar per l’estructura de directoris de la imatge

Ext2. Actors A1 Usuari

Precondició Haver obert una imatge Ext2 vàlida.

CU Relacionats Exportar Fitxer i Mostra Imatge Activació A discreció de l’usuari Flux Principal 1. L’usuari clica sobre un fitxer o directori

2. L’aplicació mostra les propietats del fitxer / directori i en mostra el seu contingut en ASCII i en Hex

3. L’usuari podrà clicar a les opcions Exportar Fitxer i Mostra Imatge (si es un fitxer JPEG)


Taula 20. Especificació cas d’ús mostrar arbre de directori

Cas ús: Exportar fitxer ID CU8 Objectiu Exportar un fitxer al disc local Actors A1 Usuari

Precondició Haver clicat sobre un fitxer en l’arbre de directoris

CU Relacionats Mostrar Arbre de Directoris i Mostra Imatge Activació A discreció de l’usuari Flux Principal 1. Es demana a l’usuari el nom amb que vol guardar

el fitxer. 2. L’aplicació procedeix a la copia d’aquest amb el nom assignat.

Variacions - Excepcions No hi hagi prou espai en el disc local Postcondició - Comentaris -

Taula 21. Especificació cas d’ús exportar fitxer


50

Cas ús: Mostrar imatge ID CU9 Objectiu Mostrar una imatge. Actors A1 Usuari

Precondició Haver clicat sobre un fitxer amb extensió JPEG en l’arbre de directoris

CU Relacionats Exportar fitxer i Mostrar arbre directoris Activació A discreció de l’usuari Flux Principal 1. L’aplicació crea un fitxer temporal (en el disc local)

per guardar la imatge. 2. Es mostra la imatge.

Variacions - Excepcions No hi hagi prou espai en el disc local Postcondició - Comentaris -

Taula 22. Especificació cas d’ús mostrar imatge


51

6.4.1.2. Diagrama de classes

L’aplicació està formada per un gran nombre de classes. Tot seguit passarem a detallar les relacions entre aquestes fent ús d’un diagrama de classes.

Figura 13. Diagrama de classes

A continuació detallarem el contingut de cadascuna de les classes (atributs i mètodes que contenen) que conformen l’aplicació així com també una breu descripció de la seva funció.

Figura 14. Classe Program

Es la classe principal de tot projecte fet amb C#. Únicament conté la funció main que farà la crida a la classe form_ppal.


52

Figura 15. Classe form_ppal

Classe principal de l’aplicació des de la qual s’obre la imatge Ext2 i es crida a la resta de classes. Aquesta classe disposa d’interfície que mostrarà informació de la partició com la seva mida, la mida del bloc, el nom de la imatge etc.


53

Figura 16. Classe Ext2

Classe encarregada de llegir la imatge Ext2 i carregar a memòria els camps més rellevants del Superbloc (classe super_bloc) i del Group Descriptor (classe group_desc). Aquesta classe no disposa d’interfície.

Figura 17. Classe inode

La classe inode permet empaquetar tota la informació associada a un inode per tal de posteriorment tractar-la obtenint així el contingut d’un fitxer donat. Aquesta classe no disposa d’interfície.


54

Figura 18. Classe super_bloc

Classe encarregada d’emmagatzemar la informació associada amb el Superbloc. Aquesta classe és àmpliament usada ja que conté informació essencial de la imatge. No disposa d’interfície.

Figura 19. Classe group_desc

Classe encarregada d’emmagatzemar la informació associada a un group descriptor. En cas de tenir més d’un Group Descriptor es farà ús d’un array de group_desc. Aquesta classe a l’igual que amb la classe super_bloc serà àmpliament usada ja que és necessària per la localització de la taula d’inodes. No disposa d’interfície.


55

Figura 20. Classe form_superbloc

Aquesta classe disposa d’interfície i permet visualitzar tota la informació del Superbloc anteriorment emmagatzemada a la classe super_bloc.


56

Figura 21. Classe form_groupdesc

Aquesta classe disposa d’interfície i permet visualitzar tota la informació dels Group Descriptors anteriorment emmagatzemada a l’array de group_desc.


57

Figura 22. Classe form_inode_bitmap

Aquesta classe disposa d’interfície i permet visualitzar el contingut de l’inode bitmap. Per fer-ho s’accedeix al fitxer (previ càlcul de la posició a partir del camp inode_bitmap de la classe group_desc) i es va llegint el seu contingut alhora que es pinta per pantalla.

Figura 23. Classe form_block_bitmap

Aquesta classe disposa d’interfície i permet visualitzar el contingut del block bitmap. De la mateixa manera que amb l’inode bitmap s’accedeix al fitxer i es va llegint i pintant el seu contingut per pantalla.


58

Figura 24. Classe form_tree

Aquesta classe disposa d’interfície i ens permetrà visualitzar un arbre de directoris, les propietats d’un fitxer/carpeta, el contingut d’un inode en hexadecimal, el contingut d’un fitxer en ASCII o en hexadecimal etc.


59

Figura 25. Classe tree_aux

Classe que hereta de la classe TreeNode. Això permet modificar el contingut del TreeNode (per defecte un string) podent afegir-hi un enter (nombre d’inode). D’aquesta forma en clicar a un node de l’arbre ja sabem quin inode té associat.

Figura 26. Classe form_exporta_fitxer

Aquesta classe disposa d’interfície la qual ens permetrà exportar un fitxer des de la imatge Ext2 fins al disc local.


60

Figura 27. Classe form_imatge

Aquesta classe disposa d’interfície que ens permetrà visualitzar imatges (jpg o png).

Figura 28. Classe func_aux_tree

Classe que conté un conjunt de funcions auxiliars associades a la classe form_tree. Aquestes es troben en una classe independent perquè son usades per diverses classes evitant així redundància de codi.


61

Figura 29. Classe form_ajuda

Aquesta classe disposa d’interfície que ens permetrà mostrar el manual de l’aplicació.

6.4.2. Modelat dinàmic

Tot seguit passarem a veure els diagrames de seqüència dels processos més rellevants que porta a cap l’aplicació.

Figura 30. Diagrama de seqüència Obrir imatge Ext2


62

Figura 31. Diagrama de seqüència Mostrar imatge jpg

Figura 32. Diagrama de seqüència Exportar fitxer


63

6.5. Evolució projecte

Durant la realització del projecte s’han passat per un seguit de fases amb els seus problemes associats en cadascuna d’elles. Tot seguit assenyalarem cadascuna d’aquestes fases:

• Documentació: La fase de documentació va ser bastant delicada ja que hi havia força informació però aquesta era d’escàs interès. Inicialment varem decidir consultar diversos llibres però aquests no aprofundien en els detalls interns d’Ext2.

Seguidament varem decidir cercar per Internet però l’únic que trobàvem eren programes compilats com Explore2fs i Ltools. Posteriorment varem trobar el codi font d’algunes aplicacions com E2ls i Dumpe2fs però aquest no ens va ser gaire útil perquè era difícil d’entendre degut a que s’utilitzaven un gran nombre de llibreries externes a les quals no teníem accés.

Finalment varem trobar algunes pàgines on es detallaven els aspectes interns d’Ext2 i va ser d’aquestes d’on varem treure la major part d’informació.

• Programació en C: Un cop superada la fase de documentació inicial varem creure oportú realitzar proves sobre les imatges d’Ext2 que havíem creat. Varem creure oportú realitzar aquestes proves amb un llenguatge conegut així que varem escollir fer-les amb C. En aquestes proves inicials varem llegir el superbloc i els group descriptors.

Posteriorment varem llegir el block bitmap, l’inode bitmap i les taules d’inodes. A l’hora de llegir aquestes últimes varem tenir forces problemes perquè aplicàvem la mateixa estratègia que la resta de regions (lectura seqüencial) i això provocava que llegíssim brossa.

Per tal de llegir els blocs de dades varem cometre el mateix error i això ens va provocar nous problemes amb lectures de brossa.

Finalment, després de documentar-nos novament varem poder entendre els errors que havíem comès i varem ser capaços d’implementar comandes com un tree i un cat d’un fitxer.

• Programació en Visual C++: L’objectiu inicial del projecte era realitzar una aplicació didàctica i era necessari fer ús d’una aplicació amb un entorn visual agradable. Per aquest motiu es va decidir escollir programar amb Visual C++. Aquest era un entorn completament desconegut per nosaltres fins el moment i per aquest motiu varem haver de realitzar un treball de documentació. Les primeres proves van ser satisfactòries però alhora d’intentar llegir el fitxer binari varem topar amb problemes de compilació i de documentació que van forçar-nos a canviar d’entorn.

• Programació en Visual C#: Després dels problemes esmentats en que varem topar fent ús del Visual C++ varem decidir fer ús de Visual C#. Malgrat tampoc teníem cap experiència prèvia amb aquest llenguatge la documentació que varem trobar era extensa i detallada. Finalment i després d’alguns errors varem ser capaços d’implementar una aplicació usable i fàcil d’entendre.


64

6.6. Proves realitzades

Per tal de garantir el correcte funcionament de l’aplicació s’han realitzat un conjunt de proves que tot seguit detallarem.

• Particions de diverses mides: S’han realitzat particions de diverses mides per tal de garantir que l’aplicació no fallés en cap moment. Les particions que hem creat van dels 500 KB fins els 100MB. Un cop realitzades aquestes proves hem pogut comprovar que l’aplicació no presenta cap problema alhora de treballar amb particions grans.

• Particions amb diverses mides de bloc: S’han realitzat proves amb particions amb mides de bloc d’1KB, 2KB i 4KB. Un cop realitzades les proves varem observar que l’aplicació tenia problemes perquè no trobava el group descriptor. Finalment varem observar que el group descriptor es trobava en diferents localitzacions en funció de la mida de bloc i varem controlar-ho degudament.

• Fitxers de diverses mides: S’han creat fitxers de diverses mides des de 20 bytes fins els 80 MB. Un cop realitzades aquestes proves hem comprovat que l’aplicació tenia problemes alhora de tractar amb fitxers de grans dimensions ja que s’intentava carregar tot el fitxer a memòria fent que la màquina on s’executava l’aplicació quedés penjada. Per tal de solucionar això es va optar per carregar el fitxer a memòria en trossos de l’ordre d’1MB podent-nos desplaçar entre aquests mitjançant cursors.

• Fitxers de diversos tipus: S’han realitzat proves amb fitxers de diversos tipus com són: txt, jpg, doc, pdf, html etc. Un cop realitzades les proves hem pogut comprovar que l’aplicació no presenta cap problema amb els diversos tipus de fitxers provats. Per tal de fer aquestes proves s’ha calculat l’md5sum dels fitxers abans de carregar-los en una partició i després de descarregar-los d’aquesta podent observar que aquests coincideixen.

• Càrrega d’imatges corruptes: S’ha provat de carregar imatges d’Ext2 corruptes. Inicialment l’aplicació les intentava carregar i fallava. Per tal de solucionar això es va optar per llegir inicialment el magic number de tota partició Ext2 (0xEF53). Si aquest coincideix seguim llegint i en cas contrari s’atura l’aplicació.


65

6.7. Posada en explotació

Per tal de poder utilitzar l’aplicació i com s’explica en el punt 7.1 es necessita tenir una imatge Ext2 creada. Apart de la imatge Ext2 necessitarem òbviament el binari amb l’aplicació. Aquest binari però, no ens funcionarà en qualsevol màquina ja que en estar creat amb .NET es necessitarà el framework de .NET que inclou les API’s i llibreries més comuns per al correcte funcionament d’una aplicació desenvolupada en aquest entorn.

Trobem diverses opcions per generar el binari:

• Directament: Ens generarà un .exe que només es podrà executar en màquines amb el framework .NET instal·lat.

• Fent ús de la opció publish: Aquesta és una opció que ofereix el Visual Studio que permet publicar una aplicació ja sigui en una web com en un cd. Aquesta opció resulta molt útil ja que ens generarà un fitxer setup.exe que quan s’executi en qualsevol màquina es comprovarà si aquesta disposa del framework, en cas negatiu es procedirà a la descarrega del framework i posteriorment s’instal·larà l’aplicació en la màquina. Finalment tindrem instal·lada l’aplicació en la màquina completament funcional.


66

7. Manual de funcionament de l’aplicació

7.1. Prerequisits

Com ja s’ha comentat anteriorment el nostre software requereix la creació d’una partició Ext2. Per crear les particions s’ha fet ús de Linux. En el nostre cas s’ha usat Ubuntu però no suposa cap problema fer servir qualsevol altra distribució.

7.1.1. Creació partició Ext2

Per tal de crear un fitxer formatat amb Ext2 usarem les comandes següents:

• Creació fitxer: On: o of: nom de la partició o count: mida de la partició (en aquest cas 2MB.)

#dd if=/dev/zero of=particio.ex2 bs=1024 count=2048

• Creació del sistema de fitxers o Opció 1: Formatarà el fitxer amb format Ext2 assignant una mida de bloc

que s’assignarà automàticament a partir d’un model heurístic que tindrà en compte la mida de la partició i l’ús que s’espera que se’n pugui fer. # mke2fs particio.ex2

o Opció 2: Ens permet fixar una mida de bloc determinada. Podrem escollir entre 1KB, 2KB o 4KB. Per fer-ho s’usarà el modificador -bs seguit de la mida de bloc en Bytes.

# mke2fs –bs 2048 particio.ex2 Nota: Per tal d’executar aquestes comandes haurem de tenir privilegis de root.

7.1.2. Muntar partició Ext2 Muntar una partició consisteix en fer-la accessible per als diversos usuaris del sistema. Un cop muntada la partició serem capaços de llegir / escriure dades sobre aquesta. Per muntar el nou fitxer amb format Ext2 tenim diverses opcions:

o Linux: Amb Linux podem fer ús de la comanda mount, fent ús però de la opció de loopback. # mount particio.ex2 /mnt -o loop=/dev/loop/0 En aquest cas estem muntant la partició “particio.ex2” al directori /mnt. Qualsevol usuari que vulgui escriure/llegir dades de la partició haurà d’accedir a /mnt Per tal de desmuntar una partició farem ús de la comanda umount acompanyada del directori / partició que volem desmuntar. #umount /mnt Nota: Depenent de la distribució de Linux que s'usi el dispositiu de loop l'haurem d’especificar tal com esta escrit a dalt o bé: /dev/loop0


67

o Windows: Amb Windows existeixen diferents solucions apart de la creada específicament per aquest projecte. Trobem 2 tipus de solucions diferents:

o Driver: Driver que permet treballar amb particions Ext2 des de Windows.

Ens permeten muntar particions Ext2 de forma transparent per l’usuari ja que podem accedir a la partició fent ús del mateix explorador de Windows.

o Programes standalone: Alguns d’aquests programes són:

� Linux-reader: Ens mostra particions Ext2 des de l’explorador de Windows. Només permet lectura dades.

� Explore2fs: Programa escrit en Delphi que ens permet llegir particions Ext2 / ext3des de fitxer o des de disc.

Nota: Ampliació d’aquesta informació en l’apartat d’aplicacions similars (Apartat 5).

7.2. Execució aplicació

Com ja s’ha esmentat la nostra aplicació obrirà imatges amb extensió ex2. Un cop carregada una imatge vàlida l’aplicació permet realitzar un conjunt de funcions descrit anteriorment en l’anàlisi de requisits.

Tot seguit descriurem cadascuna de les funcionalitats del software creat.

7.2.1. Superbloc

Aquesta funcionalitat ens permet accedir a la regió del superbloc i mostrar-ne el seu contingut.

En aquest cas concret l’usuari no pot interactuar amb l’aplicació ja que únicament es mostren dades.

Figura 33. Captura Superbloc


68

Els camps més rellevants que podem observar en la captura són:

• Mida Bloc

• Mida Inode

• Inodes per Grup

7.2.2. Group Descriptor

Aquesta funcionalitat ens permet accedir i mostrar el contingut dels diferents Group Descriptors que pugui tenir una imatge (Ext2).

En aquest cas i degut a que podem trobar particions amb 1 únic Group Descriptor (particions petites 1 - 5MB) i d’altres amb més de 10 (particions mitjanes 100MB) es disposa d’un controls que ens permetran desplaçar-nos pels diversos Group Descriptors fàcilment.

Figura 34. Captura Group Descriptors

En la captura s’observen els Group Descriptors 3-6 d’una partició de 100MB. Com es pot apreciar cada Group Descriptor té un conjunt de camps associats. Els més rellevants són:

• Block Bitmap

• Inode Bitmap

• Inode Table

7.2.3. Inode Bitmap Aquesta funcionalitat ens permet mostrar el contingut dels diversos (1 per cada group descriptor ) inode bitmap.

De la mateixa manera que amb el cas dels Group Descriptors, l’usuari disposarà d’uns controls per desplaçar-se pels diferents Inode Bitmap.

Aquesta funcionalitat és força diferent de les 2 anteriors. En aquest cas l’usuari observarà una gran quantitat de nombres hexadecimals.


69

Això és degut a que cada Inode està simbolitzat amb 1 bit que podrà valer:

• 0: Inode Lliure

• 1: Inode ocupat

Per tant, quan la funcionalitat mostri:

• 0xFF: Voldrà dir que tenim 8 Inodes ocupats ja que 0xFF passat a binari és 1111 1111.

• 0x00: Voldrà dir que tenim 8 Inodes Lliures ja que 0x00 passat a binari és 0000 0000.

Figura 35. Captura Inode Bimap

En la captura observem un gran nombre d’Inodes Lliures, concretament d’un total de 1712 Inodes únicament estan ocupats 14:

0xFF=1111 1111 � 8 Inodes Ocupats

+

0x3F= 0011 1111� 6 Inodes Ocupats

7.2.4. Block Bitmap Aquesta funcionalitat és molt similar a la anterior però en aquest cas tractant blocs de dades en comptes d’inodes.

A l’igual que passava amb l’Inode Bitmap l’usuari disposarà d’uns controls per tal de poder desplaçar-se pels diversos Block Bitmap.

La forma de presentar les dades a l’usuari és la mateixa que en l’inode bitmap.


70

Figura 36. Captura Block Bitmap

En aquesta captura observem el nombre de blocs per grup en aquest cas 8192. En la captura també s’observa un gran nombre de 0’s i F’s que tenen el mateix significat que en el cas dels Inodes (0x00 � 8 blocs lliures i 0xFF � 8 blocs ocupats).

7.2.5. Arbre de directoris

Aquesta funcionalitat és la més important i complexa de tota l’aplicació. Aquesta disposa d’un gran nombre d’opcions que tot seguit anirem esmentant:

• Arbre: En tot moment es mostrarà un arbre de directoris que l’usuari podrà anar desplegant. Cada cop que l’usuari faci clic sobre un fitxer o carpeta es mostraran un conjunt de dades extretes de l’inode associat amb aquell fitxer o carpeta (detallat en el punt anomenat dades inode).

• Dades Inode: En clicar sobre qualsevol fitxer es mostrarà tota la informació associada sobre aquest. La informació que es mostra és:

o Nom fitxer

o Nombre d’Inode

o Permisos

o Mida

o Dates Creació, Escriptura i Accés

o Nombre Links

o Blocs reservats

o Punters a blocs dades

• Fitxer ASCII: En clicar sobre un fitxer del arbre el seu contingut es visualitzarà en aquest text box. En cas de clicar sobre un fitxer de grans dimensions apareixeran uns controls que permetran explorar el contingut del fitxer gradualment.

• Fitxer Hex: Equivalent hexadecimal del Fitxer ASCII.


71

• Inode Hex: En clicar sobre qualsevol carpeta o fitxer mostrarà l’inode en format hexadecimal. Alhora l’usuari disposarà d’uns controls que li permetran identificar d’on i com s’han extret les dades de l’inode.

• Exporta fitxer: Opció que apareixerà en clicar sobre qualsevol fitxer i que permetrà exportar el fitxer de la partició Ext2 al disc local.

• Mostra imatge: Opció que apareixerà en clicar sobre qualsevol imatge i que permetrà visualitzar una imatge sense necessitat d’exportar-la prèviament.

Figura 37. Captura Arbre Directoris

En la captura observem les diverses opcions anteriorment esmentades.

En aquest cas s’ha seleccionat un fitxer de text, del qual se’n mostren els detalls (a la part baixa de la captura) i el contingut (a la part superior dreta de la captura). Alhora també s’observa el botó exporta fitxer que ens permetrà exportar en el disc local el fitxer seleccionat.


72

8. Cost realització projecte

El cost del projecte el desglossarem en les següents 5 etapes:

• Documentació

• Disseny

• Implementació

• Memòria

• Proves

Un cop calculat el temps total aquest ens dóna unes 650 hores aproximadament. La següent taula mostra la distribució d’aquestes hores en les 5 etapes esmentades anteriorment.

Etapa Hores Percentatge

Documentació 125 19%

Disseny 50 8%

Implementació 300 46%

Memòria 150 23%

Proves 30 5%

TOTAL 655 100%

Taula 23. Estimació del cost de realització de cada etapa

Com es pot observar la etapa que té un cost més elevat ha estat la d’implementació motivada pel fet de que s’ha programat amb un llenguatge que no havíem tocat mai (Visual C#). També caldria destacar la etapa de documentació ja que aquesta ens ha portat un gran nombre d’hores motivat pel fet de que pocs llibres aprofundeixen sobre el funcionament intern d’Ext2. Finalment també caldria esmentar la fase de proves en que s’han realitzat diferents proves d’usabilitat per part del professorat de l’assignatura.


73

9. Conclusions

Les conclusions, les estructurarem en 3 parts clarament diferenciades: la primera part farà referència a l’eina implementada destacant-ne els seus avantatges i inconvenients respecte altres eines similars. Seguidament comentarem el sistema de fitxers Ext2, des del motiu de la seva elecció com a treball fins als avantatges i inconvenients que aquest presenta respecte altres sistemes de fitxers. Finalment, assenyalarem què ens ha aportat la realització d’aquest treball.

Pel que fa a l’eina implementada, considerem que hem complert amb els objectius plantejats a l’inici del treball en que ens fixàvem en que l’alumne tingués els suficients recursos disponibles per tal d’entendre el funcionament d’aquest sistema de fitxers ja siguin teòrics com pràctics.

Considerem que malgrat existeixen diferents eines que realitzen una funció similar a la nostra hem realitzat una eina completament diferent d’aquestes degut al fet que la nostra no té per objectiu donar un gran nombre de funcionalitats a l’usuari sinó que pretén ser útil per a la comprensió del funcionament intern del sistema de fitxer Ext2. Per tal de portar això a cap s’han creat estructures i funcions que permeten mostrar certes regions internes del sistema de fitxers que cap altre utilitat mostra com són el cas del Group Descriptor, l’Inode Bitmap i el Block Bitmap.

Com a contrapartida, la nostra eina no permet l’escriptura de dades en la imatge i en canvi algunes eines si que ho permeten. Això novament respon al fet que des d’un inici es va donar més preferència a l’aspecte docent que al funcional.

Pel que fa a la utilitat de l’eina considerem que serà positiu que els alumnes puguin estudiar i “tocar” un sistema de fitxers diferent de FAT ja que això els hi permetrà ampliar la seva visió dels sistemes de fitxers i de retruc dels diversos sistemes operatius.

Per tal d’avaluar el correcte funcionament de l’eina es va fer que el professorat de l’assignatura de Sistemes Operatius provés l’eina. En general el resultat va ser positiu però es van destacar algunes mancances en quan a la informació que es donava a l’usuari. Amb això volem dir que l’usuari havia de conèixer en tot moment d’on s’extreien les informacions de la imatge Ext2.

Un cop comentats diversos aspectes de l’eina implementada, passarem a comentar el sistema de fitxers escollit com a treball, Ext2. Es va escollir aquest sistema de fitxers pel fet que fins fa poc era el sistema de fitxers de referència de Linux. Caldria destacar que Ext2 va aparèixer l’any 1993 i ha sobreviscut durant gairebé 10 anys veient-se superat per sistemes de fitxers que han aparegut entre 5 i 8 anys després (Ext3 va aparèixer l’any 1998 i Reiserfs l’any 2001).

Malgrat Ext2 és un sistema de fitxers àmpliament conegut, la documentació sobre aquest és molt escassa. Això és degut a que la majoria de llibres no aprofundeixen en el funcionament intern d’Ext2 així com tampoc en la majoria de pàgines web. Això, entra amb contradicció amb el fet de que sigui un sistema de fitxers lliure ( ja que es fàcil pensar que un software lliure ha d’estar millor documentat que un que no ho és ). Una bona font d’informació que varem trobar va ser 1 paper extret d’una conferència de Linux


74

Pel que fa al funcionament intern d’Ext2 aquest resulta força senzill, això és degut a que l’estructura de tota partició Ext2 és força estàtica. El Superbloc sempre el trobarem a la posició 0x400 i seguit a aquest generalment (depèn de la mida de bloc) trobarem el Group Descriptor. A partir d’aquestes 2 regions podrem accedir a qualsevol directori/fitxer fent ús de senzills càlculs.

Val a dir però que amb la introducció de les millores d’Ext2 (Apartat 2.3) aquest millora el seu rendiment substancialment però com a contrapartida el funcionament intern es complica. Per exemple en el cas del directory indexing la millora de rendiment respecte a una cerca lineal es obvia però la contrapartida es que haurem de realitzar una cerca a través de l’arbre (més complex d’implementar). Un cop finalitzat el treball considerem que Ext2 te un gran nombre d’avantatges sobre sistemes de fitxers de la mateixa època com és el cas de FAT 12/16/32. Alguns dels avantatges més rellevants són òptim aprofitament de l’espai, fàcil implementació, etc. Tot seguit detallarem aquests avantatges. L’òptim aprofitament de l’espai fa referència al fet que els directoris amb Ext2 estan estructurats de forma dinàmica. Amb això volem dir que cada entrada directori no tindrà una mida prefixada sinó que la mida d’aquest serà completament dinàmica calculada a partir de la longitud del nom del directori. D’aquesta forma si tenim un directori anomenat dir1, la seva entrada de directori ocuparà el mínim possible. En canvi FAT estableix una mida d’entrada de directori concreta (li direm X). D’aquesta forma si l’entrada de directori ocupa menys que X es desaprofitarà espai de disc, i en cas de que l’entrada ocupi més de X es considera que el nom del directori és un nom llarg que es guardarà en una nova entrada de directori, desaprofitant d’aquesta forma més espai.

Fàcil implementació fa referència al fet que la implementació de la nostra eina requereix d’un menor nombre d’estructures que la implementació d’una eina amb FAT. Per tal d’entendre això posarem un petit exemple. Per accedir al contingut d’un fitxer amb Ext2 llegirem el seu nombre d’inode i a partir d’aquest fent uns senzills càlculs (a partir del Superbloc i del Group Descriptor) i sense necessitat d’emmagatzemar cap estructura a disc a part de les ja esmentades aconseguirem accedir al seu contingut. Per altra banda, per tal de fer la mateixa acció amb FAT 12/16/32 ens farà falta tenir carregada a memòria la FAT. Amb això volem dir que el cost computacional i de memòria que suposa realitzar aquesta operació amb Ext2 és molt menor que realitzar-la amb FAT.

Finalment, pel que fa als coneixements que ens ha portat la realització del treball, caldria destacar els següents: major experiència amb sistemes Linux, major coneixement dels sistemes de fitxers en general, aprendre Visual C#, major coneixement del procés de redactat d’un projecte etc. Tot seguit detallarem cadascun d’aquests coneixements adquirits.

Un cop finalitzat el treball hem tocat eines (que desconeixíem de la seva existència) que ens ofereix Linux, estretament lligades amb els sistemes de fitxers. Algunes d’aquestes eines són els paquets e2tools (conté eines com e2ls) i e2fsprogs (conté eines com e2fsck, mke2fs). Aquestes permeten la creació d’imatges i la seva posterior administració. Durant la realització del treball ens han sigut molt útils els coneixements previs sobre sistemes de fitxers apresos en l’assignatura de Sistemes Operatius. Com és normal però aquests se’ns han fet “petits” veient-nos obligats a documentar-nos sobre aspectes desconeguts fins el moment. Això ens ha permès ampliar una mica més la visió sobre els sistemes de fitxers.


75

A diferència dels anteriors punts dels quals en teníem certs coneixements previs a la realització del treball, el llenguatge de programació usat així com l’entorn en el qual s’emmarca eren completament desconeguts per nosaltres. Ens referim al fet que mai abans havíem programat amb .NET i més concretament amb Visual C#. Això ens va obligar a documentar-nos prèviament ja que malgrat Visual C# s’assembla a llenguatges en que ja havíem programat com és el cas de C++, aquest presenta un conjunt de característiques pròpies que van obligar-nos a programar amb més cautela del que hauria suposat programar amb un entorn conegut prèviament. Finalment, cal esmentar que mai abans havíem hagut de redactar una documentació tan extensa i rigorosa fet que ens ha obligat a familiaritzar-nos amb tasques com la creació d’una bibliografia, la correcta edició d’un document, etc.


76

10. Línies de futur

Un cop finalitzat el treball se’ns acudeixen un gran nombre de línies de futur com són:

• Dotar de compatibilitat amb Ext3: aquesta és la línia de futur més clara ja que Ext2 és força similar a Ext3. Malgrat això s’hauria d’estudiar en deteniment el funcionament intern d’Ext3 ja que apart d’incorporar una regió de journaling, Ext3 incorpora un arbre binari balancejat que permet l’acceleració de les cerques a través de la partició així com també un assignador de blocs de disc diferent d’Ext2 anomenat Orlov.

• Creació Imatges Ext2: aquesta línia de futur consistiria en afegir una opció en l’aplicació que ens permetés crear imatges de la mida desitjada per l’usuari. Malgrat pugui semblar una línia de futur senzilla aquesta comporta certes dificultats ja que en primera instància s’hauria de comprovar si resulta possible compilar el codi font de mke2fs (eina que permet la creació d’imatges Ext2/Ext3 en sistemes Linux) amb Windows. En cas negatiu s’hauria crear un nou software que ens realitzés aquesta funció. Aquesta línia de futur està estretament lligada amb la següent.

• Creació / Esborrat de carpetes i fitxers: aquesta línia de futur consistiria en dotar a l’aplicació de capacitat per modificar el contingut de les dades que es troben dins de l’aplicació així com també per afegir-ne de noves. Aquesta línia de futur també comportaria certes dificultats degut a que s’hauria de reestructurar certa part del codi així com la creació de nous formularis com són el cas dels formularis de creació / eliminació de carpetes, creació / eliminació de fitxers etc.

• Accés particions del disc local: aquesta línia de futur consistiria en dotar a l’aplicació d’accés a les particions Ext2 que es troben en el disc local. Aquesta és una línia de futur interessant ja que l’aplicació passaria de ser una aplicació purament docent a una aplicació útil per la transferència de dades de Windows a Linux. Aquesta línia també comporta certa dificultat degut a que ens hauríem de documentar sobre com llegir el contingut del MBR per tal de determinar les particions Ext2 així com la posició que ocupen en el disc.

• Aplicació multiplataforma: consistiria en fer que l’aplicació pogués executar-se independentment de la plataforma que usés l’usuari. Actualment l’aplicació està implementada en Visual C# i això resulta un problema per tots aquells usuaris que no tenen Windows instal·lat. Per tal de solucionar-ho es podria pensar en migrar l’aplicació a Java. També es podria pensar en una migració cap a un entorn web però la migració seria força més complexa degut a que aquest tipus d’entorns presenten força diferències respecte entorns de desenvolupament com són el cas de Java i .NET.

• Tests: consistiria en passar un conjunt de tests a l’alumnat juntament amb una enquesta per tal de valorar la documentació així com l’eina. Pel que fa a la documentació caldria valorar si aquesta és suficientment clara i completa, i pel que fa a l’eina caldria valorar diversos aspectes com són el cas de la usabilitat el nombre d’opcions, si ha resultat complicada la instal·lació etc. Aquests tests es passaran al maig de 2008 dins del marc de l’assignatura de Sistemes Operatius.


77

• Millores Ext2: com ja es va veure en l’apartat 2.3, Ext2 disposa d’un ampli ventall de millores sobre el sistema de fitxers original com és el cas del directory indexing i la redimensió del sistema de fitxer on-line. Una possible línia de futur podria ser estudiar la millora de rendiment que suposen cadascuna d’aquestes millores i investigar sobre possibles modificacions que representin una nova millora de rendiment. Alhora, es podria investigar sobre noves millores no publicades.

• Creació d’un nou sistema de fitxers: aquesta és la línia de futur més agosarada de totes ja que per si sola representa un PFC que resta pendent de realitzar dins de l’àrea d’arquitectura de computadors. Aquest treball requereix d’una extensa documentació prèvia dels diferents sistemes de fitxers actuals (Reiserfs, XFS, Ext4 etc.) per tal de recollir els punts forts de cadascun dels sistemes de fitxers estudiats. Fet això caldria realitzar un estudi per tal de detectar les necessitats dels potencials usuaris per tal d’optimitzar el nou sistema de fitxers a les seves necessitats. Aquest estudi consistiria en veure quina mida mitja tenen els fitxers, quants fitxers de mitjana conté un directori, si es produeixen molts esborrats etc. Finalment caldria implementar el nou sistema de fitxers tenint en compte que aquest hauria de ser multiplataforma i de lliure distribució.


78

11. Bibliografia Llibres STALLINGS, W (2005). Sistemas operativos: aspectos internos y principios de diseño. 5a Edició. Editorial Prentice Hall. PÀG. 577 ISBN: 84-205-4462-0 SILBERSCHATZ, A.; GALVIN P.; GAGNE, G. (2004). Sistemas operativos. 6ª Edició. Editorial Limusa. PÀG. 699-700 ISBN: 968-18-6168-X CARD, REMY – DUMAS, ERIC – MEVEL, FRANCK (1997) Programación Linux 2.0: api de sistema y funcionamiento de núcleo. 1ª EDICIÓ. EDITORIAL EYROLLES. PÀG 237 ISBN: 978-84-8088-207 Pàgines web CHRYS OCOME (07-02-2006) Chrysocome.net [en línia] Explore2fs [Consultat: 10 Novembre 2006]. Disponible a internet: http://www.chrysocome.net/explore2fs DAVE POIRIER (05-02-2002) Savannah [en línia] The Second Extended File System [Consultat: 15 Novembre 2006]. Disponible a Internet: http://www.nongnu.org/ext2-doc RÉMY CARD, THEODORE TS'O, STEPHEN TWEEDIE (Data desconeguda) Design and Implementation of the Second Extended Filesystem [Consultat: 15 Novembre 2006]. Dispobible a internet http://e2fsprogs.sourceforge.net/ext2intro.html. Extret del paper original: Proceedings of the First Dutch International Symposium on Linux, ISBN 90-367-0385-9 MARTIN HINNER (08-01-2007) Filesystems HOWTO [Consultat: 15 Novembre 2006]. Disponible a internet http://tldp.org/HOWTO/Filesystems-HOWTO.html MATT WU (21-10-2006) Ext2 File System Driver for Windows [Consultat: 22 Gener 2007]. Disponible a internet http://ext2fsd.sourceforge.net DAVID A. RUSLING (02-04-1997) The Second Extended File system (Ext2) [Consultat: 22 Gener 2007]. Disponible a Internet: http://www.science.unitn.it/~fiorella/guidelinux/tlk/node95.html. Extret del llibre: David a Rusling- The Linux Kernel JOHN NEWBIGIN (08-08-2005) Ext2 IFS for Windows NT/2K/XP [Consultat: 24 Gener 2007]. Disponible a Internet: http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm STEPHAN SCHREIDER (20-11-2006) Ext2 Installable File System For Windows [Consultat 18 Octubre 2007]. Disponible a internet: http://www.fs-driver.org MICROSOFT CORPORATION, MSDN Home Page [Consultat: Setembre-Octubre 2007] http://msdn2.microsoft.com


79

TFC’s DEL RÍO CEBRIÁN, J.M. (2007). Estudio de un sistema de ficheros windows e implementación de una aplicación docente para su aprendizaje. Projecte. Universitat La Salle Enginyeria.


80

12. Annex

12.1. Notació usada

Durant tot el treball s’usarà una mateixa notació per indicar on es troben certes dades, i quan ocupen.

• Posició Absoluta: Posició absoluta en la qual es troben les dades. • Offset: Mida en Bytes a partir de la qual es troba la dada que busquem. Es

tracten d’offsets relatius al bloc on ens trobem. • Mida: Mida en Bytes d’una determinada dada.

Per exemple, si el que estem buscant és el nombre de blocs lliures, per accedir-hi usarem la següent notació

• Posició Absoluta: 1036=0x40C • Offset: 12 (partint del Superblock) • Mida: 4

Per altra banda, quan ens referim a algun camp aquest sempre serà precedit per una lletra que ens permetrà saber a quina regió pertany aquest camp. La relació de lletres amb els camps associats és la següent:

• s: Superblock: • bg: Block Group • i: Inode Table

Per exemple el camp i_mode, es trobarà a la taula d’inodes.

12.2. Unix Time

Al llarg del treball apareixen un conjunt de dates. En una partició Ext2 aquestes estan formatades en un format denominat Unix Time.

Aquest és un format propi dels sistemes Unix-like que consisteix en codificar les dates fent ús d’un nombre.

Aquesta nombre, representa el nombre de segons que han transcorregut des de la mitjanit de Gener de 1970.

Per tal de transformar aquest nombre a una data intel·ligible es pot fer ús de funcions i tipus de dades creades per a tal efecte que es troben en la llibreria time.h de tot sistema Unix-like. Dintre d’aquesta llibreria trobarem:

• time_t: Estructura de dades que ens permetrà emmagatzemar dates

• time(): Funció que ens permetrà realitzar la conversió de data en format Unix Time a una data en el format desitjat.

Estudi sistema fitxers ext2 -...

Documents

Transcript of Estudi sistema fitxers ext2 -...