J'ai remarqué que XFS n'implémente pas de fsck au démarrage du système et l'une des raisons évoquées dans le fait que la journalisation des systèmes de fichiers aide à garantir que le système de fichiers est dans un état cohérent après un arrêt impur; au prochain montage (par exemple après le redémarrage), le journal est relu.
Un fsck est-il toujours nécessaire après un arrêt impur et pourquoi?
Réponses:
Je réponds à cela dans le contexte général des "systèmes de fichiers journalisés".
Je pense que si vous avez fait un certain nombre de « impures » (arrêts en tirant sur le cordon d'alimentation ou quelque chose ) tôt ou tard , vous obtiendrez à un état du système de fichiers qui nécessiterait fsckou l'équivalent moral de fsck, xfs_repair. Le ext4fichierystsm sur mon ordinateur portable pour la plupart rejoue le journal à chaque redémarrage, les arrêts propres inclus, mais de temps en temps, il fait un plein sur fsck.
Mais demandez-vous ce que "rejouer le journal" accomplit. La relecture d'un journal garantit simplement que les blocs de disques du reste du système de fichiers correspondent à l'ordre demandé par les entrées de journal. La relecture d'un journal équivaut à un petit fsckou à des parties d'un plein fsck.
Je pense qu'il y a un tour de passe-passe verbal: rejouer un journal fait partie de ce que fait le traditionnel fsck, et xfs_repairc'est exactement le même genre de programme que e2fs.fsck(ou tout autre système de fichiers fsck). Les gens de XFS venaient juste de le croire ou leur expérience les avait conduits à ne pas courir xfs_repairà chaque démarrage, juste à relire le journal.
fsckn'est pas «pédante». J'ai converti une ext3 LVMpartition ext4et j'ai commencé à obtenir des erreurs `` ext4_mb_generate_buddy '' en raison, si je comprends bien, d'un bogue dans le ext4code qui a provoqué une incompatibilité dans les copies sur disque et en mémoire du bitmap sur les partitions `` LVM '' converties. Pour autant que je sache fsck, aucune corruption ne s'est produite. La solution consistait à désactiver l' UNINIT_BGoption ou à déplacer les données et à réinitialiser la partition en tant que ext4; J'ai suivi ce dernier cours. Mais je pense quand même que quelques minutes d'attente fsckvalent la peine de ne pas perdre de données!
aider à assurer que le système de fichiers est dans un état cohérent après un arrêt impur
La première chose à noter est que XFS, reiser et la plupart des configurations d'ext n'implémentent que le journalisation des métadonnées, ce qui consiste à éviter fsck. Le journal n'est pas toujours relu au démarrage - il peut être supprimé s'il est incomplet.
Il existe des systèmes qui prennent en charge la journalisation complète des données - mais dans la pratique, le niveau d'assurance qu'ils fournissent par rapport à la simple journalisation des métadonnées est très faible dans les scénarios du monde réel.
Ainsi, un «état incohérent» et les problèmes résolus par fsck sont des décalages entre les métadonnées et les fichiers eux-mêmes. Pour éviter cela, le système d'exploitation écrit les modifications de métadonnées proposées dans le journal, puis écrit les données réelles sur le disque, puis applique les modifications de métadonnées qui sont répliquées dans le journal sur le disque. Le seul inconvénient est que le contrôleur de disque mettra en mémoire tampon et réorganisera potentiellement les demandes. Pour éviter cela, la plupart des systèmes de fichiers de journalisation implémentent des barrières: ils séparent chaque opération et attendent que le disque reconnaisse qu'il a terminé l'opération. Mais de nombreux disques modernes reconnaissent en fait l'achèvement des écritures avant la validation des données. Par conséquent, les choses peuvent devenir désordonnées.
Un fsck est-il toujours nécessaire après un arrêt impur et pourquoi
La plupart des systèmes de fichiers conservent un nombre de montages - une fois ce nombre atteint, un fsck complet sera déclenché lors de la prochaine tentative de montage du disque. La raison en est que les données du disque peuvent être corrompues même lorsqu'elles ne sont pas explicitement écrites, même sans bogues dans le logiciel. Le commentaire de psusi ci-dessus est faux.
hdparm -Wn'activez pas le cache d'écriture de disque ( ), le disque ne termine pas les demandes d'écriture tant qu'il n'est pas sur le support. Pourquoi pensez-vous que cette option existe? Les obstacles empêchent la réorganisation lorsque plusieurs demandes sont émises. Sans barrières, le fs n'émet tout simplement plus de requêtes jusqu'à ce que les précédentes soient terminées, maintenant ainsi l'ordre sans barrières ... à condition que le cache d'écriture de disque ne soit pas activé. Le but des barrières est de vous permettre d'activer le cache d'écriture, sans corrompre les fs lors d'un crash.
sync. Laisse-moi réessayer. La procédure d'écriture sur le disque sans barrières consiste à écrire dans le journal, syncvidant ainsi les caches d'écriture, puis à écrire les données réelles. Cela garantit que le journal peut toujours être utilisé pour récupérer les fs après un crash, mais la synchronisation ralentit les choses et défait à moitié le but du cache d'écriture. Ainsi, des barrières ont été ajoutées pour mieux remplacer sync, et avec le support de disque approprié, elles peuvent récupérer en toute sécurité une grande partie des performances que la synchronisation retire.
Il n'est pas nécessaire de fsck un système de fichiers de journalisation simplement en raison d'un arrêt impur.
La raison entière pour supporter la pénalité de performance d'exécution de la journalisation des métadonnées est de s'assurer que le système de fichiers peut être rendu 100% cohérent à nouveau en relisant automatiquement le journal des métadonnées sur le montage suivant, si le système de fichiers n'a pas été correctement démonté.
Le seul rôle de fsck est d'assurer la cohérence des métadonnées, il est donc redondant d'exécuter fsck simplement parce que le système de fichiers n'a pas été correctement démonté.
Un système de fichiers de journalisation peut être corrompu pour d'autres raisons, cependant - défaillance matérielle, bogues du pilote, erreurs d'administration, etc. - donc les outils fsck sont certainement nécessaires. Il n'y a aucune raison de les invoquer uniquement en raison d'un arrêt impur.