Considérations relatives aux performances pour NTFS transactionnel

Le ntfs transactionnel (TxF) a été soigneusement conçu pour les performances et fonctionne généralement mieux que les alternatives transactionnelles à usage général dans des scénarios similaires. Toutefois, les transactions de système de fichiers ont plus de surcharge que les opérations non traitées, et une certaine réduction des performances d’E/S par rapport aux E/S non traitées est attendue. Les applications critiques pour les performances doivent effectuer un cycle de qualification d’adoption de la technologie, en évaluant l’impact sur les performances des opérations de système de fichiers traitées.

Vue d’ensemble des opérations TxF

TxF utilise la journalisation des annulations pour enregistrer les modifications nécessaires pour remettre le système de fichiers dans un état cohérent, également appelé restauration, en cas d’abandon de transaction. Cette journalisation d’annulation génère des E/S supplémentaires et est la source d’une surcharge de performances TxF par rapport aux opérations de système de fichiers non transactionnelles.

Voici un résumé général du fonctionnement de TxF :

• À mesure qu’une transaction progresse, TxF écrit des enregistrements d’annulation dans son fichier journal pour chaque modification apportée au système de fichiers. Si un abandon se produit, ces enregistrements d’annulation sont analysés pour remettre le système de fichiers dans l’état qu’il était avant le début de la transaction.
• Un enregistrement d’annulation de modification des métadonnées décrit une modification uniquement apportée aux métadonnées du système de fichiers. Par exemple, les déplacements, les renommages, les ajouts et les modifications d’attributs. Pour les enregistrements d’annulation de modification des métadonnées, toutes les informations nécessaires pour annuler la modification se trouvent dans l’enregistrement et sont stockées dans le fichier journal.
• Un enregistrement d’annulation de remplacement décrit un remplacement d’une partie d’un fichier. Lorsqu’un remplacement de fichier se produit, le contenu d’origine du fichier est stocké dans un fichier d’annulation spécial dans un répertoire masqué et l’enregistrement d’annulation de remplacement pointe vers ce fichier. Lorsque les mises à jour de fichiers sont finalement vidées du cache sur le disque, le contenu du fichier d’annulation doit également être vidé, de sorte qu’un remplacement de fichier traité peut générer jusqu’à deux opérations d’E/S aléatoires supplémentaires : une pour lire les anciennes données et l’autre pour les écrire dans le fichier d’annulation. Ces opérations d’E/S supplémentaires représentent un coût de performances de TxF.
• Lorsqu’une validation se produit, TxF vide d’abord toutes les informations d’annulation, puis vide les modifications de fichier réelles, puis écrit et vide un enregistrement de validation. S’il n’y a pas de fichiers d’annulation à vider, la seule surcharge TxF supplémentaire par rapport aux E/S non traitées est le vidage du journal proprement dit. Toutefois, les vidages de journal entraînent des écritures séquentielles volumineuses efficaces, ce qui réduit le coût des performances.
• TxF est optimisé pour la validation. Il est prévu que la plupart des transactions réussissent et n’ont pas besoin d’être annulées. Par conséquent, tous les enregistrements d’annulation d’une transaction sont censés être inutilisés. Du point de vue des performances, les opérations de validation TxF sont rapides et les restaurations gourmandes en ressources.
• La restauration est plus gourmande en ressources que la validation. Pendant la restauration, toutes les modifications apportées à la transaction doivent être supprimées. En général, la durée de restauration peut être approximativement la même que celle nécessaire pour effectuer les modifications initialement. Par exemple, s’il a fallu 1 seconde pour effectuer toutes les modifications, l’annulation peut prendre environ 1 seconde. Pour les transactions très longues, la restauration peut créer des impacts supplémentaires sur les performances. Par exemple, l’heure de démarrage du système peut être retardée si le système doit restaurer automatiquement une transaction dans le cas où le système cesse de répondre et doit effectuer un redémarrage non planifié.

Les conclusions récapitulatives sur les performances qui peuvent être tirées de la liste précédente sont les suivantes :

• Le coût de performances de TxF pour les transactions impliquant des remplacements de fichiers peut être important.
• Le coût de performances de TxF pour les transactions impliquant uniquement des opérations de métadonnées peut être relativement faible, à condition d’utiliser des transactions volumineuses. Une transaction importante se produit lorsqu’il existe de nombreux enregistrements d’annulation pour chaque enregistrement de validation.

Recommandations pour de meilleures performances

Amortissez la surcharge TxF sur les transactions plus importantes. Par exemple, si vous avez N ensembles de modifications à apporter où chaque modification comporte des étapes M et que vous avez la possibilité de le faire en tant que N transactions de M étapes chacune ou de tout faire en une seule transaction avec M*N étapes, cette dernière option serait plus efficace.

Tenez compte de l’impact possible sur le démarrage de transactions très volumineuses. Comme indiqué précédemment, la restauration peut être lente et retarder le temps de démarrage si le système doit effectuer des restaurations automatiques comme heure de démarrage. Plus la transaction est importante, plus le délai est long.

Conservez les transactions pour les opérations de métadonnées principalement. C’est pour cela que TxF est optimisé et, en général, les performances sont à peu près identiques à celles des E/S de fichiers non traitées pour les transactions de métadonnées volumineuses. Des exemples de fonctions TxF de métadonnées efficaces sont MoveFileTransacted, SetFileAttributesTransacted, CopyFileTransacted, DeleteFileTransacted, CreateHardLinkTransacted et les écritures ajoutées (appelle la fonction WriteFile lorsque le pointeur de fichier est à la fin du fichier, ou EOF). Un exemple d’opérations sans métadonnées gourmandes en ressources sont des appels à la fonction WriteFile lorsque le pointeur de fichier n’est pas au niveau de l’EOF.

Résumé des attentes en matière de performances de TxF

Pour les mises à jour sur place, les remplacements vers une section d’un fichier sont beaucoup plus lents que les E/S de fichiers non traitées, tandis que les performances TxF pour les opérations de métadonnées du système de fichiers (par exemple, créer, déplacer et ajouter) sont comparables aux E/S de fichiers non traitées pour les transactions volumineuses.