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.
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
