D'après mes observations en tant que développeur Java travaillant sur des postes de travail Windows, NTFS est lent par rapport aux systèmes de fichiers Linux. La question est, y a-t-il quelque chose dans le pilote NTFS qui peut être réglé manuellement, par exemple lui donner plus de mémoire pour le cache? Activer certains algorithmes expérimentaux? Si ce n'est pas disponible, existe-t-il peut-être un autre système de fichiers qui peut être utilisé sur Windows, peut-être même commercial, qui est plus rapide que NTFS?
Pour être clair, je ne cherche pas à améliorer les vitesses de compilation pour les projets Maven, je voudrais obtenir une amélioration globale pour le système d'exploitation. J'ai l'impression que NTFS est obsolète et lent depuis longtemps par rapport aux systèmes de fichiers Linux. Il me semble étrange que le système d'exploitation le plus populaire de la planète n'ait qu'un seul système de fichiers qui nécessite toujours une défragmentation manuelle. Peut-être est une solution de rechange?
Mise à jour: Voici ce qui est lent selon mes observations. Je suis en train de construire / empaqueter un projet, ce qui signifie beaucoup d'opérations de lecture / écriture sur le disque. Le système de construction est multiplateforme (Java, Maven), donc je peux effectuer exactement les mêmes actions lors du démarrage sur Ubuntu, par exemple.
Sous Linux, mes builds sont au moins 1/3 plus rapides. D'où la question du système de fichiers. Je suis désolé si c'est déplacé.
Réponses:
Alors que j'aimerais voir quelque chose comme ZFS disponible pour les hôtes Windows, NTFS n'est pas un horrible système de fichiers. Il prend en charge la plupart des fonctionnalités du système de fichiers "modernes" (attributs étendus, journalisation, ACL, vous l'appelez), mais il est gêné par Explorer et la plupart des autres applications ne prenant en charge aucune de ces fonctionnalités.
Une chose qui va absolument tuer ses performances est d'avoir "trop" d'entrées dans un répertoire. Une fois que vous avez transmis quelques milliers d'entrées dans un même répertoire, tout ralentit en une analyse. Littéralement, la machine entière cessera d'attendre que NTFS crée ou supprime des entrées lorsque cela se produit.
J'avais l'habitude de travailler avec une application qui générait des documents HTML pour les assemblages .NET; cela créerait un fichier par propriété, méthode, classe, espace de noms, etc. La machine passait quelques heures pendant la génération bloquée sur NTFS.
En théorie, Windows prend en charge les plugins de système de fichiers, ce qui rendrait possible ZFS, ext3 ou autre (même FUSE). En pratique, les API ne sont pas documentées, vous êtes donc complètement seul.
Maintenant, puisque vous faites du développement Java, pourriez-vous installer un système d'exploitation différent sur votre machine ou utiliser une machine virtuelle par-dessus Windows?
En outre, vous voudrez peut-être essayer des benchmarks de système de fichiers indépendants de la plate-forme (iozone, bonnie ... il y en a probablement plus modernes que je ne connais pas du haut de ma tête, peut-être même quelques-uns écrits en Java) pour voir si c'est en fait, le système de fichiers vous retient, ou si c'est autre chose. Optimisation prématurée et tout ça ...
la source
Je suppose que la vraie solution serait de réécrire votre système de construction afin qu'il utilise l'API du système de fichiers Windows natif, au lieu de l'API Unix (fopen, etc.) elle-même sous le cadre de portabilité. Mais cela ne va pas se produire, donc fondamentalement, vous êtes coincé avec le niveau de performance qu'ils jugent acceptable.
Souvent, lorsque vous utilisez des systèmes non écrits à l'origine pour Windows, vous constatez que la traversée de répertoire a été très mal gérée, alors assurez-vous d'avoir une arborescence de répertoires très plate.
la source
Il existe un système de fichiers pris en charge par le nouveau système d'exploitation Windows ET plus rapide que NTFS. C'est exFAT. Il est possible de l'utiliser pour le lecteur système. Mais on ne sait pas quelles complications cela pourrait avoir.
Vous pouvez certainement l'utiliser pour d'autres partitions. C'est plus rapide avec des opérations de lecture / écriture aléatoires. Parfait pour un SSD par exemple.
la source
opendir()appel (ou équivalent).Avez-vous un programme antivirus en cours d'exécution qui vérifie l'accès / l'écriture pour votre dossier de projet?
La compilation implique la lecture et l'écriture de nombreux petits fichiers en succession rapide, ce qui peut submerger l'antivirus. Ajoutez votre dossier de projet à la liste des dossiers exclus et voyez si cela améliore la situation.
Sous Linux, vous n'avez (probablement) aucun logiciel anti-virus ....
la source