Quali operazioni sui metadati del filesystem sono effettivamente registrate su journal in ext4 & xfs?

9

Non riesco a trovare una risposta semplice e diretta su quali operazioni dei metadati del filesystem siano effettivamente persistite sui giornali dei filesystem ext4 & xfs. Si noti che sto non si informa su ciò che POSIX dichiara di essere "atomica". Sono più preoccupato per quale sottoinsieme di operazioni di filesystem atomico sono effettivamente durevoli in virtù della corsa con un journal abilitato senza doversi piegare all'indietro e fsync(2)continuamente.

Operazioni sono abbastanza sicuro contare:

creat(2)
link(2)
unlink(2)
rename(2)
mkdir(2)
rmdir(2)

Operazioni di cui non sono del tutto sicuro:

symlink(2)

Il symlink(2)caso è il più preoccupante, dal momento che non sembra essere un modo semplice per fsync(2)o fdatasync(2)le DataBlocks sottostanti che memorizzano il contenuto di un link simbolico. Sapere che il diario si occupa di questo per me sarebbe un sollievo.

— rboyer
fonte

1

Per motivi di prestazioni, ext4 di default scrive solo i metadati del filesystem attraverso il journal.

Credo che XFS diari anche tutte le transazioni di metadati, a meno che tu non abbia modificato il filesystem.

— John Westlund
fonte

Sì, ma cosa sono i "metadati" in particolare? I blocchi di una directory: certo. Gli inode stessi: sì. Collegamenti simbolici con un target abbastanza piccolo da adattarsi all'inode stesso: probabilmente? Collegamenti simbolici in cui il bersaglio si riversa in blocchi ausiliari: ??????

collegamento sarebbe di aiuto

— asdmin

1

Sono più preoccupato per quale sottoinsieme di operazioni di filesystem atomico sono effettivamente durevoli in virtù della corsa con un journal abilitato senza doversi piegare all'indietro e fsync (2) per tutto il tempo.

Nessuna. Se vuoi essere sicuro che le modifiche persistano dopo un arresto, devi sincronizzare, punto. Il journaling garantisce solo che in caso di arresto anomalo, nessuna delle operazioni elencate verrà eseguita a metà .

— psusi
fonte

So che se mi interessa devo sincronizzare i file e le directory per sapere con certezza se i blocchi hanno colpito la rotazione della ruggine, ma non c'è alcun metodo che sono stato in grado di trovare che mi permetta di sincronizzare i blocchi che supportano un collegamento simbolico se fuoriesce da l'inode. A quel punto la mia unica risorsa è quella di fare affidamento sul diario o di non utilizzare mai più i collegamenti simbolici per qualsiasi cosa sia importante.

— Rboyer,

@naelyn, un fsync () scaricherà tutti i blocchi relativi a un file, incluso un collegamento simbolico non veloce.

— psusi,

1

come faccio ad aprire un descrittore di file appropriato per l'uso in un fsync che eliminerebbe i blocchi di un symlink non veloce?

— Rboyer,

@naelyn, oh sì ... buon punto ... potrebbe essere necessario chiedere quello sulla mailing list linux-fsdevel ... con hard link Credo che tu apra e sincronizzi la directory che lo contiene, forse i symlink funzionano allo stesso modo?

— psusi,

0

Sai che il journal ext4 funziona in base al numero di blocco e non all'operazione, giusto? I "metadati" sarebbero diversi dai blocchi di dati effettivi per l'inode dato, indipendentemente dall'operazione utilizzata per modificare il blocco in questione.

— Bratchley
fonte

0

xfstests sembra sostenere che fsync () su una directory dovrebbe persistere eventuali link simbolici in esso contenuti.

Non ho verificato questo. È possibile che mi sia perso qualcosa.

xfstests è utilizzato da molti sviluppatori di filesystem Linux. Questo test si trova nella directory "generica". Implica che dovrebbe applicarsi a tutti i filesystem Linux. (O almeno, tutti i filesystem dei dispositivi a blocchi. Il test funziona usando uno speciale dispositivo a blocchi virtuali).

https://github.com/kdave/xfstests/blob/master/tests/generic/348

# Test creating a symlink, fsync its parent directory, power fail and mount
# again the filesystem. After these steps the symlink should exist and its
# content must match what we specified when we created it (must not be empty
# or point to something else).

— sourcejedi
fonte