Bonsoir,

Mon prochain Inn en cours de montage utilisera CNFS. Comme je ne connais
pas trop cette methode de stockage, je m'en remets a vous.

Je cherche a savoir si il vaut mieux creer une classe par hierarchie et je
cherche a savoir si il est de coutume d'avoir un "gros" cyclic par classe
ou bien plusieurs petits. Par exemple avoir X cyclic de 1Go plutot qu'un
seul cyclic de X Go.

At-on la possibilite d'ajouter des cyclic a un meta au cours de la vie du
serveur ou bien est-ce figee ?

Voila pour l'instant.

Merci pour vos reponses

Xavier Maillard écrivait :

> Mon prochain Inn en cours de montage utilisera CNFS. Comme je ne
> connais pas trop cette methode de stockage, je m'en remets a vous.
>
> Je cherche a savoir si il vaut mieux creer une classe par hierarchie

En découpant chaque hiérarchie ça permet de mieux maîtriser la
rétention, simplement en jouant sur la taille des buffers.

> et je cherche a savoir si il est de coutume d'avoir un "gros" cyclic
> par classe ou bien plusieurs petits. Par exemple avoir X cyclic de 1Go
> plutot qu'un seul cyclic de X Go.

Avec plusieurs cycliques on peut les mettre sur des disques différents.

> At-on la possibilite d'ajouter des cyclic a un meta au cours de la vie
> du serveur ou bien est-ce figee ?

On peut en rajouter sans problème. Faut quand même arrêter le serveur
pendant l'opération, bien sûr.

Le Vendredi 26 août 2005 à 22:40 UTC, Patrick Lamaizière écrivait sur
fr.comp.usenet.serveurs :

>> At-on la possibilite d'ajouter des cyclic a un meta au cours de la vie
>> du serveur ou bien est-ce figee ?
>
> On peut en rajouter sans problème. Faut quand même arrêter le serveur
> pendant l'opération, bien sûr.

Il faut arreter et redémarrer le serveur parce que cycbuff.conf n'est
lu qu'au démarrage de INN.
Sinon, pour créer le buffer, modifier cycbuff.conf on peut le faire
pendant que INN tourne.
Et le message 'innd: CNFS-sm No magic found for cycbuff...' au
redémarrage est normal.

Voir le man cycbuff.conf
<http://www.eyrie.org/~eagle/software/inn/docs-2.4/cycbuff.conf.html>

@+
--
> Quelqu'un aurait-il une solution pour réinitialiser un MBR
Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bs=512k count=1 (sous Linux)
-+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-

Le Vendredi 26 août 2005 à 20:48 UTC, Xavier Maillard écrivait sur
fr.comp.usenet.serveurs :

> Je cherche a savoir si il vaut mieux creer une classe par hierarchie

Ça ça dépend vraiment de ce que tu veux faire.
Comme l'expire est cyclique et dépend de la taille du buffer, je pense
qu'il vaut mieux séparer les hierarchie à fort trafic pour éviter un
expire trop court.
(ce n'est que mon avis)
Personnelement, c'est vers cette option que je m'oriente.

> et je cherche a savoir si il est de coutume d'avoir un "gros" cyclic
> par classe ou bien plusieurs petits. Par exemple avoir X cyclic de
> 1Go plutot qu'un seul cyclic de X Go.

Si inn est compilé avec le support des gros fichiers pas de limitation
de taille (sauf celle du système). Sinon il me semble que la taille
des buffers doit être inférieure à 2 GB.

> At-on la possibilite d'ajouter des cyclic a un meta au cours de la vie du
> serveur ou bien est-ce figee ?

Je trouve que c'est tout l'interret de la méthode.
Inutile de redimensionner le spool, il suffit de rajouter des buffers
pour augmenter la capacité du spool.

@+
--
> Quelqu'un aurait-il une solution pour réinitialiser un MBR
Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
dd if=/dev/zero of=/dev/hda bs=512k count=1 (sous Linux)
-+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-

On Sat, 27 Aug 2005 05:41:35 +0000, Gérald Niel wrote:

>> et je cherche a savoir si il est de coutume d'avoir un "gros" cyclic
>> par classe ou bien plusieurs petits. Par exemple avoir X cyclic de
>> 1Go plutot qu'un seul cyclic de X Go.
>
> Si inn est compilé avec le support des gros fichiers pas de limitation
> de taille (sauf celle du système). Sinon il me semble que la taille
> des buffers doit être inférieure à 2 GB.

En fait j'ai l'impression que cette limitation n'affecte que le cyclic en
mode block (solution que j'ai retenue)

A++

Gérald Niel écrivait :

>> On peut en rajouter sans problème. Faut quand même arrêter le serveur
>> pendant l'opération, bien sûr.
>
> Il faut arreter et redémarrer le serveur parce que cycbuff.conf n'est
> lu qu'au démarrage de INN.
> Sinon, pour créer le buffer, modifier cycbuff.conf on peut le faire
> pendant que INN tourne.
> Et le message 'innd: CNFS-sm No magic found for cycbuff...' au
> redémarrage est normal.

J'avais modifié storage.conf avant de mettre à jour cycbuff.conf et de
créer les buffers. Je pensais qu'il ne lisait storage.conf qu'au
démarrage. INN n'était pas très content.

On Sat, 27 Aug 2005 19:36:50 +0200, F. Senault wrote:

> J'ajouterais que certains groupes (je pense à nanae et nanau) sont très
> sensibles à des attaques par flood, et que CNFS est très sensible à
> cela. Ca évite de se retrouver avec trois jours de fr.* parce qu'un
> clampin à posté 100k messages sur nanae.

Tu peux expliciter un peu plus ? En quoi CNFS est plus sensible ? En fait
le tradspoll, c'est ce qu eje pratiquais avant mais:

1. mes inodes ne sont pas extensibles
2. expire et expirover sont tres pompeux (charge machine trop elevee)

Bref, CNFS en block device, j'y vois que des avantages pour le moment:

1. rapide (tres rapide)
2. plus de "gachis" d'inodes
3. expire tres simple et "naturel"
4. tres peu consomateurs en CPU et RAM

Xavier Maillard écrivait :

> On Sat, 27 Aug 2005 19:36:50 +0200, F. Senault wrote:
>
>> J'ajouterais que certains groupes (je pense à nanae et nanau) sont
>> très sensibles à des attaques par flood, et que CNFS est très
>> sensible à
>> cela. Ca évite de se retrouver avec trois jours de fr.* parce qu'un
>> clampin à posté 100k messages sur nanae.
>
> Tu peux expliciter un peu plus ? En quoi CNFS est plus sensible ?

C'est simplement que les 100K du clampin ont fait avancer le pointeur du
buffer cyclique d'autant. Ce qui réduit la rétention.

Chez moi j'ai mis un petit buffer cyclique pour stocker control.* et
éviter ça lors de vagues de spams + les cancels qui suivent. Je vais y
mettre nanae et nanau aussi.

Le 27 août 2005 à 21:02, Xavier Maillard a écrit :

> On Sat, 27 Aug 2005 20:35:31 +0200, Patrick Lamaizière wrote:

>>> Tu peux expliciter un peu plus ? En quoi CNFS est plus sensible ?
>>
>> C'est simplement que les 100K du clampin ont fait avancer le pointeur du
>> buffer cyclique d'autant. Ce qui réduit la rétention.
>>
>> Chez moi j'ai mis un petit buffer cyclique pour stocker control.* et
>> éviter ça lors de vagues de spams + les cancels qui suivent. Je vais y
>> mettre nanae et nanau aussi.
>
> Ah ben oui Perso j'ai cree un buffer dedie pour control, je rajouterai
> les autres au cas ou. 100k sr un truc de 2Go...

100k, c'est pour 100.000 articles, heing. 2Go, ça représente, au nez,
500.000 d'articles. Le zozo vient de diminuer (si ses articles sont de
taille standard) ta rétention d'un quart.

Et là, c'est dans un groupe classique, pas des cancels. Les cancels,
s'ils suivent, vont évidemment diminuer une fois de plus d'autant ta
rétention.

Fred
--
Don't you die on me
You haven't made your peace
Live life, breathe, breathe
(Within Temptation, Dark Wings)

Xavier Maillard écrivait :

> Ah ben oui Perso j'ai cree un buffer dedie pour control, je
> rajouterai les autres au cas ou. 100k sr un truc de 2Go...

C'est vraiment au cas où en effet, je n'ai que 57 Mo en 4 mois pour
control.*. Mais bon c'est toujours ça de pris.

On Sat, 27 Aug 2005 21:22:10 +0200, F. Senault wrote:

> Le 27 août 2005 à 21:02, Xavier Maillard a écrit :

>> Ah ben oui Perso j'ai cree un buffer dedie pour control, je rajouterai
>> les autres au cas ou. 100k sr un truc de 2Go...
>
> 100k, c'est pour 100.000 articles, heing. 2Go, ça représente, au nez,
> 500.000 d'articles. Le zozo vient de diminuer (si ses articles sont de
> taille standard) ta rétention d'un quart.
>
> Et là, c'est dans un groupe classique, pas des cancels. Les cancels,
> s'ils suivent, vont évidemment diminuer une fois de plus d'autant ta
> rétention.

Note que je ne te contredis pas, je disais simplewent que j'etais plus ou
moins "protege" contre ce genre de chose. Enfin au moins le gus ne
fichera pas le bins dans mes hierarchies.

Ca me fait penser qu'il va falloir que je mette en place une strategie de
filtrage.

Xavier Maillard wrote:
> 1. mes inodes ne sont pas extensibles
> 2. expire et expirover sont tres pompeux (charge machine trop elevee)

Et timecaf, il sent le pâté ? :p

> 1. rapide (tres rapide)
> 2. plus de "gachis" d'inodes

timecaf est aussi rapide, et ne consomme pas beaucoup d'inodes.

> 3. expire tres simple et "naturel"

Euh, sauf qu'il faut expirer l'history et l'overview quand même (ca peur
être long). Et là aussi, le timecaf est aussi "naturel" (chaque morceau
est effacé au fil du temps)

> 4. tres peu consomateurs en CPU et RAM

Par plus/moins pour timecaf.

Le seul avantage de cnfs, c'est que la taille est définie de manière
stricte (pas de risques de débordements)

Le 28 août 2005 à 09:50, Xavier Roche a écrit :

> Gérald Niel wrote:
>> Justement, je me posais la question par rapport à CNFS. Comment ça se
>> passe ?
>
> Les méthodes d'overview sont tradindexed, buffindexed et ovdb. ovdb a
> l'air plus sexy, mais il n'a pas été "vraiment testé à fond" (dixit la
> doc de INN), donc j'ai eu un peu peur de le mettre en place en
> production ..

J'ai utilisé ovdb à mes débuts, et je n'ai pas eu à m'en plaindre.
C'est peut-être un poil plus sensible aux coupures - il me semble avoir
au moins une fois complètement trashé mon overview, mais à part ça, ça
marchait.

> de plus il semble que le gros du code ait été fait
> récemment sur tradindexed, qui semble être le seul vraiment utilisé.

AMHA, buffindexed doit être pas mal utilisé aussi, pour les plus gros
sites.

> Et puis il y a l'history, qui est un simple fichier indexé, et qui peut
> aussi faire mouliner INN pas mal ..

Mais c'est inévitable (à moins de régler la durée de rétention de
l'history, mais attention aux doublons).

Au fait, penser aussi à avoir un système de disques (et de fichiers)
convenable, ça peut énormément changer, évidemment.

Fred
--
I've been crawling on my belly, clearing out what could've been. I've
been wallowing in my own chaotic and insecure delusions. I wanna feel
the change consume me, feel the outside turning in. I wanna feel the
metamorphosis and cleansing I've endured within (Tool, Forty-Six & 2)

On 28 Aug 2005, F. Senault wrote:

> Au fait, penser aussi à avoir un système de disques (et de
> fichiers) convenable, ça peut énormément changer, évidemment.

Je plussoie nerveusement. Un peu de RAM, une CPU potable et de
bons disques --i.e rapides, et ce qui était un soucis redevient
acceptable.
--
Hacker Wonderland Xavier Maillard| "Stand Back! I'm a programmer!"
..0. zedek@gnu-rox.orgz|
...0 (+33) 326 770 221 | Webmaster, emacsfr.org
000 PGP : 0x1E028EA5 | Membre de l' APRIL

F. Senault wrote:
> Au fait, penser aussi à avoir un système de disques (et de fichiers)
> convenable, ça peut énormément changer, évidemment.

Ouais, c'est clair. Lors de mon dernier crash de news, la filesystem
était totalement à la rue, à cause d'une fragmentation gigantesque.
C'est là aussi que CNFS peut sauver la vie, humm.

Faire donc gaffe à tuner si besoin la filesystem pour pré-réserver des
blocs assez grands, ou choisir une filesystem solide.

Le Sun, 28 Aug 2005 12:04:07 +0200, Xavier Roche écrivit:
> Ouais, c'est clair. Lors de mon dernier crash de news, la filesystem
> Faire donc gaffe à tuner si besoin la filesystem pour pré-réserver des
> blocs assez grands, ou choisir une filesystem solide.

Pourquoi filesystem au féminin ? On dit *un* système de fichiers,
donc même avec l'anglicisme, ça devrait rester masculin, non ?

Arnaud.
--
Perso: http://launay.org/blog/
Consulting: http://www.cusae.com/
Hébergement: http://www.nocworld.com/