Adesso ti dimenticherai delle invalidazioni degli HD ora capiterà raramente, con SFS sarebbe stato ancora più raro ma questo Filesystem non supporta il Kick 1.3
Invalidazioni ancora più rare con SFS anzichè con PFS3AIO, in quanto SFS è (credo come tutti gli OS moderni, es: Win,
GNU/Linux e sue distro/flavours, MacOS X ecc ...) "Journaled", ovvero si comporta nel seguente modo:
supponiamo che un processo voglia scrivere un file su disco.
Il processo in questione invoca un'API-funzione verso l'OS, una chiamata di sistema insomma, a mezzo della quale il
processo chiede gentilmente all'OS il permesso di scrivere sul disco su un certo file.
L'OS, se il semaforo è verde, concede al processo di scrivere sul file in questione, rossificando di conseguenza il semaforo
(qualunque altro processo che richieda, invocando la stessa API, di accedere a quel file su quel disco, viene messo in coda
dall'OS sul semaforo che protegge quella risorsa condivisa).
Insomma, adesso che l'OS permette al processo di scrivere su file su disco, prima ancora che la scrittura inizi, supponiamo scrittura
da chip-ram (un file in chip-ram, ad esempio un'immagine ILBM) verso il disco, tramite un canale DMA (uno dei canali DMA messi
a disposizione da FatAgnus, giusto?), dicevo prima che tale scrittura inizi, l'OS registra su un file speciale, chiamato file di "rollback",
i metadati relativi al file che il processo richiedente sta per accedere in scrittura.
Purtroppo, per ragioni di efficienza, SFS registra nel log-file "rollback" appena citato, prima dell'operazione di accesso al file su disco,
solo i metadati, non i dati veri e propri: c'è solo un caso in cui (credo data la criticità dell'operazione) SFS scrive in "rollback" sia i metadata che i data, ovvero durante l'auto-deframmentazione che SFS esegue in background, autonomamente, al volo, mentre il filesystem è in uso per altri scopi, ovvero mentre altri processi concorrenti R/W-accedono al disco, c'è un demone che si occupa della deframmentazione dei files sul disco stesso, e solo in questo caso la registrazione su log-file "rollback", prima di una R/W-operazione, include anche i data, oltre che i metadata.
Una volta che la scrittura su file è terminata, e quindi il semaforo è verdificato nuovamente, a questo punto SFS registra sullo stesso file "rollback" i metadata di esito finale dell'operazione, ovvero il risultato finale dell'operazione di scrittura su file appena terminata,
e se tale risultato coincide con la "dichiarazione di intenti" registrata su "rollback" prima dell'inizio dell'operazione, allora vuol dire
che tutto è andato bene.
Supponiamo invece che, durante la scrittura su file su disco (un canale DMA di FatAgnus sta trasferendo i dati), si verifica un incidente, ad esempio l'alimentazione viene improvvisamente meno, oppure improvvisamente il disco si rompe, oppure viene scollegato, oppure ancora si verifica un crash del sistema, ecc ... in questi casi la scrittura fallisce.
Quindi quando il sistema Amiga verrà riavviato e SFS verrà rimontato, SFS come prima cosa controlla il file di "rollback", per valutare se ai metadata di "dichiarazione di intenti" registrati prima dell'inizio delle R/W-operazioni, corrisponde coerentemente una struttura di metadata relativa all'esito finale di suddette operazioni.
Se c'è coerenza fra le due strutture di metadata, tutto ok, altrimenti, nel caso in cui la R/W-operazione abbia fallito (spegnimento improvviso, crash ecc...), allora SFS, grazie al mismatch fra metadata di prima e di dopo (probabilmente i metadata di dopo semplicemente non ci sono: c'è la struttura di metadata di pre-R/W-operazione, ma nessuna struttura analoga di metadata di post-R/W-operazione), allora SFS "riavvolge il nastro", nel senso che SFS recupera la coerenza della struttura dei files, cancellando i metadati di pre-R/W-operazione.
I dati possono essere persi in questo modo (tranne durante l'auto-deframmentazione, come già detto), ma non i metadati, quindi il filesystem non si dovrebbe mai invalidare.