Système de fichier pour spool de news

Le
Yves Lambert
Bonjour,

J'utilise leafnode

J'ai ça :

/var/spool est en ext3

$ df -i /var/spool
Sys. de fich. Inodes IUtil. ILib. %IUti. Monté sur
/dev/hdb14 820896 820798 98 100% /var/spool

$ df /var/spool
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/hdb14 6459428 4214968 1916336 69% /var/spool

La partition a l'air saine et elle n'est remplie qu'à 70%

Je présume (je peux me tromper) leafnode génère beaucoups de liens,
donc occupe beaucoup d'inodes et la taille moyenne des fichiers est trop
petite pour ext3.

Dans ce cas, quel système de fichier vaudrait mieux pour ce type d'usage ?

j'xposte sur fcys et fcolc et propose le suivi sur ce dernier
--

http://myurl.in/chocolat
http://myurl.in/iff
200 news-1.free.fr (13-2) NNRP Service Ready - newsmaster@proxad.net
(posting ok)
500 What?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #1903403
Yves Lambert wrote in message
Dans ce cas, quel système de fichier vaudrait mieux pour ce type d'usage ?


Pour ça, c'est ReiserFS qui est toujours conseillé.

F. Senault
Le #1903400

Dans ce cas, quel système de fichier vaudrait mieux pour ce type d'usage ?


Je sais bien qu'on ma regardé de travers la fois où j'ai suggéré ça,
mais la plupart des systèmes de fichiers permettent de déterminer la
densité d'inodes sur un filesystem. A partir de là, tu peux reformatter
ta partition en prévoyant 2 ou 4* plus d'inodes et tu devrais être
tranquille.

(Je laisse sur fcolc, mais je ne le lis pas.)

Fred
--
Notre père qui êtes aux cieux Accordez nous une heure ou deux Pour
glisser sur la tranche des lames Mais sans bien sûr blesser les âmes
Maria, sors des décombres Recommence à bouger ton ombre...
Danse sur le feu Maria ! (Noir Désir, Danse sur le feu Maria)

Yves Lambert
Le #1903362
tu peux reformatter
ta partition en prévoyant 2 ou 4* plus d'inodes et tu devrais être
tranquille.


J'ai finalement opté pour reiserfs. J'ai sauvegardé la partition et je
l'ai restaurée. Je n'ai pas l'impression d'avoire perdu des fichiers à
la restauration, et là il y a un truc et demi bizarre :

J'avais (en ext3)
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/hdb14 6459428 4214968 1916336 69% /var/spool

Maintenant j'ai :
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/hdb14 6562288 2839808 3722480 44% /var/spool

Il semblerait que les hardlink en ext3 occupent non seulement 1 inode
mais aussi un bloc. J'ai en tout cas apparamment beaucoup plus de place.

Par contre gnu df n'aime pas reiserfs :

Sys. de fich. Inodes IUtil. ILib. %IUti. Monté sur
/dev/hdb14 0 0 0 - /var/spool

Je n'ai pas d'info sur les inodes...

(Je laisse sur fcolc, mais je ne le lis pas.)


Je xposte sur fcus vu que ce sont suirtout des newsmasters qui m'ont
répondu (pas étonnant vu la question) et je mets le suivi sur fcolc.


--

http://myurl.in/chocolat
http://myurl.in/iff
200 news-1.free.fr (13-2) NNRP Service Ready -
(posting ok)
500 What?

Nicolas George
Le #1903361
Yves Lambert wrote in message
Il semblerait que les hardlink en ext3 occupent non seulement 1 inode
mais aussi un bloc.


Non, pas du tout. Tu peux le vérifier par exemple avec :

echo foo > bar; df .; ln bar bar2; df .

J'ai en tout cas apparamment beaucoup plus de place.


C'est lié au fait que ReiserFS alloue l'espace beaucoup plus finement. Ext3
alloue par blocs de 4 ko, donc un fichier de 5 ko en occupe 8. Tu avais dans
l'original environ 820 000 fichiers ; si on compte en moyenne 2 ko perdus
par fichier, ça fait 1,6 Go, ce qui n'est pas loin des 1,72 Go que tu
récupères.

Par contre gnu df n'aime pas reiserfs :

Sys. de fich. Inodes IUtil. ILib. %IUti. Monté sur
/dev/hdb14 0 0 0 - /var/spool

Je n'ai pas d'info sur les inodes...


Il n'y a pas de table d'inodes séparée en ReiserFS, donc pas de limitation.
Du coup, pas de statistiques non plus.

Nicolas S.
Le #1903360
Nicolas George
J'ai en tout cas apparamment beaucoup plus de
place.


C'est lié au fait que ReiserFS alloue l'espace beaucoup plus
finement. Ext3 alloue par blocs de 4 ko, donc un fichier de 5 ko en
occupe 8. Tu avais dans l'original environ 820 000 fichiers ; si on
compte en moyenne 2 ko perdus par fichier, ça fait 1,6 Go, ce qui
n'est pas loin des 1,72 Go que tu récupères.


La différence restante pouvant s'expliquer en bonne partie par la
fragmentation de l'ancien système de fichiers.

--
Nicolas S.


Nicolas George
Le #1903359
"Nicolas S." wrote in message
La différence restante pouvant s'expliquer en bonne partie par la
fragmentation de l'ancien système de fichiers.


Euh... Non, pas du tout. La fragmentation fait perdre de la vitesse, mais
absolument aucune place..

Nicolas S.
Le #1903357
Nicolas George
Euh... Non, pas du tout. La fragmentation fait perdre de la vitesse,
mais absolument aucune place..


Si un fichier est écrit dans des blocs non-contigus, il faut bien
spécifier l'adresse du bloc suivant en fin de bloc et à la place
d'éventuelles données, non?


--
Nicolas S.

Yves Lambert
Le #1903356

La différence restante pouvant s'expliquer en bonne partie par la
fragmentation de l'ancien système de fichiers.


Euh... Non, pas du tout. La fragmentation fait perdre de la vitesse, mais
absolument aucune place..


C'est clair, quelque soit la taille des fichiers, avec des blocs de 4K
on perd 2K en moyenne si les tailles sont réparties uniformément entre
n×4K et (n+1)×4K alors que si la taille des block est de 1K on ne perd
que 512 octets en moyenne (j'ai bon ?). Toujours dans l'hypothèse de la
répartition uniforme, on devrait pouvoir dédier la taille moyenne des
fichiers... et de là en négligeant les autres fichiers de la partition,
le nombre moyen de crosposts :o) (valable uniquement sur les groupes ou
je suis abonné)

soit n la taille moyenne des fichiers (en Ko)

K = (nb de block 1K occupés avec ReiserFS)/(nb de blocks occupé avec ext)
(n+1/2)/(n+2)=K

n>0 => n+1/2=(n+2).K
n=(2*K-1/2)/(1-K)

K(39808/4214968

n = 2.5976K (un peu moins que les 3K annoncé, jusqu'ici c'est cohérent...

Chaque fichier occupait *en moyenne* 4.5976 blocs (n+2) et occupe
maintenant 3,0976 blocs en moyenne (2,5976+0,5 (Toujours dans
l'hypothèse d'une répartition uniforme. S'il faut faire une gaussienne,
je sèche parce que je ne vois pas comment passer au log)

J'aurais donc environ 916780 messages de news (qui occupaient 4,5K
chacun et faisaient 2,6K en moyenne) comment est-ce possible avec
seulement 800 0000 inodes ????



--

http://myurl.in/chocolat
http://myurl.in/iff
200 news-1.free.fr (13-2) NNRP Service Ready -
(posting ok)
500 What?


Nicolas George
Le #1903355
"Nicolas S." wrote in message
Si un fichier est écrit dans des blocs non-contigus, il faut bien
spécifier l'adresse du bloc suivant en fin de bloc et à la place
d'éventuelles données, non?


Je ne sais pas comment fait ReiserFS au juste, mais les filesystems Unix
traditionnels, et Ext2/Ext3, stockent le numéro de chaque bloc, qu'il soit
contigu au précédent ou pas.

Nicolas George
Le #1903351
Yves Lambert wrote in message
C'est clair, quelque soit la taille des fichiers, avec des blocs de 4K
on perd 2K en moyenne si les tailles sont réparties uniformément entre
n×4K et (n+1)×4K alors que si la taille des block est de 1K on ne perd
que 512 octets en moyenne (j'ai bon ?).


Ce n'est pas tout à fait vrai. C'est ce qu'on perd par fragmentation
interne (quand on parle de fragmentation tout court, c'est la fragmentation
externe). Mais on perd aussi de la place avec l'adressage des blocs.

En Ext3 avec des blocs de 4 ko, on ne perd rien jusqu'à 48 ko (les pointeurs
sont de toutes façons dans l'inode), puis 4 octets par bloc pour les 4 Mo
suivants (soit 1/1024), et un poil plus (1 octet par méga-octet, puis encore
1 octet par giga-octet) ensuite. Avec des blocs d'1 ko, on tombe à 4 octets
perdus pour chaque kilo-octet utilisé.

Mais ReiserFS ne fonctionne pas exactement comme ça. Je ne sais pas quel est
son mode de fonctionnement exact, mais il n'alloue pas par blocs entiers.
Donc ton calcul ne marche pas.

Publicité
Poster une réponse
Anonyme