[gull] Taille de fichier dans un LVM

Philippe Ney philippe at overcool.ch
Sat Feb 2 17:46:19 CET 2008


> > > > La seule autre différence que je vois est que le deuxième système est un
> > > > 64 bits alors que le premier était un 32 bits. Bien que je doute que ceci
> > > > ait une influence sur la taille d'un fichier.
> > > > 
> > > > Merci d'avance pour vos pointeurs.
> > > 
> > > Est-ce qu'on peut voir le résultat de "tune2fs -l" sur les deux systèmes
> > > de fichiers?
> > 
> > Les voilà :
> > 
> > Serveur 1 :
> > ---------------------------
> ...snip...
> > Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
> > Default mount options:    (none)
> ...snip...
> > 
> > Serveur 2 : 
> > ---------------------------
> ...snip...
> > Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
> > Default mount options:    user_xattr acl
> ...snip...
> 
> Je ne sais pas, mais je soupçonne qu'il y'a des extended-attributes
> utilisées dans le nouveau système de fichiers qui prendre un block extra
> par inode.  Est-ce que tu utilises un logiciel d'indexation comme Beagle
> ou Tracker?

Je n'utilise pas de logiciel d'indexation.

Et d'après ce que j'ai vu, la taille du inode (128 bytes) est trop petite
pour contenir les attributs étendus.

Je n'utilise pas d'attributs étendus, ou alors à l'insu de mon plein gré.
Est-ce que le seul fait de monter le fichier avec le support pour xattr
réserve automatiquement un block de plus afin de pouvoir les sauver au cas
où ?

Je vais investiguer et vous tiendrai au courant si je trouve quelque chose
d'intéressant.

Merci et bon week-end,
Philippe



More information about the gull mailing list