Il faut être spécial pour pas pouvoir attendre 15 secondes que le
portable démarre.
J'éteins mon PC tous les soirs.
Il faut être spécial pour pas pouvoir attendre 15 secondes que le
portable démarre.
J'éteins mon PC tous les soirs.
Il faut être spécial pour pas pouvoir attendre 15 secondes que le
portable démarre.
J'éteins mon PC tous les soirs.
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).
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 14-12-2011, Yliur a écrit :Ascadix a écrit :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.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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Le 14-12-2011, Yliur <yliur@free.fr> a écrit :
Ascadix <ascadix.ng@free.fr> a écrit :
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.
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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Le 14-12-2011, Yliur a écrit :Ascadix a écrit :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.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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Le 14/12/2011 08:30, Hugolino a écrit :Le 14-12-2011, Yliur a écrit :Ascadix a écrit :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.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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Sans doute je n'ai pas tout suivi des débats qui auraient pu avoir lieu sur
ce groupe (on m'a dit quelque part que j'avais un pseudo "frais"), mais j'ai
un peu de mal avec ce genre de réaction: voilà un participant que prend la
peine de rédiger une note non dénuée d'intérêt au sujet de la fragmentation
et des stratégies mises en ½uvre, suivi d'une réaction également technique et
argumentée. C'est le type même de débat qu'on s'attend à trouver sur des
forums techniques, et c'est malheureusement trop rare.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une remarque
insultante?
Le 14/12/2011 08:30, Hugolino a écrit :
Le 14-12-2011, Yliur<yliur@free.fr> a écrit :
Ascadix<ascadix.ng@free.fr> a écrit :
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.
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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Sans doute je n'ai pas tout suivi des débats qui auraient pu avoir lieu sur
ce groupe (on m'a dit quelque part que j'avais un pseudo "frais"), mais j'ai
un peu de mal avec ce genre de réaction: voilà un participant que prend la
peine de rédiger une note non dénuée d'intérêt au sujet de la fragmentation
et des stratégies mises en ½uvre, suivi d'une réaction également technique et
argumentée. C'est le type même de débat qu'on s'attend à trouver sur des
forums techniques, et c'est malheureusement trop rare.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une remarque
insultante?
Le 14/12/2011 08:30, Hugolino a écrit :Le 14-12-2011, Yliur a écrit :Ascadix a écrit :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.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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Sans doute je n'ai pas tout suivi des débats qui auraient pu avoir lieu sur
ce groupe (on m'a dit quelque part que j'avais un pseudo "frais"), mais j'ai
un peu de mal avec ce genre de réaction: voilà un participant que prend la
peine de rédiger une note non dénuée d'intérêt au sujet de la fragmentation
et des stratégies mises en ½uvre, suivi d'une réaction également technique et
argumentée. C'est le type même de débat qu'on s'attend à trouver sur des
forums techniques, et c'est malheureusement trop rare.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une remarque
insultante?
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 ?
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 ?
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 ?
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une
remarque insultante?
Te frappe pas, c'est la caractéristique même d' "Hugolino" et qq uns de
ses copains sur fcold, jamais la moindre contribution technique, et des
montagnes d'insultes à l'encontre de toute personne qui intervient sans
adhérer à leur vision dogmatique de Linux en tant que la "Solution"
unique et omnipotente.
Et le simple fait d'evoquer MS/Windows pour tout autre motif que de
vomir dessus leur provoque des crises de rage relevant plus amha d'un pb
psychiatrique que d'une discussion technique ou même "philosophique".
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une
remarque insultante?
Te frappe pas, c'est la caractéristique même d' "Hugolino" et qq uns de
ses copains sur fcold, jamais la moindre contribution technique, et des
montagnes d'insultes à l'encontre de toute personne qui intervient sans
adhérer à leur vision dogmatique de Linux en tant que la "Solution"
unique et omnipotente.
Et le simple fait d'evoquer MS/Windows pour tout autre motif que de
vomir dessus leur provoque des crises de rage relevant plus amha d'un pb
psychiatrique que d'une discussion technique ou même "philosophique".
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une
remarque insultante?
Te frappe pas, c'est la caractéristique même d' "Hugolino" et qq uns de
ses copains sur fcold, jamais la moindre contribution technique, et des
montagnes d'insultes à l'encontre de toute personne qui intervient sans
adhérer à leur vision dogmatique de Linux en tant que la "Solution"
unique et omnipotente.
Et le simple fait d'evoquer MS/Windows pour tout autre motif que de
vomir dessus leur provoque des crises de rage relevant plus amha d'un pb
psychiatrique que d'une discussion technique ou même "philosophique".
denis.paris a utilisé son clavier pour écrire :Le 14/12/2011 08:30, Hugolino a écrit :Le 14-12-2011, Yliur a écrit :Ascadix a écrit :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.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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Sans doute je n'ai pas tout suivi des débats qui auraient pu avoir
lieu sur ce groupe (on m'a dit quelque part que j'avais un pseudo
"frais"), mais j'ai un peu de mal avec ce genre de réaction: voilà un
participant que prend la peine de rédiger une note non dénuée
d'intérêt au sujet de la fragmentation et des stratégies mises en
½uvre, suivi d'une réaction également technique et argumentée. C'est
le type même de débat qu'on s'attend à trouver sur des forums
techniques, et c'est malheureusement trop rare.
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
denis.paris a utilisé son clavier pour écrire :
Le 14/12/2011 08:30, Hugolino a écrit :
Le 14-12-2011, Yliur<yliur@free.fr> a écrit :
Ascadix<ascadix.ng@free.fr> a écrit :
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.
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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Sans doute je n'ai pas tout suivi des débats qui auraient pu avoir
lieu sur ce groupe (on m'a dit quelque part que j'avais un pseudo
"frais"), mais j'ai un peu de mal avec ce genre de réaction: voilà un
participant que prend la peine de rédiger une note non dénuée
d'intérêt au sujet de la fragmentation et des stratégies mises en
½uvre, suivi d'une réaction également technique et argumentée. C'est
le type même de débat qu'on s'attend à trouver sur des forums
techniques, et c'est malheureusement trop rare.
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
denis.paris a utilisé son clavier pour écrire :Le 14/12/2011 08:30, Hugolino a écrit :Le 14-12-2011, Yliur a écrit :Ascadix a écrit :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.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.
T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
à cet imbécile ?
N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
eux-mêmes par A + B qu'ils sont incapables de penser correctement.
Allez Ascadix, retourne jouer avec tes copains...
Sans doute je n'ai pas tout suivi des débats qui auraient pu avoir
lieu sur ce groupe (on m'a dit quelque part que j'avais un pseudo
"frais"), mais j'ai un peu de mal avec ce genre de réaction: voilà un
participant que prend la peine de rédiger une note non dénuée
d'intérêt au sujet de la fragmentation et des stratégies mises en
½uvre, suivi d'une réaction également technique et argumentée. C'est
le type même de débat qu'on s'attend à trouver sur des forums
techniques, et c'est malheureusement trop rare.
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
..., sans jamais la moindre intervention constructive et technique.
..., sans jamais la moindre intervention constructive et technique.
..., sans jamais la moindre intervention constructive et technique.
Yliur avait prétendu :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.
ça n'a rien à voir comme cause ... mais l'effet des 2 sur les perfs est
cumulatif.Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés.
Oui ...
J'ai écrit + ou - sensible, j'ai jamais écrit inexistant.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.
Il y a encore plus de "temps mort" en mono-tâche ...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).
Que la tête saute d'une piste du début à une piste de fin, ou s'arréte
par une piste intermédiaire pour lire qq secteurs, c'est pas la même
vitesse. en comparaison, une fois positioné sur une piste, lire 1 ou 50
secteurs ça provoque un cout en temps bien moindre que le positionnement
sur une piste intermédiaire.
Alors bien sur, si elle les softs demandent dans l'ordre :
piste 1 ... piste 100 + piste 50 ... piste 200 + piste 30
... -> requetes multiples
+ -> fragmentation
et que le DD lit physiquement dans cet ordre c'est pas bon.
La réorganisation des I/O par l'OS, éventuellement épaulé par des
technos plus proches du matos comme le NCQ va permetre d'optimiser ça en
réalisant mécaniquement une lecteur dans l'ordre :
p1 - p30 - p50 - p100 - p200
Mais ça restera quand même plus lent que si il avait seulemernt eu
besoin de faire
p1 - p30 - 200 (si ça avait été défragmenté)
ou simplement
p 100 + p 50 si seul soft avait été en cours et que personne ne demande
à lire p1 / p200 / p30
Les 2 causes se combinent et donnent toujours un résultat plus lent,
même si c'est + /- notable suivant le détail, c'est toujorus + lent.
Yliur avait prétendu :
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.
ça n'a rien à voir comme cause ... mais l'effet des 2 sur les perfs est
cumulatif.
Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés.
Oui ...
J'ai écrit + ou - sensible, j'ai jamais écrit inexistant.
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.
Il y a encore plus de "temps mort" en mono-tâche ...
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).
Que la tête saute d'une piste du début à une piste de fin, ou s'arréte
par une piste intermédiaire pour lire qq secteurs, c'est pas la même
vitesse. en comparaison, une fois positioné sur une piste, lire 1 ou 50
secteurs ça provoque un cout en temps bien moindre que le positionnement
sur une piste intermédiaire.
Alors bien sur, si elle les softs demandent dans l'ordre :
piste 1 ... piste 100 + piste 50 ... piste 200 + piste 30
... -> requetes multiples
+ -> fragmentation
et que le DD lit physiquement dans cet ordre c'est pas bon.
La réorganisation des I/O par l'OS, éventuellement épaulé par des
technos plus proches du matos comme le NCQ va permetre d'optimiser ça en
réalisant mécaniquement une lecteur dans l'ordre :
p1 - p30 - p50 - p100 - p200
Mais ça restera quand même plus lent que si il avait seulemernt eu
besoin de faire
p1 - p30 - 200 (si ça avait été défragmenté)
ou simplement
p 100 + p 50 si seul soft avait été en cours et que personne ne demande
à lire p1 / p200 / p30
Les 2 causes se combinent et donnent toujours un résultat plus lent,
même si c'est + /- notable suivant le détail, c'est toujorus + lent.
Yliur avait prétendu :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.
ça n'a rien à voir comme cause ... mais l'effet des 2 sur les perfs est
cumulatif.Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés.
Oui ...
J'ai écrit + ou - sensible, j'ai jamais écrit inexistant.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.
Il y a encore plus de "temps mort" en mono-tâche ...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).
Que la tête saute d'une piste du début à une piste de fin, ou s'arréte
par une piste intermédiaire pour lire qq secteurs, c'est pas la même
vitesse. en comparaison, une fois positioné sur une piste, lire 1 ou 50
secteurs ça provoque un cout en temps bien moindre que le positionnement
sur une piste intermédiaire.
Alors bien sur, si elle les softs demandent dans l'ordre :
piste 1 ... piste 100 + piste 50 ... piste 200 + piste 30
... -> requetes multiples
+ -> fragmentation
et que le DD lit physiquement dans cet ordre c'est pas bon.
La réorganisation des I/O par l'OS, éventuellement épaulé par des
technos plus proches du matos comme le NCQ va permetre d'optimiser ça en
réalisant mécaniquement une lecteur dans l'ordre :
p1 - p30 - p50 - p100 - p200
Mais ça restera quand même plus lent que si il avait seulemernt eu
besoin de faire
p1 - p30 - 200 (si ça avait été défragmenté)
ou simplement
p 100 + p 50 si seul soft avait été en cours et que personne ne demande
à lire p1 / p200 / p30
Les 2 causes se combinent et donnent toujours un résultat plus lent,
même si c'est + /- notable suivant le détail, c'est toujorus + lent.
Le 14/12/2011 18:04, Ascadix a écrit :
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Dixit le gars qui 'oublie' de spécifier que Windows Phone est bon à
réinstaller après un petit SMS.
Dixit le gars qui soutiens qu'android est aussi sujet à ce même
problème, mais qui girouette le sujet quand on lui demande des preuves !
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une
remarque insultante?
Te frappe pas, c'est la caractéristique même d' "Hugolino" et qq uns de
ses copains sur fcold, jamais la moindre contribution technique, et des
montagnes d'insultes à l'encontre de toute personne qui intervient sans
adhérer à leur vision dogmatique de Linux en tant que la "Solution"
unique et omnipotente.
Donc, pour ne pas adhérer à la vision dogmatique des utilisateurs de
linux, il faudrait adhérer à la vision totalitaire des utilisateurs de
windows ?
Et le simple fait d'evoquer MS/Windows pour tout autre motif que de
vomir dessus leur provoque des crises de rage relevant plus amha d'un pb
psychiatrique que d'une discussion technique ou même "philosophique".
Comment pourrais tu le savoir, puisque tes interventions ici n'ont été
que du niveau : Linux c'est de la merde, windows c'est mieux !
Le 14/12/2011 18:04, Ascadix a écrit :
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Dixit le gars qui 'oublie' de spécifier que Windows Phone est bon à
réinstaller après un petit SMS.
Dixit le gars qui soutiens qu'android est aussi sujet à ce même
problème, mais qui girouette le sujet quand on lui demande des preuves !
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une
remarque insultante?
Te frappe pas, c'est la caractéristique même d' "Hugolino" et qq uns de
ses copains sur fcold, jamais la moindre contribution technique, et des
montagnes d'insultes à l'encontre de toute personne qui intervient sans
adhérer à leur vision dogmatique de Linux en tant que la "Solution"
unique et omnipotente.
Donc, pour ne pas adhérer à la vision dogmatique des utilisateurs de
linux, il faudrait adhérer à la vision totalitaire des utilisateurs de
windows ?
Et le simple fait d'evoquer MS/Windows pour tout autre motif que de
vomir dessus leur provoque des crises de rage relevant plus amha d'un pb
psychiatrique que d'une discussion technique ou même "philosophique".
Comment pourrais tu le savoir, puisque tes interventions ici n'ont été
que du niveau : Linux c'est de la merde, windows c'est mieux !
Le 14/12/2011 18:04, Ascadix a écrit :
Il y a des groupes où on en trouve pas mal, d'autre comme FCOLD ou c'est
archi-rare, la rêgle générale dans ce ng étant l'insulte, les coups bas,
les traficotages et falsifications de messages.
Dixit le gars qui 'oublie' de spécifier que Windows Phone est bon à
réinstaller après un petit SMS.
Dixit le gars qui soutiens qu'android est aussi sujet à ce même
problème, mais qui girouette le sujet quand on lui demande des preuves !
Si tu débute sur les ngs, passe pas trop de temsp par ici, c'est navrant
et décourageant.
Si tu cherche des infos tech coté Linux, tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Je ne prends pas parti sur qui a raison ou qui a tort, n'ayant pas
d'expertise dans ce domaine, mais pourquoi tout gâcher avec une
remarque insultante?
Te frappe pas, c'est la caractéristique même d' "Hugolino" et qq uns de
ses copains sur fcold, jamais la moindre contribution technique, et des
montagnes d'insultes à l'encontre de toute personne qui intervient sans
adhérer à leur vision dogmatique de Linux en tant que la "Solution"
unique et omnipotente.
Donc, pour ne pas adhérer à la vision dogmatique des utilisateurs de
linux, il faudrait adhérer à la vision totalitaire des utilisateurs de
windows ?
Et le simple fait d'evoquer MS/Windows pour tout autre motif que de
vomir dessus leur provoque des crises de rage relevant plus amha d'un pb
psychiatrique que d'une discussion technique ou même "philosophique".
Comment pourrais tu le savoir, puisque tes interventions ici n'ont été
que du niveau : Linux c'est de la merde, windows c'est mieux !