se spengo il computer subito dopo aver modificato e salvato un file, molto probabilmente le mie modifiche andranno perse?
Potrebbero esserlo. Non direi "molto probabile", ma la probabilità dipende da molte cose.
Un modo semplice per aumentare le prestazioni delle scritture di file è che il sistema operativo si limiti a memorizzare nella cache i dati, dire (mentire a) all'applicazione che è stata eseguita la scrittura e quindi eseguire effettivamente la scrittura in un secondo momento. Ciò è particolarmente utile se sono in corso altre attività del disco contemporaneamente:il sistema operativo può dare la priorità alle letture ed eseguire le scritture in un secondo momento. Può anche rimuovere completamente la necessità di una scrittura effettiva, ad esempio nel caso in cui un file temporaneo venga rimosso rapidamente in seguito.
Il problema della memorizzazione nella cache è più pronunciato se l'archiviazione è lenta. La copia di file da un SSD veloce a una chiavetta USB lenta comporterà probabilmente un sacco di scrittura nella cache, poiché la chiavetta USB non riesce a tenere il passo. Ma il tuo cp command ritorna più velocemente, così puoi continuare a lavorare, possibilmente anche modificando i file che sono stati appena copiati.
Ovviamente il caching del genere ha lo svantaggio che noti, alcuni dati potrebbero andare persi prima che vengano effettivamente salvati. L'utente sarà seccato se il suo editore gli dice che la scrittura è andata a buon fine, ma il file non era effettivamente sul disco. Ecco perché c'è il fsync() chiamata di sistema, che dovrebbe tornare solo dopo che il file ha effettivamente raggiunto il disco. Il tuo editore può usarlo per assicurarsi che i dati siano corretti prima di segnalare all'utente che la scrittura è riuscita.
Ho detto "dovrebbe", poiché l'unità stessa potrebbe dire le stesse bugie al sistema operativo e dire che la scrittura è completa, mentre il file esiste davvero solo in una cache di scrittura volatile all'interno dell'unità. A seconda dell'unità, potrebbe non esserci modo di evitarlo.
Oltre a fsync() , ci sono anche i sync() e syncfs() chiamate di sistema che chiedono al sistema di assicurarsi che tutte le scritture a livello di sistema o tutte le scritture su un particolare filesystem abbiano raggiunto il disco. L'utilità sync può essere usato per chiamarli.
Poi c'è anche il O_DIRECT flag a open() , che dovrebbe "cercare di ridurre al minimo gli effetti della cache dell'I/O da e verso questo file". La rimozione della memorizzazione nella cache riduce le prestazioni, quindi viene utilizzata principalmente dalle applicazioni (database) che eseguono la propria memorizzazione nella cache e vogliono averne il controllo.(O_DIRECT non è privo di problemi, i commenti a riguardo nella pagina man sono alquanto divertenti.)
Ciò che accade in caso di spegnimento dipende anche dal filesystem. Non sono solo i dati del file di cui dovresti preoccuparti, ma i metadati del filesystem. Avere i dati del file su disco non è molto utile se non riesci a trovarlo. La semplice estensione di un file a una dimensione maggiore richiederà l'allocazione di nuovi blocchi di dati e devono essere contrassegnati da qualche parte.
Il modo in cui un filesystem gestisce le modifiche ai metadati e l'ordine tra metadati e scritture di dati varia molto. Ad esempio, con ext4 , se imposti il flag di montaggio data=journal , quindi tutte le scritture, anche quelle di dati, passano attraverso il diario e dovrebbero essere piuttosto sicure. Ciò significa anche che vengono scritti due volte, quindi le prestazioni diminuiscono. Le opzioni predefinite tentano di ordinare le scritture in modo che i dati siano sul disco prima che i metadati vengano aggiornati. Altre opzioni o altri filesystem potrebbero essere migliori o peggiori; Non tenterò nemmeno uno studio completo.
In pratica, su un sistema poco carico, il file dovrebbe raggiungere il disco in pochi secondi. Se hai a che fare con l'archiviazione rimovibile, smonta il filesystem prima di estrarre il supporto per assicurarti che i dati vengano effettivamente inviati all'unità e non ci siano ulteriori attività. (Oppure chiedi al tuo ambiente GUI di farlo per te.)
C'è un estremamente modo semplice per dimostrare che non può essere vero che le modifiche ai file vengono sempre salvate direttamente su disco, vale a dire il fatto che ci sono filesystem che non sono supportati da un disco in primo luogo . Se un filesystem non ha un disco in primo luogo, allora non è possibile scrivere le modifiche su disco, sempre .
Alcuni esempi sono:
tmpfs, un file system che esiste solo nella RAM (o più precisamente, nella cache del buffer)ramfs, un file system che esiste solo nella RAM- qualsiasi file system di rete (NFS, CIFS/SMB, AFS, AFP, …)
- qualsiasi file system virtuale (
sysfs,procfs,devfs,shmfs, …)
Ma anche per i file system supportati da disco questo di solito non è vero. La pagina Come corrompere un database SQLite ha un capitolo intitolato Mancata sincronizzazione che descrive molti modi diversi in cui le scritture (in questo caso i commit su un database SQLite) possono non arrivare sul disco. SQLite ha anche un white paper che spiega i molti ostacoli che devi superare per garantire l'Atomic Commit In SQLite . (Notare che scrittura atomica è molto più difficile del semplice scrivere , ma ovviamente la scrittura su disco è un sottoproblema della scrittura atomica, e puoi imparare molto anche su questo problema da questo documento.) Questo documento ha una sezione su Cose che possono andare storte che include una sottosezione sugli svuotamenti incompleti del disco che forniscono alcuni esempi di sottili complessità che potrebbero impedire a una scrittura di raggiungere il disco (come il controller dell'HDD che segnala di aver scritto sul disco quando in realtà non l'ha fatto - sì, ci sono produttori di HDD che lo fanno, e potrebbe anche essere legale secondo le specifiche ATA, perché è formulato in modo ambiguo a questo proposito).
È vero che la maggior parte dei sistemi operativi, inclusi Unix, Linux e Windows, utilizza una cache di scrittura per velocizzare le operazioni. Ciò significa che spegnere un computer senza spegnerlo è una cattiva idea e può portare alla perdita di dati. Lo stesso vale se rimuovi un archivio USB prima che sia pronto per essere rimosso.
La maggior parte dei sistemi offre anche la possibilità di rendere sincrone le scritture. Ciò significa che i dati saranno su disco prima che un'applicazione riceva una conferma di successo, a costo di essere più lenti.
In breve, c'è un motivo per cui dovresti spegnere correttamente il tuo computer e preparare adeguatamente l'archivio USB per la rimozione.