[gull] Différence taille entre répertoire

[Marc SCHAEFER]

On Tue, Mar 14, 2006 at 06:18:46PM +0100, Frederic Schutz wrote:
> Est-ce que quelqu'un a une idée de pourquoi mon repertoire change de 
> taille après une copie, même si je ne trouve pas de différence entre 
> l'original et la copie ?

Un répertoire POSIX est un fichier dont les blocs de données sont des
entrées de répertoire. Une entrée de répertoire est un nom et un numéro
d'inode (la table fixe des inodes contient les véritables méta-données).

Lorsqu'un répertoire contient beaucoup de fichiers, plus de blocs de
données sont nécessaires.

Il n'y a par défaut pas de `compaction' de répertoire (voir e2fsck(8),
option -D).

Sauf erreur, sauf si tu as énormément de fichiers (style spool de mail
non hiérarchique ou de news), ce n'est pas le problème. Le symptôme
est que la taille du répertoire vue par `ls' est > 4096 bytes.

(c'est un peu différent sur les systèmes de fichiers qui ne suivent pas
le modèle POSIX d'organisation des blocs de données, des pointeurs
d'indirection et autres, parfois pour de bonnes raisons).

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.

Ne pas confondre avec le problème de la `fragmentation': un fichier
étant réparti sur des blocs distants car il n'y a plus assez de blocs
voisins: ext2/3 évite cela (tant qu'il reste assez de place) par
préallocation ... je ne sais pas si cela peut aussi expliquer ce que tu
vois.

Si tu copies des données d'un fs à l'autre avec une autre taille de
bloc, ou carrément une autre organisation / un autre filesystem,
il y aura des arrondis.  Faire un `du --apparent-size'
(en bytes, plutôt qu'en blocks).

Si la taille *augmente* avec la copie, cela peut être dû à la présence
de `sparse files' (des fichiers pleins de zéros dont les zéros ne sont
pas encore alloués: p.ex. base de données indexée, fichier projeté en
mémoire avec mmap(2), etc).

Une dernière possibilité serait que les méta-données contiennent des
ACLs ou autres resource forks (sisi, c'est implémentable en ext2/ext3,
via les extended attributes) qui ne seraient pas copiés par `cp',
mais cela me semble peu probable.

Ah, et cp déréférence, par défaut, les liens symboliques, `-a' pour
copier le lien lui-même.