Complier le noyau...

ptilou

13/12/2011 à 23:31

On 13 déc, 22:57, Tonton Th wrote:

On 12/13/2011 10:50 PM, ptilou wrote:

> On peut connaitre tes références ?

<4ee7c320$0$24950$

C'est normal, y a des imbéciles de linuxiens, que quanD tu fais
entendre une voie contraire à se qu'ils souhaitent, ils font une p'tit
attaque informatique de surcroît, il ont tous à cou la phobie du
partage de la connaissance ...
Alors que depuis que les iraniens ont détournés un dronne top secret
made in USA, j'ai comme un doute, même en matière de crypto !
Un relent de "Stunext" ?
Peut-être qu'ils ont fais une course poursuite avec un filet et un
avion ?
Tous çà naturellement tourne sous linux ...

Ptilou

ptilou

13/12/2011 à 23:37

On 13 déc, 23:27, NiKo wrote:

Le 13/12/2011 22:33, ptilou a écrit :

> On Dec 13, 10:26 pm, NiKo wrote:
>> Le 13/12/2011 22:01, P4nd1-P4nd4 a écrit :

>>> .... Et cracher les morceaux !

>>> Cette opération indispensable pour l'utilisateur avertis (Enfin, ce lui
>>> qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
>>> qu'il n'y pas de défragmenteur sous Linux...) qui souhaite "optimis er"
>>> sa viellie brèle peut être maintenant effectuée en 60 secondes. ..

>> Normal ! Linux n'utilise pas un FS de merde comme Windows, qui ne sait
>> pas placer un fichier sur deux clusters contigus.

>> Quant à l'utilisateur averti, point on en trouve sous Windows !

> Escuse, j'ai big blue France le boss des ingés son portable, il est
> sous MS 7

T'es sur que c'est big blue ?
T'es sur que c'est france ?

Non, parce que là, j'ai du mal à te croire ... Va savoir pourquoi !

> Je crois quand matière d'informatique big blue est quelqu'un et celui
> qui dirige les ingés est AVERTI ?

T'as un portable IBM ?

Non un boss d'IBM ; quand tu comprend pas tu cherche sur http://fr.wikipedi a.org
, c'est dans l'esprit LL

T'ain, c'te classe !

Il en font plus ...
Il parait qu'il vendent du logiciel libre ...
Bon il savent travailler, leur com c'est pas MS c'est de la merde faut
pas acheter !

Ptilou

NiKo

14/12/2011 à 00:15

Le 13/12/2011 23:37, ptilou a écrit :

On 13 déc, 23:27, NiKo wrote:
Le 13/12/2011 22:33, ptilou a écrit :

On Dec 13, 10:26 pm, NiKo wrote:
Le 13/12/2011 22:01, P4nd1-P4nd4 a écrit :

.... Et cracher les morceaux !

Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...) qui souhaite "optimiser"
sa viellie brèle peut être maintenant effectuée en 60 secondes....

Normal ! Linux n'utilise pas un FS de merde comme Windows, qui ne sait
pas placer un fichier sur deux clusters contigus.

Quant à l'utilisateur averti, point on en trouve sous Windows !

Escuse, j'ai big blue France le boss des ingés son portable, il est
sous MS 7

T'es sur que c'est big blue ?
T'es sur que c'est france ?

Non, parce que là, j'ai du mal à te croire ... Va savoir pourquoi !

Je crois quand matière d'informatique big blue est quelqu'un et celui
qui dirige les ingés est AVERTI ?

T'as un portable IBM ?

Non un boss d'IBM ; quand tu comprend pas tu cherche sur http://fr.wikipedia.org
, c'est dans l'esprit LL

T'en as de la chance dis donc !

Tout ce que j'espère, pour que tu ne perdes pas ton job, c'est que tu ne
lui envoies pas trop de messages écris à ce boss ...

T'ain, c'te classe !

Il en font plus ...
Il parait qu'il vendent du logiciel libre ...

Tu devrais causer un peu au boss de big blue, il te dirait ce qu'ils
vendent réellement. J'ai bien dit 'causer' hein ! Pas écrire !

Bon il savent travailler, leur com c'est pas MS c'est de la merde faut
pas acheter !

Y'a pas longtemps que tu connais big blue toi !

Ptilou

--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !

SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !

Ascadix

14/12/2011 à 00:37

Tonton Th a pensé très fort :

On 12/13/2011 10:01 PM, P4nd1-P4nd4 wrote:

Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...)

Faudrait d'abord nous prouver en quoi la fragmentation est
un souci...

Sur un support flash genre SSD par ex, aucun pb.

Sur un support mécanique mobile genre disque dur traditionnel, ça
dégrade les perfs dans le temps, faut pondérer en fonction bien sur du
taux de remplissage et de l'activité sur le DD.
Et il faut y ajouter l'impact causé par le phénoméne de dispersion des
données (parfois désigné sous le terme de "fragmentation de l'espace
libre")

C'est bien sur moin sensible sur les DD trés rapide au niveau temps
d'accés.
Moins sensible en mono-tache, plus en multi-tache ou usage genre BDD.
C'est équalement amoindri par l'usage du NCQ.

Pour ne pas subir ce genre de dégradation, il faut éviter / limiter /
réduire la fragmentation.

Et ça, ça dépend du FS et surtout de son implémentaiton dans l'OS.

Au début, tant que le DD est relativement libre et qu'on se contente
d'ajouter des fichiers en 1 passe, sans rajouter de données au bout
d'un fichier déjà écrit, c'est quasiment automatique quel que soit le
FS / l'OS.

Quand il s'agit de rajouter des fichiers en 1 passe, mais cette fois
sur un DD déjà partiellement occupé et présentant des trous venant de
la suppression de ficheir antérieurs, c'est potentiellement assez
facile à éviter tant qu'il reste de la place sur le disque, NT/NT6 dans
toutes les variantes y arrive trés bien, surtout sur NTFS, la pluspart
des versions actuelles de Linux y arrivent trés bien aussi. à
contrario, Win9x était plutot mauvais la desus, étant donné qu'il ne
provilégiait une allocation contigue de secteurs que pour les fichiers
inférieurs à une taille entre qq centaines de ko et 2 Mo.

Ensuite, les cas problématiques:
- quand on veut écrire un fichier de taille > au plus grand espace
libre contigue.
- quand on veut rajouter des données au bout d'un fichier mais qu'il
n'y a pas assez d'esapce libre contigu à la fin de celui-ci.
- quand on ajoute des données au milieu d'un fichier clairsemé ("Sparse
files") existant

On à le choix entre 2 options :
- écrire en fragmentant cette écriture mais sans toucher aux autres
données déjà présente sur le disque.
- différée l'écriture le temps d'éffectuer +/ "à la volée" une
défragmentation localisée suffisante pour disposer d'assez d'espace
pour une écriture non fragmentée.
rien n'interdit d'utilsier les 2, aprés ça dépend des mécanismes
d'arbitrage au sein de l'implémentation des FS dans l'OS d'utiliser tel
ou tel méthode d'allocation.

NB: dans tous 2 cas, une gestion intelligente d'un cache en écriture
apporte un gain en permetant de combiner des écritures rapprochées en
une seule opération (XFS par ex fait un usage intensif de ce mécanisme)

La première option est plus rapide sur le coup, mais à la longue
dégrade les perfs plus rapidement que la 2°.
La 2° est moins rapide sur le coup, plus casse-gueule en dehors d'un
systeme ondulé, moins performante en écriture, mais maitient mieux les
perfs en lecture.

Windows/NTFS utilise la premiere, j'ai pas assez fouillé coté pingouin
pour connaitre tous les détails de comment il gére les différents
cas/FS, ceci dit vu les résultats, il utilise au moins une partie du
temps la méthode 1.

Reste donc, que dés que l'on utilise même à minima l'écriture
fragmentée, on obtient ... de la fragmentation :-)

Et là, plusieurs politique suivant les OS/FS:
- On peut traiter ça avec un defragmenteur +/- en continu ou ponctuel,
prenant si possible en compte l'activité de la machine et gérant des
priorité sur les I/O pour ne pas perturber les autres opérations ( XFS,
NTFS, +/- Ext4) et lisser ces pbs de fragmentation et leur conséquences
en terme de perfs.
- On peut faire l'autruche et pratiquer la méthode Coué (Ext3) ce qui
conduit à une des + belle légende urbaine de l'info du XX° siécle
.."Linux ne fragmente pas"

--> le clin d'oeuil, malheuresement pour les crétins d'Ayatolah du
nunux techniquements déficients qui continuent à pérorer cette ineptie
depuis desanénes, ils ont des enemis au sein même du coeur du
pingouin,les dévellopeurs concernés par ext4 sont contre eux puisqu'ils
ont l'audace incroyable de prévoir la défragmentation avec Ext4 :-))

--> Astuce pour défragmenter quand même une Ext3 quand elle commence à
sentir le moisi en terme de perf: un bon gros coup de CP vers une autre
partition (vide) et inverser les points de montage :-)

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Tonton Th a pensé très fort :

On 12/13/2011 10:01 PM, P4nd1-P4nd4 wrote:

Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...)

Faudrait d'abord nous prouver en quoi la fragmentation est
un souci...

Sur un support flash genre SSD par ex, aucun pb.

Sur un support mécanique mobile genre disque dur traditionnel, ça
dégrade les perfs dans le temps, faut pondérer en fonction bien sur du
taux de remplissage et de l'activité sur le DD.
Et il faut y ajouter l'impact causé par le phénoméne de dispersion des
données (parfois désigné sous le terme de "fragmentation de l'espace
libre")

C'est bien sur moin sensible sur les DD trés rapide au niveau temps
d'accés.
Moins sensible en mono-tache, plus en multi-tache ou usage genre BDD.
C'est équalement amoindri par l'usage du NCQ.

Pour ne pas subir ce genre de dégradation, il faut éviter / limiter /
réduire la fragmentation.

Et ça, ça dépend du FS et surtout de son implémentaiton dans l'OS.

Au début, tant que le DD est relativement libre et qu'on se contente
d'ajouter des fichiers en 1 passe, sans rajouter de données au bout
d'un fichier déjà écrit, c'est quasiment automatique quel que soit le
FS / l'OS.

Quand il s'agit de rajouter des fichiers en 1 passe, mais cette fois
sur un DD déjà partiellement occupé et présentant des trous venant de
la suppression de ficheir antérieurs, c'est potentiellement assez
facile à éviter tant qu'il reste de la place sur le disque, NT/NT6 dans
toutes les variantes y arrive trés bien, surtout sur NTFS, la pluspart
des versions actuelles de Linux y arrivent trés bien aussi. à
contrario, Win9x était plutot mauvais la desus, étant donné qu'il ne
provilégiait une allocation contigue de secteurs que pour les fichiers
inférieurs à une taille entre qq centaines de ko et 2 Mo.

Ensuite, les cas problématiques:
- quand on veut écrire un fichier de taille > au plus grand espace
libre contigue.
- quand on veut rajouter des données au bout d'un fichier mais qu'il
n'y a pas assez d'esapce libre contigu à la fin de celui-ci.
- quand on ajoute des données au milieu d'un fichier clairsemé ("Sparse
files") existant

On à le choix entre 2 options :
- écrire en fragmentant cette écriture mais sans toucher aux autres
données déjà présente sur le disque.
- différée l'écriture le temps d'éffectuer +/ "à la volée" une
défragmentation localisée suffisante pour disposer d'assez d'espace
pour une écriture non fragmentée.
rien n'interdit d'utilsier les 2, aprés ça dépend des mécanismes
d'arbitrage au sein de l'implémentation des FS dans l'OS d'utiliser tel
ou tel méthode d'allocation.

NB: dans tous 2 cas, une gestion intelligente d'un cache en écriture
apporte un gain en permetant de combiner des écritures rapprochées en
une seule opération (XFS par ex fait un usage intensif de ce mécanisme)

La première option est plus rapide sur le coup, mais à la longue
dégrade les perfs plus rapidement que la 2°.
La 2° est moins rapide sur le coup, plus casse-gueule en dehors d'un
systeme ondulé, moins performante en écriture, mais maitient mieux les
perfs en lecture.

Windows/NTFS utilise la premiere, j'ai pas assez fouillé coté pingouin
pour connaitre tous les détails de comment il gére les différents
cas/FS, ceci dit vu les résultats, il utilise au moins une partie du
temps la méthode 1.

Reste donc, que dés que l'on utilise même à minima l'écriture
fragmentée, on obtient ... de la fragmentation :-)

Et là, plusieurs politique suivant les OS/FS:
- On peut traiter ça avec un defragmenteur +/- en continu ou ponctuel,
prenant si possible en compte l'activité de la machine et gérant des
priorité sur les I/O pour ne pas perturber les autres opérations ( XFS,
NTFS, +/- Ext4) et lisser ces pbs de fragmentation et leur conséquences
en terme de perfs.
- On peut faire l'autruche et pratiquer la méthode Coué (Ext3) ce qui
conduit à une des + belle légende urbaine de l'info du XX° siécle
.."Linux ne fragmente pas"

--> le clin d'oeuil, malheuresement pour les crétins d'Ayatolah du
nunux techniquements déficients qui continuent à pérorer cette ineptie
depuis desanénes, ils ont des enemis au sein même du coeur du
pingouin,les dévellopeurs concernés par ext4 sont contre eux puisqu'ils
ont l'audace incroyable de prévoir la défragmentation avec Ext4 :-))

--> Astuce pour défragmenter quand même une Ext3 quand elle commence à
sentir le moisi en terme de perf: un bon gros coup de CP vers une autre
partition (vide) et inverser les points de montage :-)

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Vous avez filtré cet utilisateur ! Consultez son message

Tonton Th a pensé très fort :

On 12/13/2011 10:01 PM, P4nd1-P4nd4 wrote:

Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...)

Faudrait d'abord nous prouver en quoi la fragmentation est
un souci...

Sur un support flash genre SSD par ex, aucun pb.

Sur un support mécanique mobile genre disque dur traditionnel, ça
dégrade les perfs dans le temps, faut pondérer en fonction bien sur du
taux de remplissage et de l'activité sur le DD.
Et il faut y ajouter l'impact causé par le phénoméne de dispersion des
données (parfois désigné sous le terme de "fragmentation de l'espace
libre")

C'est bien sur moin sensible sur les DD trés rapide au niveau temps
d'accés.
Moins sensible en mono-tache, plus en multi-tache ou usage genre BDD.
C'est équalement amoindri par l'usage du NCQ.

Pour ne pas subir ce genre de dégradation, il faut éviter / limiter /
réduire la fragmentation.

Et ça, ça dépend du FS et surtout de son implémentaiton dans l'OS.

Au début, tant que le DD est relativement libre et qu'on se contente
d'ajouter des fichiers en 1 passe, sans rajouter de données au bout
d'un fichier déjà écrit, c'est quasiment automatique quel que soit le
FS / l'OS.

Quand il s'agit de rajouter des fichiers en 1 passe, mais cette fois
sur un DD déjà partiellement occupé et présentant des trous venant de
la suppression de ficheir antérieurs, c'est potentiellement assez
facile à éviter tant qu'il reste de la place sur le disque, NT/NT6 dans
toutes les variantes y arrive trés bien, surtout sur NTFS, la pluspart
des versions actuelles de Linux y arrivent trés bien aussi. à
contrario, Win9x était plutot mauvais la desus, étant donné qu'il ne
provilégiait une allocation contigue de secteurs que pour les fichiers
inférieurs à une taille entre qq centaines de ko et 2 Mo.

Ensuite, les cas problématiques:
- quand on veut écrire un fichier de taille > au plus grand espace
libre contigue.
- quand on veut rajouter des données au bout d'un fichier mais qu'il
n'y a pas assez d'esapce libre contigu à la fin de celui-ci.
- quand on ajoute des données au milieu d'un fichier clairsemé ("Sparse
files") existant

On à le choix entre 2 options :
- écrire en fragmentant cette écriture mais sans toucher aux autres
données déjà présente sur le disque.
- différée l'écriture le temps d'éffectuer +/ "à la volée" une
défragmentation localisée suffisante pour disposer d'assez d'espace
pour une écriture non fragmentée.
rien n'interdit d'utilsier les 2, aprés ça dépend des mécanismes
d'arbitrage au sein de l'implémentation des FS dans l'OS d'utiliser tel
ou tel méthode d'allocation.

NB: dans tous 2 cas, une gestion intelligente d'un cache en écriture
apporte un gain en permetant de combiner des écritures rapprochées en
une seule opération (XFS par ex fait un usage intensif de ce mécanisme)

La première option est plus rapide sur le coup, mais à la longue
dégrade les perfs plus rapidement que la 2°.
La 2° est moins rapide sur le coup, plus casse-gueule en dehors d'un
systeme ondulé, moins performante en écriture, mais maitient mieux les
perfs en lecture.

Windows/NTFS utilise la premiere, j'ai pas assez fouillé coté pingouin
pour connaitre tous les détails de comment il gére les différents
cas/FS, ceci dit vu les résultats, il utilise au moins une partie du
temps la méthode 1.

Reste donc, que dés que l'on utilise même à minima l'écriture
fragmentée, on obtient ... de la fragmentation :-)

Et là, plusieurs politique suivant les OS/FS:
- On peut traiter ça avec un defragmenteur +/- en continu ou ponctuel,
prenant si possible en compte l'activité de la machine et gérant des
priorité sur les I/O pour ne pas perturber les autres opérations ( XFS,
NTFS, +/- Ext4) et lisser ces pbs de fragmentation et leur conséquences
en terme de perfs.
- On peut faire l'autruche et pratiquer la méthode Coué (Ext3) ce qui
conduit à une des + belle légende urbaine de l'info du XX° siécle
.."Linux ne fragmente pas"

--> le clin d'oeuil, malheuresement pour les crétins d'Ayatolah du
nunux techniquements déficients qui continuent à pérorer cette ineptie
depuis desanénes, ils ont des enemis au sein même du coeur du
pingouin,les dévellopeurs concernés par ext4 sont contre eux puisqu'ils
ont l'audace incroyable de prévoir la défragmentation avec Ext4 :-))

--> Astuce pour défragmenter quand même une Ext3 quand elle commence à
sentir le moisi en terme de perf: un bon gros coup de CP vers une autre
partition (vide) et inverser les points de montage :-)

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Yliur

14/12/2011 à 01:01

Le Wed, 14 Dec 2011 00:37:46 +0100
Ascadix a écrit :

[la fragmentation]

Moins sensible en mono-tache, plus en multi-tache ou usage genre BDD.

Pourquoi moins sensible en mono-tâche ?

Ascadix

14/12/2011 à 01:36

Il se trouve que Yliur a formulé :

Le Wed, 14 Dec 2011 00:37:46 +0100
Ascadix a écrit :

[la fragmentation]
Moins sensible en mono-tache, plus en multi-tache ou usage genre BDD.

Pourquoi moins sensible en mono-tâche ?

Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un bout
à l'autre du DD en raison des accés simultanés à de nombreux fichiers,
à multiplier par la fragmentation des fichiers.

En monotache, t'as globalement moins d'accés fichiers simultanés donc à
niveau defragmentaiton équivalent, les têtes doivent se déplacer 1* nb
de fragments alors qu'en multi-tache c'est X*nb de frag ( et X et +/-
plus grand que 1)

Pour reprendre l'analogie de l'armoire à dossier chère à certains
, tu va aller plus vite si je te demande de me récupérer un dossier
éparpillé dans 5 tiroirs que si tu doit récupérer les morceaux de 10
dossiers éparpillé dans 5*10 = 50 tirroirs

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Ascadix

14/12/2011 à 02:18

NiKo a formulé ce mardi :

Le 13/12/2011 22:01, P4nd1-P4nd4 a écrit :
.... Et cracher les morceaux !

Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...) qui souhaite "optimiser"
sa viellie brèle peut être maintenant effectuée en 60 secondes...

Normal ! Linux n'utilise pas un FS de merde comme Windows,

si tu veux comparer FAT à Ext2 ... j'hésite ... c'est 2 trucs légers.
si tu veux comparer NTFS à Ext3 : y a pas photo, un vrai FS contre une
sombre merde.
NTFS vs Ext4 : vrai FS contre évolution à peu prés utilisable en
théorie d'uen sombre merde
NTFS vs XFS : 2 vrais FS.

qui ne sait
pas placer un fichier sur deux clusters contigus.

Même Windows 95/98/Me en FAT fait mieux que ça.
Par défaut, il cherche un bloc contigue de 500 ko (ça peut se régler)
..ça fait combien en cluster ça ?

Et je parle mêmepas d'un Windwos récent famille NT sur du NTFS ...

Manifestement, tu sais pas de quoi tu parle.

Quant à l'utilisateur averti, point on en trouve sous Windows !

Pov tache imbu de ta petit personne minable.

On en trouve sous les 2 Os et même d'autes, chacun prend l'OS qui colle
le mieux à ses besoins.

L'utilisateur avertis, il essaye et il réflechit en terme de besoins
technique, de cout et rapport Q/P pas d'idéologie fumeuse.

--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.

Yliur

14/12/2011 à 02:41

Le Wed, 14 Dec 2011 01:36:39 +0100
Ascadix a écrit :

Il se trouve que Yliur a formulé :
> Le Wed, 14 Dec 2011 00:37:46 +0100
> Ascadix a écrit :
>
> [la fragmentation]
>> Moins sensible en mono-tache, plus en multi-tache ou usage genre
>> BDD.
>
> Pourquoi moins sensible en mono-tâche ?

Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
bout à l'autre du DD en raison des accés simultanés à de nombreux
fichiers, à multiplier par la fragmentation des fichiers.

En monotache, t'as globalement moins d'accés fichiers simultanés donc
à niveau defragmentaiton équivalent, les têtes doivent se déplacer 1*
nb de fragments alors qu'en multi-tache c'est X*nb de frag ( et X et
+/- plus grand que 1)

Tu veux dire que faire plusieurs accès disques simultanés c'est plus
lent qu'en faire un seul, en fait. Mais ça n'a rien à voir avec la
fragmentation. Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés. Et en multi-tâches avec un peu de chances certains
processus ont autre chose à faire que lire sur le disque pendant qu'un
autre est bloqué dessus, ce qui limite les pertes de temps dues aux
accès disques.

Pour reprendre l'analogie de l'armoire à dossier chère à certains
, tu va aller plus vite si je te demande de me récupérer un dossier
éparpillé dans 5 tiroirs que si tu doit récupérer les morceaux de 10
dossiers éparpillé dans 5*10 = 50 tirroirs

Justement, dans cet exemple comme lorsque tu parles plus haut de sauter
d'un bout à l'autre du disque, le fait de passer d'un fichier à l'autre
est confondu avec le fait de passer d'une fragment à l'autre. Pour
prendre une image illustrant simplement mon propos : une tâche avec des
accès disque un peu partout : la tête doit parcourir tout l'espace
entre deux fragments extrêmes pour passer de l'un à l'autre. Deux tâches
simultanées, avec des fragments de fichiers entrecroisés : la tête doit
faire à peu près le même chemin, avec plus d'arrêts, ce qui ne prend
pas plus de temps (temps de parcours cumulé). Au contraire, si les deux
tâches étaient accomplies de manière séquentielle, le trajet total de
la tête aurait été plus important. Tout ça si le système est capable de
réorganiser les accès aux disques pour simplifier le parcours de la
tête, bien sûr (pour faire simple, imaginons qu'il utilise quelque
chose du genre de l'algorithme de l'ascenseur : le temps de déplacement
cumulé ne dépend pas du nombre d'arrêts intermédiaires). Et si on ne
considère pas cette optimisation, le côté multi-tâches reste neutre du
point de vue de la fragmentation (à vue de nez).

Le Wed, 14 Dec 2011 01:36:39 +0100
Ascadix <ascadix.ng@free.fr> a écrit :

Il se trouve que Yliur a formulé :
> Le Wed, 14 Dec 2011 00:37:46 +0100
> Ascadix <ascadix.ng@free.fr> a écrit :
>
> [la fragmentation]
>> Moins sensible en mono-tache, plus en multi-tache ou usage genre
>> BDD.
>
> Pourquoi moins sensible en mono-tâche ?

Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
bout à l'autre du DD en raison des accés simultanés à de nombreux
fichiers, à multiplier par la fragmentation des fichiers.

En monotache, t'as globalement moins d'accés fichiers simultanés donc
à niveau defragmentaiton équivalent, les têtes doivent se déplacer 1*
nb de fragments alors qu'en multi-tache c'est X*nb de frag ( et X et
+/- plus grand que 1)

Tu veux dire que faire plusieurs accès disques simultanés c'est plus
lent qu'en faire un seul, en fait. Mais ça n'a rien à voir avec la
fragmentation. Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés. Et en multi-tâches avec un peu de chances certains
processus ont autre chose à faire que lire sur le disque pendant qu'un
autre est bloqué dessus, ce qui limite les pertes de temps dues aux
accès disques.

Pour reprendre l'analogie de l'armoire à dossier chère à certains
, tu va aller plus vite si je te demande de me récupérer un dossier
éparpillé dans 5 tiroirs que si tu doit récupérer les morceaux de 10
dossiers éparpillé dans 5*10 = 50 tirroirs

Justement, dans cet exemple comme lorsque tu parles plus haut de sauter
d'un bout à l'autre du disque, le fait de passer d'un fichier à l'autre
est confondu avec le fait de passer d'une fragment à l'autre. Pour
prendre une image illustrant simplement mon propos : une tâche avec des
accès disque un peu partout : la tête doit parcourir tout l'espace
entre deux fragments extrêmes pour passer de l'un à l'autre. Deux tâches
simultanées, avec des fragments de fichiers entrecroisés : la tête doit
faire à peu près le même chemin, avec plus d'arrêts, ce qui ne prend
pas plus de temps (temps de parcours cumulé). Au contraire, si les deux
tâches étaient accomplies de manière séquentielle, le trajet total de
la tête aurait été plus important. Tout ça si le système est capable de
réorganiser les accès aux disques pour simplifier le parcours de la
tête, bien sûr (pour faire simple, imaginons qu'il utilise quelque
chose du genre de l'algorithme de l'ascenseur : le temps de déplacement
cumulé ne dépend pas du nombre d'arrêts intermédiaires). Et si on ne
considère pas cette optimisation, le côté multi-tâches reste neutre du
point de vue de la fragmentation (à vue de nez).

Vous avez filtré cet utilisateur ! Consultez son message

Le Wed, 14 Dec 2011 01:36:39 +0100
Ascadix a écrit :

Il se trouve que Yliur a formulé :
> Le Wed, 14 Dec 2011 00:37:46 +0100
> Ascadix a écrit :
>
> [la fragmentation]
>> Moins sensible en mono-tache, plus en multi-tache ou usage genre
>> BDD.
>
> Pourquoi moins sensible en mono-tâche ?

Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
bout à l'autre du DD en raison des accés simultanés à de nombreux
fichiers, à multiplier par la fragmentation des fichiers.

En monotache, t'as globalement moins d'accés fichiers simultanés donc
à niveau defragmentaiton équivalent, les têtes doivent se déplacer 1*
nb de fragments alors qu'en multi-tache c'est X*nb de frag ( et X et
+/- plus grand que 1)

Tu veux dire que faire plusieurs accès disques simultanés c'est plus
lent qu'en faire un seul, en fait. Mais ça n'a rien à voir avec la
fragmentation. Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés. Et en multi-tâches avec un peu de chances certains
processus ont autre chose à faire que lire sur le disque pendant qu'un
autre est bloqué dessus, ce qui limite les pertes de temps dues aux
accès disques.

Pour reprendre l'analogie de l'armoire à dossier chère à certains
, tu va aller plus vite si je te demande de me récupérer un dossier
éparpillé dans 5 tiroirs que si tu doit récupérer les morceaux de 10
dossiers éparpillé dans 5*10 = 50 tirroirs

Justement, dans cet exemple comme lorsque tu parles plus haut de sauter
d'un bout à l'autre du disque, le fait de passer d'un fichier à l'autre
est confondu avec le fait de passer d'une fragment à l'autre. Pour
prendre une image illustrant simplement mon propos : une tâche avec des
accès disque un peu partout : la tête doit parcourir tout l'espace
entre deux fragments extrêmes pour passer de l'un à l'autre. Deux tâches
simultanées, avec des fragments de fichiers entrecroisés : la tête doit
faire à peu près le même chemin, avec plus d'arrêts, ce qui ne prend
pas plus de temps (temps de parcours cumulé). Au contraire, si les deux
tâches étaient accomplies de manière séquentielle, le trajet total de
la tête aurait été plus important. Tout ça si le système est capable de
réorganiser les accès aux disques pour simplifier le parcours de la
tête, bien sûr (pour faire simple, imaginons qu'il utilise quelque
chose du genre de l'algorithme de l'ascenseur : le temps de déplacement
cumulé ne dépend pas du nombre d'arrêts intermédiaires). Et si on ne
considère pas cette optimisation, le côté multi-tâches reste neutre du
point de vue de la fragmentation (à vue de nez).

YBM

14/12/2011 à 02:53

Le 13.12.2011 22:01, P4nd1-P4nd4 a écrit :

Sujet: Complier le noyau...

Une faute dans le sujet... ça commence bien...

... Et cracher les morceaux !

Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...)

Faux et sans rapport avec la fragmentation. Comme à ton habitude tu te
ridiculise dès que tu prétends parler d'un sujet technique.

qui souhaite "optimiser"
sa viellie brèle peut être maintenant effectuée en 60 secondes...

Maljeureusement, il faut un processeur super costaud !

Douze fautes d'orthographe et de grammaire plus tard : un nouveau
mensonge de pandipandule...

(On se demande pourquoi alors recomplier son noyau, mais bon, on n'en
est pas à une contradiction près avec Linux....)

Et la même faute encore, pas fute-fute le pandule, il n'a sans doute
même pas saisi de quoi il est question depuis le début.

Recomplier son noyau notamment à enlever des choses "très
consommatrice", comme le suport de la dsiquette 720 Ko et 1.44 MB,

Pour économiser l'espace occupé sur disque de quelques dizaine de
Kio d'un pilote jamais utilisé ? Tu te mets à l'embarqué, guignol?

ou encore optimiser sa distros pour son PIII

À la limite, why not ? Tu as une idée de la façon d'évaluer l'impact
d'une recompilation de noyau sur un système en production, petit
scarabée ? Sinon laisse faire les grande personnes, et retourne à
ton bac à sable.

Bref, si vous ne savez pas faire cette opération, vous êtes un crétin et
faut rester sous WIndows

Le rapport logique entre le délire au dessus et cette conclusion reste
assez ténu.

Le pendi-pendule se serait-il mis à la drogue ?

P.S. Un noyau, ou tout autre logiciel pour ce qu'il en est, ça ne se
"complie" pas, ça se "compile".

Frederic Bezies

14/12/2011 à 06:50

Le Tue, 13 Dec 2011 22:01:06 +0100, P4nd1-P4nd4 a écrit :

... Et cracher les morceaux !

Cette opération indispensable pour l'utilisateur avertis (Enfin, celui
qui veut que son ordinateur fonctionne plus vite sans défragmenter vu
qu'il n'y pas de défragmenteur sous Linux...) qui souhaite "optimiser"

Ah ? Tu m'expliqueras la différence entre un noyau et un système de
fichiers. Tu te dis informaticien, non ?

sa viellie brèle peut être maintenant effectuée en 60 secondes...

Ah, oui, j'ai entendu parler de cela.

Maljeureusement, il faut un processeur super costaud !

(On se demande pourquoi alors recomplier son noyau, mais bon, on n'en
est pas à une contradiction près avec Linux....)

Il est vrai que l'on doit recompiler le noyau au moindre changement de
matériel... Ah, on me dit que ce n'est plus nécessaire depuis le noyau 2.0
en 1996...

Recomplier son noyau notamment à enlever des choses "très
consommatrice", comme le suport de la dsiquette 720 Ko et 1.44 MB, ou
encore optimiser sa distros pour son PIII

Tu es resté en 1995 ? uname -a te dit que tu as un noyau 1.2.xx ?

Bref, si vous ne savez pas faire cette opération, vous êtes un crétin et
faut rester sous WIndows

Pourquoi tant de haine envers toi-même ?

--
Frederic Bezies -
Blog : http://frederic.bezies.free.fr/blog/

Complier le noyau...

10 réponses

Veuillez sélectionner un problème