On Fri, Feb 11, 2005 at 11:49:30AM +0100, schaefer wrote: > 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).
(petit compl�ment: le nombre d'objets du syst�mes de fichiers est limit� par le nombre d'inodes, mais avec les disques modernes et sans modifier le -i au mke2fs on en a souvent des millions). > qu'un r�pertoire peut contenir vu que chaque r�pertoire contient une > r�f�rence compt�e (lien dur) au parent. pour r�f�rence: nlink_t i_nlink; unsigned short (16 bits sur plateforme ix86), donc 65534 r�pertoires dans un r�pertoire. > 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 J'ajoute que si les donn�es ne font `que' 200 MB (et probablement 200 MB y compris les vides dus � l'organisation de la base en arbre ou structure d�rivant d'un hash) elles tiennent tr�s certainement en m�moire vive. La question de la performance est donc moins importante. > On s'en sort mieux en g�n�ral en faisant cp -r . /some/other/place et un -a si l'on veut garder les permissions (copier depuis CD: les fichiers seront donc read-only). J'ajoute qu'il est en g�n�ral mauvais d'archiver les fichiers en format ISO-9660 (m�me avec extensions RockRidge et/ou Joliet), en raison des limites vues pr�c�demment avec ce fs. tar + gzip est en g�n�ral une bonne solution (sous UNIX). _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
