Linux garantisce che i contenuti di un file vengano scaricati su disco dopo close ()?

Quando un file viene chiuso utilizzando close() o fclose() (ad esempio), Linux garantisce che il file venga riscritto sul disco (permanente)?

Quello che intendo è, se close() restituisce 0 e poi subito dopo la mancanza di alimentazione, i dati scritti in precedenza sono garantiti per persistere, cioè essere durevoli?

La chiamata di sistema fsync() fornisce questa garanzia. Anche la chiusura di un file è sufficiente?

Non riesco a trovare nulla che possa far valere qualsiasi pretesa in un modo o nell’altro al momento.


Domanda 2:

Se close() fa implicitamente un fsync() , c’è un modo per dirlo di no?

Da ” man 2 close “:

Una chiusura corretta non garantisce che i dati siano stati salvati correttamente sul disco, come scrive il kernel.

La pagina man dice che se vuoi essere sicuro che i tuoi dati siano su disco, devi usare fsync () tu stesso.

No, close non esegue un fsync (2) e picchia molte macchine fino alla morte se lo facesse. Molti file intermedi vengono aperti e chiusi dal loro creatore, quindi aperti e chiusi dai loro utenti, quindi eliminati, e questa sequenza molto comune richiederebbe di toccare il disco se close (2) esegue un fsync automatico (2) . Invece, il disco non viene solitamente toccato e il disco non sa mai che il file era lì.

È anche importante notare che fsync non garantisce che un file sia su disco; garantisce solo che il sistema operativo abbia richiesto al filesystem di scaricare le modifiche sul disco. Il filesystem non deve scrivere nulla su disco

da man 3 fsync

Se _POSIX_SYNCHRONIZED_IO non è definito, la dicitura fa molto affidamento sul documento di conformità per dire all’utente cosa ci si può aspettare dal sistema. È esplicitamente inteso che è consentita un’implementazione nulla.

Fortunatamente, tutti i filesystem comuni per Linux in realtà scrivono le modifiche sul disco; sfortunatamente non garantisce ancora che il file sia sul disco. Molti dischi rigidi sono dotati di buffer di scrittura triggersto (e quindi hanno i propri buffer che fsync non scarica). E alcuni controller di unità / raid ti mentono persino sul fatto di aver svuotato i buffer.

No. fclose () non implica fsync (). Un sacco di file system Linux ritardano le scritture e le scaricano, il che migliora le prestazioni complessive, presumibilmente riduce l’usura sul disco rigido e migliora la durata della batteria per i laptop. Se il sistema operativo dovette scrivere su disco ogni volta che un file viene chiuso, molti di questi benefici andrebbero persi.

Paul Tomblin menzionò una polemica nella sua risposta e spiegando quello che ho visto non rientrerebbe in un commento. Ecco cosa ho sentito:

La recente controversia riguarda l’ordine di ext4 (ext4 è il successore proposto del popolare file system ext3 Linux). È consuetudine, nei sistemi Linux e Unix, modificare file importanti leggendo quello vecchio, scrivendo quello nuovo con un nome diverso e rinominando quello nuovo con quello vecchio. L’idea è di garantire che sia il nuovo che il vecchio sarà lì, anche se il sistema fallisce ad un certo punto. Sfortunatamente, ext4 sembra essere felice di leggere quello vecchio, rinominare quello nuovo con quello vecchio e scrivere quello nuovo, il che può essere un problema reale se il sistema scende tra i passaggi 2 e 3.

Il modo standard per gestirlo è naturalmente fsync (), ma questo compromette le prestazioni. La vera soluzione è modificare ext4 per mantenere l’ordine ext3, dove non rinominerebbe un file fino a quando non ha finito di scriverlo. Apparentemente questo non è coperto dallo standard, quindi è un problema di implementazione della qualità, e il QoI di ext4 è davvero pessimo qui, non essendoci modo di scrivere in modo affidabile una nuova versione dei file di configurazione senza chiamare costantemente fsync (), con tutti i problemi ciò causa o rischia di perdere entrambe le versioni.

No, non è garantito. Il sistema operativo ha il proprio caching. Tutto vicino garantisce davvero che i buffer dei programmi siano scaricati sul sistema operativo, ma il sistema operativo potrebbe ancora trattenerli non scritti. Credo che ci sia qualche controversia nel mondo del kernel di Linux perché anche fsync non garantisce che sia scaricato su disco, almeno in ext3.

La manpage per open dice:

Per garantire l’I / O sincrono, O_SYNC deve essere utilizzato in aggiunta a O_DIRECT .

e quello

In generale questo (O_DIRECT) ridurrà le prestazioni.

Si potrebbe triggersre questo flag usando fcntl con F_SETFL in modo da minimizzare gli effetti di cache dell’I / O per ogni lettura e scrittura successiva.

Potresti anche essere interessato a questo bug report dal database firebird sql riguardante fcntl (O_SYNC) che non funziona su linux.

Inoltre, la domanda che chiedi implica un potenziale problema. Cosa intendi scrivendo sul disco? Perchè importa? Sei preoccupato che l’alimentazione si spenga e il file non sia presente nell’unità? Perché non utilizzare un UPS sul sistema o sulla SAN?

In tal caso è necessario un file system di journaling e non solo un file system di journaling dei meta-dati, ma un journal completo anche per tutti i dati.

Anche in questo caso devi capire che oltre al coinvolgimento di O / S, la maggior parte dei dischi rigidi ti dice di fare un fsync. – fsync invia semplicemente i dati all’unità e spetta al singolo sistema operativo sapere come aspettare che l’unità svuoti le proprie cache.

–jeffk ++

Non penso che Linux possa garantire questo dato che l’unità stessa può memorizzare anche i dati.

Non dovremmo preoccuparci di questo se il computer / sistema operativo avesse un file system fault tolerant che avrebbe garantito la scrittura su qualcosa che fosse sopravvissuto a un ciclo di spegnimento per almeno i file su cui abbiamo applicato questo vincolo. Non deve essere disco se c’è qualche RAM non volatile o equivalente. Alcuni ricordi di un’epoca passata che ricordo vagamente avevano meccanismi del genere e presumibilmente facevano tali garanzie.