[Tech] Re: File System Ext2 (+pippo story)

[Gianni Casalini]

On Thursday 14 March 2002 06:29, you wrote:

> Date: Thu, 14 Mar 2002 00:04:28 +0100
> From: Gabriele Grilli <grilligab@tiscalinet.it>

Ciao Gabriele, mi ha fatto piacere leggere la tua risposta e trovo 
ottima l'idea di farne una dispensa.  
Ti scrivo alcuni appunti, molto poco tecnici, li metto qui in lista, 
ma se sono un problema te li mando in privato... dipende un po' dagli 
umori di tech :) Ho avuto poco tempo e non ti ho potuto rispondere 
prima.

PRE-prologo
Quando si scrive bisogna sapere per chi si scrive. Mescolare tipi di 
lettori porta a non scrivere niente di utile per nessuno.
A mio moooodestissimo avviso il problema delle dispense linux (non 
tutte intendiamoci) che si trovano in giro e' questo: nella prima 
parte dicono cose "banali" o estremamente intuitive, ad un certo 
punto c'e' uno stacco e, anche all'interno dello stesso discorso, 
introducono dei concetti (tramite dei termini) di cui si ignora tutto 
e di cui non e' stato precedentemente data nessuna definizione.
"Tanto c'e' sempre un link che lo spiega" non mi sembra un bel modo 
di scrivere. Questo e un punto di vista di un lettore a proposito 
dell'argomento dispense.


> PROLOGO
> Un File System (FS) serve per memorizzare delle informazioni su un
> supporto e,
> per fare cio' utilizza delle strutture dati che memorizza nel
> supporto stesso, diviso in blocchi.

"Serve", cosa e' uno strumento? Una serie di regole... cioe' un 
protocollo? Un pezzo di hardware? Anche il meccanismo che modifica 
fisicamente il supporto magnetico serve a questo, ma non credo che 
sia un FS...
"Utilizza delle strutture dati"....?

> (Su questo ci sono delle dispense del corso reperibili dal sito).

<SCHERZOSO MODE> 
  Ma avevi intenzione di scriverne una nuova?
</SCHERZOSO MODE>

> FILE SYSTEM EXT2
> Quanto indicato di seguito si riferisce al FS EXT2 e quindi non
> varra' per gli altri
> che utilizzano altre strutture +/- efficienti e generiche.
> INODE e Entita' File
> Un INode e' la struttura, del FS EXT2, dedita a memorizzare le
> informazioni
> di ciascuna "entita' file" (EF).

... te usi la parola "struttura" (secondo me inflazionata) , per 
struttura si intende: il modo in cui le singole parti di un qualcosa 
sono disposte e ordinate tra loro per costruire un qualche sistema...
Meglio per me sarebbe dire che struttura e' l'insieme delle relazioni 
tra singole parti che costituiscono un sistema, cioe' le relazioni 
che portano ad un ordine di complessita' maggiore. Magari ci sono 
altre definizioni migliori.
Dire che "un INode e' la struttura..." di sicuro e' corretto, ma se 
uno viene da win. scappa mentalmente al calduccio delle sue icone. 
Poi da quello che scrivi (se applico il significato alla parola 
"struttura") otterrei: 

"Un INode e' un insieme di relazioni [tra quali termini?], del FS 
EXT2, 'dedita' [una struttura dedita?] a memorizzare le informazioni 
di ciascuna "entita' file" (EF) -che giustamente definisci dopo-

Prova a sostituire la definizione di FS che hai dato prima a 'FS' 
all'interno del discorso...

> Una "entita' file" e' un file (comunemente detto), una directory,
> uno special file oppure
> un link, simbolico o fisico. Ho scelto questo termine perche' con
> file si intende, troppo spesso,
> quegli oggetti che contengono dei dati, escludendo le directory.

Un'informazione e' la notizia di una differenza. 
L'unita' fondamentale dell'informazione e' il bit.
L'insieme dei bit costituisce l'unita' informazionale o file...e 
cosi' via.
...Gregory Bateson, mi sembra in: 'Mente e Natura'... non ce l'ho 
sotto mano.
Nell'informazione tutto e' un file. Unix e' rigoroso rispetto alle 
teorie, gli altri creano metafore piu' o meno fruibili dal pubblico 
(o mi sbaglio?).

> In base a quanto detto, l'INode contiene tutte le info relative a
> ciascuna EF :
> tipo di EF
> data di creazione/Modifica,
> dimensione,
> permessi
> indirizzi dei blocchi contenenti le informazioni dell'EF
> e altre informazioni.

Mi piacerebbe capire le seguenti questioni:

1. Le cose che definisci sono in qualche luogo fisico o sono 
strutture logiche? Se sono strutture logiche rimandano a qualche 
luogo fisico? (prima o poi di sicuro).
2. DOVE si trovano le cose che definisci.
La nostra realta' e' definita in termini di spazio e tempo. Se dico 
"in Italia piove" o faccio poesia o dico cose poco significative... 
per un calcolatore, invece, mi accontento di sapere "dove" si trovano 
le informazioni e che relazioni possono creare con altre 
informazioni. Il tempo che ci mettono, ad essere processate, come 
utente dico, non e' che mi interessi molto.

In base a quanto detto io ho capito che l'INode e'un "record" di un 
database che mi rimanda al file vero e proprio (o EF).
La sua carta di identita', il suo indirizzo ect.
Per quello che hai detto per me l'INode e' un "file" che manda ad un 
altro file. 
Dal penultimo punto intuisco che l'EF si trova fisicamente da qualche 
parte e che il sistema (o il FS? O qualche applicazione del FS?) non 
saprebbe dove pescarla se non si leggesse un bell'INode... ma forse 
sbaglio, correggimi

> L'INode e EF sono collegati mediante relazioni,
> volendo fare un paragone con i database: le EF stanno in relazione
> 1-1 con gli INode,
> viceversa gli INode stanno in relazione 1-N con le EF questo per
> dire che a nomi diversi di
> file, per esempio puo' corrispondere lo stesso INode e quindi gli
> stessi dati.

Quanti sono gli inode? Da quello che dici capisco che ci sono molti 
file e pochi INode... pero' questo contrasta con la relazione 1-1... 
Non ha senso parlare dell'INode del file pippo.txt?
Forse gli INode possono essere visualizzati come il centro di una 
raggiera e all'estremita' dei raggi ci sono i file? Il raggio sarebbe 
la relazione e se lo guardo dal punto di vista dei file e' 1-1 se lo 
guardo dal punto di vista dell'INode e' 1-N.
Allora se "perdo" (non so se si possono perdere o cancellare o 
distruggere perche' ancora non ho capito di cosa sono fatti) un INode 
non trovo piu' la strada per N file?
Quello che c'e' di confuso, per me, e' che definisci un comportamento 
senza definire il soggetto. Magari in informatica e' perfettamente 
lecito, pero' non e' intuitivo per niente. Metti in conto che sono 
anche duro, ma sai i "principianti" lo sono, in qualche modo.

> A questo punto si puo' fare una panoramica di alcune strutture dati
> che servono a EXT2:
> 1) bitmap degli INode: indica quali sono liberi e quali occupati.

INode liberi e occupati? File liberi o occupati?

> Questo implica che abbiamo una limitazione nel FS data dal numero
> massimo di INode

Questo cosa? Il fatto che indichi quali sono liberi e quali occupati, 
implica questa limitazione?

> 2) Tabella degli INode : contiene le informazioni relative a
> ciascuna EF, in base alla
> bitmap degli INode possiamo sapere quali sono usati e quali no.

File?
Cosa intendi per "in base alla bitmap degli INode?

> 3) spazio dati : spazio riservato alla memorizzazione di dati.

Quali dati?

> 4) Un SuperBlock che e' una tabella a sua volta contenente, fra i
> vari campi,
> l'INode della directory "/"

Il SuperBlock non ho mai capito che fosse, mi sembrerebbe strano 
cominciare ora.

Hai citato 4 strutture. Un INode e' formato di queste? Gli INode le 
formano? Insomma che c'incastrano con gli INode. Mi sfugge la 
gerarchia.

> Quello che vorrei sottolineare e' che ogni INode ha gli indirizzi
> dei blocchi contenenti le informazioni
> dell'EF 

HA gli indirizzi dei blocchi contenenti le informazioni o E' 
costituito dagli indirizzi dei blocchi contenenti le informazioni?

>e percio' l'INode puo' accedere a tali informazioni che,
> possono essere viste come sequenza di byte.

come tutte le informazioni

> Tali informazioni quindi possono venire processate in un modo
> oppure in un altro a seconda del tipo di EF
> a cui l'INode si riferisce.
> Un file di testo, usera' tali informazioni come sequenza di
> caratteri, spetta all'utilizzatore usare la giusta

Scusa, ma secondo me un file di testo non usa tali informazioni, e' 
tali informazioni. Senno' non ho capito per niente cosa si intende 
per file.

> applicazione per aprirlo, infatti usando un editor di immagini non
> si otterrebbe la semantica corretta
> cioe' il giusto significato dei dati.
:)
> Una directory usera' tali informazioni, una di seguito all'altra,
> secondo lo specifico formato indicato di seguito:

Una directory e' un file, no? Non capisco il verbo "usare" qua 
dentro... l'utente (o utilizzatore) interroga, processa, "apre" tali 
informazioni. Una directory contiene, e'... Correggimi. 

> <INode relativo a EF1><Lunghezza del Nome EF1 + 1><Nome EF1>
> <INode relativo a EF2><Lunghezza del Nome EF2 + 1><Nome EF2>
> <INode relativo a EF3><Lunghezza del Nome EF3 + 1><Nome EF3>

> Di solito le prime due voci si riferiscono alle directory "." e
> ".." quindi non sono altro che dei collegamenti a se stessi e al
> padre. Se noi analizzassimo tali informazioni con un editor di
> immagini otterremmo lo stesso risultato errato come nel
> caso precedente.

Una curiosita', <Nome EF1>; <Nome EF2> sono cio' che appare sullo 
schermo: "."; ".."? E, magari, <Nome EF3> e' proprio: pippo.txt?

> In entrambi i casi modificare tali informazioni porta ad avere dei
> dati incomprensibili e, soprattutto nel secondo caso
> ad un danneggiamento dei file dentro la directory.

Nei casi delle prime due voci?

[...]

> Quello che pensavo era di scrivere questi appunti per fare delle
> dispense per il sito, relative al corso " Struttura di un
> sistema Linux: il file system" dato che ancora manca.
Hai tutto il mio incoraggiamento.
ciao

Gianni C.

PS una proposta: risulterebbe molto didattico il seguire la "vita" di 
un file (tipo pippo.txt), dalla creazione alla sua posizione a... 
tutto quello che puo' succedere a quel file. In fondo la storia di 
pippo.txt e' la storia di ogni file :)