[gull] Nombre maximum de fichiers dans un repertoire

Marc SCHAEFER schaefer at alphanet.ch
Fri Feb 11 15:21:02 CET 2005


On Thu, Feb 10, 2005 at 06:18:31PM +0100, Pierre Keller - BCU Lausanne wrote:
> Quel est le nombre maximum de fichiers qu'on peut mettre dans un répertoire ?
> (sur du ext2).

Un répertoire, sous un système de fichiers vaguement POSIX, est limité
uniquement par le nombre de data-blocks que le répertoire peut contenir.
En bref ce n'est `pas limité'  (ne suis pas allé vérifier dans la
source).

Il y a peut-être une limite plus faible pour le nombre de répertoires
qu'un répertoire peut contenir vu que chaque répertoire contient une
référence comptée (lien dur) au parent.

> L'application que nous sommes en train de convertir d'un serveur Windows +
> Access vers un Linux + MySQL a actuellement env. 6'800 fichiers dans un seul
> répertoire (pas loin de 200 még...). J'ai remarqué que ça posait des problèmes,

Le problème principal sera celui de la performance. Les systèmes de
fichiers POSIX ne se comportent pas très bien avec beaucoup de fichiers
par répertoires (performance).  Une solution serait alors d'appliquer un
patch `balanced tree' à ext2/ext3, ou encore d'utiliser une version non
dangereuse de reiserfs -- un système de fichiers optimisé pour ce cas de
figure.

Alternativement, si l'application peut être réécrite, il pourrait être
intéressant de répartir ces fichiers dans divers répertoires, un peu
comme le cache de squid.

Il y a quelques années quelqu'un avait écrit un module empilable (FIST)
qui permettait de monter un système de fichiers virtuel, utilisant un
autre comme base (ext3, ext2, etc) et gérant automatiquement une telle
répartition.

> p. ex. la commande "cp *" ne marche plus (apparemment elle fait d'abord une
> liste des fichiers, ce qui fait qu'elle n'a plus assez de mémoire). Mais je

Comme cela a été dit ici, cp * est rarement une bonne solution:

   - cela ne copie pas les fichiers qui commencent par un '.'
   - cela nécessite une expansion, par le shell, des noms de fichiers
     (limite de la ligne de commande, performance).

On s'en sort mieux en général en faisant cp -r . /some/other/place

PS: malgré tout, un ext3 sera toujours plus rapide qu'un NTFS même avec
beaucoup de fichiers. Cette distinction est donc très interne `Linux vs
Linux'. ext3 est recommandé plutôt qu'ext2.

PS/2: le seul problème que je vois souvent dans le portage
d'applications MySQL Microsoft Windows vers GNU/Linux est que les noms
de fichiers de base de données et de tables sont exactement les mêmes
que ceux du filesystem: le problème de la non distinction de la casse
des systèmes de fichiers non POSIX se pose.

   Exemple:

      CREATE TABLE MaTable(id INTEGER);
      CREATE TABLE matable(id INTEGER);

   sont équivalents sous NTFS ou VFAT; non équivalents sous ext3 ou
   reiserfs.




More information about the gull mailing list