2011-09-06 5 views
5

Je maintiens une application qui recueille des données à partir d'un enregistreur de données et ajoute ces données à la fin d'un fichier binaire. La nature de ce système est que le fichier peut développer de grandes étapes (> 4 gigaoctets) à la fois. Sur les utilisateurs de mon application a vu des cas sur sa partition NTFS où les tentatives d'ajouter des données échouent. L'erreur est signalée à la suite d'un appel à fflush(). Lorsque cela se produit, la valeur de retour pour GetLastError() est 665 (ERROR_FILE_SYSTEM_LIMITATION). MSDN donne ce qui suit description pour cette erreurQuels sont les facteurs pouvant conduire à Win32 error 665 (limitation du système de fichiers)?

L'opération demandée n'a pas pu être effectuée en raison d'une limitation du système de fichiers

Une recherche de ce code d'erreur sur Google donne des résultats liés au serveur SQL avec une très grande fichiers (dizaines de gigaoctets) mais, à l'heure actuelle, notre fichier est beaucoup plus petit. Cet utilisateur n'a pas pu obtenir le fichier à dépasser 10 gigaoctets. Nous pouvons corriger temporairement la situation lorsque nous faisons une opération (comme copier le fichier) qui force une sorte de réécriture dans le système de fichiers. Malheureusement, je ne suis pas sûr de ce qui se passe pour nous mettre dans cette condition en premier lieu. Quelles conditions spécifiques dans un système de fichiers NTFS peuvent conduire à cette erreur particulière signalée lors d'un appel à fflush()?

+0

Peut-être que [ce] (http://blogs.technet.com/b /mikelag/archive/2011/02/09/how-fragmentation-on-incorrectly-formatted-ntfs-volumes-affects-exchange.aspx) aide. Il s'agit d'Exchange, mais peut-être que vous pouvez trouver quelque chose là-bas. –

+2

http://support.microsoft.com/default.aspx?scid=kb;EN-US;967351 –

Répondre

9

Cela semble avoir atteint une limite dans la fragmentation du fichier. En d'autres termes, chaque vidage crée une nouvelle extension (fragment) du fichier et le système de fichiers a du mal à trouver un endroit pour garder une trace de la liste des fragments. Cela expliquerait pourquoi la copie du fichier aide - cela crée un nouveau fichier avec moins de fragments.

Une autre chose qui fonctionnerait probablement est la défragmentation du fichier (en utilisant l'utilitaire contig de Sysinternals, vous pourrez peut-être le faire pendant son utilisation). Vous pouvez également utiliser contig pour vous indiquer le nombre de fragments du fichier. Je suppose que c'est de l'ordre d'un million.

Si vous devez vider le fichier fréquemment et ne pouvez pas le défragmenter, vous pouvez simplement créer le fichier assez volumineux (pour allouer l'espace en une seule fois), puis écrire sur des octets successifs de le fichier plutôt que d'ajouter.

Si vous êtes courageux (et votre processus a accès admin), vous pouvez vous défragmenter le fichier avec quelques appels API: http://msdn.microsoft.com/en-us/library/aa363911(v=VS.85).aspx

+0

Je n'étais pas au courant de l'utilitaire contig et il semble être un outil utile. Malheureusement, il n'a pas été capable de défragmenter le fichier. Le code d'erreur était le même (665). Apparemment, contig est incapable de défragmenter un fichier trop fragmenté. –

+0

@Jon: Oui, j'ai bien peur que vous deviez lancer contig' * avant que ça ne devienne aussi gros. Que dit 'contig -a' à propos de votre fichier? – Gabe

+0

contig -a signalé que le fichier avait 77771 fragments. J'ai copié le fichier et contig a ensuite signalé que le fichier avait un fragment. Le nombre rapporté de fragments semble être une sorte de limite étrange dans le système de fichiers. Y a-t-il une limite stricte ou y a-t-il une sorte d'indirection? –

Questions connexes