Quel est le système de fichiers le plus rapide pour les constructions de développeurs ?

Système de fichiers le plus rapide ? tmpfs monté sur toute la RAM disponible, avec noatime set.

Ceci n'est viable que si vous avez une procédure pour vérifier tout ce qui est nécessaire à la construction de votre arbre des sources (puisque le contenu d'un système de fichiers tmpfs disparaîtra au redémarrage), et si les sources et les objets tiennent dans un coin raisonnable de votre RAM disponible (avec suffisamment de reste pour faire tourner votre compilateur et votre linker sans swapping). Ceci dit, il n'y a rien de mieux que de travailler à partir de la RAM pour la vitesse

A la réponse de Michael Dillon, je peux ajouter que vous pouvez créer un système de fichiers ext4 avec quelques options :

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>

dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 vous donne plus d'inodes par taille, utile parce que les environnements de construction créent beaucoup de fichiers.

Pour les sources, il est préférable de disposer d'un support de compression à la volée, ce qui est le suivant Reiser4 o Btrfs . Les deux ne sont pas encore "pour la production", bien que j'aie entendu parler de personnes utilisant les deux FS de manière intensive et heureuse :-)

Le choix suivant (que je fais habituellement) est Reiser3 no Ext3 . Ext3 peut être un peu plus rapide de nos jours, mais Reiser3 n'a pas de limites de temps pour le format i-nodes, supporte le changement en ligne de l'option "data=". Il a le support de "tail" permettant un emballage plus serré des petits fichiers, mais si vous êtes concerné par la vitesse, "notail".

XFS et JFS seraient tous deux pénibles dans le cas de "beaucoup de petits fichiers", surtout si vous devez les rmiser.

(J'ai oublié de mentionner EXT4 : Oui, il est encore plus rapide que EXT3. Mais toutes les limitations d'EXT3 mentionnées ci-dessus sont aussi celles d'EXT4).

Pour beaucoup de petits fichiers, je recommanderais Reiser sur ext3, xfs, jfs..., bien que j'aie entendu dire que ext4 est beaucoup mieux (c'est-à-dire l'opposé de ce que dit poise) que ses incarnations précédentes pour ce modèle d'accès.

Reiser repousse une grande partie de la structure des fichiers vers le haut de l'arbre des inodes, ce qui lui permet de fonctionner très bien lorsqu'il s'agit de petits fichiers.

Cependant, les différences de comportement entre les principaux systèmes de fichiers sont relativement faibles par rapport aux avantages que vous obtiendrez en ayant suffisamment de mémoire physique pour mettre en cache/buffer efficacement.

et d'analyser les répertoires pour voir quels fichiers ont été modifiés.

C'est une mauvaise façon de résoudre le problème, même si elle est relativement simple. Si c'est si important, pensez à écrire un fichier inotify pour indexer les mods.

Par contre, si vous utilisez un SSD flash (qui vous donnera des temps de recherche très bas), je vous recommanderais d'utiliser un fs qui distribue les écritures plus efficacement pour des raisons de longévité - par exemple JFFS2.