Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k. Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A partir de 2 blocs il y a un risque que les deux blocs ne soient pas consécutifs, et le risque augmente évidemment avec le nombre de blocs. Si le fichier est assez gros il faut des blocs indirects, et s'il est encore plus gros des blocs avec double indirection. Ca veut dire qu'un bloc contient par exemple les numéros des blocs suivants du fichier. A partir de là la probabilité augmente encore de fragmentation. Bref il semble intuitif que les très gros fichiers ont une probabilité importante d'être fragmentés, ce qui n'est pas non plus une catastrophe terrible, si de grandes parties du fichier peuvent être lus de manière consécutive. En pratique je crois que la majorité des fichiers sur un système Unix sont petits, sauf évidemment situation particulière telle que images ISO, etc.
Je me souviens à ce propos d'une technique très simple pour limiter la fragmentation dans un système avec des petits blocs et de très gros blocs. C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que l'uptime devenait conséquent. La solution était d'allouer les petits blocs à la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de l'utilisateur ...
Hohohohohoooooooooooohhhhhhhhhhhhhhooooooo
-- P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède désormais son blog p4nd1-p4nd4.over-blog.com
Toxico Nimbus avait énoncé :
Le 15/04/2010 16:32, Michel Talon a écrit :
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Je me souviens à ce propos d'une technique très simple pour limiter la
fragmentation dans un système avec des petits blocs et de très gros blocs.
C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance
à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que
l'uptime devenait conséquent. La solution était d'allouer les petits blocs à
la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de
l'utilisateur ...
Hohohohohoooooooooooohhhhhhhhhhhhhhooooooo
--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k. Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A partir de 2 blocs il y a un risque que les deux blocs ne soient pas consécutifs, et le risque augmente évidemment avec le nombre de blocs. Si le fichier est assez gros il faut des blocs indirects, et s'il est encore plus gros des blocs avec double indirection. Ca veut dire qu'un bloc contient par exemple les numéros des blocs suivants du fichier. A partir de là la probabilité augmente encore de fragmentation. Bref il semble intuitif que les très gros fichiers ont une probabilité importante d'être fragmentés, ce qui n'est pas non plus une catastrophe terrible, si de grandes parties du fichier peuvent être lus de manière consécutive. En pratique je crois que la majorité des fichiers sur un système Unix sont petits, sauf évidemment situation particulière telle que images ISO, etc.
Je me souviens à ce propos d'une technique très simple pour limiter la fragmentation dans un système avec des petits blocs et de très gros blocs. C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que l'uptime devenait conséquent. La solution était d'allouer les petits blocs à la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de l'utilisateur ...
Hohohohohoooooooooooohhhhhhhhhhhhhhooooooo
-- P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède désormais son blog p4nd1-p4nd4.over-blog.com
leeed
Le 16-04-2010, P4nd1-P4nd4 <P4nd1-P4nd4@> a écrit :
Toxico Nimbus avait énoncé :
Le 15/04/2010 16:32, Michel Talon a écrit :
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k. Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A partir de 2 blocs il y a un risque que les deux blocs ne soient pas consécutifs, et le risque augmente évidemment avec le nombre de blocs. Si le fichier est assez gros il faut des blocs indirects, et s'il est encore plus gros des blocs avec double indirection. Ca veut dire qu'un bloc contient par exemple les numéros des blocs suivants du fichier. A partir de là la probabilité augmente encore de fragmentation. Bref il semble intuitif que les très gros fichiers ont une probabilité importante d'être fragmentés, ce qui n'est pas non plus une catastrophe terrible, si de grandes parties du fichier peuvent être lus de manière consécutive. En pratique je crois que la majorité des fichiers sur un système Unix sont petits, sauf évidemment situation particulière telle que images ISO, etc.
Je me souviens à ce propos d'une technique très simple pour limiter la fragmentation dans un système avec des petits blocs et de très gros blocs. C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que l'uptime devenait conséquent. La solution était d'allouer les petits blocs à la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de l'utilisateur ...
Hohohohohoooooooooooohhhhhhhhhhhhhhooooooo
Tu ne sais vraiment pas lire et comprendre un texte simple de 5 lignes, avec 3 phrases. Le monsieur te parle de la façon pour le système et les programmeurs sous AmigaOS d'allouer de la mémoire *vive* (non paginée, de plus les 68k sur Amiga n'avaient en général pas de MMU, donc la mémoire dite "virtuelle" était gérée par les applications elles mêmes dans leur propre fichier de swap - exemple, ImageFX, Wordworth… et non par l'OS. En même temps les applis étaient tellement légères et optimisées que le swap était rarement nécessaire.). Toi, tu parles d'utilisateur, comme si les gens s'amusaient à allouer à la main les petits blocs de mémoire pour leurs softs. C'est vraiment de l'ignorance crasse. Et là, c'est moi qui fait mwahahaha!
Le 16-04-2010, P4nd1-P4nd4 <P4nd1-P4nd4@> a écrit :
Toxico Nimbus avait énoncé :
Le 15/04/2010 16:32, Michel Talon a écrit :
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k.
Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A
partir de 2 blocs il y a un risque que les deux blocs ne soient pas
consécutifs, et le risque augmente évidemment avec le nombre de blocs.
Si le fichier est assez gros il faut des blocs indirects, et s'il est
encore plus gros des blocs avec double indirection. Ca veut dire qu'un
bloc contient par exemple les numéros des blocs suivants du fichier.
A partir de là la probabilité augmente encore de fragmentation. Bref
il semble intuitif que les très gros fichiers ont une probabilité
importante d'être fragmentés, ce qui n'est pas non plus une catastrophe
terrible, si de grandes parties du fichier peuvent être lus de manière
consécutive. En pratique je crois que la majorité des fichiers sur un
système Unix sont petits, sauf évidemment situation particulière telle
que images ISO, etc.
Je me souviens à ce propos d'une technique très simple pour limiter la
fragmentation dans un système avec des petits blocs et de très gros blocs.
C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance
à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que
l'uptime devenait conséquent. La solution était d'allouer les petits blocs à
la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de
l'utilisateur ...
Hohohohohoooooooooooohhhhhhhhhhhhhhooooooo
Tu ne sais vraiment pas lire et comprendre un texte simple de 5 lignes,
avec 3 phrases. Le monsieur te parle de la façon pour le système et les
programmeurs sous AmigaOS d'allouer de la mémoire *vive* (non paginée,
de plus les 68k sur Amiga n'avaient en général pas de MMU, donc la
mémoire dite "virtuelle" était gérée par les applications elles mêmes
dans leur propre fichier de swap - exemple, ImageFX, Wordworth… et non
par l'OS. En même temps les applis étaient tellement légères et
optimisées que le swap était rarement nécessaire.). Toi, tu parles
d'utilisateur, comme si les gens s'amusaient à allouer à la main les
petits blocs de mémoire pour leurs softs.
C'est vraiment de l'ignorance crasse.
Et là, c'est moi qui fait mwahahaha!
Le 16-04-2010, P4nd1-P4nd4 <P4nd1-P4nd4@> a écrit :
Toxico Nimbus avait énoncé :
Le 15/04/2010 16:32, Michel Talon a écrit :
Les fichiers sont stockés dans des blocs, d'une taille de l'order de 4k. Tant que le fichier tient dans un bloc, il ne va pas être fragmenté. A partir de 2 blocs il y a un risque que les deux blocs ne soient pas consécutifs, et le risque augmente évidemment avec le nombre de blocs. Si le fichier est assez gros il faut des blocs indirects, et s'il est encore plus gros des blocs avec double indirection. Ca veut dire qu'un bloc contient par exemple les numéros des blocs suivants du fichier. A partir de là la probabilité augmente encore de fragmentation. Bref il semble intuitif que les très gros fichiers ont une probabilité importante d'être fragmentés, ce qui n'est pas non plus une catastrophe terrible, si de grandes parties du fichier peuvent être lus de manière consécutive. En pratique je crois que la majorité des fichiers sur un système Unix sont petits, sauf évidemment situation particulière telle que images ISO, etc.
Je me souviens à ce propos d'une technique très simple pour limiter la fragmentation dans un système avec des petits blocs et de très gros blocs. C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que l'uptime devenait conséquent. La solution était d'allouer les petits blocs à la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de l'utilisateur ...
Hohohohohoooooooooooohhhhhhhhhhhhhhooooooo
Tu ne sais vraiment pas lire et comprendre un texte simple de 5 lignes, avec 3 phrases. Le monsieur te parle de la façon pour le système et les programmeurs sous AmigaOS d'allouer de la mémoire *vive* (non paginée, de plus les 68k sur Amiga n'avaient en général pas de MMU, donc la mémoire dite "virtuelle" était gérée par les applications elles mêmes dans leur propre fichier de swap - exemple, ImageFX, Wordworth… et non par l'OS. En même temps les applis étaient tellement légères et optimisées que le swap était rarement nécessaire.). Toi, tu parles d'utilisateur, comme si les gens s'amusaient à allouer à la main les petits blocs de mémoire pour leurs softs. C'est vraiment de l'ignorance crasse. Et là, c'est moi qui fait mwahahaha!
debug this fifo
P4nd1-P4nd4 wrote:
Je me souviens à ce propos d'une technique très simple pour limiter la fragmentation dans un système avec des petits blocs et de très gros blocs. C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que l'uptime devenait conséquent. La solution était d'allouer les petits blocs à la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de l'utilisateur ...
putain, mais il ne comprend meme plus le français ! proutiprouta est le premier kroteux a etre passé directement de l'imbécilité à l'obsolescence.
Hohohohohoooooooooooohhhhhhhhhhhhhhooooooo
un orgasme sans statistique ? pas credible...
P4nd1-P4nd4 wrote:
Je me souviens à ce propos d'une technique très simple pour limiter la
fragmentation dans un système avec des petits blocs et de très gros
blocs. C'était un système utilisé sur Amiga où la mémoire non paginée
avait tendance à fragmenter (l'espace libre bien sûr), ce qui était
problématique dès que l'uptime devenait conséquent. La solution était
d'allouer les petits blocs à la fin de l'espace mémoire et les gros au
début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de
l'utilisateur ...
putain, mais il ne comprend meme plus le français ! proutiprouta est
le premier kroteux a etre passé directement de l'imbécilité à
l'obsolescence.
Je me souviens à ce propos d'une technique très simple pour limiter la fragmentation dans un système avec des petits blocs et de très gros blocs. C'était un système utilisé sur Amiga où la mémoire non paginée avait tendance à fragmenter (l'espace libre bien sûr), ce qui était problématique dès que l'uptime devenait conséquent. La solution était d'allouer les petits blocs à la fin de l'espace mémoire et les gros au début (ou l'inverse)
En effet c'est très pratique à gérer, c'est vraiment le rôle de l'utilisateur ...
putain, mais il ne comprend meme plus le français ! proutiprouta est le premier kroteux a etre passé directement de l'imbécilité à l'obsolescence.
