je ne sais pas vraiement comment intituler le post, je ne retrouve pas le
fil sur lequel J P Roche m'avait répondu
A propos de fichiers qu on n'arrive pas a virer, de fragmentation, mais il
m'avait conseillé Ccleaner et j'ai essayé aussi Defrag, effectivement les
fichiers a la noix ont été detruits, et apres, juste pour voir une défrag
avec diskeepper qui trouve que tout va bien, Defrag lui trouve encore de
l'ordre à faire, ca semble pas mal, merci JP :=)
--
--
Ricco
Mais oui ils fragmentent comme tous les OS mais sous linux la defragmentation est lancée régulièrement tous les 30 lancements par exemple ou tous les X jours
Plutôt la vérification (fschk).
Ca va plus vite que sous win mais je ne sais pas pourquoi
Facile, on se contente de vérifier la cohérence du système de fichiers, pas de jouer au taquin avec les données :) -- Jacques L'helgoualc'h
Le 28-11-2007, bruno a écrit :
[...]
Mais oui ils fragmentent comme tous les OS mais sous linux la
defragmentation est lancée régulièrement tous les 30 lancements par
exemple ou tous les X jours
Plutôt la vérification (fschk).
Ca va plus vite que sous win mais je ne sais pas pourquoi
Facile, on se contente de vérifier la cohérence du système de fichiers,
pas de jouer au taquin avec les données :)
--
Jacques L'helgoualc'h
Mais oui ils fragmentent comme tous les OS mais sous linux la defragmentation est lancée régulièrement tous les 30 lancements par exemple ou tous les X jours
Plutôt la vérification (fschk).
Ca va plus vite que sous win mais je ne sais pas pourquoi
Facile, on se contente de vérifier la cohérence du système de fichiers, pas de jouer au taquin avec les données :) -- Jacques L'helgoualc'h
markorki
les fichiers que l'on modifie se fragmentent. les fichiers que l'on ne fait que lire (ex: les programmes) ne se fragmentent pas. mais un fichier programme est la plupart du temps fragmenté lors de l'installation initiale. .../...
Bonjour, Je n'ai jamais trop bien compris les différences d'écritures/lectures sur disque entre Windows et Linux.
Et, je précise d'emblée : il s'agit d'une question et non de l'ouverture d'un troll. On n'est pas vendredi ;-)
ce n'est pas un troll, c'est une question d'algorithme
cherche sur google avec : memory allocation "best fit" et "first fit" la famille Unix privilégie le best fit par rapport au "first fit" En gros, premier trou que je trouve, ou trou de la taille la plus proche: aussi simple que ça, si on a une cartographie du DD, ça ne prend pas énormément de temps à l'écriture (calcul processeur), et on gagne énormément à la relecture (mouvements de bras de disque, **à_chaque_lecture**)
mais bon, M$ "innove", c'est-à-dire qu'il est capable d'ignorer 20 ans d'état de l'art ou plus, y compris de concepts enseignés dans toutes les écoles depuis parfois le années 70 (voir aussi par ex mwm, alias "windows manager" qui explique qu'on peut sauf chez windows, déplacer une fenêtre même si elle fait un gros calcul ou même si elle est en arrière plan sans perdre son contenu, ou même la différence entre une dll windows et un bibliothèque dynamique -au chargement comme au déchargement- chez les Unix) bon, ne nourrissons pas le troll, on est Mercredi, mais windows dominant, c'est comme le VHS éliminant ses concurrents, et comme-si la Trabant éliminait les Mercedes, BM, et autres hdi-FAP...
les fichiers que l'on modifie se fragmentent. les fichiers que l'on ne
fait que lire (ex: les programmes) ne se fragmentent pas. mais un
fichier programme est la plupart du temps fragmenté lors de
l'installation initiale.
.../...
Bonjour,
Je n'ai jamais trop bien compris les différences d'écritures/lectures
sur disque entre Windows et Linux.
Et, je précise d'emblée : il s'agit d'une question et non de l'ouverture
d'un troll. On n'est pas vendredi ;-)
ce n'est pas un troll, c'est une question d'algorithme
cherche sur google avec : memory allocation "best fit" et "first fit"
la famille Unix privilégie le best fit par rapport au "first fit"
En gros, premier trou que je trouve, ou trou de la taille la plus
proche: aussi simple que ça, si on a une cartographie du DD, ça ne prend
pas énormément de temps à l'écriture (calcul processeur), et on gagne
énormément à la relecture (mouvements de bras de disque,
**à_chaque_lecture**)
mais bon, M$ "innove", c'est-à-dire qu'il est capable d'ignorer 20 ans
d'état de l'art ou plus, y compris de concepts enseignés dans toutes les
écoles depuis parfois le années 70 (voir aussi par ex mwm, alias
"windows manager" qui explique qu'on peut sauf chez windows, déplacer
une fenêtre même si elle fait un gros calcul ou même si elle est en
arrière plan sans perdre son contenu, ou même la différence entre une
dll windows et un bibliothèque dynamique -au chargement comme au
déchargement- chez les Unix)
bon, ne nourrissons pas le troll, on est Mercredi, mais windows
dominant, c'est comme le VHS éliminant ses concurrents, et comme-si la
Trabant éliminait les Mercedes, BM, et autres hdi-FAP...
les fichiers que l'on modifie se fragmentent. les fichiers que l'on ne fait que lire (ex: les programmes) ne se fragmentent pas. mais un fichier programme est la plupart du temps fragmenté lors de l'installation initiale. .../...
Bonjour, Je n'ai jamais trop bien compris les différences d'écritures/lectures sur disque entre Windows et Linux.
Et, je précise d'emblée : il s'agit d'une question et non de l'ouverture d'un troll. On n'est pas vendredi ;-)
ce n'est pas un troll, c'est une question d'algorithme
cherche sur google avec : memory allocation "best fit" et "first fit" la famille Unix privilégie le best fit par rapport au "first fit" En gros, premier trou que je trouve, ou trou de la taille la plus proche: aussi simple que ça, si on a une cartographie du DD, ça ne prend pas énormément de temps à l'écriture (calcul processeur), et on gagne énormément à la relecture (mouvements de bras de disque, **à_chaque_lecture**)
mais bon, M$ "innove", c'est-à-dire qu'il est capable d'ignorer 20 ans d'état de l'art ou plus, y compris de concepts enseignés dans toutes les écoles depuis parfois le années 70 (voir aussi par ex mwm, alias "windows manager" qui explique qu'on peut sauf chez windows, déplacer une fenêtre même si elle fait un gros calcul ou même si elle est en arrière plan sans perdre son contenu, ou même la différence entre une dll windows et un bibliothèque dynamique -au chargement comme au déchargement- chez les Unix) bon, ne nourrissons pas le troll, on est Mercredi, mais windows dominant, c'est comme le VHS éliminant ses concurrents, et comme-si la Trabant éliminait les Mercedes, BM, et autres hdi-FAP...
markorki
On pourrait pourtant supposer que Linux optimise la place sur le disque comme Windows en exploitant tous les espaces disponibles. Or, apparemment il ne le fait pas. Et, pourtant, le disque ne paraît pas pénalisé par des « trous » vides de données disséminés à sa surface...
Des petits trous n'ont pas d'importance ; ce qu'il faut d'abord éviter, c'est que les têtes de lecture jouent à la marelle.
Dans un système de fichiers convenable (utilisé sous Linux ou autre, *BSD, Mac, etc.), la fragmentation ne dépasse guère 2 à 3%, mais la situation se dégrade fortement quand on le taux d'occupation du disque approche de 100%.
Avec un bon système de fichiers, les ennuis commence au-dessus de 90% ; sous windows il paraît que c'est plus tôt...
en fait, quand on traite des photos, on consomme beaucoup de temporaires (zones de "marche arrière" de PSP ou toshop) et donc de fait, même si les données "permanentes" représentent nettement moins de 90% du volume, on "fait tourner" pas mal les allocations de secteurs (enfin, de "granules" alias clusters) sur le DD dès qu'on traite pas mal d'images (par exemple je suis rentré du Japon avec quelques centaines d'images, dont beaucoup (chuis pas bon ;-( avaient besoin d'un peu de cosmétique, recadrage, masquage, etc...)
donc en fait, la fragmentation si le système est enclin à en provoquer, peut arriver assez rapidement, et les différences d'algo se sentent très vite (et oui, fsck, ce n'est pas defrag, juste un équivalent de scandisk un peu moins permissif)
On pourrait pourtant supposer que Linux optimise la place sur le disque
comme Windows en exploitant tous les espaces disponibles. Or,
apparemment il ne le fait pas. Et, pourtant, le disque ne paraît pas
pénalisé par des « trous » vides de données disséminés à sa surface...
Des petits trous n'ont pas d'importance ; ce qu'il faut d'abord éviter,
c'est que les têtes de lecture jouent à la marelle.
Dans un système de fichiers convenable (utilisé sous Linux ou autre,
*BSD, Mac, etc.), la fragmentation ne dépasse guère 2 à 3%, mais la
situation se dégrade fortement quand on le taux d'occupation du disque
approche de 100%.
Avec un bon système de fichiers, les ennuis commence au-dessus de 90% ;
sous windows il paraît que c'est plus tôt...
en fait, quand on traite des photos, on consomme beaucoup de temporaires
(zones de "marche arrière" de PSP ou toshop) et donc de fait, même si
les données "permanentes" représentent nettement moins de 90% du volume,
on "fait tourner" pas mal les allocations de secteurs (enfin, de
"granules" alias clusters) sur le DD dès qu'on traite pas mal d'images
(par exemple je suis rentré du Japon avec quelques centaines d'images,
dont beaucoup (chuis pas bon ;-( avaient besoin d'un peu de cosmétique,
recadrage, masquage, etc...)
donc en fait, la fragmentation si le système est enclin à en provoquer,
peut arriver assez rapidement, et les différences d'algo se sentent très
vite (et oui, fsck, ce n'est pas defrag, juste un équivalent de scandisk
un peu moins permissif)
On pourrait pourtant supposer que Linux optimise la place sur le disque comme Windows en exploitant tous les espaces disponibles. Or, apparemment il ne le fait pas. Et, pourtant, le disque ne paraît pas pénalisé par des « trous » vides de données disséminés à sa surface...
Des petits trous n'ont pas d'importance ; ce qu'il faut d'abord éviter, c'est que les têtes de lecture jouent à la marelle.
Dans un système de fichiers convenable (utilisé sous Linux ou autre, *BSD, Mac, etc.), la fragmentation ne dépasse guère 2 à 3%, mais la situation se dégrade fortement quand on le taux d'occupation du disque approche de 100%.
Avec un bon système de fichiers, les ennuis commence au-dessus de 90% ; sous windows il paraît que c'est plus tôt...
en fait, quand on traite des photos, on consomme beaucoup de temporaires (zones de "marche arrière" de PSP ou toshop) et donc de fait, même si les données "permanentes" représentent nettement moins de 90% du volume, on "fait tourner" pas mal les allocations de secteurs (enfin, de "granules" alias clusters) sur le DD dès qu'on traite pas mal d'images (par exemple je suis rentré du Japon avec quelques centaines d'images, dont beaucoup (chuis pas bon ;-( avaient besoin d'un peu de cosmétique, recadrage, masquage, etc...)
donc en fait, la fragmentation si le système est enclin à en provoquer, peut arriver assez rapidement, et les différences d'algo se sentent très vite (et oui, fsck, ce n'est pas defrag, juste un équivalent de scandisk un peu moins permissif)
Jean-Pierre Roche
donc en fait, la fragmentation si le système est enclin à en provoquer, peut arriver assez rapidement, et les différences d'algo se sentent très vite
Oui mais on peut aussi (avec les bons logiciels) loger les données temporaires sur une partition ou un disque dédié...
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
donc en fait, la fragmentation si le système est enclin à en provoquer,
peut arriver assez rapidement, et les différences d'algo se sentent très
vite
Oui mais on peut aussi (avec les bons logiciels) loger les
données temporaires sur une partition ou un disque dédié...
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
donc en fait, la fragmentation si le système est enclin à en provoquer, peut arriver assez rapidement, et les différences d'algo se sentent très vite
Oui mais on peut aussi (avec les bons logiciels) loger les données temporaires sur une partition ou un disque dédié...
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Jean-Claude Ghislain
en fait, quand on traite des photos, on consomme beaucoup de temporaires
Il est judicieux de diriger ces temporaires vers des partitions dédiées, l'avantage est double, cela ne fragmente pas l'entièreté du disque et les données temporaires sont toujours dans une zone non fragmentée, d'où un gain de vitesse.
Depuis 1970 ce ne sont pas les systèmes de fichiers qui manquent : http://fr.wikipedia.org/wiki/Comparaison_des_syst%C3%A8mes_de_fichiers
Le nouveau WinFS de Microsoft semble arriver : http://fr.wikipedia.org/wiki/WinFS
-- Jean-Claude Ghislain www.grimart.com
en fait, quand on traite des photos, on consomme beaucoup de
temporaires
Il est judicieux de diriger ces temporaires vers des partitions dédiées,
l'avantage est double, cela ne fragmente pas l'entièreté du disque et
les données temporaires sont toujours dans une zone non fragmentée, d'où
un gain de vitesse.
Depuis 1970 ce ne sont pas les systèmes de fichiers qui manquent :
http://fr.wikipedia.org/wiki/Comparaison_des_syst%C3%A8mes_de_fichiers
Le nouveau WinFS de Microsoft semble arriver :
http://fr.wikipedia.org/wiki/WinFS
en fait, quand on traite des photos, on consomme beaucoup de temporaires
Il est judicieux de diriger ces temporaires vers des partitions dédiées, l'avantage est double, cela ne fragmente pas l'entièreté du disque et les données temporaires sont toujours dans une zone non fragmentée, d'où un gain de vitesse.
Depuis 1970 ce ne sont pas les systèmes de fichiers qui manquent : http://fr.wikipedia.org/wiki/Comparaison_des_syst%C3%A8mes_de_fichiers
Le nouveau WinFS de Microsoft semble arriver : http://fr.wikipedia.org/wiki/WinFS
-- Jean-Claude Ghislain www.grimart.com
Jean-Claude Ghislain
Pourquoi la fragmentation n'existe-t-elle pas sous Linux ?
Comme déjà répondu, elle existe : http://fr.wikipedia.org/wiki/Ext2
-- Jean-Claude Ghislain www.grimart.com
Pourquoi la fragmentation n'existe-t-elle pas sous Linux ?
Comme déjà répondu, elle existe :
http://fr.wikipedia.org/wiki/Ext2
Pourquoi la fragmentation n'existe-t-elle pas sous Linux ?
Comme déjà répondu, elle existe : http://fr.wikipedia.org/wiki/Ext2
-- Jean-Claude Ghislain www.grimart.com
Ofnuts
Jacques L'helgoualc'h wrote:
[...]
Mais oui ils fragmentent comme tous les OS mais sous linux la defragmentation est lancée régulièrement tous les 30 lancements par exemple ou tous les X jours
Plutôt la vérification (fschk).
Ca va plus vite que sous win mais je ne sais pas pourquoi
Facile, on se contente de vérifier la cohérence du système de fichiers, pas de jouer au taquin avec les données :)
Oui, normalement, les filesystems Unix (ext2/3, reiserfs et autres) sont moins sensibles à la fragmentation (ne pas oublier que ce sont des FS normalement taillés pour des serveurs qu'on ne reboote pour ainsi dire jamais...)
Par ailleurs, pour ceux qui redémarrent souvent leur Linux, plutôt qu'être bloqué tous les 30 jours par un fsck sur tous les FS en même temps, définir un intervalle différent pour chaque FS, et les choisir premiers entre eux (par ex: 23, 29, 31)(pour 3 FS, la totale tous les 20677 jours...).
-- Bd.
Jacques L'helgoualc'h wrote:
[...]
Mais oui ils fragmentent comme tous les OS mais sous linux la
defragmentation est lancée régulièrement tous les 30 lancements par
exemple ou tous les X jours
Plutôt la vérification (fschk).
Ca va plus vite que sous win mais je ne sais pas pourquoi
Facile, on se contente de vérifier la cohérence du système de fichiers,
pas de jouer au taquin avec les données :)
Oui, normalement, les filesystems Unix (ext2/3, reiserfs et autres) sont
moins sensibles à la fragmentation (ne pas oublier que ce sont des FS
normalement taillés pour des serveurs qu'on ne reboote pour ainsi dire
jamais...)
Par ailleurs, pour ceux qui redémarrent souvent leur Linux, plutôt
qu'être bloqué tous les 30 jours par un fsck sur tous les FS en même
temps, définir un intervalle différent pour chaque FS, et les choisir
premiers entre eux (par ex: 23, 29, 31)(pour 3 FS, la totale tous les
20677 jours...).
Mais oui ils fragmentent comme tous les OS mais sous linux la defragmentation est lancée régulièrement tous les 30 lancements par exemple ou tous les X jours
Plutôt la vérification (fschk).
Ca va plus vite que sous win mais je ne sais pas pourquoi
Facile, on se contente de vérifier la cohérence du système de fichiers, pas de jouer au taquin avec les données :)
Oui, normalement, les filesystems Unix (ext2/3, reiserfs et autres) sont moins sensibles à la fragmentation (ne pas oublier que ce sont des FS normalement taillés pour des serveurs qu'on ne reboote pour ainsi dire jamais...)
Par ailleurs, pour ceux qui redémarrent souvent leur Linux, plutôt qu'être bloqué tous les 30 jours par un fsck sur tous les FS en même temps, définir un intervalle différent pour chaque FS, et les choisir premiers entre eux (par ex: 23, 29, 31)(pour 3 FS, la totale tous les 20677 jours...).
-- Bd.
markorki
donc en fait, la fragmentation si le système est enclin à en provoquer, peut arriver assez rapidement, et les différences d'algo se sentent très vite
Oui mais on peut aussi (avec les bons logiciels) loger les données temporaires sur une partition ou un disque dédié...
bien sûr, mais ces temporaires rameront assez vite, or PSP ou autre en
mode "système de retour en arrière activé" ne peut qu'attendre la fin de la sauvegarde d'un état avant d'accepter de nouvelles modifs.
Ce n'est pas la partition système ou programmes, mais bien les temporaires qui sont cause mais aussi sensibles à la fragmentation. Bref, cette partitionnséparée protège les zones programme et système, mais la fragmentation fait dans une autre partition les dégats qu'elle ferait sur C: ( perso je n'ai que windows, Programchose et les "temporary internet files" sur C:, parce que quand on déplace "temporary internet files" dans la BDR , certains process utilisent quand-même le chemin C: pour windowsTempIF et windowstmp )
donc en fait, la fragmentation si le système est enclin à en
provoquer, peut arriver assez rapidement, et les différences d'algo se
sentent très vite
Oui mais on peut aussi (avec les bons logiciels) loger les données
temporaires sur une partition ou un disque dédié...
bien sûr, mais ces temporaires rameront assez vite, or PSP ou autre en
mode "système de retour en arrière activé" ne peut qu'attendre la fin de
la sauvegarde d'un état avant d'accepter de nouvelles modifs.
Ce n'est pas la partition système ou programmes, mais bien les
temporaires qui sont cause mais aussi sensibles à la fragmentation.
Bref, cette partitionnséparée protège les zones programme et système,
mais la fragmentation fait dans une autre partition les dégats qu'elle
ferait sur C: ( perso je n'ai que windows, Programchose et les
"temporary internet files" sur C:, parce que quand on déplace "temporary
internet files" dans la BDR , certains process utilisent quand-même le
chemin C: pour windowsTempIF et windowstmp )
donc en fait, la fragmentation si le système est enclin à en provoquer, peut arriver assez rapidement, et les différences d'algo se sentent très vite
Oui mais on peut aussi (avec les bons logiciels) loger les données temporaires sur une partition ou un disque dédié...
bien sûr, mais ces temporaires rameront assez vite, or PSP ou autre en
mode "système de retour en arrière activé" ne peut qu'attendre la fin de la sauvegarde d'un état avant d'accepter de nouvelles modifs.
Ce n'est pas la partition système ou programmes, mais bien les temporaires qui sont cause mais aussi sensibles à la fragmentation. Bref, cette partitionnséparée protège les zones programme et système, mais la fragmentation fait dans une autre partition les dégats qu'elle ferait sur C: ( perso je n'ai que windows, Programchose et les "temporary internet files" sur C:, parce que quand on déplace "temporary internet files" dans la BDR , certains process utilisent quand-même le chemin C: pour windowsTempIF et windowstmp )
markorki
en fait, quand on traite des photos, on consomme beaucoup de temporaires
Il est judicieux de diriger ces temporaires vers des partitions dédiées, l'avantage est double, cela ne fragmente pas l'entièreté du disque et les données temporaires sont toujours dans une zone non fragmentée, d'où un gain de vitesse.
oui si on reformate avant de bosser le fragmentation touche **aussi** les zones libres : quand on efface (avec ou sans passage corbeille) un fichier sous Zindoz, les zones libres restent fragmentées (je suppose que les granules libres sont juste remis dans une liste dans l'ordre de libération)
une façon simple de le vérifier: effacer tout sur une partoche, et lancer la défragmentation: elle va bosser comme s'il y aavait des fichiers (au moins en fat, et **beaucoup** de XP fonctionnent plutôt en FAT qu'en NTFS, comme les portables ASUS au moins, et au moins certains HP, peut-être entre autres pour raison de disponibilité d'outillage de réparation ;-)
en fait, quand on traite des photos, on consomme beaucoup de temporaires
Il est judicieux de diriger ces temporaires vers des partitions dédiées,
l'avantage est double, cela ne fragmente pas l'entièreté du disque et
les données temporaires sont toujours dans une zone non fragmentée, d'où
un gain de vitesse.
oui si on reformate avant de bosser
le fragmentation touche **aussi** les zones libres : quand on efface
(avec ou sans passage corbeille) un fichier sous Zindoz, les zones
libres restent fragmentées (je suppose que les granules libres sont
juste remis dans une liste dans l'ordre de libération)
une façon simple de le vérifier: effacer tout sur une partoche, et
lancer la défragmentation: elle va bosser comme s'il y aavait des
fichiers (au moins en fat, et **beaucoup** de XP fonctionnent plutôt en
FAT qu'en NTFS, comme les portables ASUS au moins, et au moins certains
HP, peut-être entre autres pour raison de disponibilité d'outillage de
réparation ;-)
en fait, quand on traite des photos, on consomme beaucoup de temporaires
Il est judicieux de diriger ces temporaires vers des partitions dédiées, l'avantage est double, cela ne fragmente pas l'entièreté du disque et les données temporaires sont toujours dans une zone non fragmentée, d'où un gain de vitesse.
oui si on reformate avant de bosser le fragmentation touche **aussi** les zones libres : quand on efface (avec ou sans passage corbeille) un fichier sous Zindoz, les zones libres restent fragmentées (je suppose que les granules libres sont juste remis dans une liste dans l'ordre de libération)
une façon simple de le vérifier: effacer tout sur une partoche, et lancer la défragmentation: elle va bosser comme s'il y aavait des fichiers (au moins en fat, et **beaucoup** de XP fonctionnent plutôt en FAT qu'en NTFS, comme les portables ASUS au moins, et au moins certains HP, peut-être entre autres pour raison de disponibilité d'outillage de réparation ;-)
Jean-Pierre Roche
**beaucoup** de XP fonctionnent plutôt en FAT qu'en NTFS, comme les portables ASUS au moins, et au moins certains HP, peut-être entre autres pour raison de disponibilité d'outillage de réparation ;-)
C'était le cas avec XP mais maintenant tout est sous Vista et semble bien en NTFS.
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
**beaucoup** de XP fonctionnent plutôt en
FAT qu'en NTFS, comme les portables ASUS au moins, et au moins certains
HP, peut-être entre autres pour raison de disponibilité d'outillage de
réparation ;-)
C'était le cas avec XP mais maintenant tout est sous Vista
et semble bien en NTFS.
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
**beaucoup** de XP fonctionnent plutôt en FAT qu'en NTFS, comme les portables ASUS au moins, et au moins certains HP, peut-être entre autres pour raison de disponibilité d'outillage de réparation ;-)
C'était le cas avec XP mais maintenant tout est sous Vista et semble bien en NTFS.
