La fragmentation MFT pourrait-elle être un problème sur mon serveur de fichiers occupé ?

Lorsque vous sauvegardez un tel volume, vous allez sérieusement solliciter le stockage sous-jacent. Lorsque vous commencez à lire ces millions de petits fichiers éparpillés dans le système de fichiers, le facteur limitant va être l'IOPS de lecture aléatoire que les disques sous-jacents de votre SAN peuvent fournir. Le SAN lui-même n'est peut-être pas du tout sollicité, mais le volume que vous lisez en prend un coup et tout autre processus qui tente de faire autre chose en même temps en pâtira, à moins que vous ne réduisiez l'activité de sauvegarde.

La chose à regarder est la profondeur de la file d'attente sur ce volume. Si elle est nettement supérieure au nombre de disques qui sauvegardent le volume, vous atteignez les limites IOPS. Perfmon vous donnera une idée, mais les meilleures données proviendront des analyses propres à la baie de stockage, s'il est possible de les obtenir. Je doute sérieusement que votre problème ait quelque chose à voir avec le verrouillage des fichiers. Les responsables du stockage doivent examiner les IOPS sur les disques dans le pack RAID à partir duquel votre volume est découpé, je soupçonne que ces disques atteignent plus de ~ 150 IOP chacun (plus s'ils sont 15k, plus s'ils sont 7.2k). Si vous avez un groupe RAID 10 de 6 disques hébergeant ce volume, alors il atteindra son maximum à un taux pas beaucoup plus élevé que 10Meg/sec s'il sauvegarde réellement des millions de fichiers de 10k et très peu de fichiers beaucoup plus gros.

NtfsDisableLastAccessUpdate sera utile dans votre cas - il supprime un ensemble d'IOPS de chaque activité de fichier et, en particulier, il évite quelques lectures et écritures supplémentaires associées à chaque fichier. Étant donné que vous en avez des millions et que vos fichiers sont si petits, il devrait y avoir un gain significatif, peut-être même de 50%. Cela dit, l'effet le plus probable que vous verrez est que votre sauvegarde s'accélérera, mais se heurtera toujours à une limite d'IOPs.

Vous devez également prendre en compte alignement de la partition du disque si cela n'a pas déjà été fait. Dans un cas comme celui-ci (beaucoup de petites lectures), ce n'est pas un gain aussi important que pour d'autres modèles d'E/S, probablement environ 10% en supposant que la taille de votre bande RAID est de 128k et que votre lecture moyenne est d'environ 10k, mais cela peut valoir la peine. Il faudra sauvegarder l'ensemble du volume, le repartitionner et le reformater, puis restaurer les données, ce qui n'est pas un exercice trivial.

L'exécution du défragmenteur de disque en mode analyse est le seul moyen que je connaisse pour voir combien de fragments MFT vous avez.

Si le volume est utilisé 24 heures sur 24 et 7 jours sur 7, vous êtes probablement obligé de "déranger" les utilisateurs. Sinon, programmez la commande "defrag -a -v C :" pour qu'elle soit exécutée en dehors des heures de travail et que sa sortie soit redirigée vers un fichier. Cela vous permettra d'obtenir le résultat de la commande sans avoir à être réveillé pour l'exécuter à 4 heures du matin un dimanche. >smile<

Je ne peux pas vous donner de statistiques concernant "NtfsDisableLastAccessUpdate", mais je l'activerais certainement à moins que vous n'ayez besoin que le dernier accès soit sauvegardé. (J'utiliserais la commande "fsutil behavior set disablelastaccess 1", plutôt que de la définir dans le registre. Vous devez également redémarrer pour que le changement prenne effet).

Vous pouvez également envisager de désactiver la création de noms de fichiers 8dot3 si vous n'en avez pas besoin. Faites-le, en particulier, si vous avez un grand nombre de fichiers dans un seul répertoire. (Bien que le fait de désactiver cette fonction ne vous débarrassera pas des noms 8dot3 qui sont déjà présents...)

Comparer la sortie de "fsutil fsinfo statistics" sur le volume en question avant / après ce lent "crawl initial" pourrait vous dire quelque chose sur ce qui se passe, bien que je pense que cela va juste vous montrer qu'une quantité hideuse de lectures de métadonnées se produisent.

Disposez-vous de suffisamment d'espace sur le SAN pour restaurer l'intégralité du contenu du volume sur un nouveau LUN configuré de manière similaire (en ce qui concerne ses propriétés SAN - niveau RAID, etc.) au LUN de production ? Il serait intéressant de voir comment un système de fichiers NTFS fraîchement installé avec la création de noms 8dot3 désactivée dès le départ, et peut-être une zone MFT de taille différente, se comporte par rapport au LUN de production. (Il ne serait pas trop difficile, non plus, d'orchestrer une migration en copiant les fichiers modifiés du LUN de production vers ce LUN de mise en scène si ce dernier s'avère mieux fonctionner).