Je viens de découvrir qu'il est possible d'agrandir les vignettes sous
l'explorateur Windows, en installant Tweak UI (fourni par Micro$oft).
Je trouve que cette manip. rend Acd See nettement moins nécessaire. Acd See
que je trouve parfait, sauf sa p***n de base de données qui rame à
l'écriture et qui est hyper fragmentée et ne me sert à rien.
Une fois les vignettes agrandies sous l'explorateur, Exploreur.exe + apperçu
des photos et télécopies + Ifranview, font (me semble-t-il à première vue),
à peu près ce dont j'ai besoin. Pour infiniment moins cher.
De plus, je ne connais pas le moyen sous XP de défragmenter un seul fichier ou répertoire.
Cela doit être possible en entrant l'adresse et le nom du fichier dans layout.ini, il serait dès lors pris en charge par la défragmentation automatique, mais je n'ai jamais essayé.
-- Jean-Claude Ghislain www.grimart.com
De plus, je ne connais pas le moyen sous XP de défragmenter un seul
fichier ou répertoire.
Cela doit être possible en entrant l'adresse et le nom du fichier dans
layout.ini, il serait dès lors pris en charge par la défragmentation
automatique, mais je n'ai jamais essayé.
De plus, je ne connais pas le moyen sous XP de défragmenter un seul fichier ou répertoire.
Cela doit être possible en entrant l'adresse et le nom du fichier dans layout.ini, il serait dès lors pris en charge par la défragmentation automatique, mais je n'ai jamais essayé.
-- Jean-Claude Ghislain www.grimart.com
see
jean-daniel dodin wrote:
FAb wrote:
Bref tout support fragmente en s'en servant.
renseignez-vous sur
* reiserfs (linux) * xfs (sun, je crois) * jfs (IBM) aucun ne fragmente de façon significative
C'est une légende. Tous les filesystems se fragmentent de façon significative en cas d'utilisation intensive même sous Unix !
Exemple pour défragmenter un FS sous jfs (même jfs2) : <http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.i bm.aix.doc/cmds/aixcmds2/defragfs.htm>
Cela doit être pareil pour les autres fs que tu cites.
-- Bruno http://errance.lirano.net (photographies)
jean-daniel dodin <jdd@dodin.org> wrote:
FAb wrote:
Bref tout support fragmente en s'en servant.
renseignez-vous sur
* reiserfs (linux)
* xfs (sun, je crois)
* jfs (IBM)
aucun ne fragmente de façon significative
C'est une légende.
Tous les filesystems se fragmentent de façon significative en cas
d'utilisation intensive même sous Unix !
Exemple pour défragmenter un FS sous jfs (même jfs2) :
<http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.i
bm.aix.doc/cmds/aixcmds2/defragfs.htm>
Cela doit être pareil pour les autres fs que tu cites.
--
Bruno
http://errance.lirano.net (photographies)
* reiserfs (linux) * xfs (sun, je crois) * jfs (IBM) aucun ne fragmente de façon significative
C'est une légende. Tous les filesystems se fragmentent de façon significative en cas d'utilisation intensive même sous Unix !
Exemple pour défragmenter un FS sous jfs (même jfs2) : <http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.i bm.aix.doc/cmds/aixcmds2/defragfs.htm>
Cela doit être pareil pour les autres fs que tu cites.
-- Bruno http://errance.lirano.net (photographies)
jean-daniel dodin
pehache grmpf wrote:
jean-daniel dodin wrote:
renseignez-vous sur
* reiserfs (linux) * xfs (sun, je crois) * jfs (IBM) aucun ne fragmente de façon significative
La seule explication est qu'il y a un process qui tourne en tâche de fond et qui défragmente en permanence.
Pour les petits fichiers on peut imaginer un système qui attend que le fichier soit complètement écrit en cache mémoire avant de l'écrire sur disque: connaissant la taille du fichier complet, il peut alors l'écrire sur le disque en sélectionnant une zone contigue de taille suffisante. Mais dans le cas général, on ne peut pas empêcher la fragmentation à l'écriture.
non.
il y a différentes façons de stocker un fichier. la plus efficace est de le considérer comme une base de données, avec un arbre de création/indexation (d'où la nécessité du journal pour avoir un index à jour)
de la même façon, au temps du DOS, le traitement de texte "Sprint", de Borland (turbopascal) permettait de naviguer instantanément dans un texte de plusieurs mégas
j'arrète ici sur ce sujet, je crois que ca devient vraiment trop hors charte jdd
-- pour m'écrire, aller sur: http://www.dodin.net
pehache grmpf wrote:
jean-daniel dodin wrote:
renseignez-vous sur
* reiserfs (linux)
* xfs (sun, je crois)
* jfs (IBM)
aucun ne fragmente de façon significative
La seule explication est qu'il y a un process qui tourne en tâche de fond et
qui défragmente en permanence.
Pour les petits fichiers on peut imaginer un système qui attend que le
fichier soit complètement écrit en cache mémoire avant de l'écrire sur
disque: connaissant la taille du fichier complet, il peut alors l'écrire sur
le disque en sélectionnant une zone contigue de taille suffisante. Mais dans
le cas général, on ne peut pas empêcher la fragmentation à l'écriture.
non.
il y a différentes façons de stocker un fichier. la plus
efficace est de le considérer comme une base de données,
avec un arbre de création/indexation (d'où la nécessité du
journal pour avoir un index à jour)
de la même façon, au temps du DOS, le traitement de texte
"Sprint", de Borland (turbopascal) permettait de naviguer
instantanément dans un texte de plusieurs mégas
j'arrète ici sur ce sujet, je crois que ca devient vraiment
trop hors charte
jdd
* reiserfs (linux) * xfs (sun, je crois) * jfs (IBM) aucun ne fragmente de façon significative
La seule explication est qu'il y a un process qui tourne en tâche de fond et qui défragmente en permanence.
Pour les petits fichiers on peut imaginer un système qui attend que le fichier soit complètement écrit en cache mémoire avant de l'écrire sur disque: connaissant la taille du fichier complet, il peut alors l'écrire sur le disque en sélectionnant une zone contigue de taille suffisante. Mais dans le cas général, on ne peut pas empêcher la fragmentation à l'écriture.
non.
il y a différentes façons de stocker un fichier. la plus efficace est de le considérer comme une base de données, avec un arbre de création/indexation (d'où la nécessité du journal pour avoir un index à jour)
de la même façon, au temps du DOS, le traitement de texte "Sprint", de Borland (turbopascal) permettait de naviguer instantanément dans un texte de plusieurs mégas
j'arrète ici sur ce sujet, je crois que ca devient vraiment trop hors charte jdd
-- pour m'écrire, aller sur: http://www.dodin.net
pehache grmpf
jean-daniel dodin wrote:
non. il y a différentes façons de stocker un fichier. la plus efficace est de le considérer comme une base de données, avec un arbre de création/indexation (d'où la nécessité du journal pour avoir un index à jour)
Tu peux expliquer en quoi ça empêche la fragmentation ?
de la même façon, au temps du DOS, le traitement de texte "Sprint", de Borland (turbopascal) permettait de naviguer instantanément dans un texte de plusieurs mégas
Je ne vois pas le rapport. Des tables d'indexation sophistiquées permettent d'améliorer les performances d'accès (on sait plus rapidement où est ce que l'on cherche). Rien à voir avec la fragmentation.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
jean-daniel dodin wrote:
non.
il y a différentes façons de stocker un fichier. la plus
efficace est de le considérer comme une base de données,
avec un arbre de création/indexation (d'où la nécessité du
journal pour avoir un index à jour)
Tu peux expliquer en quoi ça empêche la fragmentation ?
de la même façon, au temps du DOS, le traitement de texte
"Sprint", de Borland (turbopascal) permettait de naviguer
instantanément dans un texte de plusieurs mégas
Je ne vois pas le rapport. Des tables d'indexation sophistiquées permettent
d'améliorer les performances d'accès (on sait plus rapidement où est ce que
l'on cherche). Rien à voir avec la fragmentation.
--
pehache
enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply
http://pehache.free.fr/public.html
non. il y a différentes façons de stocker un fichier. la plus efficace est de le considérer comme une base de données, avec un arbre de création/indexation (d'où la nécessité du journal pour avoir un index à jour)
Tu peux expliquer en quoi ça empêche la fragmentation ?
de la même façon, au temps du DOS, le traitement de texte "Sprint", de Borland (turbopascal) permettait de naviguer instantanément dans un texte de plusieurs mégas
Je ne vois pas le rapport. Des tables d'indexation sophistiquées permettent d'améliorer les performances d'accès (on sait plus rapidement où est ce que l'on cherche). Rien à voir avec la fragmentation.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
Francois Jouve
Bruno Jargot wrote:
jean-daniel dodin wrote:
FAb wrote:
Bref tout support fragmente en s'en servant. renseignez-vous sur
* reiserfs (linux) * xfs (sun, je crois) * jfs (IBM) aucun ne fragmente de façon significative
C'est une légende. Tous les filesystems se fragmentent de façon significative en cas d'utilisation intensive même sous Unix !
Tout dépend de ce qu'on appelle "significative" Sur un disque ext2 ou ext3 sous linux, plein à 70%, utilisé intensivement pendant 5 ans, sans jamais de défragmentation, on a typiquement entre 0.5% et 3% des fichiers fragmentés.
Le moindre windows XP fait beaucoup plus en une journée...
-- F.J.
Bruno Jargot wrote:
jean-daniel dodin <jdd@dodin.org> wrote:
FAb wrote:
Bref tout support fragmente en s'en servant.
renseignez-vous sur
* reiserfs (linux)
* xfs (sun, je crois)
* jfs (IBM)
aucun ne fragmente de façon significative
C'est une légende.
Tous les filesystems se fragmentent de façon significative en cas
d'utilisation intensive même sous Unix !
Tout dépend de ce qu'on appelle "significative"
Sur un disque ext2 ou ext3 sous linux, plein à 70%, utilisé
intensivement pendant 5 ans, sans jamais de défragmentation,
on a typiquement entre 0.5% et 3% des fichiers fragmentés.
Le moindre windows XP fait beaucoup plus en une journée...
Bref tout support fragmente en s'en servant. renseignez-vous sur
* reiserfs (linux) * xfs (sun, je crois) * jfs (IBM) aucun ne fragmente de façon significative
C'est une légende. Tous les filesystems se fragmentent de façon significative en cas d'utilisation intensive même sous Unix !
Tout dépend de ce qu'on appelle "significative" Sur un disque ext2 ou ext3 sous linux, plein à 70%, utilisé intensivement pendant 5 ans, sans jamais de défragmentation, on a typiquement entre 0.5% et 3% des fichiers fragmentés.
Le moindre windows XP fait beaucoup plus en une journée...
-- F.J.
daniel patin
pehache grmpf wrote:
jean-daniel dodin wrote:
non. il y a différentes façons de stocker un fichier. la plus efficace est de le considérer comme une base de données, avec un arbre de création/indexation (d'où la nécessité du journal pour avoir un index à jour)
Tu peux expliquer en quoi ça empêche la fragmentation ?
à ce sujet, une explication est lisible (bien que le texte date un peu) ici:
ceci dit sans esprit contestataire :-) -- daniel.patin (et non pas marcel.dugenou) mon blog : http://leinad.blogspirit.com musique : http://k-dee.blogspot.com/ photos : http://www.flickr.com/photos/leinad-dp/
pehache grmpf wrote:
jean-daniel dodin wrote:
non.
il y a différentes façons de stocker un fichier. la plus
efficace est de le considérer comme une base de données,
avec un arbre de création/indexation (d'où la nécessité du
journal pour avoir un index à jour)
Tu peux expliquer en quoi ça empêche la fragmentation ?
à ce sujet, une explication est lisible (bien que le texte date un peu) ici:
ceci dit sans esprit contestataire :-)
--
daniel.patin (et non pas marcel.dugenou)
mon blog : http://leinad.blogspirit.com
musique : http://k-dee.blogspot.com/
photos : http://www.flickr.com/photos/leinad-dp/
non. il y a différentes façons de stocker un fichier. la plus efficace est de le considérer comme une base de données, avec un arbre de création/indexation (d'où la nécessité du journal pour avoir un index à jour)
Tu peux expliquer en quoi ça empêche la fragmentation ?
à ce sujet, une explication est lisible (bien que le texte date un peu) ici:
ceci dit sans esprit contestataire :-) -- daniel.patin (et non pas marcel.dugenou) mon blog : http://leinad.blogspirit.com musique : http://k-dee.blogspot.com/ photos : http://www.flickr.com/photos/leinad-dp/
pehache
Francois Jouve wrote:
Tout dépend de ce qu'on appelle "significative" Sur un disque ext2 ou ext3 sous linux, plein à 70%, utilisé intensivement pendant 5 ans, sans jamais de défragmentation, on a typiquement entre 0.5% et 3% des fichiers fragmentés.
Le moindre windows XP fait beaucoup plus en une journée...
Ca dépend sans doute du type de partition: ce que je constate sur mon PC, sur lequel j'ai des partitions FAT32 et NTFS, c'est que ce sont surtout les FAT32 qui fragmentent beaucoup, et les NTFS nettement moins.
Donc je suppose que NTFS intègre aussi des fonctionnalités qui luttent contre la fragmentation: soit une tâche de fond qui défragmente après coup (mais là ça m'étonnerait), soit une optimisation à l'écriture, basée sur une hypothèse sur la taille moyenne des fichiers (sans une telle hypothèse je ne vois pas comment ça pourrait marcher).
-- pehache
Francois Jouve wrote:
Tout dépend de ce qu'on appelle "significative"
Sur un disque ext2 ou ext3 sous linux, plein à 70%, utilisé
intensivement pendant 5 ans, sans jamais de défragmentation,
on a typiquement entre 0.5% et 3% des fichiers fragmentés.
Le moindre windows XP fait beaucoup plus en une journée...
Ca dépend sans doute du type de partition: ce que je constate sur mon
PC, sur lequel j'ai des partitions FAT32 et NTFS, c'est que ce sont
surtout les FAT32 qui fragmentent beaucoup, et les NTFS nettement
moins.
Donc je suppose que NTFS intègre aussi des fonctionnalités qui
luttent contre la fragmentation: soit une tâche de fond qui
défragmente après coup (mais là ça m'étonnerait), soit une
optimisation à l'écriture, basée sur une hypothèse sur la taille
moyenne des fichiers (sans une telle hypothèse je ne vois pas comment
ça pourrait marcher).
Tout dépend de ce qu'on appelle "significative" Sur un disque ext2 ou ext3 sous linux, plein à 70%, utilisé intensivement pendant 5 ans, sans jamais de défragmentation, on a typiquement entre 0.5% et 3% des fichiers fragmentés.
Le moindre windows XP fait beaucoup plus en une journée...
Ca dépend sans doute du type de partition: ce que je constate sur mon PC, sur lequel j'ai des partitions FAT32 et NTFS, c'est que ce sont surtout les FAT32 qui fragmentent beaucoup, et les NTFS nettement moins.
Donc je suppose que NTFS intègre aussi des fonctionnalités qui luttent contre la fragmentation: soit une tâche de fond qui défragmente après coup (mais là ça m'étonnerait), soit une optimisation à l'écriture, basée sur une hypothèse sur la taille moyenne des fichiers (sans une telle hypothèse je ne vois pas comment ça pourrait marcher).
-- pehache
Bernard Perrot
pehache wrote:
Donc je suppose que NTFS intègre aussi des fonctionnalités qui luttent contre la fragmentation: soit une tâche de fond qui défragmente après coup (mais là ça m'étonnerait), soit une optimisation à l'écriture, basée sur une hypothèse sur la taille moyenne des fichiers (sans une telle hypothèse je ne vois pas comment ça pourrait marcher).
NTFS est un système de fichiers assez complexe qui se résume mal a ces deux hypothèses. En particulier, NTFS est un filesystem journalisé, et alors, la notion basique de fragmentation héritée de la culture FAT12/16/32 devient un peu obsolète. Il est plus prudent de retenir qu'avec un système de fichier journalisé bien fait, l'utilisateur final doit (devrait) ne pas/plus se préoccuper de ce genre de concept passé.
La "fragmentation" (dispersion) des fichiers d'un filesystem NTFS sur une machine Windows (NT/2000/XP) n'en ayant qu'une, ou ayant de toute façon le fichier de pagination et les répertoires utilisateurs sur la partition principale (C:) est cependant effective. On peut lutter efficacement contre par exemple en :
- en empêchant Windows de recreer/bouger/retailler a tout bout de champ ce fichier de pagination : lui assigner une taille mini = taille maxi - le mettre sur une autre partition que C: (et supprimer celui sur C:) dédiée, qui alors sera plus performante en FAT32 (pas besoin de NTFS pour héberger le pagefile). - déplacer les répertoire utilisateurs sur une autre partition egalement (ni C:, ni celle de pagination).
A propos d'une autre intervention : une base de donnée (relationnelle) n'est pas un arbre.
pehache wrote:
Donc je suppose que NTFS intègre aussi des fonctionnalités qui
luttent contre la fragmentation: soit une tâche de fond qui
défragmente après coup (mais là ça m'étonnerait), soit une
optimisation à l'écriture, basée sur une hypothèse sur la taille
moyenne des fichiers (sans une telle hypothèse je ne vois pas comment
ça pourrait marcher).
NTFS est un système de fichiers assez complexe qui se résume mal a ces deux
hypothèses. En particulier, NTFS est un filesystem journalisé, et alors, la
notion basique de fragmentation héritée de la culture FAT12/16/32 devient un
peu obsolète.
Il est plus prudent de retenir qu'avec un système de fichier journalisé bien
fait, l'utilisateur final doit (devrait) ne pas/plus se préoccuper de ce genre
de concept passé.
La "fragmentation" (dispersion) des fichiers d'un filesystem NTFS sur une
machine Windows (NT/2000/XP) n'en ayant qu'une, ou ayant de toute façon le
fichier de pagination et les répertoires utilisateurs sur la partition
principale (C:) est cependant effective. On peut lutter efficacement contre
par exemple en :
- en empêchant Windows de recreer/bouger/retailler a tout bout de champ ce
fichier de pagination : lui assigner une taille mini = taille maxi
- le mettre sur une autre partition que C: (et supprimer celui sur C:)
dédiée, qui alors sera plus performante en FAT32 (pas besoin de NTFS pour
héberger le pagefile).
- déplacer les répertoire utilisateurs sur une autre partition egalement (ni
C:, ni celle de pagination).
A propos d'une autre intervention : une base de donnée (relationnelle) n'est
pas un arbre.
Donc je suppose que NTFS intègre aussi des fonctionnalités qui luttent contre la fragmentation: soit une tâche de fond qui défragmente après coup (mais là ça m'étonnerait), soit une optimisation à l'écriture, basée sur une hypothèse sur la taille moyenne des fichiers (sans une telle hypothèse je ne vois pas comment ça pourrait marcher).
NTFS est un système de fichiers assez complexe qui se résume mal a ces deux hypothèses. En particulier, NTFS est un filesystem journalisé, et alors, la notion basique de fragmentation héritée de la culture FAT12/16/32 devient un peu obsolète. Il est plus prudent de retenir qu'avec un système de fichier journalisé bien fait, l'utilisateur final doit (devrait) ne pas/plus se préoccuper de ce genre de concept passé.
La "fragmentation" (dispersion) des fichiers d'un filesystem NTFS sur une machine Windows (NT/2000/XP) n'en ayant qu'une, ou ayant de toute façon le fichier de pagination et les répertoires utilisateurs sur la partition principale (C:) est cependant effective. On peut lutter efficacement contre par exemple en :
- en empêchant Windows de recreer/bouger/retailler a tout bout de champ ce fichier de pagination : lui assigner une taille mini = taille maxi - le mettre sur une autre partition que C: (et supprimer celui sur C:) dédiée, qui alors sera plus performante en FAT32 (pas besoin de NTFS pour héberger le pagefile). - déplacer les répertoire utilisateurs sur une autre partition egalement (ni C:, ni celle de pagination).
A propos d'une autre intervention : une base de donnée (relationnelle) n'est pas un arbre.
jean-daniel dodin
daniel patin wrote:
à ce sujet, une explication est lisible (bien que le texte date un peu) ici: http://www.pps.jussieu.fr/~dicosmo/Piege/cybersnare/piege.html
ceci dit sans esprit contestataire :-)
à relire chaque année :-) jdd
-- pour m'écrire, aller sur: http://www.dodin.net
daniel patin wrote:
à ce sujet, une explication est lisible (bien que le texte date un peu)
ici:
http://www.pps.jussieu.fr/~dicosmo/Piege/cybersnare/piege.html
