Il filesystem può diventare incoerente se interrotto quando si sposta un file?

Ho due cartelle sulla stessa partizione (EXT2) Se si verificano io mv folder1/file folder2e qualche interruzione (es. Mancanza di corrente) il file system potrebbe finire per essere incoerente?

L' mvoperazione non è atomica?

Aggiornamento: Finora su IRC ho avuto le seguenti prospettive:

1. è atomico, quindi non possono verificarsi incoerenze
2. prima copi la voce dir nella nuova dir e poi cancelli la voce nella dir precedente, quindi potresti avere l'incoerenza di avere un file referenziato due volte, ma il conteggio dei ref è 1
3. prima cancella il puntatore e quindi copia il puntatore in modo che l'incoerenza sia che il file ha riferimento 0

Qualcuno può chiarire?

Innanzitutto, dissipiamo alcuni miti.

è atomico, quindi non possono verificarsi incoerenze

Lo spostamento di un file all'interno dello stesso filesystem (ovvero la rename) chiamata di sistema è atomico rispetto all'ambiente software. Atomicity significa che qualsiasi processo che cerca il file lo vedrà nella sua posizione precedente o nella sua nuova posizione; nessun processo sarà in grado di osservare che il file ha un conteggio dei collegamenti diverso o che il file è presente nella directory di origine dopo essere stato presente nella directory di destinazione o che il file è assente dalla directory di destinazione dopo essere stato assente nella sorgente directory.

Tuttavia, se il sistema si arresta in modo anomalo a causa di un bug, un errore del disco o un'interruzione dell'alimentazione, non vi è alcuna garanzia che il filesystem venga lasciato in uno stato coerente, per non parlare del fatto che lo spostamento non viene lasciato a metà. Linux non offre in generale una garanzia di atomicità rispetto agli eventi hardware.

prima copi la voce dir nella nuova dir e poi cancelli la voce nella dir precedente, quindi potresti avere l'incoerenza di avere un file referenziato due volte, ma il conteggio dei ref è 1

Questo si riferisce a una tecnica di implementazione specifica. Ce ne sono altri

Accade così che ext2 su Linux (a partire dal kernel 3.16) usi questa particolare tecnica. Tuttavia, ciò non implica che il contenuto del disco passi attraverso la sequenza [vecchia posizione] → [entrambe le posizioni] → [nuova posizione], poiché le due operazioni (aggiungi nuova voce, rimuovi vecchia voce) non sono atomiche neanche a livello hardware : è possibile che uno di essi venga interrotto, lasciando il file system in uno stato incoerente. (Speriamo che fsck lo ripari.) Inoltre lo strato di blocco può riordinare le scritture, quindi la prima metà potrebbe essere impegnata su disco appena prima dello schianto e la seconda metà non sarebbe stata eseguita.

Il conteggio dei riferimenti non sarà mai osservato essere diverso da 1 finché il sistema non si arresta in modo anomalo (vedere sopra) ma tale garanzia non si estende a un arresto anomalo del sistema.

prima cancella il puntatore e quindi copia il puntatore in modo che l'incoerenza sia che il file ha riferimento 0

Ancora una volta, ciò si riferisce a una particolare tecnica di implementazione. Un file pendente non può essere osservato se il sistema non si arresta in modo anomalo, ma è una possibile conseguenza di un arresto anomalo del sistema, almeno in alcune configurazioni.

Secondo un post sul blog di Alexander Larsson , ext2 non fornisce alcuna garanzia di coerenza in caso di crash del sistema, ma ext3 funziona in data=orderedmodalità. (Nota che questo post sul blog non riguarda renamese stesso, ma la combinazione di scrivere su un file e chiamare renamequel file.)

Theodore Ts'o, il principale autore dei filesystem ext2, ext3 ed ext4, ha scritto un post sul blog sullo stesso problema . Questo post sul blog discute atomicità (solo rispetto all'ambiente software) e durata (che è atomicità rispetto agli arresti anomali più una garanzia di impegno, cioè sapendo che l'operazione è stata eseguita). Purtroppo non riesco a trovare informazioni sull'atomicità rispetto ai soli incidenti. Tuttavia, le garanzie di durabilità fornite per ext4 richiedono che renamesia atomico. La documentazione del kernel per ext4 afferma che ext4 con l' auto_da_allocopzione (che è l'impostazione predefinita nei kernel moderni), così come ext4, fornisce una garanzia di durata per un writeseguito da unrename, il che implica che renameè atomico rispetto agli arresti anomali dell'hardware.

Per Btrfs, un file renameche sovrascrive un file esistente è garantito in modo atomico rispetto agli arresti anomali, ma un file renameche non sovrascrive un file può comportare l' assenza di file o di entrambi i file.

In sintesi, la risposta alla tua domanda è che non solo si sta spostando un file non atomico rispetto agli arresti anomali su ext2, ma non è nemmeno garantito che lasci il file in uno stato coerente (anche se i guasti che fscknon possono essere riparati sono rari) - praticamente nulla lo è, motivo per cui sono stati inventati file system migliori. Ext3, ext4 e btrfs offrono garanzie limitate.

L'operazione di ridenominazione è molto veloce su qualsiasi filesystem, quindi è improbabile che venga interrotta, ma su un filesystem classico può certamente essere interrotta - se crea prima il collegamento di destinazione, potrebbe lasciare due collegamenti su un file - che è legale, ma il file pensa di averne solo uno, il che potrebbe causare problemi se uno viene eliminato in seguito. D'altra parte, se rimuove prima il collegamento di origine, il file potrebbe andare perso. L'esecuzione di fsck rileverà e correggerà di solito entrambe le condizioni, anche se se il file viene perso verrà inserito in una directory "lost + found" con un nome arbitrario anziché nella posizione desiderata - e se ha due collegamenti il ​​conteggio dei collegamenti sarà semplicemente essere aggiornato, quindi il file esisterà in due posizioni se il filesystem lo supporta.

Se è necessario che un filesystem sia robusto di fronte a interruzioni di corrente, è necessario utilizzare un filesystem journaling , come NTFS, EXT3 o XFS. La maggior parte dei sistemi moderni utilizzerà un file system di journaling per impostazione predefinita, anche se è necessario tenere presente che FAT non è un file system di journaling se lo si utilizza per unità esterne.

Un filesystem journaling utilizza un sistema a "doppia voce": scrive nel file journal il fatto che intende spostarlo, quindi esegue lo spostamento. Quando il filesystem viene verificato all'avvio, se è stato interrotto, noterà che lo spostamento non è stato completato e quindi lo ripeterà.

Esistono due tipi di file system di journaling: l'inserimento nel journal dei metadati e l'inserimento nel journal completo. Il journaling dei metadati significa che non tiene traccia delle modifiche al contenuto del file nel sistema journal (quindi, potresti finire per perdere il contenuto se stai scrivendo su un file), ma manterrà comunque traccia delle informazioni importanti sul filesystem come il contenuto della directory , proprietà del file, ecc.

Quando le persone parlano dell'operazione atomica di ridenominazione, significano che non può essere osservata a metà transizione da un altro processo sul sistema, e non può essere lasciata incompleta, ad esempio interrompendo il mvcomando stesso ^C. Il processo fisico di scrittura su ciascuna directory, il cui spazio di archiviazione può trovarsi in posizioni molto diverse sul disco, non può essere un'operazione veramente atomica a livello hardware.

Per completezza, noterò che ci sono anche alcune operazioni I / O accidentali associate a una ridenominazione oltre a creare il nuovo collegamento nella directory di destinazione e rimuoverlo in quello precedente - aggiornando il mtime di entrambe le directory, eventualmente estendendo il dimensione di allocazione della directory di destinazione, modifica del ..conteggio e del conteggio dei collegamenti delle directory principali se il file è una directory. Inoltre, non sono sicuro che sia influenzato l'atime del file stesso.

Questa domanda è stata posta in modo leggermente diverso a Super User. La pagina Wikipedia sul mvcomando lo spiega anche abbastanza bene:

Lo spostamento di file all'interno dello stesso file system viene generalmente implementato in modo diverso rispetto alla copia del file e alla rimozione dell'originale. Su piattaforme che non supportano la ridenominazione di syscall, un nuovo collegamento viene aggiunto alla nuova directory e quella originale viene eliminata. I dati del file non sono accessibili.

Linux ha la rinomina syscall e pertanto rinominerà il file come un'operazione atomica, cioè non integrabile. Quindi no, il filesystem non può diventare incoerente nella situazione che hai descritto.