$ 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
--
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
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)
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)
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
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.
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.
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.
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.
Yves Lambert wrote in message <ga8nt4xmda.ln2@usine-a-gaz.bidart.net>:
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.
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.
Nicolas George <nicolas$ a écrit:
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 <nicolas$george@salle-s.org> a écrit:
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.
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
"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." wrote in message
<20071007180617.0db42bb0.ni.s-factice@laposte.net>:
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..
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.
Nicolas George <nicolas$ a écrit:
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.
Nicolas George <nicolas$george@salle-s.org> a écrit:
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?
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
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 ????
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 ????
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 ????
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 S." wrote in message
<20071008000344.ff6c27fe.ni.s-factice@laposte.net>:
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.
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
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.
Yves Lambert wrote in message <iv4ot4xrvb.ln2@usine-a-gaz.bidart.net>:
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.
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.