2017-09-26 9 views
0

Je cherche à utiliser fio pour vérifier les données sur le stockage après un arrêt, à cet effet à l'aide fio écriture avec --trigger-file option pour arrêter fio fonctionnement à mi-chemin (et simuler la puissance vers le bas). fio puis fio lire avec --verify_state_load option pour vérifier seulement les parties de données qui ont réussi à terminer, mais vérifier échoue, semble que state_load n'a aucun effet (read verify fonctionnera correctement comme prévu si le travail d'écriture n'est pas terminé partiellement par trigger).FIO verify_state_load et de déclenchement ne fonctionnent pas

Y a-t-il des restrictions à l'aide de trigger/state_load auxquelles je dois faire attention?

Ecrire des paramètres d'emploi:

[global] 
verify_fatal=1 
do_verify=0 
loops=1 
group_reporting=1 
filename=/dev/nvme0n1 
cpus_allowed=0-7 
cpus_allowed_policy=split 
runtime=0 
verify=crc32c-intel 
direct=1 
rw=randwrite 
verify_offset=100 
ioengine=libaio 
iodepth=32 
size=200mb 
bs=4096 
verify_backlog=16384.0 

[job_0] 
size=209715200 
offset=0 

[job_1] 
size=209715200 
offset=1744830464 

[job_2] 
size=209715200 
offset=3489660928 

[job_3] 
size=209715200 
offset=5234491392 

[job_4] 
size=209715200 
offset=6979321856 

[job_5] 
size=209715200 
offset=8724152320 

[job_6] 
size=209715200 
offset=10468982784 

[job_7] 
size=209715200 
offset=12213813248 

Lire les paramètres d'emploi:

[global] 
verify_fatal=1 
do_verify=1 
loops=1 
group_reporting=1 
filename=/dev/nvme0n1 
cpus_allowed=0-7 
verify_state_load=1 
cpus_allowed_policy=split 
runtime=0 
verify=crc32c-intel 
direct=1 
rw=read 
verify_offset=100 
ioengine=libaio 
iodepth=32 
size=1mb 
bs=4096 
verify_backlog=16384.0 

[job_0] 
size=1048576 
offset=0 

[job_1] 
size=1048576 
offset=1744830464 

[job_2] 
size=1048576 
offset=3489660928 

[job_3] 
size=1048576 
offset=5234491392 

[job_4] 
size=1048576 
offset=6979321856 

[job_5] 
size=1048576 
offset=8724152320 

[job_6] 
size=1048576 
offset=10468982784 

[job_7] 
size=1048576 
offset=1221381324 

Erreurs dans l'emploi de lecture:

à partir de 8 processus JOB_5: Non E/S effectuée par libaio , peut-être essayer l'option --debug = io pour plus de détails? job_4: Aucune E/S effectuée par libaio, peut-être essayer l'option --debug = io pour plus de détails? job_7: Aucune E/S effectuée par libaio, peut-être essayer l'option --debug = io pour plus de détails? job_6: Aucune E/S effectuée par libaio, peut-être essayer l'option --debug = io pour plus de détails? job_3: Aucune E/S effectuée par libaio, peut-être essayer l'option --debug = io pour plus de détails? job_2: Aucune E/S effectuée par libaio, peut-être essayer l'option --debug = io pour plus de détails? vérifier: mauvais en-tête offset 466944, recherché 20480 dans le fichier/dev/nvme0n1 offset 20480, longueur 4096 vérifier: mauvais en-tête offset 462848, recherché 24576 dans le fichier/dev/nvme0n1 offset 24576, longueur 4096 job_0: Aucune E/S effectuée par libaio, peut-être essayer l'option --debug = io pour plus de détails? fio: pid = 1920, err = 84/fichier: io_u.c: 1985, func = io_u_queued_complete, erreur = invalide ou incomplète ou multi-octets caractère large

Répondre

0

Mise à jour

Je pense que cela a fini par étant déposé par @ RononWeiss sur https://github.com/axboe/fio/issues/468. Là-bas un mainteneur fio a suggéré que le problème était vu parce que l'écriture des données était faite avec rw=randwrite mais l'étape séparée "vérification" était faite en utilisant rw=read et parce que fio fonde les données re-générées sur les paramètres du travail, le second étape génère différentes données à la première étape et donc signaler les discordances. Si la seconde étape utilise rw=randread, les discordances ne devraient pas être présentes (en supposant que les données ont été sauvegardées correctement ;-).

réponse originale

Hmm, vous pourriez être mieux demander cela aux gens fio directement (si vous choisissez de le faire, prenez un coup d'œil à https://github.com/axboe/fio/blob/master/REPORTING-BUGS et assurez-vous que vous êtes sur une version assez récente et fio voir https://github.com/axboe/fio/releases pour avoir une idée de quelles versions elles pourraient être).

Vos emplois ressemblent un peu étrange (verify_backlog ne prend pas les décimales, vous auriez pu faire size un mondial dans le travail de lecture, mais vous renouveler sans cesse, runtime est 0, etc.).La chose qui ressort immédiatement est que dans votre travail de "vérification" vous utilisez une taille différente du travail d'origine qui n'aura probablement pas une fin heureuse mais je ne peux pas dire que c'est le problème à coup sûr. Malheureusement vos travaux sont gros et compliqués ce qui rend difficile le repérage du problème (je suis très décontracté donc si je ne vois pas le problème en 30 secondes, je passe normalement en silence). Si vous avez des problèmes avec un travail de fio, je vous recommande fortement de réduire les paramètres de travail au strict minimum qui font toujours le problème (par exemple pouvez-vous faire le problème avec seulement deux emplois? Un seul travail? Combien d'options peuvent vous supprimez des globals de telle sorte que le problème continue à se produire?). De cette façon, les gens comme moi ont une excuse de moins pour éviter de diagnostiquer le problème ;-)

+0

merci, semble que le problème que je faisais peut être lié à l'aide d'écritures aléatoires, avec des écritures non aléatoires semble fonctionner comme je l'aurais prévu, mais supposé que cela aurait dû fonctionner avec aléatoire –

+0

@RonenWeiss ah bon à savoir. J'ai mis à jour la réponse - est-ce que ça a l'air mieux? – Anon

0

Mon problème semblait être que j'utilisais fio rw = randwrite pour générer des données et séparer rw = lire le travail pour vérifier les données après le déclenchement, en utilisant Merci pour vérifier les données adressées le problème que j'avais