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.
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é.
Alors là il va falloir m'expliquer le rapport entre journalisation et fragmentation.
La journalisation permet d'éviter les incohérences du file system en cas de crash, alors que la fragmentation concerne l'allocation des blocs.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Bernard Perrot <bernard.perrot@univ-rennes1.fr> writes:
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é.
Alors là il va falloir m'expliquer le rapport entre journalisation et
fragmentation.
La journalisation permet d'éviter les incohérences du file system en
cas de crash, alors que la fragmentation concerne l'allocation des blocs.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
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é.
Alors là il va falloir m'expliquer le rapport entre journalisation et fragmentation.
La journalisation permet d'éviter les incohérences du file system en cas de crash, alors que la fragmentation concerne l'allocation des blocs.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Jean-Claude Ghislain
- en empêchant Windows de recreer/bouger/retailler a tout bout de champ ce fichier de pagination : lui assigner une taille mini = taille maxi
Conseil valable pour toutes machines Windows.
- 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).
Dans mon cas, le fichier de pagination est sur un autre disque, dans une partition dédiée et formatée en FAT16.
- déplacer les répertoire utilisateurs sur une autre partition egalement (ni C:, ni celle de pagination).
En suivant ces petits conseils, ma partition C: n'est jamais très fragmentée, de l'ordre de 1% en général.
-- Jean-Claude Ghislain www.grimart.com
- en empêchant Windows de recreer/bouger/retailler a tout bout de
champ ce fichier de pagination : lui assigner une taille mini =
taille maxi
Conseil valable pour toutes machines Windows.
- 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).
Dans mon cas, le fichier de pagination est sur un autre disque, dans une
partition dédiée et formatée en FAT16.
- déplacer les répertoire utilisateurs sur une autre partition
egalement (ni C:, ni celle de pagination).
En suivant ces petits conseils, ma partition C: n'est jamais très
fragmentée, de l'ordre de 1% en général.
- en empêchant Windows de recreer/bouger/retailler a tout bout de champ ce fichier de pagination : lui assigner une taille mini = taille maxi
Conseil valable pour toutes machines Windows.
- 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).
Dans mon cas, le fichier de pagination est sur un autre disque, dans une partition dédiée et formatée en FAT16.
- déplacer les répertoire utilisateurs sur une autre partition egalement (ni C:, ni celle de pagination).
En suivant ces petits conseils, ma partition C: n'est jamais très fragmentée, de l'ordre de 1% en général.
-- Jean-Claude Ghislain www.grimart.com
pehache
Jean-Claude Ghislain wrote:
à relire chaque année :-)
Sans oublier d'évoluer, Windows n'en est plus au système de fichiers évoqué dans l'article.
Tout à fait, on n'est plus obligé d'utiliser FAT32 aujourd'hui sous Windows.
On y voit que NTFS est un système de fichiers tout aussi sophistiqué que ext2fs, notamment en ce qui concerne la préallocation des clusters (donc la fragmentation). Simplement, les principes et stratégies de ces deux systèmes de fichiers étant différents, l'un ou l'autre pourra être plus efficace suivant les cas et les applications (par exemple NTFS semble plus adapté à la gestion de nombreux petits fichiers, ext2fs plus adapté à la gestion de gros fichiers).
-- pehache
Jean-Claude Ghislain wrote:
à relire chaque année :-)
Sans oublier d'évoluer, Windows n'en est plus au système de fichiers
évoqué dans l'article.
Tout à fait, on n'est plus obligé d'utiliser FAT32 aujourd'hui sous
Windows.
On y voit que NTFS est un système de fichiers tout aussi sophistiqué
que ext2fs, notamment en ce qui concerne la préallocation des clusters
(donc la fragmentation). Simplement, les principes et stratégies de
ces deux systèmes de fichiers étant différents, l'un ou l'autre
pourra être plus efficace suivant les cas et les applications (par
exemple NTFS semble plus adapté à la gestion de nombreux petits
fichiers, ext2fs plus adapté à la gestion de gros fichiers).
On y voit que NTFS est un système de fichiers tout aussi sophistiqué que ext2fs, notamment en ce qui concerne la préallocation des clusters (donc la fragmentation). Simplement, les principes et stratégies de ces deux systèmes de fichiers étant différents, l'un ou l'autre pourra être plus efficace suivant les cas et les applications (par exemple NTFS semble plus adapté à la gestion de nombreux petits fichiers, ext2fs plus adapté à la gestion de gros fichiers).
-- pehache
mdnews
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 :-)
A mettre aussi sans complexe sur le tas de compost de l'histoire informatique (*1998*) Depuis Windows 2000 et surtout depuis les HD rapides avec cache, on n'a plus aucun besoin de défragmenter. Mais c'est joli et ça fait vendre des logiciels qui déplacent des petits carrés (un Tetris horizontal automatique :-) On défragmentait surtout à l'époque des disques dur MFM uniquement pour économiser sur les mouvements mécanique des têtes de disques. Question logiciel, on ne gagne rien.
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 :-)
A mettre aussi sans complexe sur le tas de compost de l'histoire
informatique (*1998*)
Depuis Windows 2000 et surtout depuis les HD rapides avec cache, on n'a
plus aucun besoin de défragmenter. Mais c'est joli et ça fait vendre des
logiciels qui déplacent des petits carrés (un Tetris horizontal automatique
:-)
On défragmentait surtout à l'époque des disques dur MFM uniquement pour
économiser sur les mouvements mécanique des têtes de disques. Question
logiciel, on ne gagne rien.
à 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 :-)
A mettre aussi sans complexe sur le tas de compost de l'histoire informatique (*1998*) Depuis Windows 2000 et surtout depuis les HD rapides avec cache, on n'a plus aucun besoin de défragmenter. Mais c'est joli et ça fait vendre des logiciels qui déplacent des petits carrés (un Tetris horizontal automatique :-) On défragmentait surtout à l'époque des disques dur MFM uniquement pour économiser sur les mouvements mécanique des têtes de disques. Question logiciel, on ne gagne rien.
Bernard Perrot
FiLH wrote:
Alors là il va falloir m'expliquer le rapport entre journalisation et fragmentation.
il y en a forcement un, car le support d'ecriture est le meme...
La journalisation permet d'éviter les incohérences du file system en cas de crash, alors que la fragmentation concerne l'allocation des blocs.
La journalisation ajoute une couche d'abstraction dans l'accès au fragments des fichiers, la perception intuitive que la fragmentation oblige la tete de lecture a se deplacer plus devient moins adequate car il faut aussi acceder a des données de journalisation a chaque transaction de toute façon. Et on pourrait aussi ajouter qu'avec les disque SATA desormais (tout comme avec les disques SCSI depuis longtemps), la dispersion geometrique des données a lire sur la surface du disque est moins generatrice de perte de performances, car les requetes sont reordonnées en fonction de la geométrie justement. Les utilisateurs de systemes multiutilisateurs (Unix) savent aussi que la notion de fragmentation est importante quand il n'y a qu'un seul utilisateur qui accede a un seul fichier a la fois. Parce que de toute facon, meme si les fichiers de chacun ne sont pas fragmentés, quand plusieurs personnes veulent chacune accédder a leur fichier, il y a forcement necessité de balader la tête de lecture. D'ou l'interet de l'usage des disques SCSI dans de tels environnement, et SATA maintenant.
Comme on va etre très vite encore plus HS dans ce groupe, disons que avec un filesystem "moderne" sur un disque "moderne", on n'en a plus rien a fiche de savoir où est écrit un fichier et comment sur le support de stockage. Et c'est bien !
FiLH wrote:
Alors là il va falloir m'expliquer le rapport entre journalisation et
fragmentation.
il y en a forcement un, car le support d'ecriture est le meme...
La journalisation permet d'éviter les incohérences du file system en
cas de crash, alors que la fragmentation concerne l'allocation des blocs.
La journalisation ajoute une couche d'abstraction dans l'accès au fragments
des fichiers, la perception intuitive que la fragmentation oblige la tete de
lecture a se deplacer plus devient moins adequate car il faut aussi acceder a
des données de journalisation a chaque transaction de toute façon. Et on
pourrait aussi ajouter qu'avec les disque SATA desormais (tout comme avec les
disques SCSI depuis longtemps), la dispersion geometrique des données a lire
sur la surface du disque est moins generatrice de perte de performances, car
les requetes sont reordonnées en fonction de la geométrie justement. Les
utilisateurs de systemes multiutilisateurs (Unix) savent aussi que la notion
de fragmentation est importante quand il n'y a qu'un seul utilisateur qui
accede a un seul fichier a la fois. Parce que de toute facon, meme si les
fichiers de chacun ne sont pas fragmentés, quand plusieurs personnes veulent
chacune accédder a leur fichier, il y a forcement necessité de balader la tête
de lecture. D'ou l'interet de l'usage des disques SCSI dans de tels
environnement, et SATA maintenant.
Comme on va etre très vite encore plus HS dans ce groupe, disons que avec un
filesystem "moderne" sur un disque "moderne", on n'en a plus rien a fiche de
savoir où est écrit un fichier et comment sur le support de stockage. Et c'est
bien !
Alors là il va falloir m'expliquer le rapport entre journalisation et fragmentation.
il y en a forcement un, car le support d'ecriture est le meme...
La journalisation permet d'éviter les incohérences du file system en cas de crash, alors que la fragmentation concerne l'allocation des blocs.
La journalisation ajoute une couche d'abstraction dans l'accès au fragments des fichiers, la perception intuitive que la fragmentation oblige la tete de lecture a se deplacer plus devient moins adequate car il faut aussi acceder a des données de journalisation a chaque transaction de toute façon. Et on pourrait aussi ajouter qu'avec les disque SATA desormais (tout comme avec les disques SCSI depuis longtemps), la dispersion geometrique des données a lire sur la surface du disque est moins generatrice de perte de performances, car les requetes sont reordonnées en fonction de la geométrie justement. Les utilisateurs de systemes multiutilisateurs (Unix) savent aussi que la notion de fragmentation est importante quand il n'y a qu'un seul utilisateur qui accede a un seul fichier a la fois. Parce que de toute facon, meme si les fichiers de chacun ne sont pas fragmentés, quand plusieurs personnes veulent chacune accédder a leur fichier, il y a forcement necessité de balader la tête de lecture. D'ou l'interet de l'usage des disques SCSI dans de tels environnement, et SATA maintenant.
Comme on va etre très vite encore plus HS dans ce groupe, disons que avec un filesystem "moderne" sur un disque "moderne", on n'en a plus rien a fiche de savoir où est écrit un fichier et comment sur le support de stockage. Et c'est bien !
Jean-Claude Ghislain
Comme on va etre très vite encore plus HS dans ce groupe
En fin de compte, on est pas si HS que ça. Certes dans frp on serait totalement HS, mais dans frpn c'est déjà beaucoup moins sûr. Pour classer, retoucher ou envoyer ses images, le photographe numérique passe beaucoup de temps sur des ordinateurs et un minimum de connaissance des "Filesystem" n'est pas un luxe.
-- Jean-Claude Ghislain www.grimart.com
Comme on va etre très vite encore plus HS dans ce groupe
En fin de compte, on est pas si HS que ça. Certes dans frp on serait
totalement HS, mais dans frpn c'est déjà beaucoup moins sûr.
Pour classer, retoucher ou envoyer ses images, le photographe
numérique passe beaucoup de temps sur des ordinateurs et un
minimum de connaissance des "Filesystem" n'est pas un luxe.
Comme on va etre très vite encore plus HS dans ce groupe
En fin de compte, on est pas si HS que ça. Certes dans frp on serait totalement HS, mais dans frpn c'est déjà beaucoup moins sûr. Pour classer, retoucher ou envoyer ses images, le photographe numérique passe beaucoup de temps sur des ordinateurs et un minimum de connaissance des "Filesystem" n'est pas un luxe.
-- Jean-Claude Ghislain www.grimart.com
jean-daniel dodin
Jean-Claude Ghislain wrote:
Comme on va etre très vite encore plus HS dans ce groupe
En fin de compte, on est pas si HS que ça. Certes dans frp on serait totalement HS, mais dans frpn c'est déjà beaucoup moins sûr. Pour classer, retoucher ou envoyer ses images, le photographe numérique passe beaucoup de temps sur des ordinateurs et un minimum de connaissance des "Filesystem" n'est pas un luxe.
d'ailleurs la fragmentation du système de fichiers fat16
_sur la carte cf_ limite la durée des videos avec mon canon A70, on peut penser que ce même phénomène pose des problèmes de vitesse à un APN réfLexe en rafale...
JDD
-- pour m'écrire, aller sur: http://www.dodin.net
Jean-Claude Ghislain wrote:
Comme on va etre très vite encore plus HS dans ce groupe
En fin de compte, on est pas si HS que ça. Certes dans frp on serait
totalement HS, mais dans frpn c'est déjà beaucoup moins sûr.
Pour classer, retoucher ou envoyer ses images, le photographe
numérique passe beaucoup de temps sur des ordinateurs et un
minimum de connaissance des "Filesystem" n'est pas un luxe.
d'ailleurs la fragmentation du système de fichiers fat16
_sur la carte cf_ limite la durée des videos avec mon canon
A70, on peut penser que ce même phénomène pose des problèmes
de vitesse à un APN réfLexe en rafale...
Comme on va etre très vite encore plus HS dans ce groupe
En fin de compte, on est pas si HS que ça. Certes dans frp on serait totalement HS, mais dans frpn c'est déjà beaucoup moins sûr. Pour classer, retoucher ou envoyer ses images, le photographe numérique passe beaucoup de temps sur des ordinateurs et un minimum de connaissance des "Filesystem" n'est pas un luxe.
d'ailleurs la fragmentation du système de fichiers fat16
_sur la carte cf_ limite la durée des videos avec mon canon A70, on peut penser que ce même phénomène pose des problèmes de vitesse à un APN réfLexe en rafale...
JDD
-- pour m'écrire, aller sur: http://www.dodin.net
Bernard Perrot
jean-daniel dodin wrote:
d'ailleurs la fragmentation du système de fichiers fat16 _sur la carte cf_ limite la durée des videos avec mon canon A70, on peut penser que ce même phénomène pose des problèmes de vitesse à un APN réfLexe en rafale...
Moi, quand j'ai tranféré les photos de ma carte mémoire, via le menu de l'appareil, je n'efface pas (genre fonction "effacer tous les fichiers"), je reformatte toujours. En FAT, c'est toujours plus prudent effectivement...
jean-daniel dodin wrote:
d'ailleurs la fragmentation du système de fichiers fat16 _sur la carte
cf_ limite la durée des videos avec mon canon A70, on peut penser que ce
même phénomène pose des problèmes de vitesse à un APN réfLexe en rafale...
Moi, quand j'ai tranféré les photos de ma carte mémoire, via le menu de
l'appareil, je n'efface pas (genre fonction "effacer tous les fichiers"), je
reformatte toujours. En FAT, c'est toujours plus prudent effectivement...
d'ailleurs la fragmentation du système de fichiers fat16 _sur la carte cf_ limite la durée des videos avec mon canon A70, on peut penser que ce même phénomène pose des problèmes de vitesse à un APN réfLexe en rafale...
Moi, quand j'ai tranféré les photos de ma carte mémoire, via le menu de l'appareil, je n'efface pas (genre fonction "effacer tous les fichiers"), je reformatte toujours. En FAT, c'est toujours plus prudent effectivement...
FiLH
Bernard Perrot writes:
FiLH wrote:
Alors là il va falloir m'expliquer le rapport entre journalisation et fragmentation.
il y en a forcement un, car le support d'ecriture est le meme...
Merci de séparer les fonctionnalités, on peut faire un système qui ne fragmente pas sans journalisation, et le contraire aussi.
Ce n'est pas parce que ça parle de FS qu'il y a un rapport de cause à effet de l'un vers l'autre. Il y a plein de fonctionnalités que peut avoir un FS, chacune indépendante les unes des autres.
La journalisation permet d'éviter les incohérences du file system en cas de crash, alors que la fragmentation concerne l'allocation des blocs.
La journalisation ajoute une couche d'abstraction dans l'accès au fragments des fichiers, la perception intuitive que la fragmentation oblige la tete de lecture a se deplacer plus devient moins adequate car il faut aussi acceder a des données de journalisation a chaque transaction de toute façon. Et on pourrait aussi ajouter qu'avec les disque SATA desormais (tout comme avec les disques SCSI depuis longtemps), la dispersion geometrique des données a lire sur la surface du disque est moins generatrice de perte de performances, car les requetes sont reordonnées en fonction de la geométrie justement. Les utilisateurs de systemes multiutilisateurs (Unix) savent aussi que la notion de fragmentation est importante quand il n'y a qu'un seul utilisateur qui accede a un seul fichier a la fois. Parce que de toute facon, meme si les fichiers de chacun ne sont pas fragmentés, quand plusieurs personnes veulent chacune accédder a leur fichier, il y a forcement necessité de balader la tête de lecture. D'ou l'interet de l'usage des disques SCSI dans de tels environnement, et SATA maintenant.
Heu.. gloubi boulga là vous mélangez tout dans un charabia qui parle de toutes les couches mélangées.
Désolé...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Bernard Perrot <bernard.perrot@univ-rennes1.fr> writes:
FiLH wrote:
Alors là il va falloir m'expliquer le rapport entre journalisation et
fragmentation.
il y en a forcement un, car le support d'ecriture est le meme...
Merci de séparer les fonctionnalités, on peut faire un système
qui ne fragmente pas sans journalisation, et le contraire aussi.
Ce n'est pas parce que ça parle de FS qu'il y a un rapport de cause à
effet de l'un vers l'autre. Il y a plein de fonctionnalités que peut
avoir un FS, chacune indépendante les unes des autres.
La journalisation permet d'éviter les incohérences du file system en
cas de crash, alors que la fragmentation concerne l'allocation des blocs.
La journalisation ajoute une couche d'abstraction dans l'accès au
fragments des fichiers, la perception intuitive que la fragmentation
oblige la tete de lecture a se deplacer plus devient moins adequate
car il faut aussi acceder a des données de journalisation a chaque
transaction de toute façon. Et on pourrait aussi ajouter qu'avec les
disque SATA desormais (tout comme avec les disques SCSI depuis
longtemps), la dispersion geometrique des données a lire sur la
surface du disque est moins generatrice de perte de performances, car
les requetes sont reordonnées en fonction de la geométrie justement.
Les utilisateurs de systemes multiutilisateurs (Unix) savent aussi que
la notion de fragmentation est importante quand il n'y a qu'un seul
utilisateur qui accede a un seul fichier a la fois. Parce que de toute
facon, meme si les fichiers de chacun ne sont pas fragmentés, quand
plusieurs personnes veulent chacune accédder a leur fichier, il y a
forcement necessité de balader la tête de lecture. D'ou l'interet de
l'usage des disques SCSI dans de tels environnement, et SATA
maintenant.
Heu.. gloubi boulga là vous mélangez tout dans un charabia qui parle
de toutes les couches mélangées.
Désolé...
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Alors là il va falloir m'expliquer le rapport entre journalisation et fragmentation.
il y en a forcement un, car le support d'ecriture est le meme...
Merci de séparer les fonctionnalités, on peut faire un système qui ne fragmente pas sans journalisation, et le contraire aussi.
Ce n'est pas parce que ça parle de FS qu'il y a un rapport de cause à effet de l'un vers l'autre. Il y a plein de fonctionnalités que peut avoir un FS, chacune indépendante les unes des autres.
La journalisation permet d'éviter les incohérences du file system en cas de crash, alors que la fragmentation concerne l'allocation des blocs.
La journalisation ajoute une couche d'abstraction dans l'accès au fragments des fichiers, la perception intuitive que la fragmentation oblige la tete de lecture a se deplacer plus devient moins adequate car il faut aussi acceder a des données de journalisation a chaque transaction de toute façon. Et on pourrait aussi ajouter qu'avec les disque SATA desormais (tout comme avec les disques SCSI depuis longtemps), la dispersion geometrique des données a lire sur la surface du disque est moins generatrice de perte de performances, car les requetes sont reordonnées en fonction de la geométrie justement. Les utilisateurs de systemes multiutilisateurs (Unix) savent aussi que la notion de fragmentation est importante quand il n'y a qu'un seul utilisateur qui accede a un seul fichier a la fois. Parce que de toute facon, meme si les fichiers de chacun ne sont pas fragmentés, quand plusieurs personnes veulent chacune accédder a leur fichier, il y a forcement necessité de balader la tête de lecture. D'ou l'interet de l'usage des disques SCSI dans de tels environnement, et SATA maintenant.
Heu.. gloubi boulga là vous mélangez tout dans un charabia qui parle de toutes les couches mélangées.
Désolé...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FAb
daniel patin writes:
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:
Document très sympa dans l'ensemble. J'ai déjà essayé de le faire lire à ma mère...
ceci dit sans esprit contestataire :-)
Mouais. Je vous conseille le «Principes appliqués des systèmes d'exploitation» de A. Silberschatz, P. Galvin et G. Gagne aux éditions Vuibert, ISBN 2-7117-8685-X.
Je voudrais pas faire le mec à la science infuse(*), mais il n'y pas de miracle, les systèmes actuels comme ext2 se fragmentent quand on les utilise. Certes de manière infiniment moins sensible, dans la plus par des cas, que sur de la VFAT. Idem pour la RAM, pagination tout ça...
Vous en doutez encore ? Bigre crashez donc un système en ext2... au redémarrage le salvateur fsck finira pour vous dire ... xy% NON CONTIGUOUS files.
Après les pertes en espace et temps d'accès cela reste discutable et relativement négligeable. Et on pourrait aussi débattre sur la fragmentation interne.
Puisqu'on cause technique, qu'utilisez-vous comme outil de visionnage et/ou tri pour vos stocks de photos ?
- gqview + une norme dans les (longs) noms de fichiers sur ext3 + mémoire humaine - simple et rapide sur ma pétrolette anté-diluvienne. - perfectible, car les recherches sont limitées par ma mémoire et j'arrive bientôt à ses limites
Tiens je me demande si y a pas déjà un fil là dessus.
FAb (*) ou passer pour un psychopathe à cheval sur le vocabulaire :-p
daniel patin <marcel.dugenou@free.fr> writes:
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:
Document très sympa dans l'ensemble. J'ai déjà essayé de le faire lire à ma
mère...
ceci dit sans esprit contestataire :-)
Mouais. Je vous conseille le «Principes appliqués des systèmes d'exploitation»
de A. Silberschatz, P. Galvin et G. Gagne aux éditions Vuibert, ISBN
2-7117-8685-X.
Je voudrais pas faire le mec à la science infuse(*), mais il n'y pas de miracle,
les systèmes actuels comme ext2 se fragmentent quand on les utilise. Certes de
manière infiniment moins sensible, dans la plus par des cas, que sur de la VFAT.
Idem pour la RAM, pagination tout ça...
Vous en doutez encore ? Bigre crashez donc un système en ext2... au redémarrage
le salvateur fsck finira pour vous dire ... xy% NON CONTIGUOUS files.
Après les pertes en espace et temps d'accès cela reste discutable et
relativement négligeable. Et on pourrait aussi débattre sur la fragmentation
interne.
Puisqu'on cause technique, qu'utilisez-vous comme outil de visionnage et/ou tri
pour vos stocks de photos ?
- gqview + une norme dans les (longs) noms de fichiers sur ext3 + mémoire
humaine
- simple et rapide sur ma pétrolette anté-diluvienne.
- perfectible, car les recherches sont limitées par ma mémoire et j'arrive
bientôt à ses limites
Tiens je me demande si y a pas déjà un fil là dessus.
FAb
(*) ou passer pour un psychopathe à cheval sur le vocabulaire :-p
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:
Document très sympa dans l'ensemble. J'ai déjà essayé de le faire lire à ma mère...
ceci dit sans esprit contestataire :-)
Mouais. Je vous conseille le «Principes appliqués des systèmes d'exploitation» de A. Silberschatz, P. Galvin et G. Gagne aux éditions Vuibert, ISBN 2-7117-8685-X.
Je voudrais pas faire le mec à la science infuse(*), mais il n'y pas de miracle, les systèmes actuels comme ext2 se fragmentent quand on les utilise. Certes de manière infiniment moins sensible, dans la plus par des cas, que sur de la VFAT. Idem pour la RAM, pagination tout ça...
Vous en doutez encore ? Bigre crashez donc un système en ext2... au redémarrage le salvateur fsck finira pour vous dire ... xy% NON CONTIGUOUS files.
Après les pertes en espace et temps d'accès cela reste discutable et relativement négligeable. Et on pourrait aussi débattre sur la fragmentation interne.
Puisqu'on cause technique, qu'utilisez-vous comme outil de visionnage et/ou tri pour vos stocks de photos ?
- gqview + une norme dans les (longs) noms de fichiers sur ext3 + mémoire humaine - simple et rapide sur ma pétrolette anté-diluvienne. - perfectible, car les recherches sont limitées par ma mémoire et j'arrive bientôt à ses limites
Tiens je me demande si y a pas déjà un fil là dessus.
FAb (*) ou passer pour un psychopathe à cheval sur le vocabulaire :-p
