Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage
FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la
sauvegarde complète de mes partitions, soit un total de 109 Gio sur un
autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule
partition.
Cas 1 : Disque formaté FAT32 : 64 minutes
Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture,
mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf :
Disque 1 : NTFS clusters de 4 kio
Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante
augmentation de temps ?
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des
partitions ?
Merci.
--
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la sauvegarde complète de mes partitions, soit un total de 109 Gio sur un autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule partition.
Cas 1 : Disque formaté FAT32 : 64 minutes Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture, mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf : Disque 1 : NTFS clusters de 4 kio Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis pour limiter l'espace inutilisé qui est perdu.
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des partitions ?
Désactiver l'indexation, la compression si ce n'est déja fait, mais tu perds les avantages qui sont liés à ces fonctionnalités.
Ta source est de quel type FAT32 ou NTFS.
Bonjour,
Dominique Ottello a écrit :
Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage
FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la
sauvegarde complète de mes partitions, soit un total de 109 Gio sur un
autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule
partition.
Cas 1 : Disque formaté FAT32 : 64 minutes
Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture,
mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf :
Disque 1 : NTFS clusters de 4 kio
Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante
augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis
pour limiter l'espace inutilisé qui est perdu.
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des
partitions ?
Désactiver l'indexation, la compression si ce n'est déja fait, mais tu perds
les avantages qui sont liés à ces fonctionnalités.
Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la sauvegarde complète de mes partitions, soit un total de 109 Gio sur un autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule partition.
Cas 1 : Disque formaté FAT32 : 64 minutes Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture, mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf : Disque 1 : NTFS clusters de 4 kio Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis pour limiter l'espace inutilisé qui est perdu.
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des partitions ?
Désactiver l'indexation, la compression si ce n'est déja fait, mais tu perds les avantages qui sont liés à ces fonctionnalités.
Ta source est de quel type FAT32 ou NTFS.
Dominique Ottello
Michel__D écrivait :
> Serait-ce la taille des clusters qui induit cette importante > augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis pour limiter l'espace inutilisé qui est perdu.
Attention ! C'est un cas bien particulier de sauvegarde de partitions entières, pas de fichiers. Le résultat est : - Un fichier de 109 Gio en sauvegarde sur disque NTFS - 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32 Donc, je pense que dans ce cas précis, des clusters de 4 kio ne servent à rien.
Désactiver l'indexation, la compression si ce n'est déja fait, mais tu perds les avantages qui sont liés à ces fonctionnalités.
Ta source est de quel type FAT32 ou NTFS.
Les partitions à sauvegarder sont de type FAT32 -- Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
> Serait-ce la taille des clusters qui induit cette importante
> augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis
pour limiter l'espace inutilisé qui est perdu.
Attention ! C'est un cas bien particulier de sauvegarde de partitions
entières, pas de fichiers.
Le résultat est :
- Un fichier de 109 Gio en sauvegarde sur disque NTFS
- 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32
Donc, je pense que dans ce cas précis, des clusters de 4 kio ne servent
à rien.
Désactiver l'indexation, la compression si ce n'est déja fait, mais tu perds
les avantages qui sont liés à ces fonctionnalités.
Ta source est de quel type FAT32 ou NTFS.
Les partitions à sauvegarder sont de type FAT32
--
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
> Serait-ce la taille des clusters qui induit cette importante > augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis pour limiter l'espace inutilisé qui est perdu.
Attention ! C'est un cas bien particulier de sauvegarde de partitions entières, pas de fichiers. Le résultat est : - Un fichier de 109 Gio en sauvegarde sur disque NTFS - 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32 Donc, je pense que dans ce cas précis, des clusters de 4 kio ne servent à rien.
Désactiver l'indexation, la compression si ce n'est déja fait, mais tu perds les avantages qui sont liés à ces fonctionnalités.
Ta source est de quel type FAT32 ou NTFS.
Les partitions à sauvegarder sont de type FAT32 -- Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
Michel__D
Re,
Dominique Ottello a écrit :
Michel__D écrivait :
Serait-ce la taille des clusters qui induit cette importante augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis pour limiter l'espace inutilisé qui est perdu.
Attention ! C'est un cas bien particulier de sauvegarde de partitions entières, pas de fichiers. Le résultat est : - Un fichier de 109 Gio en sauvegarde sur disque NTFS - 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32 Donc, je pense que dans ce cas précis, des clusters de 4 kio ne servent à rien.
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la différence de taille des clusters qui engendre cette différence.
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la comparaison car si le système se met à plus utiliser le swap ben cela va ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Serait-ce la taille des clusters qui induit cette importante
augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis
pour limiter l'espace inutilisé qui est perdu.
Attention ! C'est un cas bien particulier de sauvegarde de partitions
entières, pas de fichiers.
Le résultat est :
- Un fichier de 109 Gio en sauvegarde sur disque NTFS
- 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32
Donc, je pense que dans ce cas précis, des clusters de 4 kio ne servent
à rien.
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la
différence de taille des clusters qui engendre cette différence.
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la
comparaison car si le système se met à plus utiliser le swap ben cela va
ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Serait-ce la taille des clusters qui induit cette importante augmentation de temps ?
Oui et non, mais de toute façon les clusters de 4 kio sont un bon compromis pour limiter l'espace inutilisé qui est perdu.
Attention ! C'est un cas bien particulier de sauvegarde de partitions entières, pas de fichiers. Le résultat est : - Un fichier de 109 Gio en sauvegarde sur disque NTFS - 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32 Donc, je pense que dans ce cas précis, des clusters de 4 kio ne servent à rien.
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la différence de taille des clusters qui engendre cette différence.
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la comparaison car si le système se met à plus utiliser le swap ben cela va ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Dominique Ottello
Michel__D écrivait :
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la différence de taille des clusters qui engendre cette différence.
Mais si, mais si ! Et c'est même phénoménal !
Opiniâtre et cartésien, j'ai procédé à une nouvelle sauvegarde, via le CD de boot Acronis True Image, sur le même disque dur NTFS, mais formaté avec des clusters de 32 kio, tout étant identique par ailleurs.
Pour ce cas particulier de très gros fichiers, la taille des clusters est importante. D'ailleurs, ce soir, je vais essayer avec des clusters de 64 kio ; juste pour voir. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la
différence de taille des clusters qui engendre cette différence.
Mais si, mais si ! Et c'est même phénoménal !
Opiniâtre et cartésien, j'ai procédé à une nouvelle sauvegarde, via le
CD de boot Acronis True Image, sur le même disque dur NTFS, mais formaté
avec des clusters de 32 kio, tout étant identique par ailleurs.
Pour ce cas particulier de très gros fichiers, la taille des clusters
est importante. D'ailleurs, ce soir, je vais essayer avec des clusters
de 64 kio ; juste pour voir.
--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net)
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la différence de taille des clusters qui engendre cette différence.
Mais si, mais si ! Et c'est même phénoménal !
Opiniâtre et cartésien, j'ai procédé à une nouvelle sauvegarde, via le CD de boot Acronis True Image, sur le même disque dur NTFS, mais formaté avec des clusters de 32 kio, tout étant identique par ailleurs.
Pour ce cas particulier de très gros fichiers, la taille des clusters est importante. D'ailleurs, ce soir, je vais essayer avec des clusters de 64 kio ; juste pour voir. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Dominique Ottello
Michel__D écrivait :
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la comparaison car si le système se met à plus utiliser le swap ben cela va ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Windows et le swap, on s'en fout ! Là n'est pas le problème car :
Lancement d'Acronis True Image depuis le boot sur le CD (Comme précisé dans ma première contribution) ; donc depuis un système Linux.
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la
comparaison car si le système se met à plus utiliser le swap ben cela va
ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Windows et le swap, on s'en fout ! Là n'est pas le problème car :
Lancement d'Acronis True Image depuis le boot sur le CD (Comme précisé
dans ma première contribution) ; donc depuis un système Linux.
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la comparaison car si le système se met à plus utiliser le swap ben cela va ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Windows et le swap, on s'en fout ! Là n'est pas le problème car :
Lancement d'Acronis True Image depuis le boot sur le CD (Comme précisé dans ma première contribution) ; donc depuis un système Linux.
Michel__D
Re,
Dominique Ottello a écrit :
Michel__D écrivait :
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la différence de taille des clusters qui engendre cette différence.
Mais si, mais si ! Et c'est même phénoménal !
Opiniâtre et cartésien, j'ai procédé à une nouvelle sauvegarde, via le CD de boot Acronis True Image, sur le même disque dur NTFS, mais formaté avec des clusters de 32 kio, tout étant identique par ailleurs.
Pour ce cas particulier de très gros fichiers, la taille des clusters est importante. D'ailleurs, ce soir, je vais essayer avec des clusters de 64 kio ; juste pour voir.
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la
différence de taille des clusters qui engendre cette différence.
Mais si, mais si ! Et c'est même phénoménal !
Opiniâtre et cartésien, j'ai procédé à une nouvelle sauvegarde, via le
CD de boot Acronis True Image, sur le même disque dur NTFS, mais formaté
avec des clusters de 32 kio, tout étant identique par ailleurs.
Pour ce cas particulier de très gros fichiers, la taille des clusters
est importante. D'ailleurs, ce soir, je vais essayer avec des clusters
de 64 kio ; juste pour voir.
Ok pour le type de sauvegarde, par contre je ne pense pas que ce soit la différence de taille des clusters qui engendre cette différence.
Mais si, mais si ! Et c'est même phénoménal !
Opiniâtre et cartésien, j'ai procédé à une nouvelle sauvegarde, via le CD de boot Acronis True Image, sur le même disque dur NTFS, mais formaté avec des clusters de 32 kio, tout étant identique par ailleurs.
Pour ce cas particulier de très gros fichiers, la taille des clusters est importante. D'ailleurs, ce soir, je vais essayer avec des clusters de 64 kio ; juste pour voir.
Ok, je m'incline.
Michel__D
Re,
Dominique Ottello a écrit :
Michel__D écrivait :
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la comparaison car si le système se met à plus utiliser le swap ben cela va ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Windows et le swap, on s'en fout ! Là n'est pas le problème car :
Lancement d'Acronis True Image depuis le boot sur le CD (Comme précisé dans ma première contribution) ; donc depuis un système Linux.
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la
comparaison car si le système se met à plus utiliser le swap ben cela va
ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Windows et le swap, on s'en fout ! Là n'est pas le problème car :
Lancement d'Acronis True Image depuis le boot sur le CD (Comme précisé
dans ma première contribution) ; donc depuis un système Linux.
Utilise la même façon de faire soit 27 fichiers de 4Gio + reliquat pour la comparaison car si le système se met à plus utiliser le swap ben cela va ralentir la sauvegarde car je suppose que les fichiers de sauvegarde sont compressés.
Windows et le swap, on s'en fout ! Là n'est pas le problème car :
Lancement d'Acronis True Image depuis le boot sur le CD (Comme précisé dans ma première contribution) ; donc depuis un système Linux.
Et le système Linux n'utilise pas de swap ?
_Dine & Clau_
Michel__D écrivit dans news:4a8fd483$0$12618$:
Et le système Linux n'utilise pas de swap ?
Non, c'est particulier à Windows. __ CB C&C
Michel__D <Michel.NOSPAM@orange-ft.com.invalid> écrivit dans
news:4a8fd483$0$12618$ba4acef3@news.orange.fr:
C'est bizarre, moi j'ai toujours été contraint de créer une partition dédié au swap, tu confirme toujours tes dires ?
_Dine & Clau_
Dominique Ottello écrivit dans news::
soit un total de 109 Gio sur un autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule partition.
Tu as tout-à-fait raison de souligner la lenteur du NTFS et d'indiquer que les clusters de 4Ko ne conviennent pas nécessairement à ce type de travail. (l'avantage du NTFS se situe au niveau de la "sécurité")
Démonstration par l'absurde : *si cela était possible*, un seul cluster de 109 Goctets permettrait à l'image du disque de s'inscrire sur le dd de destination en une passe. (sans s'éparpiller sur plusieurs secteurs du disque).
En fait, le système idéal pour ce genre de travail de backup serait un OS qui taille directement ...- (une sorte de "fdisk sous win32") - ... une partition avec un secteur équivalent à la taille de l'image disque à y déposer (pour faire simple). __ CB Mais je peux me tromper !, hein !! ;+) C&C
Dominique Ottello <air.intakes@fra.fr.invalid> écrivit dans
news:04av85h5217n9th10gfp6fsbdpu807iqqr@4ax.com:
soit un total de 109 Gio sur un
autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une
seule partition.
Tu as tout-à-fait raison de souligner la lenteur du NTFS et
d'indiquer que les clusters de 4Ko ne conviennent pas nécessairement
à ce type de travail. (l'avantage du NTFS se situe au niveau de la
"sécurité")
Démonstration par l'absurde : *si cela était possible*, un seul
cluster de 109 Goctets permettrait à l'image du disque de s'inscrire
sur le dd de destination en une passe. (sans s'éparpiller sur
plusieurs secteurs du disque).
En fait, le système idéal pour ce genre de travail de backup serait
un OS qui taille directement ...- (une sorte de "fdisk sous win32") -
... une partition avec un secteur équivalent à la taille de l'image
disque à y déposer (pour faire simple).
__
CB Mais je peux me tromper !, hein !! ;+)
C&C
soit un total de 109 Gio sur un autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule partition.
Tu as tout-à-fait raison de souligner la lenteur du NTFS et d'indiquer que les clusters de 4Ko ne conviennent pas nécessairement à ce type de travail. (l'avantage du NTFS se situe au niveau de la "sécurité")
Démonstration par l'absurde : *si cela était possible*, un seul cluster de 109 Goctets permettrait à l'image du disque de s'inscrire sur le dd de destination en une passe. (sans s'éparpiller sur plusieurs secteurs du disque).
En fait, le système idéal pour ce genre de travail de backup serait un OS qui taille directement ...- (une sorte de "fdisk sous win32") - ... une partition avec un secteur équivalent à la taille de l'image disque à y déposer (pour faire simple). __ CB Mais je peux me tromper !, hein !! ;+) C&C
