Newsgroup: it.comp.os.linux.iniziare
Titolo: buco sul filesystem

ciao a tutti, stavo leggendo la System Administration Guide (da 
tldp.org
),
e c'e' una cosa che non ho capito.
Nella fattispecie, non ho capito in che modo l'uso di "buchi" sul
filesystem possa far risparmiare spazio (per chi ha il pdf, a pagina 45).
grazie :)

 pdf, a pagina 45). grazie :)
Come se avessi detto: "La 'Divina commedia' a pagina 45"!
Certo, ma a quale edizione ti riferisci? Ne esistono
centinaia.
Quindi per lo meno cita la versione, ad esempio
"The Linux System Administrator's Guide version 0.9"
capitolo 5 paragrafo 10 sottoparagrafo 1
Per quanto riguarda la domanda, non si può capire a 
cosa ti riferisci; potrebbero essere diverse cose.
Una è il modo in cui ext2 immagazzina i dati sul 
disco, lasciando ampi spazi vuoti tra un file e 
l'altro. Ma questo non serve a risparmiare spazio 
ma a limitare la frammentazione dei file a valori 
accettabili.
Un altra cosa potrebbe essere il fatto che molti
file-system permettono i file sparsi, ovvero
ammettono l' esistenza di buchi nei file; esempio:
Apro un file, mi posiziono al milionesimo byte,
scrivo un paio di byte, chiudo il file.
Si ottiene un file con un milione di byte nulli 
e solo gli ultimi due byte sono significativi.
Un file-system come il FAT fa così: 
scrive un milione di zero sul disco, poi scrive
ancora due byte e poi chiude il file. 
Invece Unix fa così: alloca lo i-node ma non alloca 
i blocchi del file e lascia i puntatori a questi 
blocchi vuoti. Poi alloca un blocco sul disco, quello 
che contiene il byte milionesimoprimo, e lo inserisce 
nella lista degli i-node, eventualmente riempie il 
blocco con zeri, poi scrive ancora due byte ed infine
chiude il file.
La differenza è che nel primo caso ho impiegato 
un megabyte sul disco, nel secondo solo pochi 
kilobyte per un i-node e per un blocco dati;
il risparmio è evidente.

 pdf, a pagina 45). grazie :)
Come se avessi detto: "La 'Divina commedia' a pagina 45"!





che contiene il byte milionesimoprimo, lo inserisce 
nella lista degli i-node, eventualmente riempie il 
blocco con zeri, scrive ancora due byte ed infine
chiude il file.
La differenza è che nel primo caso ho impiegato 
un megabyte sul disco, nel secondo solo pochi 
kilobyte per un i-node e per un blocco dati;
il risparmio di spazio è evidente.

 pdf, a pagina 45). grazie :)
Come se avessi detto: "La 'Divina commedia' a pagina 45"!





nello i-node, eventualmente riempie il blocco con zeri, 
poi scrive ancora due byte ed infine chiude il file.
La differenza è che nel primo caso ho impiegato 
un megabyte sul disco, nel secondo solo pochi 
kilobyte per un i-node e per un blocco dati;
il risparmio è evidente.

 ancora due byte e poi chiude il file. 
Beh, non proprio. :-)
Fat prende i cluster che servono ad occupare il milione di bytes, e
li marca come occupati, e poi scrive i due byte nell'ultimo cluster.
Ma NON pulisce lo spazio intermedio.
E' un trucco che si usa ancora oggi per cercare roba su disco su
sistemi che non hanno certi strumenti:
Crei un file vuoto, fai una seek alla fine dello spazio disponibile,
scrivi un byte, e chiudi.
A quel punto hai un file che contiene tutta la spazzatura che c'era
nei cluster non utilizzati, da esaminare con comodo.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 ...
Ti ringrazio per la correzione.
In effetti nella fretta ho descritto ciò
che *dovrebbe* accadere e non ciò che 
*accade* *realmente*.
Ma ora mi viene un dubbio:
Ho sperimentato i file sparsi usando i
comandi GNU, ma scrivendo un programma in 
C che usa le librerie standard si ottiene 
lo stesso risultato od un file pieno di 
spazzatura?
post scriptum: ho il sospetto che il 
comportamento da me descritto non derivi
tanto dal file system ma dai programmi
e dai comandi usati per creare i file sparsi
e quindi usando i da una shell i classici
comandi Unix (cat, touch, dd) su un file system
ext2 o FAT si dovrebbero ottenere gli stessi 
risultati (a parte il particolare che FAT
non supporta i file sparsi.)
Una ultima cosa FAT non supporta i file sparsi
e IBMDOS/MSDOS/Windows non hanno i comandi per 
gestire i file sparsi.

 spazzatura?
L'avanzamento di una seek con creazione dello spazio allocato,
e' demandata allo strato del file system, percio' dovresti avere
comunque un file sparso.
http://linuxgazette.net/issue24/rogers.html


 
http://linuxgazette.net/issue24/rogers.html
In effetti il dubbio riguardava il modo 
in cui GNU/Linux gestisce i filesystem 
FAT: facendo un seek su un file vuoto
su un filesystem FAT si ottiene un file 
contenente zeri secondo le specifiche
oppure un file pieno di spazzatura 
come con MSDOS?
PS In tal caso non si potrebbe mai otterre
   un file sparso.

    un file sparso.
Non lo supporta il file system.


 comunque un file sparso.
Non solo, alcuni programmi (leggi P2P) che usano creare files molto 
grandi e poi scriverli un pezzo per volta in posizioni pseudocasuali 
emulano il comportamento degli sparse files anche su vFAT.
-- 
Lorenzo `paulatz' Paulatto
Trieste
``Se Gauss fosse vivo oggi, sarebbe un hacker.''
      --Peter Sarnak (Princeton University)

 
Ma, se non sbaglio, lo spazio lo allocano tutto da subito.
No, non uso p2p e pertanto non lo so.
