Implementazione FS Struttura tipica FS

Implementazione FS
1. Rappresentazione e memorizzazione di file e directory;
in particolare mapping nome file → lista di blocchi
2. gestione spazio su disco; p.es.:
• |blocco|
• rappresentazione spazio libero/occupato
• quote
3. efficienza
4. affidabilità
Struttura tipica FS
• Superblocco: informa su tipo di FS, num blocchi partizione ...
• I-nodes o altre forme di indice (FAT)
File system: implementazione - 27/02/2006
1/26
Allocazione contigua
• + semplice (corrispondenza: file ↔ blocco iniziale +
dimensione)
• + veloce: syscall R/W richiede 1 R/W HW del controller
• + seek blocco random N richiede 0 accessi al disco
(indirizzo blocco = base+N)
• - richiede conoscenza dim max file all’atto della creazione
• - frammentazione (da creazione/cancellazione)
Oggi è tornata ad aver senso per i FS dei CD.
File system: implementazione - 27/02/2006
2/26
Linked list
•
•
•
•
•
+
+
2)
in dir entry basta memorizzare il blocco iniziale
anche se lo spazio libero è frammentato, lo si può utilizzare
R/W sequenziale causa vari R/W HW del controller
seek random a blocco N costa, in accessi a disco, O(N)
per via dei puntatori, |blocco file|≠ |blocco disco| (potenza di
Rimedio: indice (p.es. dopo il superblocco)
File system: implementazione - 27/02/2006
3/26
Linked list e indice (FAT)
Elimina due dei difetti della linked list pura. Adesso:
• seek random a blocco N costa, in accessi a indice (RAM), O(N)
• |blocco file| = |blocco disco| (potenza di 2)
Problema residuo: l'indice occupa molta RAM; p.es.:
• partizione 16GB, blocco 1K → 16M blocchi
• indice di 16M=224 entry → entry 3 byte (o 4 per allineamento)
• |indice| = 16M x 3 = 48M (64M)
File system: implementazione - 27/02/2006
4/26
Linked list e indice: FAT16 (MS-DOS)
Compromesso, per ridurre dimensione indice (o FAT):
• indice di max 64K → entry di 2B → max |indice|=128K
• partizione max 2GB
• → per partizione di 2GB, blocchi (cluster) grandi;,
|blocco| = |partizione|/(n.entry in indice) = 231/216 = 215 = 32K
Problemi FAT16:
• blocchi grandi → frammentazione interna
• per DOS (640K RAM controllata) non occupa comunque troppo
spazio?
Soluzione: tenere in RAM solo indici per blocchi di file aperti,
anziché un unico indice per tutti i blocchi;
→ a questo punto, conviene separare indici anche su disco
File system: implementazione - 27/02/2006
5/26
Allocazione con i-node
Ogni file ha un index-node che ne dà attributi e indirizzi dei blocchi:
I-node in locazioni fisse su disco, caricati in RAM per file aperti.
Layout tipico. Disco: 32 bit address, 1K block. I-node:
• attributi
• 10 direct pointers: file < 10K
• puntatore a indirect block, porta a 1K/4=256=28 blocchi:
file < 256K+10K
• puntatore a double indirect block, porta a 216=64K blocchi:
file < 64M+266K
• puntatore a triple indirect block, porta a 224=16M blocchi:
file < 16G+64M+266K
Vantaggio: un accesso al file costa max 3 accessi al disco e
i file piccoli sono meno penalizzati.
File system: implementazione - 27/02/2006
6/26
Ext2FS / ReiserFS
Ext2FS: http://web.mit.edu/tytso/www/linux/ext2intro.html
Reiser V3: http://linux.co.uk/ldp/LDP/LG/issue55/florido.html
Reiser V4: http://www.namesys.com/v4/v4.html
Confronti tra FS:
http://en.wikipedia.org/wiki/Comparison_of_file_systems
File system: implementazione - 27/02/2006
7/26
Implementazione directory
• Directory: tabella multilivello, con una dir entry per file.
• Dir entry = puntatore/i-node a blocchi del file + (a volte) attributi
• nomi di file di lunghezza variabile (NB: allineati su word)
• per migliorare prestazioni di ricerca su directory:
• hashing, oppure
• caching delle ricerche già effettuate
File system: implementazione - 27/02/2006
8/26
Esempi di implementazione delle directory
•
•
•
•
CP/M
dim file in blocchi, non byte
per OS file=insieme blocchi
per i programmi fine file=^Z
file di n blocchi occupa n/16
dir entries, numerate da Extent
DOS
Unix
Apertura file: pathname→dir entry→indirizzi blocchi file.
Esempio: lookup di /usr / as t /mbox in Unix:
• i-node di root dir ha n. fisso
• dir entry . e . . per lookup pathname relativi, es.
. . / a s t /mbox
File system: implementazione - 27/02/2006
9/26
Link
Rendono un DAG il directory tree (condivisione o evitare ridondanza)
Un (hard) link al file /.../g è una dir entry di nome g (= o ≠ f),
che punta a:
• stesso i-node di /.../f (hard link)
• → originale f e link g sono indistinguibili
Il pathname /.../g si dice talvolta alias di /.../f
dir di B
dir di C
f
g
Owner=C
n.links=2
i-node
Problema link: inganna discese ricorsive (p. es. backup/restore)
Problemi hard link:
• CP/M: impossibile → dir entry ha indirizzi di più blocchi del file
(p.es. come registrare sui link nuovi blocchi dopo append?)
• DOS: append funziona (opera su FAT), ma non
delete ( filename) : blocchi resi liberi in FAT, ma la dir entry / link punta ancora al 1°
• cancellazione problematica; p.es. cosa accade se C vuole cancellare il file g?
• l’i-node non si può eliminare se non insieme con l’hard link di B (altrimenti
questo resterebbe dangling (“pendente”))
• ma l’hard link non si può eliminare: FS non può dall’i-node risalire a ogni hard
link (hard link = dir entry, quindi non indirizzabile facilmente)
• soluzione non ideale: i-node e hard link di B restano, C risulta owner e paga!
File system: implementazione - 27/02/2006
10/26
Symbolic link
Un symlink al file /.../f è una dir entry di nome g (= o ≠ f), che punta
a:
• i-node di un nuovo file contenente il pathname /.../f (symbolic link)
Il pathname /.../g si dice talvolta alias di /.../f
dir /bin
dir /user/bin
file /user/bin/g
/bin/f
f
g
link simbolico
Owner=user
Owner=root
n.links=1
i-node
i-node (di tipo LINK)
Vantaggi:
• cancellazione i-node ok (symbolic link resta invalido)
• network pathname via symbolic link
Problemi symbolic link:
• overhead da doppio lookup di pathname
• extra i-node e blocco per file contenente pathname
(ottimizzazione: pathname in i-node)
• rende difficile discese ricorsive accurate
File system: implementazione - 27/02/2006
11/26
Gestione spazio su disco
Scelta di fondo (simile a segmentation/paging)
1. allocazione in settori contigui
2. suddivisione in blocchi non contigui
Problemi/tradeoff:
1. allocazione contigua:
• frammentazione interna
• frammentazione esterna (dello spazio libero)
• difficoltà incremento dimensione
• cf. segmentazione e gestione memoria centrale, ma
qui compattare è assai più oneroso che in RAM
2. allocazione in blocchi non contigui;
• frammentazione interna
• frammentazione da scattering (sparpagliamento dei blocchi
di un file) → peggiora seek/latency time
File system: implementazione - 27/02/2006
12/26
Dimensione dei blocchi
|Blocco|? Scelte ovvie: cilindro, traccia, n× settore, frame (se paging)
Tradeoff su dimensione blocco:
• piccolo → frammentazione esterna e da scattering
• grande → frammentazione interna
Valori tipici: blocco=0.5K, 1K, 2K, 4K; settore=0.5K
Analisi data rate medio per |block|=B
• a occhio conviene B grande per diminuire impatto seek + latency:
• T(B) = SeekTime + Period/2 + Period × (B / |track|) =
SeekTime + Period/2 × (1+2B/|track|)
• Data Rate=B/T(B); è quasi lineare se 2B≪|track|
NB: nel grafico B è riportato sulle ascisse in scala logaritmica
• curva a tratti = tasso utilizzo legato a frammentazione interna:
• si suppone ogni file di 2K (tipica dimensione mediana)
• utilizzo =
100%
per B=...0.25K, 0.5K, 1K, 2K
2K/B
per B=4K, 8K, ...
• B ottimale ≃4K (come in NT, in Unix è 1K per motivi storici)
File system: implementazione - 27/02/2006
13/26
Gestione blocchi liberi
• Linked free list di blocchi contenenti i numeri dei blocchi liberi
• 1 blocco free list contiene num. liberi: (|blocco|/|n.blocco|) -1
• P.es. Partizione 16GB, blocco 1K, n. blocco a 32 bit:
• 1 blocco di free list memorizza 255 blocchi liberi
• nel caso peggiore (tutta la partizione libera) free list contiene
16M blocchi e occupa 16M/255 ≈ 64K blocchi
• Bitmap: 1 bit per blocco.
• Esempio precedente (partizione 16GB, blocco di 1K):
la bitmap occupa 16Mbit = 16M/8 Byte = 2MB = 2K blocchi
File system: implementazione - 27/02/2006
14/26
Confronto bitmap/free list
• Con il disco quasi vuoto, la free list occupa molto più spazio,
ma ciò non è necessariamente un problema:
• una free list grande (causata da disco quasi vuoto) può
essere memorizzata proprio nei molti blocchi liberi
• tenere tutta la free list in memoria sarebbe oneroso, ma
in effetti basta tenerne un blocco
• Se si cerca di tenere un solo blocco di free list in memoria, va
evitato che questo sia troppo vicino a riempirsi:
• se un file di 3 blocchi viene spesso cancellato e creato (su
/tmp):
•
•
•
•
si rischia di oscillare da (a) in (b) e ritorno;
conviene invece mantenere la situazione (c):
un blocco di lista libera in memoria pieno per metà
in corrispondenza, un blocco di lista libera sul disco, pieno
per metà
• Anche con la bitmap si può:
• tenere un solo blocco della bitmap in memoria e
• il resto sul disco
File system: implementazione - 27/02/2006
15/26
Quote
• Hard limit non si può superare
• Soft limit exceeded: warning al login, decremento warning count
• warning count = 0: no login
Implementazione:
• tabella delle quote in memoria
• ogni creat viene controllato
• ogni append su file aperto viene controllato
Open file table
Attributes
Disk Addresses
User = 108
Quota pointer
Quota table
Soft block limit
Hard block limit
Current n. of blocks
n. Block warnings left
Soft file limit
Quota record
for user 108
Hard file limit
Current n. of files
n. File warnings left
File system: implementazione - 27/02/2006
16/26
Affidabilità FS
Gestione bad blocks:
• hw: controller rimappa ogni bad block su spare block
(tabella memorizzata in apposito settore)
• sw: FS o utility (DOS) marcano bad block o
costruiscono bad file (cui non si accede mai)
Backup:
• incrementale: file cambiati da ultimo backup full o incrementale;
• cambiamento riconoscibile da archive bit (DOS) o dal confronto
tra modified time e backup time (memorizzato a parte)
Concetti relativi all'affidabilità:
• mirroring on line
• hot swap
• MTBF (Mean Time Between Failures) non scala linearmente
con il costo del disco
• ridondanza
⇒ RAID
• ridondanza e majority voting
File system: implementazione - 27/02/2006
17/26
RAID
DOC SuSe
Like a RAID controller,which canoftenbequiteexpensive,soft RAID is alsoableto takeon thesetasks.SUSE Linux offers
theoptionof combiningseveralharddisksinto onesoft RAID systemwith thehelp of YaST—a veryreasonablealternativeto
hardwareRAID. RAID impliesseveralstrategiesfor combiningseveralharddisksin a RAID system,eachof themhaving
differentgoals,advantagesandcharacteristics.Thesevariationsarecommonlyknownas RAID levels.
CommonRAID levelsare:
RAID 0
This level improvestheperformanceof your dataaccessby spreadingoutblocksof eachfile acrossmultipledisk drives.
Actually, this is not really a RAID, becauseit doesnotprovidedatabackup,butthenameRAID 0 for this typeof systemhas
becomethenorm.With RAID 0, two or moreharddisksarepooledtogether.The performanceis verygood,buttheRAID
systemis destroyedandyour datalost if evenoneharddisk fails.
RAID 1
This level providesadequatesecurityfor yourdata,becausethedatais copiedto anotherharddisk 1:1. This is knownas hard
diskmirroring. If a disk is destroyed,a copyof its contentsis availableon anotherone.All of themexceptonecouldbe
damagedwithoutendangeringyour data.The writingperformancesuffersa little in thecopyingprocesscomparedto when
usingsingledisk access(tento twentypercentslower),butreadaccessis significantlyfasterin comparisonto anyoneof the
normalphysical harddisks,becausethedatais duplicatedso canbe parallel scanned.Generally it canbe said thatLevel 1
providesnearlytwicethereadtransactionrateof singledisksandalmostthesamewritetransactionrateas singledisks.
RAID 2 andRAID 3
Thesearenottypical RAID implementations.Level 2 stripesdataat thebit level ratherthantheblock level. Level 3 provides
byte-level stripingwith a dedicatedparitydisk andcannotservicesimultaneousmultiplerequests.Both levelsareonly rarely
used.
RAID 4
Level 4 providesblock-level stripingjust like Level 0 combinedwith a dedicatedparitydisk. In thecaseof a datadisk failure,
theparitydatais usedto createa replacementdisk. However,theparitydisk maycreatea bottleneckfor writeaccess.
Nevertheless,Level 4 is sometimesused.
RAID 5
RAID 5 is an optimizedcompromisebetweenLevel 0 andLevel 1 in termsof performanceandredundancy.The harddisk
spaceequalsthenumberof disksusedminusone.The datais distributedovertheharddisksas with RAID 0. Parity blocks,
createdon oneof thepartitions,aretherefor securityreasons.Theyarelinkedto eachotherwith XOR, enablingthecontents,
via XOR, to bereconstructedby thecorrespondingparityblock in caseof systemfailure.With RAID 5, no morethanonehard
disk canfail at thesametime.If oneharddisk fails, it mustbereplacedas soonas possibleto avoid therisk of losingdata.
OtherRAID Levels
SeveralotherRAID levelshavebeendeveloped(RAIDn, RAID 10, RAID 0+1,RAID 30, RAID 50, etc.), someof thembeing
proprietaryimplementationscreatedby hardwarevendors.
File system: implementazione - 27/02/2006
18/26
RAID (Tanenbaum)
Backup and parity drives are shaded
File system: implementazione - 27/02/2006
19/26
File system consistency
Integrità: compromessa se avviene crash prima che
blocco modificato in RAM sia copiato su disco.
Consistency: compromessa se il blocco contiene struttura dati FS:
• i-node
• directory entry
• parte di free list
FS check (consistency) a boot time: blocchi, dir entries, euristica.
Blocchi. FS check (e2fsck ) determina, per ogni blocco:
1.
n. usi = n. presenze in qualche file (segue puntatori da ∀ inode)
2.
n. presenze in free list (o bitmap con 0)
File system: implementazione - 27/02/2006
20/26
FS check sui blocchi: esempio
• b. blocco (p.es. 2) non usato né in free list (mancante):
mettilo in free list
• c. blocco (p.es. 4) duplicato in free list (impossibile con
bitmap): ricostituisci free list
• d. blocco (p.es. 5) in 2 file: copialo su blocco, inseriscilo in
uno dei file; informa utente
• e. (non in fig.) blocco in file e in free list: eliminalo da free
list
Osservazioni:
• (b) è solo inefficiente, ma (d) implica perdita dati
• è opportuno riparare (c),(e) perché può accadere (e)→(d), o
(c)→(e)
• altra transizione possibile: (d)→(e)
File system: implementazione - 27/02/2006
21/26
FS consistency: file check
Visita directory tree e per ogni i-node conta r =numero riferimenti:
• r =l (link count registrato in i-node) → ok
• r<l non pericoloso, ma spreca spazio:
rm r entries rende link count=l-r>0 → i-node resta in uso
• correzione: link count:= r;
• r>l pericoloso, causa perdita dati:
rm l entries, fa link count=0 → FS libera i-node e blocchi puntati
•
correzione: link count:= r;
FS integrity: altre misure
Euristiche segnalano situazioni errate o strane:
• controllo formato dir entry, p.es. i-node n. > n. i-node su disco
• controllo n. entry in dir (p.es. > 100000)
• controllo diritti, p.es. other>user
• controllo file in user dir, con owner=root e SETUID=1 (security)
Alcuni sistemi consentono undelete:
• DOS
• Unix con Wastebasket
File system: implementazione - 27/02/2006
22/26
Performance: caching
Accesso a memoria ≈ 10ns, accesso a blocco ≈ 10ms.
Block/buffer cache: blocchi di disco memorizzati in RAM.
Tipico algoritmo:
• se è richiesto un blocco lo si cerca in cache (ricerca hash)
• se il blocco non è in cache, ve lo si copia
• se la cache era piena, si fa posto scegliendo una vittima
• se cache è usata anche per Write, le vittime dirty vanno salvate
La vittima si può scegliere con Page Replacement Algorithm:
• p.es. LRU; è possibile l'implementazione con LRU list:
accessi a cache più rari che a frame VM
• la lista LRU è integrata con una tabella hash
File system: implementazione - 27/02/2006
23/26
Buffer cache: accorgimenti
Il rimpiazzamento LRU puro è inadeguato, in quanto prescinde da:
• se il blocco sarà presto necessario o viceversa; p.es.:
1. blocco parzialmente pieno in corso di scrittura o viceversa
• → dovrebbe servire presto e va forzato su MRU
2. blocco pieno, double/triple indirect block, blocco i-node;
• → non dovrebbero servire e vanno forzati su LRU
Per la consistency del FS è importante che i blocchi dirty in cache
vengano salvati presto su disco:
• i blocchi dirty non contenenti dati vanno scritti immediatamente,
prescindendo da quando li scaccerà /salverà LRU
Ma anche i cache block non critici, se modificati, vanno salvati spesso:
• sync invocata da processo update ogni 30 s
• write-back o write-through cache (nessun caching, MS-DOS)
•
NB: ovviamente l’applicazione DOS non scrive un byte alla volta, ma usa un
buffer più grande.
File system: implementazione - 27/02/2006
24/26
Performance / 2
Read-ahead dei blocchi di un file:
• presuppone accesso prevalentemente sequenziale
• quest'informazione si può rispecchiare con un bit:
• azzerato da seek()
• impostato da accessi sequenziali
Allocare nuovi blocchi di un file consecutivamente:
• facile con bitmap (specie se in RAM),
• difficile con free list (specie se in parte su disco)
Soluzione per allocazione con free list:
• allocare non un blocco, ma una zona di n blocchi;
• ciò consente di diminuire:
• i movimenti del braccio, quindi
• i tempi di trasferimento
• la cache e quindi i trasferimenti da/a disco restano organizzati
in blocchi
Nozione estesa di “contiguità”:
• si cerca di allocare i blocchi consecutivi di un file
• finché è possibile nella stessa traccia,
• quindi nello stesso cilindro
File system: implementazione - 27/02/2006
25/26
Performance / 3
Altro problema:
• i-node all’inizio del disco, settori lontani
• → apertura+accesso a un blocco causa un ampio seek.
Soluzioni:
• i-node nei cilindri centrali
• i-node suddivisi tra cilindri:
• i blocchi per un file sono scelti (se possibile)
• dai cilindri del suo i-node.
File system: implementazione - 27/02/2006
26/26