Quali sono le differenze tra journaling HFS + e non journaling HFS +?


41

Sto per formattare un disco rigido esterno (HDD).

Quali sono le principali differenze tra il journaling HFS + e il non journaling HFS +? A parte il fatto che uno ha l' inserimento nel journal e l'altro no, in che modo influisce sulle prestazioni dell'unità (con i numeri)?

La mia impressione è che nell'uso "normale" il journaling sarebbe la strada da percorrere, ma ci sono situazioni in cui HFS + senza journaling dovrebbe essere preso in considerazione? La compatibilità con Linux è una di queste, poiché sembra che il modulo hfsplus del kernel supporti la lettura e la scrittura su HFS + senza journal, ma che legga solo su HFS + con journal.

C'è qualcos'altro degno di nota?

Risposte:


35

Non ho numeri per il backup dell'istruzione, ma l'utilizzo di HFS + senza journaling è una buona idea in alcuni volumi che richiedono una velocità assoluta, senza preoccuparsi (troppo) di una possibile "perdita di dati" o "corruzione dei dati" nel caso di mancanza di corrente o simile.

Quando usare HFS + senza journal è un'idea BAD ?

  • Unità esterne (USB, FW, ESata) che vengono collegate e ricollegate spesso: di solito è una cattiva idea, poiché queste unità tendono a essere accidentalmente disconnesse molto spesso e le loro fonti di alimentazione vengono scollegate.

  • Partizioni in cui l'integrità dei dati è importante e la protezione da una perdita di potenza imprevista è un must. (Documenti, musica, video, backup, ecc.).

Quando usare HFS + senza journal è una buona idea ?

  • Scratch, Temp, archiviazione banale e unità e partizioni simili, dove la velocità è> integrità dei dati in caso di interruzione di corrente. Volete che il vostro volume di lavoro di Final Cut non sia registrato su giornale (avete comunque un UPS, vero?). Volete che la vostra temperatura di Photoshop non sia registrata su giornale. Guida per copiare oggetti in giro (una pen drive, ad esempio se ti occupi di espellere correttamente).

  • Qualsiasi altra unità che richiede portabilità e compatibilità come correttamente sottolineato.

Ricordare che la manutenzione del journal aggiunge un piccolo sovraccarico, ma i vantaggi in caso di smontaggio del volume improprio sono importanti, non solo per evitare una "scansione" completa del disco all'avvio o sul re-mount, ma anche in termini di assicurarsi che i dati non siano corrotto in primo luogo.

Il montaggio di un'unità non registrata su giornale che è stata smontata in modo non corretto causerà una scansione fsck , mentre l'unità registrata su giornale sarà in grado di essere operativa e funzionante in un periodo di tempo più breve (scansione del giornale e applicazione di transazioni non vincolate).

Per quanto riguarda la velocità e i test, non ho molte informazioni per il backup della rivendicazione di cui sopra, tuttavia, per quanto ne so la differenza di velocità non solo è molto piccola e persino difficile da notare, ma in alcuni casi il filesystem journaled è più veloce di non -journaled.

Si scopre che nonostante l'overhead del journal, alcune operazioni possono essere eseguite in modo asincrono nell'unità Journaled, mentre la versione non journal deve eseguire le cose in modo sincrono.

Per riferimento ho cercato un po 'su Google cercando di trovare un vecchio confronto (i numeri sono probabilmente validi poiché HFS + non è cambiato molto dalle loro prime iterazioni in OSX, oltre all'aggiunta di record di dati di attributi inline e alla sicurezza dei file dell'elenco di controllo di accesso e forse qualcos'altro.

Ecco il sito Web con i grafici:

Confronto tra HFS + Journaled vs HFS + Non journaled

TL; DR:

La sequenza di copia / duplicazione / copia dei file è stata praticamente altrettanto veloce sia per HFS con journaling che non. La stessa sequenza con la cartella era di nuovo un po 'più veloce con l'HFS registrato su giornale

(enfatizzare il mio)

Conclusione

Sono un po 'sorpreso di vedere i risultati di cui sopra, poiché ero un po' convinto che l'uso di Non-Journaled fosse davvero più veloce per alcune operazioni, ma apparentemente i piccoli casi in cui può fare la differenza, è sovraponderato dalla "sicurezza" del Journaling.


@Griffo in realtà è +1 sulla domanda per farmi indagare e raggiungere la conclusione di cui sopra ;-) Grazie.
Martin Marconcini,

@ MartínMarconcini la sezione di risposta "piccolo overhead" non ha il sovraccarico in termini di consumo di spazio su disco. Ad esempio, quanto più spazio su disco sarà disponibile per l'archiviazione dei file quando il journaling non è abilitato?
Pro Backup

@ProBackup Anche se non ho "numeri", credo davvero che la dimensione del Journal sarà trascurabile nelle unità di oggi.
Martin Marconcini,

@ MartínMarconcini Mi chiedo quale sia il sovraccarico in termini di spazio su disco consumato perché: (1) La maggior parte di queste funzionalità bonus vengono aggiunte in modo proporzionale. (2) Tutti questi extra si sommano tutti: 209,7 MB per una partizione EFI, altri 1,4 MB per la possibilità di creare 128 partizioni dove è necessario solo 1. (3) Il fatto diskutil moveJournal externalcreerà una partizione Apple_Journal da 512 MB. (4) Su un 2,7 TB (vecchio stile da 3 TB) vengono utilizzati 736 MB ( df -h) quando si memorizza solo 1 file (secondo sudo du /Volumes/Name).
Pro Backup

4

Il journaling aggiunge ritardo e complessità ad ogni operazione che verrà registrata su journal. Il journal scrive la forzatura della scrittura immediata dei dati nell'unità, il che può rallentare altre transazioni in sospeso.

Un buon trattamento di ciò che fa il journaling è nella nota tecnica in pensione TN1150: HFS Plus Volume Format .

L'area del journal sul file system è scritta in modo pesante e forza il sistema operativo a sincronizzare i dati su base regolare. Ciò può interferire con operazioni di lettura e scrittura di grandi dimensioni eseguite contemporaneamente a una modifica del file system che richiede voci di giornale.

Il vantaggio di un sistema di journaling è che al momento del montaggio, il sistema può facilmente completare qualsiasi voce di creazione di file o di modifica della directory che era nel mezzo del tentativo. Il file system stesso viene riparato e trasformato in uno stato coerente con estrema rapidità rispetto a un controllo completo del catalogo del file system.

Per gli utenti principianti: avere un computer che chiede loro di riparare un disco non è divertente e provoca incertezza e li costringe a imparare un po 'su come funzionano le cose. Sì, sottolinea il fatto che potrebbero perdere quell'immagine che stavano scaricando o spostando. In pratica, il buon senso assicura che anche i nuovi utenti ricontrollino il file prima di eliminarlo dalla fotocamera quando il "maledetto computer" si riavvia nel mezzo della copia delle loro foto su iPhoto. (Più probabilmente chiamano il loro sistema di supporto per aiuto a questo punto se notano anche che l'avvio successivo è stato più lento o accade più di due volte a settimana)

Per gli utenti avanzati che desiderano prestazioni più veloci, i vantaggi del journaling sembrano più simili a penali al prezzo di prestazioni più lente. Queste sanzioni possono essere sostanziali se il sistema è già vicino alla capacità o necessita delle massime prestazioni per trasferimenti di dati sostenuti di grandi dimensioni tipici del video professionale o di alcuni flussi di lavoro del database.

Cose come queste sono buoni motivi per disabilitare l'inserimento nel journal:

  • file di archiviazione del database
  • macchine ridondanti con routine di guarigione dei dati dopo un errore
  • Archiviazione RAID che si occupa del journaling e altro ancora
  • solo bisogno di maggiore velocità, indipendentemente dal costo

TN1150 sembrava scomparire dal dominio apple.com, quindi l'edizione 2004 è riapparsa come documento ritirato su developer.apple.com/legacy/mac/library/#technotes/tn/… e poi trasferita su developer.apple.com/legacy/ libreria / technotes / tn / tn1150.html . C'è una copia in stile nostalgico dell'edizione 2004 su dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html
Graham Perrin

RAID non si occupa del tipo di errori che impedisce l'inserimento nel journal. Il journaling serve a garantire che quando il sistema operativo / file system si trova nel mezzo dell'aggiornamento della directory, che è una struttura ad albero complicata su HFS, un arresto del sistema o la rimozione del disco non distruggano l'intero albero di directory perdendo potenzialmente nodi importanti ( rami) che nemmeno fsck non riesce a recuperare. Il RAID non lo impedisce - ciò impedisce solo la perdita di dati a causa di un errore del disco, che è un tipo molto diverso di perdita di dati.
Thomas Tempelmann,

1

Potresti dare un'occhiata agli strumenti per sviluppatori per confrontare le prestazioni del disco di diversi filesystem se eri così incline, c'è una guida qui:  http://developer.apple.com/library/mac/DOCUMENTATION/Performance/Conceptual/FileSystem/Articles /MacOSXAndFiles.html

Non riesco a trovare alcun confronto con numeri concreti, ma probabilmente va da sé che un filesystem journaling offre tolleranza d'errore ma un filesystem non journaling offre prestazioni migliori

Ho aggiunto anche il tag del file system


+1 per il link dev, tendo a dimenticare quanto sia utile la risorsa. E un +1 invisibile per la retag ;-)
Jari Keinänen il
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.