Performances de stockage CS
Ce test vérifie que les performances du périphérique de stockage répondent aux exigences de performances.
Détails du test
| Spécifications |
|
| Plateformes |
|
| Versions prises en charge |
|
| Durée d’exécution attendue (en minutes) | 240 |
| Catégorie | Référence |
| Délai d’expiration (en minutes) | 14400 |
| Nécessite un redémarrage | false |
| Nécessite une configuration spéciale | false |
| Type | automatique |
Documentation supplémentaire
Les tests de cette zone de fonctionnalité peuvent avoir une documentation supplémentaire, y compris les conditions préalables, l’installation et les informations de résolution des problèmes, que vous trouverez dans les rubriques suivantes :
Exécution du test
Le périphérique de stockage doit être attaché au contrôleur approprié. Le test n’étant pas destructif, aucun fichier ou partition ne sera détruit pendant le test. Toutefois, les fichiers seront écrits sur le lecteur. Il est important de réduire la quantité d’activité qui se produit sur le lecteur en dehors du test de logo. Étant donné qu’il s’agit d’un test de performances, une activité externe peut affecter les résultats.
Dépannage
Pour la résolution des problèmes génériques des échecs de test HLK, consultez Résolution des échecs de test HLK Windows.
Vérifier la trace WTT :
Accédez à résultats du travail enfant de RunJob - Bibliothèque de performances de stockage.
Affichez le journal des tâches de l’exécution de StorPerf.
Ouvrez le fichier journal StorPerf.wtl.
Recherchez les messages susceptibles de résoudre le problème.
Échec de la taille de l’étendue :
Message d’erreur : « La taille d’étendue demandée, 10737418240 octets, est supérieure au fichier de condition préalable, 7195066368 octets. Test de logo invalidé. »
Si la taille d’étendue demandée est supérieure au fichier de condition préalable, une erreur est enregistrée, mais le test continue à s’exécuter. Le fichier testzone.tmp créé est trop petit pour tester suffisamment la plage requise par le test.
Vous devez faire plus d’espace pour créer ce fichier, sinon le fichier était trop petit et n’était pas correctement supprimé avant de commencer le test.
Actuellement, la taille minimale du fichier de préconditionnement requis est de 10 Go. 20 % d’espace libre doit également être laissé sur le lecteur. La phase de préconditionnement écrit un fichier qui remplit tout l’espace libre en laissant 20 % de l’espace libre total sur le lecteur.
Taille totale du disque * 20 % + 10 Go < d’espace libre
Vérifiez les résultats des tests individuels :
Parcourez les journaux des travaux des performances de stockage CS / Performances de stockage USB3.
Il existe plusieurs types de fichiers pour chaque exécution de cas de test à l’intérieur du test qui sont copiés dans le contrôleur pour le triage. Ces fichiers contiennent plus d’informations que celles disponibles dans les journaux WTT.
Les fichiers .result sont la sortie de la console de chaque processus lancé à partir de ce test.
Les fichiers .xml sont générés par la charge de travail que ce test lance. C’est ce qui est analysé pour obtenir les métriques.
Le fichier .csv est l’agrégat de toutes les données analysées pour chaque cas de test.
Le fichier .xls est le même agrégat que le fichier .csv du même nom, à ceci près qu’il a un code de passage/échec avec code couleur avec la valeur de la barre de métrique attendue.
Le nommage des fichiers .result et .xml identifie de manière unique l’exécution du cas de test.
Scen = Scénario.
La longue chaîne hexadécimale identifie tous les paramètres passés à la charge de travail.
La chaîne hexadécimale à trois chiffres est l’ID de thread.
Les derniers chiffres sont les exécutions de ce même cas de test sur la même charge de travail.
Si une erreur se produit dans le journal, le premier endroit où case activée est le fichier .result du même nom que le cas de test où l’erreur s’est produite. Lorsqu’une erreur se produit dans la charge de travail, le fichier .result est copié dans le fichier journal .wtl pour faciliter l’accès au contenu.
S’il ne parvient pas à ouvrir un handle sur le disque, il est possible qu’il n’ait pas de partition sur le lecteur ou qu’il ne s’exécute pas en tant qu’administrateur.
En cas d’incohérence concernant la métrique, les valeurs se trouvent dans le fichier de .xml
S’il existe une différence entre les interactions de variance ou de cas de test, les fichiers /.xls .csvaffichent les résultats de tous les tests.
Problèmes avec les journaux ETW ouverts :
Si le test est fermé pendant l’exécution, il est possible qu’un journal ETW reste actif.
Le moyen le plus simple de le réinitialiser consiste à redémarrer l’ordinateur.
L’enregistreur d’événements peut également être fermé manuellement :
Ouvrez une invite de commandes avec des privilèges élevés.
Exécuter la requête logman -ets
Exécuter logman stop -ets « Circular BitLocker Logger »
Pour plus d’informations sur la résolution des problèmes, consultez Résolution des problèmes de test Device.Storage.
Plus d’informations
Le travail accepte l’ID de instance de l’appareil testé et convertit l’ID de instance de l’appareil en un numéro de lecteur physique ou une lettre de lecteur selon le scénario. Si le scénario l’exige, le travail partitionne et met en forme le lecteur pour l’obtenir dans la configuration nécessaire au test. Le test s’exécute dans une série de cas de test mappés à des éléments dans les exigences. Les cas de test sont autonomes et sont exécutés séquentiellement. Une liste de cas de test peut être obtenue à l’aide de l’option de ligne de commande PrintPolicy avec l’appareil approprié spécifié. Chacun de ces cas de test peut être exécuté sur la ligne de commande à l’aide du test en mode autonome avec un fichier xml de stratégie personnalisé à l’aide de l’option de ligne de commande PolicyXML pour des tests ou des débogages supplémentaires.
Le test de performances du stockage stocke une table de stratégie définissant pour chaque type d’appareil les tests de performances à exécuter et les métriques appropriées. Une fois les éléments appropriés dans la table sélectionnés, le test génère séquentiellement des instances de la charge de travail spécifiée, StorageAssessment, dans ce cas, pour tester les éléments spécifiés dans la table pour cet appareil. Une fois que StorageAssessment a terminé ses tests et créé les résultats, le test de performances de stockage analyse ces valeurs et les compare aux barres définies dans les exigences de logo afin d’imprimer les journaux de réussite/échec.
Le scénario à tester est référencé par l’indicateur DeviceTag sur la ligne de commande. Cet indicateur est un TestcaseGroup dans le xml de stratégie. Le test comporte quelques scénarios intégrés, mais autorise des scénarios personnalisés, si vous le souhaitez.
Un scénario est défini par un ordre, une charge de travail, un accès, une opération, une valeur d’opération, une taille d’E/S, une taille d’étendue, un runtime, une profondeur de file d’attente, un pourcentage de condition préalable et une condition préalable en Mo. Chaque scénario défini dans la table correspond à la charge de travail qui est engendrée une fois. Plusieurs des mêmes scénarios définis pour un appareil n’appellent toujours qu’un seul cas de test.
Une métrique est définie par son type et sa valeur. Intrinsèque à la métrique est ses unités et si la barre est une limite supérieure ou inférieure. De nombreuses métriques peuvent être spécifiées pour chaque scénario, ce qui entraîne l’appel d’un seul cas de test pour ce scénario.
Pour chaque entrée de la table, il existe un critère de variance spécifié qui définit la variance maximale autorisée sur le dernier jeu d’exécutions avant qu’il arrête le test de ce cas de test. Pour la plupart des entrées, il est défini comme un minimum de 5 exécutions, un maximum de 30 exécutions, et la variance sur les 5 dernières exécutions doit être inférieure à 10 % pour continuer les tests. Le cas de test sera réexécuté jusqu’à 30 fois ou jusqu’à ce que l’exigence de variance soit satisfaite. À ce stade, la métrique est évaluée en fonction des propriétés définies de la métrique (minimum, maximum, moyenne, moyenne, etc.) sur le dernier jeu d’exécutions.
Bien que le test des performances du stockage ne se limite pas à une charge de travail, la plupart des scénarios définis dans la table de stratégies utilisent la charge de travail StorageAssessment pour générer la charge de travail et les métriques de performances.
Utilisation des commandes
| Commande | Description |
|---|---|
StorPerf.exe /DriveLetter [StorageDriveLetter] /DeviceTag CS_Boot |
Exécute le test CS sur le lecteur spécifié. DeviceTag peut également être CS_Boot_HS200 pour les lecteurs compatibles HS200. |
Syntaxe de commande
| Option de commande | Description |
|---|---|
/Numéro de lecteur <> |
Numéro de lecteur physique de l’appareil testé. Exemple : /DriveNumber 0 |
Lettre /DriveLetter <> |
Lettre de lecteur de l’appareil en cours de test. Exemple : /DriveLetter C |
Valeur /DeviceTag <> |
Identifie le TestcaseGroup ou ComparisonGroup à sélectionner comme entrée à partir des fichiers xml de configuration. Ce paramètre respecte la casse et est utilisé pour l’indexation des fichiers XML de stratégie et de comparaison. Exemple : /DeviceTag CS_Boot |
Valeur /PolicyXML <> |
Nom du fichier xml de stratégie. Définit tous les paramètres pour l’exécution des charges de travail d’E/S. Si aucune option n’est donnée, le fichier par défaut est généré. Exemple : CSPolicy.xml /PolicyXML |
/Comparer la <valeur><> |
Les deux fichiers xml à comparer. Celles-ci doivent avoir été générées à partir d’une exécution précédente de ce test. Les fichiers « FinalTestCasesAggregated*.xml » doivent être utilisés à la place des fichiers « AllTestCasesAggregated*.xml », car il n’existe aucune garantie que le nombre d’itérations est le même pour chaque cas de test. Exemple : /Compare FinalTestCasesAggregated_42f4.xml FinalTestCasesAggregated_a732.xml |
Valeur /CompareXML <> |
Nom du fichier xml de comparaison. Définit tous les paramètres pour l’exécution de la comparaison. Si aucune option n’est donnée, le fichier par défaut est généré. Exemple : /CompareXML CSCompare.xml |
/PrintPolicy |
Imprime la table de stratégie. |
Notes
Pour obtenir de l’aide sur la ligne de commande pour ce fichier binaire de test, tapez /h.
Liste de fichiers
| File | Emplacement |
|---|---|
StorPerf.exe |
<[testbinroot]>\NTTest\driverstest\storage\wdk\ |
StorageAssessment.exe |
<[testbinroot]>\NTTest\driverstest\storage\wdk\StorageAssessment\ |
ssdtest.dat |
<[testbinroot]>\NTTest\driverstest\storage\wdk\StorageAssessment\ |
Paramètres
| Nom du paramètre | Description des paramètres |
|---|---|
| LLU_NetAccessOnly | Compte d’utilisateur pour accéder au partage de fichiers de test. |
| LLU_LclAdminUsr | Compte d’utilisateur pour l’exécution du test. |
| WDKDeviceID | Chemin d’accès de l’instance de l’appareil à tester. |
| DeviceID | DriveLetter ou DriveNumber |
| DeviceTag | |
| DiskDeviceObjLink | Attribué par Créer des paramètres de stockage. |
| Destructrice | (0,1) 0=Passif, 1=Destructeur |
| QueryHS200 | Interroge si un appareil prend en charge le mode HS200 |