Trojan dans Linux

Le 11-12-2009, ? propos de
Re: Trojan dans Linux,
Amandine Parmesan ?crivait dans fr.comp.os.linux.debats :

On Fri, 11 Dec 2009 09:18:15 +0100, Stephan Peccini
<stephan@photonature.fr> wrote:

Le 11/12/2009 07:10, Yliur a écrit :

Dans l'article ils semblent dire qu'en fait la fragmentation c'est pas
grave ? Et que donc tout ce qui a été fait pour produire des
systèmes de fichiers peu fragmentés ne sert à rien ?

Cela fait partie de la ToDo list :
http://www.nilfs.org/en/current_status.html

J'imagine que ça dépend aussi de si on veut plutôt faire des lectures
ou des écritures et du taux d'efficacité du cache système.

Je viens de faire la comparaison avec ext4 et xfs et autant pour mon
usage, nilfs est plus rapide que ext4 autant xfs peut être plus rapide
en écriture et un peu plus lent en lecture. Mais cela n'a rien de
scientifique et je pense que les résultats sont faux dans d'autres
contextes. Tout cela sur un SSD.

Question, est il stable ce nilfs pour de la prod ?

Acteuelement je suis sur : Linux DC2200 2.6.28-16-generic #55-Ubuntu
SMP Tue Oct 20 19:48:32 UTC 2009 x86_64 GNU/Linux

Donc même pas en 2.6.30 mais il est dispo dans les depots.

En prod, je suis resté au 2.6.27.x car j'ai des tas de problèmes avec
les versions plus récentes (problèmes de montées en charge avec des
soft lockups à la chaîne voire des plantages secs). Seules deux machines
tournent chez moi en production avec des 2.6.30.9, mais patchés jusqu'à
la moëlle pour faire tourner correctement le iSCSI en 'target' et
'initiator' (et à cause d'une combre histoire de libpcap dont l'API
a subtilement changée). Les noyaux de la série 2.6.28 et 2.6.29 sont
à mon avis inutilisables en prod sur des serveurs critiques.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Alban Taraire a écrit :

Stephan Peccini wrote:

Un peu en retard (à cause de 6 implants placés ce matin :-) ), je te
donne juste un lien :
http://www.nilfs.org/en/index.html

Pas mal, je connaissais pas. Niveau perfs, ça donne quoi ?

Pour avoir installé mon /home dessus, je peux te dire ce que j'en pense.

Malgré que le principe soit énormément intéressant (Dans mon cas, le
/home est un raid 1, donc NILFS2 ajoute la sécurité en cas "d'erreur
humaine").

J'avais 90 Go de données à recopier. Le raid pointe son nez à près de 80
Mo/s. Il m'a fallu plus de 4 heures pour rapatrier mes données par rsync
(Entre disques SATA). Les perfs paraissent bonnes, au départ (Cela doit
surement provenir de la mise en cache, j'ai 8 Go de ram) mais
s'effondrent par la suite.

Plus de 4 heures pour 90 Go, ça fait tomber les perfs en dessous de 8
Mo/s ... Une cata quoi !

De plus, ce FS maintient une charge permanente sur la machine, avec un
load average avoisinant les 0,40 en permanence sur un Amd x2 6000.

Impossibilité de faire un montage automatique de ce fs au boot.
Pas très important pour un poste 'perso' : [ESC]mount /home[CTRL][D]

Pour l'instant, ce FS n'est pas déclaré stable. Il le dit lors dur
montage, de ne pas y stocker de données critiques.

Bref, la théorie de ce FS est géniale, mais la pratique est toute autre.

Le 11-12-2009, ? propos de
Re: Trojan dans Linux,
NiKo ?crivait dans fr.comp.os.linux.debats :

Alban Taraire a écrit :

Stephan Peccini wrote:

Un peu en retard (à cause de 6 implants placés ce matin :-) ), je te
donne juste un lien :
http://www.nilfs.org/en/index.html

Pas mal, je connaissais pas. Niveau perfs, ça donne quoi ?

Pour avoir installé mon /home dessus, je peux te dire ce que j'en pense.

Malgré que le principe soit énormément intéressant (Dans mon cas, le
/home est un raid 1, donc NILFS2 ajoute la sécurité en cas "d'erreur
humaine").

J'avais 90 Go de données à recopier. Le raid pointe son nez à près de 80
Mo/s. Il m'a fallu plus de 4 heures pour rapatrier mes données par rsync
(Entre disques SATA). Les perfs paraissent bonnes, au départ (Cela doit
surement provenir de la mise en cache, j'ai 8 Go de ram) mais
s'effondrent par la suite.

Plus de 4 heures pour 90 Go, ça fait tomber les perfs en dessous de 8
Mo/s ... Une cata quoi !

De plus, ce FS maintient une charge permanente sur la machine, avec un
load average avoisinant les 0,40 en permanence sur un Amd x2 6000.

Impossibilité de faire un montage automatique de ce fs au boot.
Pas très important pour un poste 'perso' : [ESC]mount /home[CTRL][D]

Pour l'instant, ce FS n'est pas déclaré stable. Il le dit lors dur
montage, de ne pas y stocker de données critiques.

Bref, la théorie de ce FS est géniale, mais la pratique est toute autre.

Il y a quelque part un pilote ODS-2 pour Linux, un truc qui ajoute
un numéro de version à tous les fichiers créés. /me devrait aller
voir s'il est possible de rajouter une option de montage du type
/keep=n.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 11/12/2009 11:56, NiKo a écrit :

Plus de 4 heures pour 90 Go, ça fait tomber les perfs en dessous de 8
Mo/s ... Une cata quoi !

[stephan@kulta ~]$ tar cf I.tgz Images/
[stephan@kulta ~]$ rm -fr Images/
[stephan@kulta ~]$ tar xf I.tgz
[stephan@kulta ~]$ time (tar cf I.tgz Images/ ; sync ; sync)

real 2m51.214s
user 0m0.487s
sys 0m24.527s

On a donc un temps global de 172 secondes pour 7400 Mo de données (43 Mo
en lecture et écriture sur le même système de fichiers y compris le
vidage du cache) sur un SSD avec des pointes à 170 Mo et régulier entre
70 et 80 Mo (écriture et lecture).

De plus, ce FS maintient une charge permanente sur la machine, avec un
load average avoisinant les 0,40 en permanence sur un Amd x2 6000.

C'est le garbage collector. Je suis à 0,14 sur un Q6600 à 1,6 GHz avec X
qui prend de la charge systématique à cause de mes affichages continus
de suivi du système. Le garbage collector doit représenter environ 1/10
de ma charge « idle » (c'est à dire quand je ne fais rien).

Impossibilité de faire un montage automatique de ce fs au boot.
Pas très important pour un poste 'perso' : [ESC]mount /home[CTRL][D]

[stephan@kulta Pyrénées]$ grep nilfs2 /etc/fstab
/dev/sdc1 /home/stephan nilfs2 rw 1 2

Pour l'instant, ce FS n'est pas déclaré stable. Il le dit lors dur
montage, de ne pas y stocker de données critiques.

C'est ce qui est dit, exact.

Bref, la théorie de ce FS est géniale, mais la pratique est toute autre.

Je n'ai rien à lui reprocher actuellement.

--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Le blog : <URL:http://pyrenees.peccini.fr>

Le Fri, 11 Dec 2009 11:39:55 +0800, Alban Taraire a écrit:

Pas mal, je connaissais pas. Niveau perfs, ça donne quoi ?

J'ai trouvé très bon. Un peu en dessous de XFS, mais meilleur qu'ext3. Je
parle d'accès séquentiel avec un système qui marche, genre 300 ou
400 Mo/s.

--
The question of whether computers can think is just like the question of
whether submarines can swim.
Edsger W. Dijkstra

Le Fri, 11 Dec 2009 10:01:06 +0000, JKB a écrit:

Seules deux machines
tournent chez moi en production avec des 2.6.30.9, mais patchés

jusqu'à

la moëlle pour faire tourner correctement le iSCSI en 'target' et
'initiator' (et à cause d'une combre histoire de libpcap dont

l'API a

subtilement changée).

Pour info il y a un patch pour iet 1.4.19 qui permet de fonctionner
correctement sur 2.6.32. BOn pour l'instant je l'ai simplement compilé :)

Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.

--
The first 90% of the code accounts for the first 90% of the development
time. The remaining 10% of the code accounts for the other 90% of the
development time.
Tom Cargill

Le Fri, 11 Dec 2009 11:00:28 +0100, Stephan Peccini a écrit:

Sachant qu'il y a des développements en cours, le projet ne s'engage pas
à ne rien changer dans les spécifications du système de fichiers dans
l'avenir. Donc pour de la production, j'aurai tendance à dire non ; mais
après il existe zfs qui lui est utilisable en prod mais que je trouve
moins intéressant pour un usage personnel

Oui mais ZFS, c'est pas sous linux... Pour nilfs je compte monter une
grosse machine de test ( 2 ou 30 To) et la remplir pour stresser le
bidule un max, juste pour voir.

--
Le livre, comme livre, appartient à l'auteur, mais comme pensée, il
appartient - le mot n'est pas trop vaste - au genre humain. Toutes les
intelligences y ont droit. Si l'un des deux droits, le droit de
l'écrivain et le droit de l'esprit humain, devait être sacrifié, ce
serait, certes, le droit de l'écrivain, car l'intérêt public est notre
préoccupation unique, et tous, je le déclare, doivent passer avant nous.
Victor Hugo.

Le Fri, 11 Dec 2009 11:56:13 +0100, NiKo a écrit:

Plus de 4 heures pour 90 Go, ça fait tomber les perfs en dessous de 8
Mo/s ... Une cata quoi!

Le principe de nilfs implique qu'il n'aime pas les tas de petits
fichiers, à mon avis.

--
That ideas should freely spread from one to another over the globe,
for the moral and mutual instruction of man, and the improvement of his
conditions, seems to have been peculiarly and benevolently designed by
nature, when she made them, like fire, expansible over all space,
without lessening their density in any point, and like the air in which
we breathe, move, and have our physical being, incapable of confinement
of exclusive appropriation. Inventions then cannot, in nature, be a
subject of property.
Thomas Jefferson.

Le 11-12-2009, ? propos de
Re: Trojan dans Linux,
Emmanuel Florac ?crivait dans fr.comp.os.linux.debats :

Le Fri, 11 Dec 2009 10:01:06 +0000, JKB a écrit:

Seules deux machines
tournent chez moi en production avec des 2.6.30.9, mais patchés

jusqu'à

la moëlle pour faire tourner correctement le iSCSI en 'target' et
'initiator' (et à cause d'une combre histoire de libpcap dont

l'API a

subtilement changée).

Pour info il y a un patch pour iet 1.4.19 qui permet de fonctionner
correctement sur 2.6.32. BOn pour l'instant je l'ai simplement compilé :)

Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
(sous-système SCSI/FCAL particulièrement buggué). David Miller qui
maintient le noyau sparc64 est très bon, mais il a vraiment trop tendance
à faire des trucs bizarres dans son coin et chaque nouveau noyau
sparc est une aventure extrême ;-) C'est pour cela que j'ai arrêté
de soumettre des patches pour sparc32, je n'arrivais plus à suivre
des évolutions pas vraiment documentées autrement que dans le GIT
sparc...

Tout ça pour dire que je ne vais pas installer ce noyau
immédiatement en prod sur mes machines.

Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.

Au problème près de la libcpap lorsque tu as un userland 32/64
bits !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le Fri, 11 Dec 2009 20:00:15 +0000, JKB a écrit:

Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.

Au problème près de la libcpap lorsque tu as un userland 32/64

bits !

Vu que c'est exactement la configuration dans laquelle je travaille, tu
peux préciser? Je n'ai pas remarqué de gros souci (même si j'ai eu
quelques bizarreries en FC).

--
There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way
is to make it so complicated that there are no obvious deficiencies. The
first method is far more difficult.
C.A.R. Hoare.