Linus Torvalds e il filesystem OS X.


28

Nel 2008, Linus Torvalds ha affermato in un'intervista che "OS X in qualche modo è in realtà peggio di Windows per cui programmare. Il loro file system è completo e assolutamente schifoso, il che fa paura." Ho cercato maggiori dettagli sul perché si sente in questo modo sul filesystem OS X (presumibilmente HFS +) ma non sono riuscito a trovare nulla.

A Linus sicuramente non piace il modello base di filesystem Unix, e dubito che odia HFS + per la distinzione tra maiuscole e minuscole. E nonostante quanto provocatorio sia il suo commento, dubito che sia completamente senza merito. Poiché il commento era nel contesto della programmazione per OS X, sospetto che la sua opinione potesse essere basata su prestazioni, solidità, interfaccia del sistema operativo o qualcosa del genere. Qualcuno sa quali lamentele avrebbe potuto avere Linus dell'era 2008 con HFS + dell'era 2008?


2
È stato conosciuto per avere opinioni molto forti su alcune cose, ad esempio quando ha tenuto un discorso su git @ google, ha trascorso buona parte del discorso a distruggere gli altri sistemi. Quindi direi che probabilmente ha un motivo per credere a ciò che pensa, ma è anche una persona molto esagerata, anche se è un genio. youtube.com/watch?v=4XpnKHJAok8
El Developer

3
Se non trovi qui la risposta a questa domanda che speravi, allora potresti anche considerare di cercare (e possibilmente anche chiedere) su Unix & Linux o Super User . (Con così tanti siti disponibili ora, a volte è difficile sapere qual è il posto dove porre una domanda. Almeno IMHO. :)
irrazionale John,

Tendo a testa a testa con HFS + più di qualsiasi altro filesystem che incontro normalmente. Al giorno d'oggi sulla maggior parte dei sistemi non mi sembra di notare o di preoccuparmi di quale file system stia usando, ma HFS + ha sempre qualcosa in mente. Come proprio oggi ho scoperto di essere stato fregato dalla sua mancanza di una risoluzione sub-secondo per gli orari. C'è stato anche il tempo in cui ho trovato due righe di codice C che potevano causare un deadlock nel filesystem praticamente abbattendo l'intera macchina. Ciò non è stato risolto al 10.5. Non sono sicuro delle versioni più recenti.
Iguananaut

Risposte:


21

È disponibile una trascrizione della sessione "Domande e risposte" in cui Linus ha reso il commento , ma sembra che non gli sia stato chiesto di elaborare. Non sono sicuro che un'analisi più approfondita della sua opinione su HFS + sia stata scritta altrove.

Per qualcun altro analisi 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'è che non va in HFS + ." Penso che il bit più saliente sia (enfatizzare il mio):

Concorrenza, metadati scritti nell'ordine corretto dei byte, precisione della data inferiore al secondo, supporto per volumi di grandi dimensioni e supporto dei file sparsi sono tutte caratteristiche comuni dei file system Unix. Mac OS X, ovviamente, è basato su una base Unix. Quando HFS + è stato trasferito dal classico Mac OS a Mac OS X, doveva essere esteso per supportare alcune serie minime di funzionalità previste dai file system Unix .

Alcune di queste funzionalità si adattavano facilmente, ma altre erano molto difficili da aggiungere al file system senza interrompere la compatibilità all'indietro. Un esempio particolarmente spaventoso è l'implementazione di hard link su HFS +. Per tenere traccia dei collegamenti reali, HFS + crea un file separato per ciascun collegamento reale all'interno di una directory nascosta a livello di radice del volume. Le directory nascoste sono un po 'inquietanti per cominciare, ma il vero spavento arriva quando ricordi che Time Machine è implementato usando collegamenti reali per evitare inutili duplicazioni di dati.

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 Mac OS classico e patchato per implementare le funzionalità di Mac OS X 10.0 mantenendo la compatibilità con le versioni precedenti. Apple ha successivamente implementato le funzionalità aggiuntive che ha ora in Mac OS X 10.7 (journaling, metadati, eventi del filesystem ...) utilizzando lo stesso approccio di patching piuttosto che un approccio di "progettazione da zero". Non sono sicuro di come spiegarlo non tecnicamente, ma potresti dire che tutte queste funzionalità aggiuntive si basano su una base classica di 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 reali mentre si lavorava entro i limiti di HFS + è troppo sensibile ai guasti hardware, a cui si aggiunge il fatto che HFS + non è mai stato progettato per occuparsi dei dati integrità. Naturalmente, mantenere la compatibilità con il classico Mac OS era una limitazione desiderabile in Mac OS X 10.0 ma in realtà non lo è più in Mac OS X 10.7.


1
Ottimo collegamento; che copre molte cose importanti. La mancanza di supporto per file sparsi è piuttosto folle. Linux ext2 ha sparso file anche con una semplice allocazione basata su bitmap a blocchi, come usa HFS +. Penso che faccia un affare troppo grande per la memorizzazione di metadati in big-endian, però. L' bswapistruzione x86 è molto veloce. Rende il codice più grande e brutto, ma mantenere la compatibilità su disco è un grosso problema. Linux XFS conserva ancora tutti i metadati big-endian (eccetto native-endian nel journal), a causa della sua origine in SGI su CPU MIPS. Non è una situazione ideale, ma XFS non ne è frenato.
Peter Cordes,

7

Anche se non sono un esperto del sistema operativo e ho appena iniziato a utilizzare OSX dopo essere venuto da Windows, mi considero un PowerUser in Windows e abbastanza competente in Linux. Provenendo da quello sfondo, sono rimasto sorpreso dal fatto che in un sistema operativo abbastanza moderno come OSX, il filesystem ha stranezze come il modo in cui i nomi dei file vengono "confusi".

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

Caso in questione: ho seguito 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 fatto un checkout delle mie directory pertinenti, ho scoperto che tutti i file con accenti sembrano mancare e un nuovo file con lo stesso nome appare come non versione. Scavando in esso, il problema è che il file IN nel file system è codificato Apple, mentre i dati nel repository utilizzano un'altra codifica Unicode (perfettamente valida e legittima) ...

Questo, a mio avviso, è una grave "manomissione" dei miei dati. Apple comprende entrambi i formati della codifica del nome file (l'accesso a una condivisione in Windows o l'utilizzo di una chiavetta USB da Windows mostra i nomi dei file corretti, ecc.) Ma al momento della creazione del file, si è deciso "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 in quello originale e finiscono con due file apparentemente uguali !!!)


1
Questo è solo un punto, e il vero problema è che diversi sistemi operativi normalizzano semplicemente le stringhe in modi diversi e le app multipiattaforma non lo affrontano. Non normalizzare i nomi probabilmente sarebbe peggio (potresti avere due file diversi con nomi che si normalizzano nella stessa stringa, su OS X).
Blaisorblade,

4

John Siracusa e Dan Benjamin discutono alcuni svantaggi di HFS + in Hypercritical # 56 .

Si occupano della corruzione dei dati in HFS + e prendono in considerazione alcune delle funzionalità di ZFS.


9
Esiste un modo per fornire un riepilogo della discussione nella risposta? Il flusso audio è (a questo punto nella nostra attuale tecnologia) non ricercabile e molto lungo. Per non parlare del fatto che si trova su un altro sito, quindi è suscettibile al marciume dei link. Questa sarebbe una risposta molto migliore se contenesse dettagli specifici sulla loro discussione.
Ian C.

1
La discussione sul filesystem inizia tra 23 minuti.
neoneye,

1
La maggior parte delle informazioni disponibili nel podcast può anche essere trovata in un articolo di Ars Technica di John Siracusa (uno dei due uomini nel podcast.)
TML
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.