On Wed, Mar 15, 2006 at 09:39:19AM +0100, Frederic Schutz wrote: > >Une autre possibilité est que les blocs de données soient fragmentés (au > >sens FFS/BSD: un bloc de données contient les données de plusieurs > >fichiers, car leur taille totale est plus petite que la taille > >d'allocation, usuellement 4 kilobytes avec ext2/ext3 et une grosse > >partition). Je ne savais pas que ext2/3 supportaient les fragments. > > Est-ce que dans ce cas là le fs pourrait décider de sauvegarder 2 copies > de mêmes données de 2 façon différentes ? La diminution de taille est > quand même de ~25%, donc pas seulement un ou deux blocs qui ont changé.
oui, suivant l'ordre de création, mais à ma connaissance (et dumpe2fs le confirme) avec ext3 frag_size == block_size, donc pas de `fragments' (sens BSD/FFS) avec ext3. > C'est le même fs, même répertoire. Mais 'du --apparent-size' retourne la > même valeur pour les deux répertoires (9 Mb environ). Donc un problème d'arrondi de bloc, de cause indéterminée pour le moment. cd dir_1 && find . -ls | sort > ../list_1 cd ../dir_2 && find . -ls | sort > ../list_2 cd .. && diff list_1 list_2 > Normalement pas. Mais le répertoire original venait d'un fichier tar > (que je n'ai plus malheureusement); peut-être tar a-t-il extrait les > fichiers d'une façon "étrange", qui n'est pas repliquée lors d'une copie ? Non, tar n'est pas étrange (sauf une version Mac OS X peut-être). tar ne supporte que les données et les méta-données POSIX simples (pas d'ACL, d'attributs étendus par défaut). Il a certes une option --sparse, mais faut pas l'utiliser. > >Ah, et cp déréférence, par défaut, les liens symboliques, `-a' pour > >copier le lien lui-même. > > Mais ça devrait aussi augmenter la taille, pas la diminuer ? sauf si le nom du lien < données du fichier (quadricapillosection). _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
