Stavo leggendo qualcosa di simile a questo ieri riguardo a OSX e alla sua compressione del filesystem - Fondamentalmente la risposta ruota attorno a ciò che vuoi comprimere - in questo esempio sta parlando dei dati "FAT"; strutture di file, proprietà, metadati ecc. che, se archiviati insieme, possono essere compressi per risparmiare spazio ed essere letti nella cpu più velocemente che cercare la testa dappertutto per trovare i dati per ogni file ...
Ma la compressione non riguarda solo il risparmio di spazio su disco. È anche un classico esempio di scambio di cicli della CPU per una minore latenza I / O e larghezza di banda. Negli ultimi decenni, le prestazioni della CPU sono migliorate (e le risorse di elaborazione sono più abbondanti, ne parleremo più avanti) a un ritmo molto più veloce rispetto alle prestazioni del disco. I tempi di ricerca moderni del disco rigido e i ritardi di rotazione sono ancora misurati in millisecondi. In un millisecondo, una CPU da 2 GHz passa attraverso due milioni di cicli. E poi, ovviamente, c'è ancora da considerare il tempo effettivo di trasferimento dei dati.
Certo, diversi livelli di memorizzazione nella cache in tutto il sistema operativo e l'hardware lavorano potentemente per nascondere questi ritardi. Ma quei bit devono uscire dal disco a un certo punto per riempire quelle cache. La compressione significa che devono essere trasferiti meno bit. Data la sovrabbondanza quasi comica delle risorse della CPU su un moderno Mac multi-core in normali condizioni di utilizzo, il tempo totale necessario per trasferire un carico utile compresso dal disco e utilizzare la CPU per decomprimerne il contenuto in memoria sarà di solito molto inferiore al tempo ci vorrebbe per trasferire i dati in forma non compressa.
Ciò spiega i potenziali vantaggi in termini di prestazioni del trasferimento di meno dati, ma l'uso di attributi estesi per archiviare il contenuto dei file può effettivamente rendere le cose più veloci. Tutto ha a che fare con la localizzazione dei dati.
Se c'è una cosa che rallenta un disco rigido più che trasferire una grande quantità di dati, sta spostando le sue teste da una parte del disco a un'altra. Ogni mossa significa che la testa inizia a muoversi, quindi si ferma, quindi si assicura che sia posizionata correttamente sulla posizione desiderata, quindi aspetta che il disco rotante inserisca i bit desiderati al di sotto di essa. Queste sono tutte parti reali, fisiche, in movimento, ed è sorprendente che facciano la danza nel modo più rapido ed efficiente possibile, ma la fisica ha i suoi limiti. Questi movimenti sono i veri assassini delle prestazioni per l'archiviazione rotazionale come i dischi rigidi.
Il formato volume HFS + memorizza tutte le sue informazioni sui file — metadati — in due posizioni principali sul disco: il File catalogo, che memorizza le date dei file, le autorizzazioni, la proprietà e una serie di altre cose, e il File degli attributi, che memorizza "forchette denominate ".
Gli attributi estesi in HFS + sono implementati come fork denominati nel file degli attributi. A differenza delle fork di risorse, che possono essere molto grandi (fino alla dimensione massima del file supportata dal file system), gli attributi estesi in HFS + sono memorizzati "inline" nel file degli attributi. In pratica, ciò significa un limite di circa 128 byte per attributo. Ma significa anche che la testa del disco non ha bisogno di fare un viaggio in un'altra parte del disco per ottenere i dati effettivi.
Come puoi immaginare, i blocchi su disco che compongono i file Catalog e Attributes sono frequentemente accessibili, e quindi è più probabile che la maggior parte si trovi in una cache da qualche parte. Tutto ciò cospira per rendere l'archiviazione completa di un file, inclusi i suoi metadati nei suoi dati, all'interno del catalogo strutturato in B-tree e dei file di attributi una vittoria complessiva delle prestazioni. Anche un payload di otto byte che si sovrappone a 25 byte non è un problema, purché sia ancora inferiore alla dimensione del blocco di allocazione per la normale memorizzazione dei dati e purché si adatti a un nodo B-tree nel File degli attributi che il sistema operativo deve comunque leggere nella sua interezza.
Ci sono altri contributi significativi all'ingombro ridotto del disco di Snow Leopard (ad esempio, la rimozione di localizzazioni non necessarie e file "designable.nib") ma la compressione HFS + è di gran lunga la più interessante dal punto di vista tecnico.
