Linus Torvalds e il filesystem OS X

A trascrizione di la sessione "Q & A" in cui Linus ha fatto il commento è disponibile, ma sembra che non gli sia stato chiesto di elaborare. Non sono sicuro se un'analisi più approfondita della sua opinione su HFS + sia stata trascritta da qualche altra parte.

Per l'analisi di qualcun altro della questione, puoi dare un'occhiata alle recensioni su Mac OS X di John Siracusa. In particolare quello per Mac OS X Lion che ha una sezione intitolata " Cosa c'è di sbagliato in HFS + ." Penso che il pezzo più saliente sia (enfasi mia):

Concurrency, metadata written in the correct byte order, sub-second date precision, support for massive volume sizes, and sparse file support are all common features of Unix file systems. Mac OS X, of course, is built on a Unix foundation. When HFS+ was ported from classic Mac OS to Mac OS X, it needed to be extended to support some minimum set of features that are expected from Unix file systems.

Some of those features were an easy fit, but others were very difficult to add to the file system without breaking backwards compatibility. One particularly scary example is the implementation of hard links on HFS+. To keep track of hard links, HFS+ creates a separate file for each hard link inside a hidden directory at the root level of the volume. Hidden directories are kind of creepy to begin with, but the real scare comes when you remember that Time Machine is implemented using hard links to avoid unnecessary data duplication.

Il punto importante qui è che Mac OS X sta usando un file system che non è stato nemmeno progettato per un sistema Unix, è stato progettato per il classico Mac OS e patchato per implementare le funzionalità di Mac OS X 10.0 mantenendo la retrocompatibilità . Apple ha successivamente implementato le funzionalità aggiuntive che ora ha in Mac OS X 10.7 (eventi di journaling, metadati, file system ...) utilizzando lo stesso approccio di patching piuttosto che un approccio "dal basso verso l'alto". Non sono sicuro di come spiegarlo in maniera non tecnica, ma si potrebbe dire che tutte queste funzionalità aggiuntive si basano su una base classica per Mac OS che non è mai stata progettata per supportarle. Ciò significa che la soluzione non è buona come potrebbe essere. L'esempio che Siracusa continua a discutere è che la soluzione che Apple ha dovuto utilizzare per i collegamenti fisici mentre lavorava nei limiti di HFS + è troppo sensibile agli errori hardware, il che è aggravato dal fatto che HFS + non è mai stato progettato per occuparsi dei dati integrità. Naturalmente, mantenere la compatibilità con il classico sistema operativo Mac era una limitazione auspicabile in Mac OS X 10.0 ma in realtà non lo è più in Mac OS X 10.7.

Anche se non sono un esperto del sistema operativo, e ho appena iniziato a utilizzare OSX dopo essere arrivato da Windows, mi considero un PowerUser in Windows e abbastanza competente in Linux. Venendo da questo sfondo, sono stato sorpreso che in un sistema operativo abbastanza moderno come OSX, il filesystem ha stranezze come il modo in cui i nomi dei file sono "mungled".

Capisco che i problemi di Linus con HFS + derivino dallo stesso punto: da quello che ho trovato cercando il problema, HFS + memorizza i nomi dei file usando Unicode, ma quando un file usa caratteri "estesi" o NON-ASCII ( come á, é, í, ó, ú, ñ dallo spagnolo o cose come ü in tedesco), per cui Unicode fornisce 2 modi di codificare il nome, OSX silenziosamente "normalizza" la codifica al momento dell'archiviazione ... Non è un vero Problema quando il file è stato creato e consumato in OSX, ma quando si condividono le informazioni con gli utenti di altri sistemi operativi, il fatto che il nome del file cambi, rende per tutti i tipi di comportamenti strani. ..

Esempio: ho monitorato il mio lavoro "artefatti" (file, documenti, ecc.) in Subversion negli ultimi 8 anni. Quando mi sono trasferito su Mac, ho ottenuto il client SVN per Mac, e dopo aver eseguito un Checkout delle mie directory pertinenti, ho scoperto che mancano tutti i tutti file con accenti e un nuovo file con lo stesso il nome appare come non versione. Scavando in esso, il problema è che il file nel file system è codificato Apple, mentre i dati nel repository utilizzano un'altra codifica Unicode (perfettamente valida e legittima) ...

Questo, penso, è un grossolano "maltrattamento" dei miei dati. Apple comprende i due formati della codifica del nome del file (l'accesso a una condivisione in Windows o l'utilizzo di una chiavetta USB da Windows mostra i nomi file corretti, ecc.) Ma al momento della creazione del file, ha deciso che "conosce meglio" e ha semplicemente rinominato i file. ..

Ancora una volta, non qualcosa che la maggior parte degli utenti noterà - fino a quando non fanno una copia di un file, o lo rinominano, e lo rimettono dove era l'originale e finiscono con due file apparentemente uguali !!!)

John Siracusa & Dan Benjamin discute alcuni svantaggi di HFS + in # 56 ipercritico .

Affrontano la corruzione dei dati in HFS + e prendono in considerazione alcune delle funzionalità di ZFS.