je viens de faire (comme tous les mois) la defrag de mes deux machines
Windows.
pour la pire, (la mienne) ca donne ca:
Partition C: Windows (139.638 files pour environ 37 GB utilisés)
Defraggler:
-------------------------------------
Avant la defrag:
1838 Fragmented Files
7.899 Total Fragments
16% Fragmentation
Après la defrag:
8 Fragmented Files
36 Total Fragments
12% Fragmentation
------------------------------------
Comme ca au premier coup d'oeil: avant 16% , après 12%.
Pas terrible...
A y regarder de plus près: d'ou viennent ces pourcentages?
En gros
- avant ~140 000 fichiers, dont 8 000 sont fragmentés. (ca fait pas 16%
ca ???)
- après ~140 000 fichiers, dont 36 sont fragmentés. (ca fait pas 12% ca
???)
Si je compare maintenant a OSX (snow-leopard) dont je me sers plutot
rarement et qui a beaucoup moins de logiciels et que j'ai testé il y a
quelques jours:
Partition OSX
hfsdebug-lite -s
-------------------------------------
# Volume Summary Information
files = 346206
folders = 89708
aliases = 1
hard links = 1830
symbolic links = 10708
invisible files = 54
empty files = 2463
# Data Forks
non-zero data forks = 343573
fragmented data forks = 23864
allocation blocks used = 5486045
allocated storage = 22470840320 bytes
(21944180.00 KB/21429.86 MB/20.93 GB)
actual usage = 21565315056 bytes
(21059877.98 KB/20566.29 MB/20.08 GB)
total extent records = 343591
total extent descriptors = 344217
overflow extent records = 18
------------------------------------
1re constation: le nombre total de fichiers d'OSX (hors fragmentation)
est plus du double (~345 000) pour seulement 21 GB utilisés.
2e constatation: le nombre de fragments OSX est 3 fois plus elevé (~24
000) que mon Windows non-défragmenté.
3e constatation: une vraie defrag sort al a fin: 8 fichiers non
fragmentés avec 36 fragments au total, comme ca, les doigts dans le nez,
sans reboot.
4e constation: la defrag on s'en fout quand on a un SSD. (mais j'en ai pas).
5e constatation: quand on a un SSD, la défrag automatique d'OSX réduit
inutilement la durée de vie de la mémoire: vaut mieux pas avoir de
défrag du tout sur le SSD.
Ne pas oublier d'installer TRIM enabler si vous z'avez un SSD pas d'Apple.
http://osxdaily.com/2012/01/03/enable-trim-all-ssd-mac-os-x-lion/
Mes conclusions
- OSX est déja d'avantage "fragmenté" que Windows (en nombre de fichiers)
- Il fragmente peut être naturellement peu, mais rien ne vaut une
_vraie_ défrag chaque mois.
- Apple vous le dit pas, mais bouzille joyeusement vos SSD rajoutés.
--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)
sur mon opensuse 12.2 (récente) et un vieux PIVHT avec 2Go de ram, Firefoxc utilise moins de 200 Mo (et c'est lui qui en utilise le plus),
Utilise ou mobilise ? Après combien de temps de lancement ? C'est ça le problème.
730 Firefox noelleadam 7,3 24 761,5 Mo Intel (64 bits)507,1 Mo 479 296 496
0 kernel_task root 2,2 74 695,5 Mo Intel 72,0 Mo 1 473 396 175
Premier chiffre mémoire : mémoire réelle , second chiffre mémoire virtuelle. Si je ne le ferme pas pendant une semaine, il s'étale comme une tâche de gras.
Okay, j'ai des plug-in, mais si j'utilise Firefox comme browser, c'est bien parce qu'il y a des plug-in dedans ! L'addblocker de Safari est ridicule à coté de celui de Firefox. Par compte son mode dev est très bien,meilleur que Firefox, mais dans Firefox il y aussi des plug-in sympa du genre échantilloner la couleur sur un site, ou identifier les polices. Je n'ai absolument aucune application qui aie un impact sensible sur les processeurs. Même les traitements avec NX s'effectuent assez rapidement, c'est juste la mémoire qui est beaucoup sollicité si j'ai plusieurs images (raw) ouvertes en même temps.
c'est une partition avec
accès brut secteur par secteur (pas de système de fichier), on peut pas faire mieux.
hum redis ça en français. Pas de système de fichier en général , ou bien tu parlais uniquement du système de mémoire virtuelle ? Je n'ai jamais vu la mémoire virtuelle utilliser des fichiers, la pagination mémoire n'est pas l'écriture dans des fichiers temporaire, mais je ne prétends pas avoir tout vu, ni m'être penchée sur toutes les entrailles.
Noëlle Adam
Le 28/10/12 12:58, jdd a écrit :
sur mon opensuse 12.2 (récente) et un vieux PIVHT avec 2Go de ram,
Firefoxc utilise moins de 200 Mo (et c'est lui qui en utilise le plus),
Utilise ou mobilise ? Après combien de temps de lancement ?
C'est ça le problème.
730 Firefox noelleadam 7,3 24 761,5 Mo Intel (64 bits)507,1 Mo
479 296 496
0 kernel_task root 2,2 74 695,5 Mo Intel 72,0 Mo 1 473 396 175
Premier chiffre mémoire : mémoire réelle , second chiffre mémoire
virtuelle. Si je ne le ferme pas pendant une semaine, il s'étale comme
une tâche de gras.
Okay, j'ai des plug-in, mais si j'utilise Firefox comme browser, c'est
bien parce qu'il y a des plug-in dedans ! L'addblocker de Safari est
ridicule à coté de celui de Firefox. Par compte son mode dev est très
bien,meilleur que Firefox, mais dans Firefox il y aussi des plug-in
sympa du genre échantilloner la couleur sur un site, ou identifier les
polices.
Je n'ai absolument aucune application qui aie un impact sensible sur les
processeurs. Même les traitements avec NX s'effectuent assez rapidement,
c'est juste la mémoire qui est beaucoup sollicité si j'ai plusieurs
images (raw) ouvertes en même temps.
c'est une partition avec
accès brut secteur par secteur (pas de système de fichier), on peut pas
faire mieux.
hum redis ça en français. Pas de système de fichier en général , ou bien
tu parlais uniquement du système de mémoire virtuelle ?
Je n'ai jamais vu la mémoire virtuelle utilliser des fichiers, la
pagination mémoire n'est pas l'écriture dans des fichiers temporaire,
mais je ne prétends pas avoir tout vu, ni m'être penchée sur toutes les
entrailles.
sur mon opensuse 12.2 (récente) et un vieux PIVHT avec 2Go de ram, Firefoxc utilise moins de 200 Mo (et c'est lui qui en utilise le plus),
Utilise ou mobilise ? Après combien de temps de lancement ? C'est ça le problème.
730 Firefox noelleadam 7,3 24 761,5 Mo Intel (64 bits)507,1 Mo 479 296 496
0 kernel_task root 2,2 74 695,5 Mo Intel 72,0 Mo 1 473 396 175
Premier chiffre mémoire : mémoire réelle , second chiffre mémoire virtuelle. Si je ne le ferme pas pendant une semaine, il s'étale comme une tâche de gras.
Okay, j'ai des plug-in, mais si j'utilise Firefox comme browser, c'est bien parce qu'il y a des plug-in dedans ! L'addblocker de Safari est ridicule à coté de celui de Firefox. Par compte son mode dev est très bien,meilleur que Firefox, mais dans Firefox il y aussi des plug-in sympa du genre échantilloner la couleur sur un site, ou identifier les polices. Je n'ai absolument aucune application qui aie un impact sensible sur les processeurs. Même les traitements avec NX s'effectuent assez rapidement, c'est juste la mémoire qui est beaucoup sollicité si j'ai plusieurs images (raw) ouvertes en même temps.
c'est une partition avec
accès brut secteur par secteur (pas de système de fichier), on peut pas faire mieux.
hum redis ça en français. Pas de système de fichier en général , ou bien tu parlais uniquement du système de mémoire virtuelle ? Je n'ai jamais vu la mémoire virtuelle utilliser des fichiers, la pagination mémoire n'est pas l'écriture dans des fichiers temporaire, mais je ne prétends pas avoir tout vu, ni m'être penchée sur toutes les entrailles.
Noëlle Adam
jdd
Le 28/10/2012 14:18, YouDontNeedToKnowButItsNoëlle a écrit :
c'est une partition avec
accès brut secteur par secteur (pas de système de fichier), on peut pas faire mieux.
hum redis ça en français. Pas de système de fichier en général , ou bien tu parlais uniquement du système de mémoire virtuelle ? Je n'ai jamais vu la mémoire virtuelle utilliser des fichiers,
le swap est sur une partition séparée.
Windows utilise un fichier (pagefile.sys), mac aucune idée
jdd
-- http://dodin.org
Le 28/10/2012 14:18, YouDontNeedToKnowButItsNoëlle a écrit :
c'est une partition avec
accès brut secteur par secteur (pas de système de fichier), on peut pas
faire mieux.
hum redis ça en français. Pas de système de fichier en général , ou bien
tu parlais uniquement du système de mémoire virtuelle ?
Je n'ai jamais vu la mémoire virtuelle utilliser des fichiers,
le swap est sur une partition séparée.
Windows utilise un fichier (pagefile.sys), mac aucune idée
Le 28/10/2012 14:18, YouDontNeedToKnowButItsNoëlle a écrit :
c'est une partition avec
accès brut secteur par secteur (pas de système de fichier), on peut pas faire mieux.
hum redis ça en français. Pas de système de fichier en général , ou bien tu parlais uniquement du système de mémoire virtuelle ? Je n'ai jamais vu la mémoire virtuelle utilliser des fichiers,
le swap est sur une partition séparée.
Windows utilise un fichier (pagefile.sys), mac aucune idée
jdd
-- http://dodin.org
Ascadix
Anne Le Guennec a écrit dans <1ksnc6x.jc69461dmjeo8N%: <news:1ksnc6x.jc69461dmjeo8N%
Ascadix wrote:
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et succésseurs (2000) qui gérent trés différement la compression sur disque, et ce fut la fin des compresseur de diques.
Mon vendeur de l'époque déconseillait absolument la compression du Dd principal quand on tenait à ses données.Il me me soutenait qu'un disque compressé était à peu près irrécupérable en cas de plantage grave.
D'où le DD externe et les magnéto optiques pour les sauvegardes de données sensibles.
Bien sur, ce type de compression complique nettement toute manip de récupération.
De toute façon, en cas de plantage grave, tu récupére rien sur le DD, compressé ou pas sauf à te payer un service de récup à xxxx(beaucoup) ¤ la récup du DD mort.
Et si il avait été bon, il n'aurait pas juste craché sur la compression mais insisté sur le fait de toujorus avoir un backup, quel que soit le systeme principal.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Anne Le Guennec a écrit dans <1ksnc6x.jc69461dmjeo8N%spam.out@out.fr>:
<news:1ksnc6x.jc69461dmjeo8N%spam.out@out.fr>
Ascadix <ascadix.ng@free.fr> wrote:
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et
succésseurs (2000) qui gérent trés différement la compression sur
disque, et ce fut la fin des compresseur de diques.
Mon vendeur de l'époque déconseillait absolument la compression du Dd
principal quand on tenait à ses données.Il me me soutenait qu'un disque
compressé était à peu près irrécupérable en cas de plantage grave.
D'où le DD externe et les magnéto optiques pour les sauvegardes de
données sensibles.
Bien sur, ce type de compression complique nettement toute manip de
récupération.
De toute façon, en cas de plantage grave, tu récupére rien sur le DD,
compressé ou pas sauf à te payer un service de récup à xxxx(beaucoup) ¤
la récup du DD mort.
Et si il avait été bon, il n'aurait pas juste craché sur la compression
mais insisté sur le fait de toujorus avoir un backup, quel que soit le
systeme principal.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Anne Le Guennec a écrit dans <1ksnc6x.jc69461dmjeo8N%: <news:1ksnc6x.jc69461dmjeo8N%
Ascadix wrote:
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et succésseurs (2000) qui gérent trés différement la compression sur disque, et ce fut la fin des compresseur de diques.
Mon vendeur de l'époque déconseillait absolument la compression du Dd principal quand on tenait à ses données.Il me me soutenait qu'un disque compressé était à peu près irrécupérable en cas de plantage grave.
D'où le DD externe et les magnéto optiques pour les sauvegardes de données sensibles.
Bien sur, ce type de compression complique nettement toute manip de récupération.
De toute façon, en cas de plantage grave, tu récupére rien sur le DD, compressé ou pas sauf à te payer un service de récup à xxxx(beaucoup) ¤ la récup du DD mort.
Et si il avait été bon, il n'aurait pas juste craché sur la compression mais insisté sur le fait de toujorus avoir un backup, quel que soit le systeme principal.
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Ascadix
Laszlo Lebrun a pensé très fort :
On 10/27/12 11:01 PM, Ascadix wrote:
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et succésseurs (2000) qui gérent trés différement la compression sur disque, et ce fut la fin des compresseur de diques.
Faut dire que la presque totalité des formats audio, vidéo, photo, documents sont déjà compressés en natif...
Aujourd'hui oui, ... mais là on remonte d'une 15aine d'année en arrière,
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Laszlo Lebrun a pensé très fort :
On 10/27/12 11:01 PM, Ascadix wrote:
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et
succésseurs (2000) qui gérent trés différement la compression sur
disque, et ce fut la fin des compresseur de diques.
Faut dire que la presque totalité des formats audio, vidéo, photo, documents
sont déjà compressés en natif...
Aujourd'hui oui, ... mais là on remonte d'une 15aine d'année en
arrière,
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et succésseurs (2000) qui gérent trés différement la compression sur disque, et ce fut la fin des compresseur de diques.
Faut dire que la presque totalité des formats audio, vidéo, photo, documents sont déjà compressés en natif...
Aujourd'hui oui, ... mais là on remonte d'une 15aine d'année en arrière,
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
abc abc
On 2012-10-28, jdd wrote:
Le 28/10/2012 10:22, Alf92 a écrit :
"Anne Le Guennec" a écrit
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et succésseurs (2000) qui gérent trés différement la compression sur disque, et ce fut la fin des compresseur de diques.
Mon vendeur de l'époque déconseillait absolument la compression du Dd principal quand on tenait à ses données.Il me me soutenait qu'un disque compressé était à peu près irrécupérable en cas de plantage grave.
ton vendeur était mauvais c'est tout.
à mon avis, il confondait disque compressé (ou les fichiers sont compressés un par un) et disque crypté
ceci dit, si par "récupération" on entend lecture secteur par secteur, c'est sur qu'on ne va pas récupérer un fichier compressé, mais on ne récupère pas grand chose comme ca de toute façon
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus. Il est generalement possible de récuperer une partie des données. Si c'est un disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
On 2012-10-28, jdd <jdd@dodin.org> wrote:
Le 28/10/2012 10:22, Alf92 a écrit :
"Anne Le Guennec" <spam.out@out.fr> a écrit
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et
succésseurs (2000) qui gérent trés différement la compression sur
disque, et ce fut la fin des compresseur de diques.
Mon vendeur de l'époque déconseillait absolument la compression du Dd
principal quand on tenait à ses données.Il me me soutenait qu'un disque
compressé était à peu près irrécupérable en cas de plantage grave.
ton vendeur était mauvais c'est tout.
à mon avis, il confondait disque compressé (ou les fichiers sont
compressés un par un) et disque crypté
ceci dit, si par "récupération" on entend lecture secteur par secteur,
c'est sur qu'on ne va pas récupérer un fichier compressé, mais on ne
récupère pas grand chose comme ca de toute façon
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais
certains secteurs seulement qui ne fonctionnent plus. Il est
generalement possible de récuperer une partie des données. Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est
possible que les secteurs defectueux contiennent des données nécessaires
pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
Ajoute-y l'explosion des tailles de DD et le déploiement de NT4 et succésseurs (2000) qui gérent trés différement la compression sur disque, et ce fut la fin des compresseur de diques.
Mon vendeur de l'époque déconseillait absolument la compression du Dd principal quand on tenait à ses données.Il me me soutenait qu'un disque compressé était à peu près irrécupérable en cas de plantage grave.
ton vendeur était mauvais c'est tout.
à mon avis, il confondait disque compressé (ou les fichiers sont compressés un par un) et disque crypté
ceci dit, si par "récupération" on entend lecture secteur par secteur, c'est sur qu'on ne va pas récupérer un fichier compressé, mais on ne récupère pas grand chose comme ca de toute façon
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus. Il est generalement possible de récuperer une partie des données. Si c'est un disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
jdd
Le 28/10/2012 15:33, abc abc a écrit :
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive parfois en insistant
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On peut envisager de récupérer un document texte, mais sauf s'il est extrêmement long ce serait un hasard qu'il soit détruit à moitié
ca peut servir a quelqu'un qui a perdu sa thèse et n'a pas de sauvegarde (plus fréquent qu'on ne croit)
jdd
-- http://dodin.org
Le 28/10/2012 15:33, abc abc a écrit :
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais
certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive
parfois en insistant
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est
possible que les secteurs defectueux contiennent des données nécessaires
pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On
peut envisager de récupérer un document texte, mais sauf s'il est
extrêmement long ce serait un hasard qu'il soit détruit à moitié
ca peut servir a quelqu'un qui a perdu sa thèse et n'a pas de sauvegarde
(plus fréquent qu'on ne croit)
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive parfois en insistant
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On peut envisager de récupérer un document texte, mais sauf s'il est extrêmement long ce serait un hasard qu'il soit détruit à moitié
ca peut servir a quelqu'un qui a perdu sa thèse et n'a pas de sauvegarde (plus fréquent qu'on ne croit)
jdd
-- http://dodin.org
Ascadix
jdd a écrit dans <508d4b85$0$16498$: <news:508d4b85$0$16498$
Le 28/10/2012 15:33, abc abc a écrit :
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
ça c'était dans le temps
Actuellement, les pannes DD les + fréquentes, c'est plutot la partie électronique qui lache, et là c'est d'un coup tout le DD qui disparait.
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive parfois en insistant
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On peut envisager de récupérer un document texte, mais sauf s'il est extrêmement long ce serait un hasard qu'il soit détruit à moitié
ca peut servir a quelqu'un qui a perdu sa thèse et n'a pas de sauvegarde (plus fréquent qu'on ne croit)
Quand t'en est à cette prétention de "niveau" (une thèse, quel que soit le sujet) bosser sur ordi sans faire de backup, c'est comme traverser la route sans regarder, faut laissser faire Darwin.
jdd
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
jdd a écrit dans <508d4b85$0$16498$426a74cc@news.free.fr>:
<news:508d4b85$0$16498$426a74cc@news.free.fr>
Le 28/10/2012 15:33, abc abc a écrit :
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais
certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
ça c'était dans le temps
Actuellement, les pannes DD les + fréquentes, c'est plutot la partie
électronique qui lache, et là c'est d'un coup tout le DD qui disparait.
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive
parfois en insistant
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est
possible que les secteurs defectueux contiennent des données nécessaires
pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On peut
envisager de récupérer un document texte, mais sauf s'il est extrêmement long
ce serait un hasard qu'il soit détruit à moitié
ca peut servir a quelqu'un qui a perdu sa thèse et n'a pas de sauvegarde
(plus fréquent qu'on ne croit)
Quand t'en est à cette prétention de "niveau" (une thèse, quel que soit
le sujet) bosser sur ordi sans faire de backup, c'est comme traverser
la route sans regarder, faut laissser faire Darwin.
jdd
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
jdd a écrit dans <508d4b85$0$16498$: <news:508d4b85$0$16498$
Le 28/10/2012 15:33, abc abc a écrit :
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
ça c'était dans le temps
Actuellement, les pannes DD les + fréquentes, c'est plutot la partie électronique qui lache, et là c'est d'un coup tout le DD qui disparait.
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive parfois en insistant
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On peut envisager de récupérer un document texte, mais sauf s'il est extrêmement long ce serait un hasard qu'il soit détruit à moitié
ca peut servir a quelqu'un qui a perdu sa thèse et n'a pas de sauvegarde (plus fréquent qu'on ne croit)
Quand t'en est à cette prétention de "niveau" (une thèse, quel que soit le sujet) bosser sur ordi sans faire de backup, c'est comme traverser la route sans regarder, faut laissser faire Darwin.
jdd
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
abc abc
On 2012-10-28, jdd wrote:
Le 28/10/2012 15:33, abc abc a écrit :
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive parfois en insistant
Evidemment.
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On peut envisager de récupérer un document texte, mais sauf s'il est extrêmement long ce serait un hasard qu'il soit détruit à moitié
Ben non, c'est beaucoup plus compliqué quand c'est compressé. Avec un disque compressé, le systeme compresse les données globalement, et donc n'importe quel fichier peut dépendre de données réparties un peu partout.
Y a qu'ai faire un test : - prendre un fichier texte, et remplacer aléatoirement 2 ou 3 octets par des 0. Le fichier reste utilisable. En dehors des 2 ou 3 endroits modifiés, le texte est encore correct. - prendre le meme fichier texte, et le compresser avec bzip2. Editer le fichier compressé avec un editeur hexa et remplacer 2 ou 3 octets par des 0. Essayer de décompresser le fichier: "Data integrity error". => le fichier est completement inutilisable. On a tout perdu, pas juste les 2 ou 3 endroits ou il y a eu des modifications.
On 2012-10-28, jdd <jdd@dodin.org> wrote:
Le 28/10/2012 15:33, abc abc a écrit :
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais
certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive
parfois en insistant
Evidemment.
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est
possible que les secteurs defectueux contiennent des données nécessaires
pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On
peut envisager de récupérer un document texte, mais sauf s'il est
extrêmement long ce serait un hasard qu'il soit détruit à moitié
Ben non, c'est beaucoup plus compliqué quand c'est compressé. Avec un
disque compressé, le systeme compresse les données globalement, et donc
n'importe quel fichier peut dépendre de données réparties un peu
partout.
Y a qu'ai faire un test :
- prendre un fichier texte, et remplacer aléatoirement 2 ou 3 octets par des
0. Le fichier reste utilisable. En dehors des 2 ou 3 endroits
modifiés, le texte est encore correct.
- prendre le meme fichier texte, et le compresser avec bzip2. Editer le
fichier compressé avec un editeur hexa et remplacer 2 ou 3 octets par
des 0. Essayer de décompresser le fichier: "Data integrity error".
=> le fichier est completement inutilisable. On a tout perdu, pas
juste les 2 ou 3 endroits ou il y a eu des modifications.
Quand un disque tombe en panne, souvent ce n'est pas tout le disque mais certains secteurs seulement qui ne fonctionnent plus.
ben oui, heureusement :-)
Il est
generalement possible de récuperer une partie des données.
pas celles qui sont sur la partie abimée, ou rarement ddrescue y arrive parfois en insistant
Evidemment.
Si c'est un
disque compressé par contre c'est beaucoup plus compliqué, il est possible que les secteurs defectueux contiennent des données nécessaires pour décompresser tout le reste, et donc tu ne puisse rien récuperer.
c'est pareil compressé ou pas pour tout ce qui est fichier binaire. On peut envisager de récupérer un document texte, mais sauf s'il est extrêmement long ce serait un hasard qu'il soit détruit à moitié
Ben non, c'est beaucoup plus compliqué quand c'est compressé. Avec un disque compressé, le systeme compresse les données globalement, et donc n'importe quel fichier peut dépendre de données réparties un peu partout.
Y a qu'ai faire un test : - prendre un fichier texte, et remplacer aléatoirement 2 ou 3 octets par des 0. Le fichier reste utilisable. En dehors des 2 ou 3 endroits modifiés, le texte est encore correct. - prendre le meme fichier texte, et le compresser avec bzip2. Editer le fichier compressé avec un editeur hexa et remplacer 2 ou 3 octets par des 0. Essayer de décompresser le fichier: "Data integrity error". => le fichier est completement inutilisable. On a tout perdu, pas juste les 2 ou 3 endroits ou il y a eu des modifications.
jdd
Le 28/10/2012 16:37, Ascadix a écrit :
Quand t'en est à cette prétention de "niveau" (une thèse, quel que soit le sujet) bosser sur ordi sans faire de backup, c'est comme traverser la route sans regarder, faut laissser faire Darwin.
une thèse peut être en orthographe ou histoire, l'informatique n'est pas donnée à tous le monde
d'ailleurs une vrai politique de sauvegarde, c'est pas simple
jdd
-- http://dodin.org
Le 28/10/2012 16:37, Ascadix a écrit :
Quand t'en est à cette prétention de "niveau" (une thèse, quel que soit
le sujet) bosser sur ordi sans faire de backup, c'est comme traverser la
route sans regarder, faut laissser faire Darwin.
une thèse peut être en orthographe ou histoire, l'informatique n'est pas
donnée à tous le monde
d'ailleurs une vrai politique de sauvegarde, c'est pas simple
Quand t'en est à cette prétention de "niveau" (une thèse, quel que soit le sujet) bosser sur ordi sans faire de backup, c'est comme traverser la route sans regarder, faut laissser faire Darwin.
une thèse peut être en orthographe ou histoire, l'informatique n'est pas donnée à tous le monde
d'ailleurs une vrai politique de sauvegarde, c'est pas simple
jdd
-- http://dodin.org
jdd
Le 28/10/2012 16:44, abc abc a écrit :
Ben non, c'est beaucoup plus compliqué quand c'est compressé. Avec un disque compressé, le systeme compresse les données globalement, et donc n'importe quel fichier peut dépendre de données réparties un peu partout.
à ma connaissance non. C'est compressé par fichier. Tu peux donc perdre un fichier, pas tout un répertoire
Y a qu'ai faire un test : - prendre un fichier texte, et remplacer aléatoirement 2 ou 3 octets par des 0. Le fichier reste utilisable. En dehors des 2 ou 3 endroits modifiés, le texte est encore correct. - prendre le meme fichier texte, et le compresser avec bzip2. Editer le fichier compressé avec un editeur hexa et remplacer 2 ou 3 octets par des 0. Essayer de décompresser le fichier: "Data integrity error". => le fichier est completement inutilisable. On a tout perdu, pas juste les 2 ou 3 endroits ou il y a eu des modifications.
un disque dur n'écrit jamais d'octets, mais des groupes de secteurs bien assez grands pour n'importe quel fichier texte, surtout compressé
jdd -- http://dodin.org
Le 28/10/2012 16:44, abc abc a écrit :
Ben non, c'est beaucoup plus compliqué quand c'est compressé. Avec un
disque compressé, le systeme compresse les données globalement, et donc
n'importe quel fichier peut dépendre de données réparties un peu
partout.
à ma connaissance non. C'est compressé par fichier. Tu peux donc perdre
un fichier, pas tout un répertoire
Y a qu'ai faire un test :
- prendre un fichier texte, et remplacer aléatoirement 2 ou 3 octets par des
0. Le fichier reste utilisable. En dehors des 2 ou 3 endroits
modifiés, le texte est encore correct.
- prendre le meme fichier texte, et le compresser avec bzip2. Editer le
fichier compressé avec un editeur hexa et remplacer 2 ou 3 octets par
des 0. Essayer de décompresser le fichier: "Data integrity error".
=> le fichier est completement inutilisable. On a tout perdu, pas
juste les 2 ou 3 endroits ou il y a eu des modifications.
un disque dur n'écrit jamais d'octets, mais des groupes de secteurs bien
assez grands pour n'importe quel fichier texte, surtout compressé
Ben non, c'est beaucoup plus compliqué quand c'est compressé. Avec un disque compressé, le systeme compresse les données globalement, et donc n'importe quel fichier peut dépendre de données réparties un peu partout.
à ma connaissance non. C'est compressé par fichier. Tu peux donc perdre un fichier, pas tout un répertoire
Y a qu'ai faire un test : - prendre un fichier texte, et remplacer aléatoirement 2 ou 3 octets par des 0. Le fichier reste utilisable. En dehors des 2 ou 3 endroits modifiés, le texte est encore correct. - prendre le meme fichier texte, et le compresser avec bzip2. Editer le fichier compressé avec un editeur hexa et remplacer 2 ou 3 octets par des 0. Essayer de décompresser le fichier: "Data integrity error". => le fichier est completement inutilisable. On a tout perdu, pas juste les 2 ou 3 endroits ou il y a eu des modifications.
un disque dur n'écrit jamais d'octets, mais des groupes de secteurs bien assez grands pour n'importe quel fichier texte, surtout compressé
