Quelles opérations de métadonnées de système de fichiers sont réellement journalisées dans ext4 et xfs?

9

Je ne trouve pas de réponse simple et directe sur les opérations de métadonnées du système de fichiers qui sont réellement conservées dans les journaux des systèmes de fichiers ext4 et xfs. Notez que je ne demande pas ce que POSIX déclare être "atomique". Je suis plus préoccupé par le sous-ensemble des opérations du système de fichiers atomique qui sont effectivement durables en raison de l'exécution avec un journal activé sans avoir à se pencher en arrière et fsync(2)tout le temps.

Opérations dont je suis assez certain:

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

Opérations dont je ne suis pas tout à fait sûr:

symlink(2)

Le symlink(2)cas est le plus troublant, car il ne semble pas y avoir de façon simple à fsync(2)ou fdatasync(2)les sous - jacents qui stockent datablock le contenu d'un lien symbolique. Savoir que le journal s'en occupe pour moi serait un soulagement.

— rboyer
source

1

Pour des raisons de performances, ext4 écrit par défaut uniquement les métadonnées du système de fichiers via le journal.

Je crois que XFS journalise également toutes les transactions de métadonnées, sauf si vous avez modifié le système de fichiers.

— John Westlund
source

Oui, mais qu'est-ce que les "métadonnées" en particulier? Les blocs d'un répertoire: bien sûr. Les inodes eux-mêmes: oui. Liens symboliques avec une cible suffisamment petite pour tenir dans l'inode lui-même: probablement? Liens symboliques où la cible déborde dans des blocs auxiliaires: ??????

lien aiderait

— asdmin

1

Je suis plus préoccupé par le sous-ensemble des opérations du système de fichiers atomique qui sont effectivement durables en raison de l'exécution avec un journal activé sans avoir à se pencher en arrière et fsync (2) tout le temps.

Aucun. Si vous voulez être sûr que les changements persistent après un plantage, vous devez fsync, point. La journalisation garantit uniquement qu'en cas de plantage, aucune des opérations que vous avez répertoriées ne sera à moitié effectuée.

— psusi
source

Je sais que si je m'en soucie, je dois fsync les fichiers et les répertoires pour savoir avec certitude si les blocs ont atteint la rouille tournante, mais il n'y a aucune méthode que j'ai pu trouver qui me permette de fsync les blocs qui sauvegardent un lien symbolique s'il déborde de l'inode. À ce stade, mon seul recours est de me fier au journal ou de ne plus jamais utiliser de liens symboliques pour tout ce qui compte.

— rboyer

@naelyn, un fsync () videra tous les blocs liés à un fichier, y compris un lien symbolique non rapide.

— psusi

1

comment puis-je ouvrir un descripteur de fichier approprié pour une utilisation dans un fsync qui viderait les blocs d'un lien symbolique non rapide?

— rboyer

@naelyn, oh oui ... bon point ... pourrait avoir besoin de poser des questions à ce sujet sur la liste de diffusion linux-fsdevel ... avec des liens durs Je crois que vous ouvrez et synchronisez le répertoire qui le contient, peut-être que les liens symboliques fonctionnent de la même manière?

— psusi

0

Vous savez que le journal ext4 fonctionne par numéro de bloc et non par opération, n'est-ce pas? Les "métadonnées" seraient autre chose que ces blocs de données réels pour l'inode donné, quelle que soit l'opération que vous avez utilisée pour modifier le bloc en question.

— Bratchley
source

0

xfstests semble prétendre que fsync () sur un répertoire devrait conserver tous les liens symboliques qu'il contient.

Je n'ai pas vérifié cela. Il est possible que j'ai raté quelque chose.

xfstests est utilisé par de nombreux développeurs de systèmes de fichiers Linux. Ce test se trouve dans le répertoire "générique". Cela implique qu'il devrait s'appliquer à tous les systèmes de fichiers Linux. (Ou au moins, tous les systèmes de fichiers de périphérique de bloc. Le test fonctionne en utilisant un périphérique de bloc virtuel spécial).

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
source