Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Quel système de fichier ?

0 views
Skip to first unread message

Yves Lambert

unread,
Dec 27, 2009, 4:09:53 PM12/27/09
to
In article <hh5mjd$2kao$1...@news.davenulle.org>,
Patrick Lamaizi�re <adr...@est.invalid> writes:
> Yves Lambert :
>
>> je vais installer un �tradspool� sur un disque IDE de 6.4G en local qui
>> ne va sans doute pas faire long feu :) bon il est presque neuf, pas de
>> mauvais secteur, tout va bien pour l'instant...
>>
>> Quel syst�me de fichier me conseillez vous d'installer dessus ?
>
> UFS2 ou UFS2 ou UFS2
> Y'a pas vraiment le choix ici...

OK �a vaut si je suis sous BSD :) sous linux l'�quivalent doit plus ou
moins etre ext3, non ? ... vu que je jette mon d�volu sur un
biprocesseur, a priori linux est le syst�me le mieux adapt�.


> Tu peux param�trer le FS pour avoir environ un inode pour 4Ko (taille
> moyenne d'un article de m�moire) et �viter de tomber � cours d'inode.

Et si je prend ext3 il faut que je le tune en effet � la cr�ation.

dans /etc/mke2fs.conf le type news est juste d�fini par :
news = {
inode_ratio = 4096
}
�a corrobore... bon avec des en-tetes de 10Ko (Face et autres) �a sort
:)

Je lis �a dans le man mk2fs :

-i octets_par_inode
Sp�cifier le ratio octets/inode. mke2fs cr�e une inode
pour chaque octets_par_inode octets d'espace sur le disque.
Plus le ratio octets_par_inode est �lev�, moins on cr�e
d'inodes. Cette valeur ne devrait g�n�ralement pas �tre
inf�rieure � la taille des blocs du syst�me de fichiers
car il serait alors cr�� plus d'inodes que ce qui pourrait
�tre utilis�. Sachez qu'il n'est pas possible d'augmenter
le nombre d'inodes d'un syst�me de fichiers apr�s sa cr�ation,
donc faites attention � choisir une valeur correcte pour ce
param�tre.

J'aime bien le �g�n�ralement�. en effet, dans le cas de leafnode, je ne
sais pas si c'est le cas d'autres spools, avec des blocs de 4K (la
valeur par d�faut), si la plupart des articles tiennent dans un bloc,
alors on a int�ret � avoir au moins deux fois plus d'inodes que de blocs,
vu que les articles sont stock�s pour �tre retrouv� rapidement par mid,
je suppose et sous la forme d'un hardlink dans le r�pertoire de leurs
forums respectifs. Soit deux inodes occup�s par bloc, ou plus pour les
articles xpost�s. La valeur par d�faut n'est pas renseign�e dans le man
mais d�termin�e par l'option -T (/etc/mke2fs.conf) :/

Je me demande si je n'ai pas int�ret soit � prendre une taille de bloc
tr�s petite, ce qui optimisera l'espace disque et un nombre
d'octet/inode de la taille du bloc, soit laisser mk2fs choisir la taille
du bloc optimale (*) et prendre un ratio de 4096 (je suis sage)

(*) -b taille_bloc[...] Si taille_bloc est n�gatif, mke2fs utilisera des
heuristiques pour d�terminer la taille appropri�e, en
imposant que la taille soit au moins de taille_bloc
octets. C'est utile pour certains p�riph�riques
physiques qui n�cessitent que la taille de bloc soit
un multiple de 2 ko.


> Snon un fs qui est optimal pour plein de petit fichiers ?

Voila, c'est �a :) Je cherche un filesystem qui est optimal pour plein
de petits fichiers. Je fais suivre sur fcold si quelqu'un a une id�e
autre que ext* avec ce que debian met dans le type "news" sout le ratio
de 4096.

Avec reiserfs il n'y a pas le probl�me des inodes ; mais est il pour
autant optimal ?

xpost fcus/fcold suivi fcold.

--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer

Sergio

unread,
Dec 28, 2009, 3:22:31 AM12/28/09
to
Yves Lambert a �crit :

>>> je vais installer un �tradspool� sur un disque IDE de 6.4G en local qui
>>> ne va sans doute pas faire long feu :) bon il est presque neuf, pas de
>>> mauvais secteur, tout va bien pour l'instant...

>>> Quel syst�me de fichier me conseillez vous d'installer dessus ?
>> UFS2 ou UFS2 ou UFS2
>> Y'a pas vraiment le choix ici...
>
> OK �a vaut si je suis sous BSD :) sous linux l'�quivalent doit plus ou
> moins etre ext3, non ? ... vu que je jette mon d�volu sur un
> biprocesseur, a priori linux est le syst�me le mieux adapt�.

?? En quoi Linux serait plus adapt� au biprocesseur qu'un autre Unix (comme BSD ou d'autres) ?

>> Tu peux param�trer le FS pour avoir environ un inode pour 4Ko (taille
>> moyenne d'un article de m�moire) et �viter de tomber � cours d'inode.
>
> Et si je prend ext3 il faut que je le tune en effet � la cr�ation.

Y'a aussi ext4 et reiserfs pour les amateurs d'exotisme...

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Yves Lambert

unread,
Dec 28, 2009, 8:24:48 AM12/28/09
to
In article <4b386ac7$0$11225$426a...@news.free.fr>,
Sergio <serge....@delbono.net.invalid> writes:


>> OK �a vaut si je suis sous BSD :) sous linux l'�quivalent doit plus ou
>> moins etre ext3, non ? ... vu que je jette mon d�volu sur un
>> biprocesseur, a priori linux est le syst�me le mieux adapt�.
>
> ?? En quoi Linux serait plus adapt� au biprocesseur qu'un autre Unix
> (comme BSD ou d'autres) ?

Bah c'est peut-etre un pr�jug� de ma part finalement... bon on est sur
fcolc, je commence � bien maitriser debian, je suis habitu� � exim qui
n'est pas � ma connaissance bien int�gr� � un autre OS que debian, et
meme si c'est plus facile � param�trer je n'ai pas envie de me lancer
dans la configuration de postfix... plein de raisons d'utiliser plutot
debian...



>>> Tu peux param�trer le FS pour avoir environ un inode pour 4Ko (taille
>>> moyenne d'un article de m�moire) et �viter de tomber � cours d'inode.
>>
>> Et si je prend ext3 il faut que je le tune en effet � la cr�ation.
>
> Y'a aussi ext4 et reiserfs pour les amateurs d'exotisme...

La question (� 5 cent) �tait : quel syst�me de fichier est bien adapt�
pour de nombreux petits fichiers. Pour ext4 le probl�me est le meme que
ext3 � la cr�ation, et ce n'est pas garanti que c'est optimal pour cet
usage (rapidit� d'acc�s etc.) et reiserfs est en effet ce que je m'�tais
propos� d'utiliser mais on m'en a dit pis ue pendre sur fcus
(news:hh8iqv$2ot$5...@news.httrack.net) Pas de meilleure id�e ? Sinon
j'abandonne l'id�e d'utiliser tradspool qui ne pr�sente finalement que
peu d'int�ret.

Elephant Man

unread,
Dec 28, 2009, 8:29:42 AM12/28/09
to
Yves Lambert a �crit le 28/12/2009 14:24 dans
fr.comp.os.linux.configuration :

> on m'en a dit pis ue pendre sur fcus

Je me demande pourquoi tu as fait suivre, en fait, pour le plaisir ?
(Enfin, je suis content que tu sois parvenu � r�gler ton knews.)

Pascal Hambourg

unread,
Dec 28, 2009, 9:12:17 AM12/28/09
to
Salut,

Yves Lambert a ᅵcrit :
>
> J'aime bien le ᅵgᅵnᅵralementᅵ. en effet, dans le cas de leafnode, je ne


> sais pas si c'est le cas d'autres spools, avec des blocs de 4K (la

> valeur par dᅵfaut), si la plupart des articles tiennent dans un bloc,
> alors on a intᅵret ᅵ avoir au moins deux fois plus d'inodes que de blocs,
> vu que les articles sont stockᅵs pour ᅵtre retrouvᅵ rapidement par mid,
> je suppose et sous la forme d'un hardlink dans le rᅵpertoire de leurs
> forums respectifs. Soit deux inodes occupᅵs par bloc, ou plus pour les
> articles xpostᅵs.

Euh, que je sache il ne faut qu'un inode par fichier, quel que soit le
nombre de rᅵfᅵrences (hardlinks) qui pointent dessus.

Yves Lambert

unread,
Dec 29, 2009, 6:07:54 AM12/29/09
to
In article <4b38b2c6$0$17832$426a...@news.free.fr>,

Elephant Man <conano...@gmail.com> writes:
> Yves Lambert a �crit le 28/12/2009 14:24 dans
> fr.comp.os.linux.configuration :

(� propos de reiserfs)


>> on m'en a dit pis ue pendre sur fcus
>
> Je me demande pourquoi tu as fait suivre, en fait, pour le plaisir ?


Explique moi en cas le choix d'un syst�me de fichier optimum pour de
nombreux petits fichiers sur un syst�me linux n'est pas en charte dans
fcolc ? En tout cas c'est l� que je risque de

Ta remarque aurait eu un sens (mais ma r�posne aurait �t� la meme) si le
forum fr.usenet.logiciels existait encore :/ l� elle n'a meme pas de sens.

> (Enfin, je suis content que tu sois parvenu � r�gler ton knews.)

Je n'ai absolument pas r�gl� knews. Je n'ai rien chang� � ses fichiers de
config et je l'appelle pareil. Je n'ai meme pas encore corrig� le bug
alors que je sais pr�cisement ou dans le code il faut taper pour le
corriger. Bientot tu va �crire/croire que c'est � cause de knews que je
n'�cris pas les accents circonflexes :( ben non, c'est la config de mon
clavier qqui d�conne)

C'est pas une question de r�glage de knews c'est une questioon de bug �
corriger pour pouvoir composer en utf8 (g�r� par pratiquement toutes les
applications vi, emacs, xedit (mais il affiche des pat�s meme en iso) et
renvoyer en iso si possible, sinon en utf8. Par ailleurs, le bug de knews
tu ne peux pas t'en rendre compte en lisant mes articles, et le probl�me
d'encodage des articles que j'avais venait d'un souci avec l'�diteur de
texte (Nedit) que j'utilisais, rien � voir avec knews.

En fait quand j'aurai corrig� le bug de knews (ou compens� en utilisant
mime-proxy ou en tapant dans le code), il faudra que je change d'�diteur
de texte ou bien que je corrige le bug de l'�diteur. Les deux se
compensent si ma machine est en iso et non en utf8(*)

(*)et les lecteurs qui n'affichent pas corectement l'utf8 si on ne leur
dit pas que c'est de l'UTF-8 et non de l-utf-8 ou de l'utf8 *sont*
bugu�s (soit le m^eme bug que knews : xnews, soit le meme r�sultat avec
d'autres causes).

Suivi en charte sur fr.comp.usenet.bidule

Yves Lambert

unread,
Dec 29, 2009, 6:21:41 AM12/29/09
to
In article <hhaec1$2qjb$1...@saria.nerim.net>,
Pascal Hambourg <boite-...@plouf.fr.eu.org> writes:

> Euh, que je sache il ne faut qu'un inode par fichier, quel que soit le

> nombre de r�f�rences (hardlinks) qui pointent dessus.

C'est d�j� �a de gagn� :) d�j� un param�tre dont je peux ne pas tenir
compte ceci dit �a ne r�soud pas le probl�me d'optimisation de la
stabilit� et du temps d'acc�s (� une kyrielle de petits fichiers).
je n'ai pas vu de r�glage d'Ext* en ce sens, �a ne veut pas dire
qu'il n'y en a pas, mais s'il n'y en a pas, il existe peut etre un
sgf mieux adpt�.

Emmanuel Florac

unread,
Dec 29, 2009, 7:11:35 AM12/29/09
to
Le Mon, 28 Dec 2009 13:24:48 +0000, Yves Lambert a écrit:

> reiserfs est en effet ce que je m'étais proposé d'utiliser mais on m'en


> a dit pis ue pendre sur fcus

Pour l'utiliser sur plusieurs centaines de machines depuis de longues
années, je peux affirmer en connaissance que reiserfs 3.6 est très bien.

Cependant il est très sensible aux problèmes matériels. Donc si tu as du
très bon matos, pas de problème. Si tu as du PC bas de gamme, de la RAM no
name, des contrôleurs ATA/SATA exotiques, etc, passe ton chemin.

Par contre sur des serveurs bien construits c'est nickel.

--
I have always wished for my computer to be as easy to use as my telephone;
my wish has come true because I can no longer figure out how to use my
telephone.
Bjarne Stroustrup

Yves Lambert

unread,
Dec 29, 2009, 8:45:32 AM12/29/09
to
In article <4b39f1f7$0$20875$426a...@news.free.fr>,
Emmanuel Florac <efl...@imaginet.fr> writes:
> Le Mon, 28 Dec 2009 13:24:48 +0000, Yves Lambert a �crit:
>
>> reiserfs est en effet ce que je m'�tais propos� d'utiliser mais on m'en

>> a dit pis ue pendre sur fcus
>
> Pour l'utiliser sur plusieurs centaines de machines depuis de longues
> ann�es, je peux affirmer en connaissance que reiserfs 3.6 est tr�s bien.
>
> Cependant il est tr�s sensible aux probl�mes mat�riels. Donc si tu as du
> tr�s bon matos, pas de probl�me. Si tu as du PC bas de gamme, de la RAM
> no name, des contr�leurs ATA/SATA exotiques, etc, passe ton chemin.


Je n'ai jamais eu de souci avec reiserfs (si : un bug irreproductible
qui est probablement du � une d�pendance de reiserfsck qui va s'installer
(la d�pendance) dans /usr/lib alors qu'elle devrait rester dans /lib/
debian BTS #537441).
J'ai eu beaucoup plus de soucis avec ext3 (avec pertes de donn�es et
arrachage de cheveux � la clef mais j'en fais un usage beaucoup plus
intensif.


> Par contre sur des serveurs bien construits c'est nickel.

C'est sur un serveur (relativement) bien construit, en scsi ou bien avec
de l'ata (architecture PC) tout ce qu'il y a de plus standard, au cas o�
je pousserai un memtest, mais le point faible, c'est les disques : c'est
de la r�cup�ration et c'est l� que �a risque parait-il de coincer.

J'avais aussi la possibilit� de mettre le serveur sur une ultra10,
mais l� par contre le controleur ATA est un peu exotique :/ � moins d'y
adjoindre un controleur SCSI en PCI �a limite (et puis �a entre
peut-etre dans le etc.) il y a toujouirs la possibilit� (avec reiserfs,
ce n'est pas le cas avec ext3) de mettre le journal de transaction sur
un autre support (faut faire gaffe � l'ordre de montage :) mais �a peut
limiter la casse. Pazr contre, je pr�vois � moyen terme de migrer sur un
d�di� ou un machin qui consomme peu d'�llectricit� chez moi (style bas�
sur intel atom) et l� tout sera standardoide, neuf et nickel.

Il y a un autre bemol, est que je n'ai aucune id�e des performances.
Ceci dit je ne connais pas de meilleure solution, et si j'utilise
reiserfs ce ne sera pas � contrecoeur.

En fait je voudrais savoir ce que je �risque� hors catastrophe :
genre l'augmenntation � l'exponentielle du temps de v�rification
du sgf au montage si j'ai quelques millions de fichier ? ou autres ?

Il y a un autre argument (peut-etre) en d�faveur de reiserfs pour
l'usage que je veux en faire : je peux �ventuellement tol�rer un taux
de perte de fichier (je n'ai pas besoin de cette garantie, elle ne me
gene pas, bien entendu mais son cout oui), par contre je veux optimiser
le temps d'acc�s, de cr�ation et de destruction, l'usage du disque
(pour en prolonger la demi-vie) et l'usage CPU.

Emmanuel Florac

unread,
Dec 29, 2009, 3:14:12 PM12/29/09
to
Le Tue, 29 Dec 2009 13:45:32 +0000, Yves Lambert a écrit:
>
> Je n'ai jamais eu de souci avec reiserfs (si : un bug irreproductible
> qui est probablement du à une dépendance de reiserfsck qui va
> s'installer (la dépendance) dans /usr/lib alors qu'elle devrait rester

> dans /lib/ debian BTS #537441).
> J'ai eu beaucoup plus de soucis avec ext3 (avec pertes de données et
> arrachage de cheveux à la clef mais j'en fais un usage beaucoup plus
> intensif.

J'ai eu de gros problèmes avec différents PC bas de gamme à chipset VIA.
En changeant de carte-mère, plus de problème...
J'ai eu aussi de grosses corruptions sur des contrôleurs RAID qui
flanchaient. Bien entendu le problème était matériel avant tout, c'est
seulement que reiserfs était un peu moins tolérant qu'ext3. Mais dans
l'ensemble j'en suis parfaitement satisfait.

> C'est sur un serveur (relativement) bien construit, en scsi ou bien avec

> de l'ata (architecture PC) tout ce qu'il y a de plus standard, au cas où


> je pousserai un memtest, mais le point faible, c'est les disques : c'est

> de la récupération et c'est là que ça risque parait-il de coincer.

Oui moi aussi j'ai utilisé des disques de récup, et il y a quinze jours
mon PC a vautré lamentablement pour cause de /dev/sda3 illisible... Bon
maintenant j'ai deux disques neufs en RAID-1 :)

> Il y a un autre bemol, est que je n'ai aucune idée des performances.


> Ceci dit je ne connais pas de meilleure solution, et si j'utilise

> reiserfs ce ne sera pas à contrecoeur.

Pour les petits fichiers reiserfs est le meilleur. J'ai migré mon système
de reiserfs à ext4 pour voir, et la performance sur les petits fichiers
(claws-mail :) est atroce : je dirais que mon miroir de 750 Go neufs est
moitié moins rapide que mon vieux 400Go tout seul. Je pense qu'à
l'occasion je reformaterai tout ça en reiserfs :)
En gros fichiers xfs explose tout le monde, ça n'est pas prêt de changer.
Par contre il est clairement peu performant sur les créations/
suppressions de fichiers.

>
> En fait je voudrais savoir ce que je «risque» hors catastrophe : genre

> l'augmenntation à l'exponentielle du temps de vérification du sgf au


> montage si j'ai quelques millions de fichier ? ou autres ?

J'ai eu de grosses corruptions de structure en reiserfs mais je crois
n'avoir jamais perdu de fichiers. Il fallait juste trier dans le /lost
+found :)

> Il y a un autre argument (peut-etre) en défaveur de reiserfs pour
> l'usage que je veux en faire : je peux éventuellement tolérer un taux de


> perte de fichier (je n'ai pas besoin de cette garantie, elle ne me gene
> pas, bien entendu mais son cout oui), par contre je veux optimiser le

> temps d'accès, de création et de destruction, l'usage du disque (pour


> en prolonger la demi-vie) et l'usage CPU.

reiserfs. reiserfs. reiserfs. reiserfs.

Sinon tu peux tester jfs, c'est aussi un bon conpromis. Mais je n'ai pas
beaucoup utilisé.

--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.

0 new messages