/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation<br>for more details.</div><div><br></div><div>J'ai pu résoudre ce problème avec ntfsfix<br></div><div>Pour diagnostiquer<br><br># ntfsfix -n /dev/sdc1<br>Mountingvolume... $MFTMirr does not match $MFT (record 0).<br>FAILED<br>Attempting to correct errors... <br>Processing $MFT and $MFTMirr...<br>Reading $MFT... OK<br>Reading $MFTMirr... OK<br>Comparing $MFTMirr to $MFT... FAILED<br>Correcting differences in $
<br>puis pour réparer<br><br># ntfsfix /dev/sdc1<br>Mounting volume... $MFTMirr does not match $MFT (record 0).<br>FAILED<br>Attempting to correct errors... <br>Processing $MFT and $MFTMirr...<br>Reading $MFT... OK<br>Reading $MFTMirr... OK<br>Comparing $MFTMirr to $MFT... FAILED<br>Correcting differences in $MFTMirr record 0...OK<br>Processing of $MFT and $MFTMirr completed successfully.<br>Setting required flags on partition... OK<br>Going to empty the journal ($LogFile)... OK<br>Checking
Bonjour a tous
Je viens vers vous car malgré plusieurs essais, je n'arrive pas Ã
copier 300GB de fichier d'un disque dur à un autre.
Tous mes essais jusqu'à présent se sont soldés par des erreurs assez graves: impossible de lire le disque de destination, problème de propriétaire ou d'autorisations.... enfin bon que des trucs super
angoissant où l'on se demande si on a pas tout perdu :-(
J'ai besoin de copier ces fichiers/dossiers car le HD qui les contient
est presque plein (90%).
Au niveau technique, la machine est assez ancienne et tourne encore
sous Stretch.
Le HD source est un SATA de 320GB contenant une partition NTFS (sdb1)
et un espace non alloué de 1,4MB (je ne me rappelle plus pourquoi
c'est la ca...).
Le HD de destination est un SATA de 1TB ne contenant qu'une partition
NTFS (sdc1).
Les 2 partitions sont montées par fstab, sdb1 en /mnmt/data et sdc1 en /mnt/data2.
Ma dernière tentative d'hier avec la commande:
cp -R --preserve=all /mnt/data/mondossier /mnt/data2/
c'est soldé par une catastrophe:
La copie s'est arrêtée à environ 159GB,
Ma console était remplie de message d'erreur du type "problème d'entrée/sortie: impossible de lire le fichier"
Sur les 2 HD après un ls -al, on voyait que les droits et les nom de user/group était remplacé par des ?????
J'ai alors redémarré la machine, celle-ci a bloqué durant le démarrage
a cause de sdc1 qui n'était plus montable. J'ai modifié le fstab en commentant le montage sdc1 et la machine a démarré.
Les ????? ont disparu de la partition sdb1 (HD Source).
Concernant sdc1, voici le message d'erreur au montage:
# mount -t ntfs /dev/sdc1 /mnt/data2/
$MFTMirr does not match $MFT (record 0).
Failed to mount '/dev/sdc1': Erreur d'entrée/sortie
NTFS is either inconsistent, or there is a hardware fault, or it's a SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g. /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
J'ai pu résoudre ce problème avec ntfsfix
Pour diagnostiquer
# ntfsfix -n /dev/sdc1
Mounting volume... $MFTMirr does not match $MFT (record 0).
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
$MFTMirr does not match $MFT (record 0).
Remount failed: Input/output error
puis pour réparer
# ntfsfix /dev/sdc1
Mounting volume... $MFTMirr does not match $MFT (record 0).
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdc1 was processed successfully.
Voila pour ma mésaventure d'hier.
J'ai eu le même type de problème à chaque fois que j'ai tenté de
copier ces fichiers/dossiers.
Je me rappelle plus exactement les solutions que j'ai déjà essayées
mais j'en ai tenté plusieurs, dd entre autre qui avait buggé aussi....
Je ne dois pas être le seul a avoir eu ce problème de copie mais mes recherches ne m'ont pas conduit à une solution.
Je me tourne donc vers vous pour avoir un peu d'aide car je ne vois
pas de solution.
Très cordialement
Hugues
Bonjour a tous
Je viens vers vous car malgré plusieurs essais, je n'arrive pas à copier 300GB de fichier d'un disque dur à un autre.
Tous mes essais jusqu'à présent se sont soldés par des erreurs assez graves: impossible de lire le disque de destination, problème de propriétaire ou d'autorisations.... enfin bon que des trucs super
angoissant où l'on se demande si on a pas tout perdu :-(
J'ai besoin de copier ces fichiers/dossiers car le HD qui les contient
est presque plein (90%).
Au niveau technique, la machine est assez ancienne et tourne encore sous Stretch.
Le HD source est un SATA de 320GB contenant une partition NTFS (sdb1) et
un espace non alloué de 1,4MB (je ne me rappelle plus pourquoi c'est la ca...).
Le HD de destination est un SATA de 1TB ne contenant qu'une partition
NTFS (sdc1).
Les 2 partitions sont montées par fstab, sdb1 en /mnmt/data et sdc1 en /mnt/data2.
Ma dernière tentative d'hier avec la commande:
cp -R --preserve=all /mnt/data/mondossier /mnt/data2/
NTFS c'est un format de système de fichiers proprietaire de microsoft.
Son fonctionnement est secret. Linux arrive tant bien que mal a le
supporter mais c'est tout un morceau de bravoure d'arriver a le faire.
Si tu veux faire une bonne copie de NTFS vers NTFS en gardant bien
toutes les métadonnées, fais la sous windows et non pas sous linux.
Si tu veux faire une bonne copie de NTFS vers NTFS en gardant bien
toutes les métadonnées, fais la sous windows et non pas sous linux :
Le 12/09/2022 à 12:09, Hugues MORIN-TRENEULE a écrit :tout perdu :-(
Bonjour a tous
Je viens vers vous car malgré plusieurs essais, je n'arrive pas à copier 300GB de fichier d'un disque dur à un autre.
Tous mes essais jusqu'à présent se sont soldés par des erreurs assez graves: impossible de lire le disque de destination, problème de propriétaire ou d'autorisations.... enfin bon que des trucs super angoissant où l'on se demande si on a pas
J'ai besoin de copier ces fichiers/dossiers car le HD qui les contient est presque plein (90%).
Au niveau technique, la machine est assez ancienne et tourne encore sous Stretch.
Le HD source est un SATA de 320GB contenant une partition NTFS (sdb1) et un espace non alloué de 1,4MB (je ne me rappelle plus pourquoi c'est la ca...).
Le HD de destination est un SATA de 1TB ne contenant qu'une partition NTFS (sdc1).
Les 2 partitions sont montées par fstab, sdb1 en /mnmt/data et sdc1 en /mnt/data2.
Ma dernière tentative d'hier avec la commande:
cp -R --preserve=all /mnt/data/mondossier /mnt/data2/
NTFS c'est un format de système de fichiers proprietaire de microsoft. Son fonctionnement est secret. Linux arrive tant bien que mal a le supporter mais c'est tout un morceau de bravoure d'arriver a le faire.
Dans ce systeme de fichiers la gestion des droits et des propriétaires n'est pas fait de la meme manière que dans linux, d'ou les soucis que tu a rencontrés.
Je te conseille de virer l'option --preseve=all parce que linux ne sait pas bien faire ca sur du NTFS. Evidamment tu va perdre les métadonnées de tes fichiers (gestion des droits, du proprietaire, date de création et modification, etc…).
Si tu veux faire une bonne copie de NTFS vers NTFS en gardant bien toutes les métadonnées, fais la sous windows et non pas sous linux.
Le 12/09/2022 à 12:09, Hugues MORIN-TRENEULE a écrit :
Bonjour a tous
Je viens vers vous car malgré plusieurs essais, je n'arrive pas Ã
copier 300GB de fichier d'un disque dur à un autre.
Tous mes essais jusqu'à présent se sont soldés par des erreurs assez
graves: impossible de lire le disque de destination, problème de
propriétaire ou d'autorisations.... enfin bon que des trucs super
angoissant où l'on se demande si on a pas tout perdu :-(
J'ai besoin de copier ces fichiers/dossiers car le HD qui les
contient est presque plein (90%).
Au niveau technique, la machine est assez ancienne et tourne encore
sous Stretch.
Le HD source est un SATA de 320GB contenant une partition NTFS (sdb1)
et un espace non alloué de 1,4MB (je ne me rappelle plus pourquoi
c'est la ca...).
Le HD de destination est un SATA de 1TB ne contenant qu'une partition
NTFS (sdc1).
Les 2 partitions sont montées par fstab, sdb1 en /mnt/data et sdc1 en
/mnt/data2.
Ma dernière tentative d'hier avec la commande:
cp -R --preserve=all /mnt/data/mondossier /mnt/data2/
NTFS c'est un format de système de fichiers proprietaire de microsoft.
Son fonctionnement est secret. Linux arrive tant bien que mal a le
supporter mais c'est tout un morceau de bravoure d'arriver a le faire.
Bonjour a tous
Je viens vers vous car malgré plusieurs essais, je n'arrive pas à copier >300GB de fichier d'un disque dur à un autre.
Tous mes essais jusqu'à présent se sont soldés par des erreurs assez >graves: impossible de lire le disque de destination, problème de >propriétaire ou d'autorisations.... enfin bon que des trucs super
angoissant où l'on se demande si on a pas tout perdu :-(
J'ai besoin de copier ces fichiers/dossiers car le HD qui les contient est >presque plein (90%).
Au niveau technique, la machine est assez ancienne et tourne encore sous >Stretch.
Le HD source est un SATA de 320GB contenant une partition NTFS (sdb1) et un >espace non alloué de 1,4MB (je ne me rappelle plus pourquoi c'est la ca...). >Le HD de destination est un SATA de 1TB ne contenant qu'une partition NTFS >(sdc1).
Les 2 partitions sont montées par fstab, sdb1 en /mnmt/data et sdc1 en >/mnt/data2.
Ma dernière tentative d'hier avec la commande:
cp -R --preserve=all /mnt/data/mondossier /mnt/data2/
c'est soldé par une catastrophe:
La copie s'est arrêtée à environ 159GB,
Ma console était remplie de message d'erreur du type "problème >d'entrée/sortie: impossible de lire le fichier"
Sur les 2 HD après un ls -al, on voyait que les droits et les nom de >user/group était remplacé par des ?????
J'ai alors redémarré la machine, celle-ci a bloqué durant le démarrage a >cause de sdc1 qui n'était plus montable. J'ai modifié le fstab en >commentant le montage sdc1 et la machine a démarré.
Les ????? ont disparu de la partition sdb1 (HD Source).
Concernant sdc1, voici le message d'erreur au montage:
# mount -t ntfs /dev/sdc1 /mnt/data2/
$MFTMirr does not match $MFT (record 0).
Failed to mount '/dev/sdc1': Erreur d'entrée/sortie
NTFS is either inconsistent, or there is a hardware fault, or it's a >SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very >important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g. >/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
J'ai pu résoudre ce problème avec ntfsfix
Pour diagnostiquer
# ntfsfix -n /dev/sdc1
Mounting volume... $MFTMirr does not match $MFT (record 0).
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
$MFTMirr does not match $MFT (record 0).
Remount failed: Input/output error
puis pour réparer
# ntfsfix /dev/sdc1
Mounting volume... $MFTMirr does not match $MFT (record 0).
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdc1 was processed successfully.
Voila pour ma mésaventure d'hier.
J'ai eu le même type de problème à chaque fois que j'ai tenté de copier ces
fichiers/dossiers.
Je me rappelle plus exactement les solutions que j'ai déjà essayées mais >j'en ai tenté plusieurs, dd entre autre qui avait buggé aussi....
Je ne dois pas être le seul a avoir eu ce problème de copie mais mes >recherches ne m'ont pas conduit à une solution.
Je me tourne donc vers vous pour avoir un peu d'aide car je ne vois pas de >solution.
Très cordialement
Hugues
Je me tourne donc vers vous pour avoir un peu d'aide car je ne vois pas de solution.</div><div><br></div><div></div><div>Très cordialement</div><div>Hugues<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></blockquote></div><br clear="all">Bonjour<br>As-tu essayé avec rsync qui en général fait ça très bien ?<br>Cordialement <div style='white-space: pre-wrap'>Lumière de tous les Chakras ⚡⚡⚡🤣 🤣🤣</div></body></html>
En effet, NTFS est mal supporté sous Linux, car il n'y aurait pas de
pilote en logiciel complètement libre :
Si tu veux faire une bonne copie de NTFS vers NTFS en gardant bien
toutes les métadonnées, fais la sous windows et non pas sous linux :
Sages décision et action.
Dans le man je vois :
"-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)"
il est donc inutile de mettre le "t" vu qu'il est déjà contenu dans le
"a".
Merci pour l'option -P, que je ne connaissait pas.
Selon les cas, il peut etre utile de rajouter -AXH pour les ACL, les >attributs étendus et les liens en dur. Par exemple si tu copie un
système.
J'utilise depuis des années cette commande qui ne m'a jamais fait de
sale coup
rsync -aPtv /xxx/yyy/source /vvv/zzz/destination && sync
Et quelle commande me conseillerez vous pour la copie cp, dd ou rsync?
Cette "portabilité" n'ayant plus d'intérêt pour moi, pensez vous qu'en formatant le disque de destination en ext4 cela fonctionnerait?
Et quelle commande me conseillerez vous pour la copie cp, dd ou rsync?
Question subsidiaire, je la pose mais j'y crois pas trop, ça serait trop simple ;-)
Est ce qu'il existe un moyen de changer le type de partition sans
altérer les données, passer de NTFS a ext4?
Bonjour a tous
Je viens vers vous car malgré plusieurs essais, je n'arrive pas Ã
copier 300GB de fichier d'un disque dur à un autre.
Tous mes essais jusqu'à présent se sont soldés par des erreurs assez graves: impossible de lire le disque de destination, problème de propriétaire ou d'autorisations.... enfin bon que des trucs super angoissant où l'on se demande si on a pas tout perdu :-(
J'ai besoin de copier ces fichiers/dossiers car le HD qui les contient
est presque plein (90%).
Au niveau technique, la machine est assez ancienne et tourne encore
sous Stretch.
Le HD source est un SATA de 320GB contenant une partition NTFS (sdb1)
et un espace non alloué de 1,4MB (je ne me rappelle plus pourquoi
c'est la ca...).
Le HD de destination est un SATA de 1TB ne contenant qu'une partition
NTFS (sdc1).
Les 2 partitions sont montées par fstab, sdb1 en /mnmt/data et sdc1 en /mnt/data2.
Ma dernière tentative d'hier avec la commande:
cp -R --preserve=all /mnt/data/mondossier /mnt/data2/
c'est soldé par une catastrophe:
La copie s'est arrêtée à environ 159GB,
Ma console était remplie de message d'erreur du type "problème d'entrée/sortie: impossible de lire le fichier"
Sur les 2 HD après un ls -al, on voyait que les droits et les nom de user/group était remplacé par des ?????
J'ai alors redémarré la machine, celle-ci a bloqué durant le démarrage
a cause de sdc1 qui n'était plus montable. J'ai modifié le fstab en commentant le montage sdc1 et la machine a démarré.
Les ????? ont disparu de la partition sdb1 (HD Source).
Concernant sdc1, voici le message d'erreur au montage:
# mount -t ntfs /dev/sdc1 /mnt/data2/
$MFTMirr does not match $MFT (record 0).
Failed to mount '/dev/sdc1': Erreur d'entrée/sortie
NTFS is either inconsistent, or there is a hardware fault, or it's a SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g. /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
J'ai pu résoudre ce problème avec ntfsfix
Pour diagnostiquer
# ntfsfix -n /dev/sdc1
Mounting volume... $MFTMirr does not match $MFT (record 0).
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
$MFTMirr does not match $MFT (record 0).
Remount failed: Input/output error
puis pour réparer
# ntfsfix /dev/sdc1
Mounting volume... $MFTMirr does not match $MFT (record 0).
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdc1 was processed successfully.
Voila pour ma mésaventure d'hier.
J'ai eu le même type de problème à chaque fois que j'ai tenté de
copier ces fichiers/dossiers.
Je me rappelle plus exactement les solutions que j'ai déjà essayées
mais j'en ai tenté plusieurs, dd entre autre qui avait buggé aussi....
Je ne dois pas être le seul a avoir eu ce problème de copie mais mes recherches ne m'ont pas conduit à une solution.
Je me tourne donc vers vous pour avoir un peu d'aide car je ne vois
pas de solution.
Très cordialement
Hugues
Bonjour,
Au vu des problèmes rencontrés, ton disque d origine est très probablement abimé et je te conseille d utiliser ddrescue à partir d
un linux live ( grml, systemrescuecd, ...)Â pour faire soit une copie disque vers disque soit une copie disque vers image.
Please note the following marginal Attributes:<br>ID# ATTRIBUTE_NAME      FLAG   VALUE WORST THRESH TYPE    UPDATED  WHEN_FAILED RAW_VALUE<br>184 End-to-End_Error     0x0032  098  098  099   Old_age  Always ÂFAILING_NOW 2<br></div><div><br></div><div>A ce stade, il semblerait qu'il y ait un problème sur le disque de destination.</div></div><a href="https://www.partitionwizard.com/partitionmanager/end-to-end-error.html" target="_blank">https://www.
A ce stade, il semblerait qu'il y ait un problème sur le disque de destination. https://www.partitionwizard.com/partitionmanager/end-to-end-error.html <https://www.partitionwizard.com/partitionmanager/end-to-end-error.html>
Je vais lancer le test du HD source durant la nuit
Le 12/09/2022 à 19:53, Hugues MORIN-TRENEULE a écrit :
A ce stade, il semblerait qu'il y ait un problème sur le disque de destination. https://www.partitionwizard.com/partitionmanager/end-to-end-error.html <https://www.partitionwizard.com/partitionmanager/end-to-end-error.html>
Je vais lancer le test du HD source durant la nuit
Ca depend de quel test.
Si c'est interroger smartctl, ok, mais ca ne prend pas toute la nuit.
Mais si ce disque a des soucis materiels, il faut éviter au maximum de
le faire travailler : il peut rendre l'ame totalement d'un moment a
l'autre. La priorité est donc d'en extraire le maximum de données utiles.
Si tu parle de le tester plus longuement, c'est que tu crains qu'il ait
des soucis. Fais-en d'abord une copie avec ddrescue. Quand tes données seront copiées, tu pourra investiguer plus longuement la santé
materielle du disque. Par exemple avec badblocks. Ce genre de test le
fait beaucoup travailler, si il meurt pendant le test au moins t'aura
copié les données avant.
Par contre pour le disque destination c'est le bon moment de faire un
test approfondi, avant d'y écrire des trucs dessus.
<br></div><div>J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi totalité des blocs comme défectueux !!??? O_o</div><div>Le resultat etait un truc du style (9954621654/0/0)</div><div>J'ai essayé de réparer cematin, sans succès :(<br></div><div><br></div><div>Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé.</div><div>Je pense que les essais de copie successif l'on peut être endommagé.</div><div>Ce n'est peut être que
Oui,
mais toutes ces solutions (Filezilla, CloneZilla...) doivent-elles
être précédées d'un montage de la partition NTFS avec "ntfs-3g" ?
Merci,
A. Valmer
J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi totalité des blocs comme défectueux !!??? O_o
Le resultat etait un truc du style (9954621654/0/0)
J'ai essayé de réparer ce matin, sans succès :(
Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé.
Je pense que les essais de copie successif l'on peut être endommagé.
Ce n'est peut être que des dommages logiques qui peuvent se réparer avec
un formatage bas niveau.
Dans le doute, et pour ne pas prendre de risque, je viens de racheter un
HDD neuf pour le remplacer.
Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit :statique.
J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi totalité des blocs comme défectueux !!??? O_o
Le resultat etait un truc du style (9954621654/0/0)
J'ai essayé de réparer ce matin, sans succès :(
Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé.
Je pense que les essais de copie successif l'on peut être endommagé.
Ce n'est peut être que des dommages logiques qui peuvent se réparer avec un formatage bas niveau.
Si badblocks te sort des erreurs, c'est pas un problème logiciel. C'est bien que ce disque est mort.
Vu qu'il te sort tous les blocs defectueux sur un disque neuf, il se peut que le problème soit ailleurs que sur le plateau du disque, par exemple le controleur du disque qui est mort, par exemple parce qu'il s'est pris une décharge d'électricité
A la rigueur tu peux essayer de remplacer la carte electronique du disque si t'arrive a en trouver une vraiment identique.
Dans le doute, et pour ne pas prendre de risque, je viens de racheter un HDD neuf pour le remplacer.
Sage décision.
Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit :
J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi totalité des blocs comme défectueux !!??? O_o
Le resultat etait un truc du style (9954621654/0/0)
J'ai essayé de réparer ce matin, sans succès :(
Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé. Je pense que les essais de copie successif l'on peut être endommagé.
Ce n'est peut être que des dommages logiques qui peuvent se réparer avec un formatage bas niveau.
Si badblocks te sort des erreurs, c'est pas un problème logiciel. C'est
bien que ce disque est mort.
Vu qu'il te sort tous les blocs defectueux sur un disque neuf, il se
peut que le problème soit ailleurs que sur le plateau du disque, par
exemple le controleur du disque qui est mort, par exemple parce qu'il
s'est pris une décharge d'électricité statique.
A la rigueur tu peux essayer de remplacer la carte electronique du
disque si t'arrive a en trouver une vraiment identique.
Dans le doute, et pour ne pas prendre de risque, je viens de racheter un HDD neuf pour le remplacer.
Sage décision.
</div><div>C'est tout bête mais on passe facilement à côté de ce genre de truc... qui peut être la cause de GROOOSSSS PROBLÈMES =)</div><div><br></div><div>Bonne soiree</div><div>Hugues<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 13 sept. 2022 à  12:53, hamster <<a href="mailto:hamster@suna.fdn.fr">hamster@suna.fdn.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,
Salut
J'irai pas m'embêter à remplacer la carte contrôleur, ça vaut pas le coup au vue du prix du disque (50 euro) et du risque.
A l'occasion, je ferai 2 ou 3 tests pour voir s' il repart sinon.... sûrement poubelle.
Ça sera l'occasion d'apprendre 2 ou 3 trucs de plus sur les HD même si j'arrive pas le reparer ;-)
Merci Error404 pour l'idée de remplacer le câble SATA.
C'est tout bête mais on passe facilement à côté de ce genre de truc... qui
peut être la cause de GROOOSSSS PROBLÈMES =)
Bonne soiree
Hugues
Le mar. 13 sept. 2022 à 12:53, hamster <hamster@suna.fdn.fr> a écrit :
Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit :
J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi >> > totalité des blocs comme défectueux !!??? O_oavec
Le resultat etait un truc du style (9954621654/0/0)
J'ai essayé de réparer ce matin, sans succès :(
Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé. >> > Je pense que les essais de copie successif l'on peut être endommagé.
Ce n'est peut être que des dommages logiques qui peuvent se réparer
un formatage bas niveau.
Si badblocks te sort des erreurs, c'est pas un problème logiciel. C'est
bien que ce disque est mort.
Vu qu'il te sort tous les blocs defectueux sur un disque neuf, il se
peut que le problème soit ailleurs que sur le plateau du disque, par
exemple le controleur du disque qui est mort, par exemple parce qu'il
s'est pris une décharge d'électricité statique.
A la rigueur tu peux essayer de remplacer la carte electronique du
disque si t'arrive a en trouver une vraiment identique.
Dans le doute, et pour ne pas prendre de risque, je viens de racheterun
HDD neuf pour le remplacer.
Sage décision.
/dev/sda10       115234816 173826047  58591232   28G 83 Linux<br><br>Les entrées de la table de partitions ne sont pas dans l'ordre du disque.<br><br><br>Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs<br>Unités : secteur de 1 × 512 = 512 octets<br>Taille de secteur (logique / physique) : 512 octets / 4096 octets<br>taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets<br></div><div><br></div><div><br></div><div>Cordialement </div><
Hugues</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 13 sept. 2022 à  19:59, Hugues MORIN-TRENEULE <<a href="mailto:morinh@gmail.com">morinh@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Salut</div><div><br></div><div>J'irai pas m'embêter à remplacer la carte contrôleur, ça vaut pas le coup au vue du prix du
<br></div><div>Bonne soiree</div><div>Hugues<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 13 sept. 2022 à  12:53, hamster <<a href="mailto:hamster@suna.fdn.fr" target="_blank">hamster@suna.fdn.fr</a>>a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit :<br>
bonjour,
Peut être parce que tu as créé directement le système de fichier sur sdc ?
et pas sur sdc1 ?
Si sdc1 n'existe pas, il faut le créer avec fdisk ou gparted, et ajouter
une nouvelle partition ...
pour créer ton système de fichier, quel commande as tu effectué ?
mkfs.ext4 /dev/sdc ou mkfs.ext4 /dev/sdc1 ?
Jerem
Le 14/09/2022 à 12:59, Hugues MORIN-TRENEULE a écrit :
Bonjour
Ca y est le nouveau disque est installé et formaté en ext4
Par contre un truc me parait bizarre, fdisk -l ne me fait pas
apparaître la partition sdc1 a l'instar des autres disques.
Est ce normal?
# smartctl -H /dev/sdcsmartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-19-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke,
www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
# fdisk -l
Disque /dev/sdb : 298,1 GiB, 320072933376 octets, 625142448 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xd28ed28e
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdb1 * 2048 625139711 625137664 298,1G 7 HPFS/NTFS/exFAT
Disque /dev/sda : 298,1 GiB, 320072933376 octets, 625142448 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x883a2be2
Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sda1 * 2048 3905535 3903488 1,9G 83 Linux
/dev/sda2 3907582 173826047 169918466 81G 5 Étendue /dev/sda3 173826048 330076159 156250112 74,5G 83 Linux
/dev/sda5 3907584 5859327 1951744 953M 83 Linux
/dev/sda6 5861376 13672447 7811072 3,7G 82 partition d'échang
/dev/sda7 13674496 17577983 3903488 1,9G 83 Linux
/dev/sda8 17580032 76171263 58591232 28G 83 Linux
/dev/sda9 76173312 115232767 39059456 18,6G 83 Linux /dev/sda10 115234816 173826047 58591232 28G 83 Linux
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Cordialement
Hugues
Le mar. 13 sept. 2022 à 19:59, Hugues MORIN-TRENEULE <morinh@gmail.com> a écrit :
Salut
J'irai pas m'embêter à remplacer la carte contrôleur, ça vaut pas le coup
au vue du prix du disque (50 euro) et du risque.
A l'occasion, je ferai 2 ou 3 tests pour voir s' il repart sinon....
sûrement poubelle.
Ça sera l'occasion d'apprendre 2 ou 3 trucs de plus sur les HD même si
j'arrive pas le reparer ;-)
Merci Error404 pour l'idée de remplacer le câble SATA.
C'est tout bête mais on passe facilement à côté de ce genre de truc... >> qui peut être la cause de GROOOSSSS PROBLÈMES =)
Bonne soiree
Hugues
Le mar. 13 sept. 2022 à 12:53, hamster <hamster@suna.fdn.fr> a écrit :
Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit :
J'ai lancé badblock durant la nuit, au matin il m'avait listé la quasi >>> > totalité des blocs comme défectueux !!??? O_oavec
Le resultat etait un truc du style (9954621654/0/0)
J'ai essayé de réparer ce matin, sans succès :(
Certes ce disque était un peu vieux mais il n'avait jamais ete utilisé. >>> > Je pense que les essais de copie successif l'on peut être endommagé. >>> > Ce n'est peut être que des dommages logiques qui peuvent se réparer
un formatage bas niveau.
Si badblocks te sort des erreurs, c'est pas un problème logiciel. C'est >>> bien que ce disque est mort.
Vu qu'il te sort tous les blocs defectueux sur un disque neuf, il se
peut que le problème soit ailleurs que sur le plateau du disque, par
exemple le controleur du disque qui est mort, par exemple parce qu'il
s'est pris une décharge d'électricité statique.
A la rigueur tu peux essayer de remplacer la carte electronique du
disque si t'arrive a en trouver une vraiment identique.
Dans le doute, et pour ne pas prendre de risque, je viens de racheterun
HDD neuf pour le remplacer.
Sage décision.
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique)Â : 512Â octets / 4096Â octets
taille d'E/S (minimale / optimale)Â : 4096Â octets / 4096Â octets
Bonjour
Ca y est le nouveau disque est installé et formaté en ext4
Par contre un truc me parait bizarre, fdisk -l ne me fait pas
apparaître la partition sdc1 a l'instar des autres disques.
Est ce normal?
# smartctl -H /dev/sdcsmartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-19-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke,
www.smartmontools.org <http://www.smartmontools.org>
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
# fdisk -l
Disque /dev/sdb : 298,1 GiB, 320072933376 octets, 625142448 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique)Â : 512Â octets / 512Â octets
taille d'E/S (minimale / optimale)Â : 512Â octets / 512Â octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xd28ed28e
Périphérique Amorçage Début    Fin  Secteurs Taille Id Type /dev/sdb1   *     2048 625139711 625137664 298,1G  7 HPFS/NTFS/exFAT
Disque /dev/sda : 298,1 GiB, 320072933376 octets, 625142448 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique)Â : 512Â octets / 512Â octets
taille d'E/S (minimale / optimale)Â : 512Â octets / 512Â octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x883a2be2
Périphérique Amorçage   Début    Fin  Secteurs Taille Id Type /dev/sda1   *       2048  3905535  3903488  1,9G 83 Linux
/dev/sda2        3907582 173826047 169918466   81G  5 Étendue
/dev/sda3       173826048 330076159 156250112  74,5G 83 Linux /dev/sda5        3907584  5859327  1951744  953M 83 Linux /dev/sda6        5861376  13672447  7811072  3,7G 82 partition d'échang
/dev/sda7 Â Â Â Â Â Â Â 13674496 Â 17577983 Â 3903488 Â 1,9G 83 Linux /dev/sda8 Â Â Â Â Â Â Â 17580032 Â 76171263 Â 58591232 Â Â 28G 83 Linux
/dev/sda9 Â Â Â Â Â Â Â 76173312 115232767 Â 39059456 Â 18,6G 83 Linux /dev/sda10 Â Â Â Â Â Â 115234816 173826047 Â 58591232 Â Â 28G 83 Linux
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique)Â : 512Â octets / 4096Â octets
taille d'E/S (minimale / optimale)Â : 4096Â octets / 4096Â octets
Cordialement
Hugues
Le mar. 13 sept. 2022 à  19:59, Hugues MORIN-TRENEULE <morinh@gmail.com <mailto:morinh@gmail.com>> a écrit :
Salut
J'irai pas m'embêter à remplacer la carte contrôleur, ça vaut pas
le coup au vue du prix du disque (50 euro) et du risque.
A l'occasion, je ferai 2 ou 3 tests pour voir s' il repart
sinon.... sûrement poubelle.
Ça sera l'occasion d'apprendre 2 ou 3 trucs de plus sur les HD
même si j'arrive pas le reparer ;-)
Merci Error404 pour l'idée de remplacer le câble SATA.
C'est tout bête mais on passe facilement à côté de ce genre de
truc... qui peut être la cause de GROOOSSSS PROBLÈMES =)
Bonne soiree
Hugues
Le mar. 13 sept. 2022 à  12:53, hamster <hamster@suna.fdn.fr
<mailto:hamster@suna.fdn.fr>> a écrit :
Le 13/09/2022 à 11:24, Hugues MORIN-TRENEULE a écrit :
> J'ai lancé badblock durant la nuit, au matin il m'avait
listé la quasi
> totalité des blocs comme défectueux !!??? O_o
> Le resultat etait un truc du style (9954621654/0/0)
> J'ai essayé de réparer ce matin, sans succès :(
>
> Certes ce disque était un peu vieux mais il n'avait jamais
ete utilisé.
> Je pense que les essais de copie successif l'on peut être
endommagé.
> Ce n'est peut être que des dommages logiques qui peuvent se
réparer avec
> un formatage bas niveau.
Si badblocks te sort des erreurs, c'est pas un problème
logiciel. C'est
bien que ce disque est mort.
Vu qu'il te sort tous les blocs defectueux sur un disque neuf,
il se
peut que le problème soit ailleurs que sur le plateau du
disque, par
exemple le controleur du disque qui est mort, par exemple
parce qu'il
s'est pris une décharge d'électricité statique.
A la rigueur tu peux essayer de remplacer la carte
electronique du
disque si t'arrive a en trouver une vraiment identique.
> Dans le doute, et pour ne pas prendre de risque, je viens de
racheter un
> HDD neuf pour le remplacer.
Sage décision.
Le 14/09/2022 à 12:59, Hugues MORIN-TRENEULE a écrit :
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Je vois l'avant derniere ligne :
"Taille de secteur (logique / physique) : 512 octets / 4096 octets"
Il s'agit d'un disque 4K. Le formatage que tu a fait est fonctionnel
mais pas optimal. Tu aurais interet a faire un formatage 4K pour avoir
sur cette ligne :
"Taille de secteur (logique / physique) : 4096 octets / 4096 octets"
Allocation des tables de groupe : complété             <br>Écriture des tables d'i-noeuds : complété             <br>Création du journal (262144 blocs) : complété<br>Écriture des superblocset de l'information de comptabilité du système de<br>fichiers : complété <br></div><div><br></div><div># fdisk -l<br>[...]<br>Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs<br>Unités : secteur de 1 × 512 = 512Â
Tout semble ok, sauf la taille du bloc logique comme le signale Hamster: Taille de secteur (logique / physique)Â : 512Â octets / 4096Â octets
J'ai beau chercher dans les man (mkfs, fdisk) et sur le net, je ne
trouve pas comment faire pour passer la partition logique a 4096 (ou
alors je suis passé à côté car je n'ai pas compris ce que j'ai lu).
Salut
Je me demande si ce n’est pas lié au format du partitionnement(ancien style msdos / nouveau format GPT) ?
La, je dois avouer que ça dépasse mes compétences et je ne sais pas comment basculer de l'un à l'autre lors du partionnement/formatage
Je vais essayer de repartitionner et formater avec GParted.
Ça fonctionne pour Hamster, ca devrait fonctionner pour moi aussi.
Je me demande si ce n’est pas lié au format du partitionnement (ancienstyle msdos / nouveau format GPT) ?
Bonjour,
Vu que c’est fdisk qui te sort l’info, c’est plutôt lié aux partitionnement qu’aux systèmes de fichiers que les partitions contiennent…
Je me demande si ce n’est pas lié au format du partitionnement (ancien style msdos / nouveau format GPT) ?
Cdlt,
Fred.
*De :* Hugues MORIN-TRENEULE <morinh@gmail.com>
*Envoyé :* mercredi 14 septembre 2022 22:19
*À :* Liste Debian <debian-user-french@lists.debian.org>
*Objet :* Re: Copier 300GB d'un disque dur a un autre
Salut
Oui, je l'ai fait un peu à la "va vite" en utilisant l'interface graphique...
Je viens de reprendre tout ca proprement
D'abord avec un fdisk /dev/sdc pour creer sdc1
Puis pour formater
# mkfs.ext4 -b 4096 /dev/sdc1
mke2fs 1.43.4 (31-Jan-2017)
En train de créer un système de fichiers avec 244190390 4k blocs et 61054976 i-noeuds.
UUID de système de fichiers=efe88182-8ed2-4057-b1db-b2135c0bb300
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848
Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Création du journal (262144 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété
# fdisk -l
[...]
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x334ead1d
Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sdc1 2048 1953525167 1953523120 931,5G 83 Linux
Tout semble ok, sauf la taille du bloc logique comme le signale Hamster:
Taille de secteur (logique / physique) : 512 octets / 4096 octets
J'ai beau chercher dans les man (mkfs, fdisk) et sur le net, je ne trouve
pas comment faire pour passer la partition logique a 4096 (ou alors je suis passé à côté car je n'ai pas compris ce que j'ai lu).
Cordialement
Hugues
Le mer. 14 sept. 2022 à 13:40, hamster <hamster@suna.fdn.fr> a écrit :
Le 14/09/2022 à 12:59, Hugues MORIN-TRENEULE a écrit :
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Je vois l'avant derniere ligne :
"Taille de secteur (logique / physique) : 512 octets / 4096 octets"
Il s'agit d'un disque 4K. Le formatage que tu a fait est fonctionnel
mais pas optimal. Tu aurais interet a faire un formatage 4K pour avoir
sur cette ligne :
"Taille de secteur (logique / physique) : 4096 octets / 4096 octets"
</p></div>
Salut,
Pour convertir de MBR vers GPT, il faut utiliser le programme gdisk.
https://www.explorelinux.com/convert-disk-mbr-to-gpt-on-linux/
Rien de bien sorcier.
Bon courage.
steve
Par contre, ça rien changer au niveau de la taille des secteurs logique/physique:
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique)Â : 512Â octets / 4096Â octets
taille d'E/S (minimale / optimale)Â : 4096Â octets / 4096Â octets
Type d'étiquette de disque : gpt
Identifiant de disque : 10976883-90A9-412E-A78E-EF579FA75262
Le 15/09/2022 à 18:50, Hugues MORIN-TRENEULE a écrit :
Par contre, ça rien changer au niveau de la taille des secteurs logique/physique:
Disque /dev/sdc : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 10976883-90A9-412E-A78E-EF579FA75262
Ah, en effet.
Heu, désolé mais je saurai pas t'aider plus sur ce coup.
Bonsoir
Vous m'avez tous déjà bien aidé à sortir d'une sacrée galère dont je cherchais la solution depuis un bout de temps ;-)
Merci :)
Sinon, est ce que ce problème de taille de secteur logique/physique qui n'est pas optimal, peut être un problème important?
Ou est-ce juste une optimisation qui devrait être faite mais qui n'a pas
de conséquence importante sur le système et la sécurité du stockage de données?
Le 15/09/2022 à 21:02, Hugues MORIN-TRENEULE a écrit :
Bonsoir
Vous m'avez tous déjà bien aidé à sortir d'une sacrée galère dont je cherchais la solution depuis un bout de temps ;-)
Merci :)
Sinon, est ce que ce problème de taille de secteur logique/physique qui n'est pas optimal, peut être un problème important?
Ou est-ce juste une optimisation qui devrait être faite mais qui n'a pas de conséquence importante sur le système et la sécurité du stockage de données?
Pas important du tout. Ca ralentit un peu la vitesse d'ecriture et ca
fait un peu plus travailler le disque, c'est tout. Tu peux très bien
vivre avec.
Si t'a envie de comprendre : le secteur c'est la plus petite quantité
qu'on peut manipuler sur le disque. On peut lire ou ecrire un secteur,
ou meme plusieurs secteurs, mais pas un demi secteur.
Historiquement, les disques avaient des secteurs de 512 octets. Les
disques récents sont devenus plus gros et ca fait un grand nombre de secteurs, alors les secteurs ont été agrandis a 4096 octets (8 fois plus grands).
Quand tu a un formattage 512 sur un disque 4096, le microcontroleur
intégré dans le disque se charge de gerer le truc.
Si tu veux lire un secteur de 512, le microcontroleur va lire le secteur
4096 qui contiens ce que tu demande, puis il découpe ce qu'il a lu en 8
et te donne le bon morceau.
Si tu veux ecrire un secteur de 512, le microcontroleur calcule dans
quel secteur 4096 la zone que tu veux écrire va tomber, il lit ce
secteur 4096, il remplace la bonne zone 512 par ce que tu veux écrire
puis il re-ecrit le secteur 4096.
Bon, c'est quand meme rare qu'on ecrive juste un secteur 512. Ca arrive surtout au début ou a la fin d'un fichier, donc au total ca fait une
grande quantité de secteurs 4096 écris (par groupes de 8 secteurs 512)
et un petit nombre de fois ou il fait cette gymnastique.
Salut
Merci pour l'explication
C'est ce que je supputais sans pouvoir le formuler aussi clairement et précisément que tu l'as fait.
Même si ce n'est pas optimal, ça fera tres bien l'affaire pour l'utilisation que j'en ai :-)
Allez, je passe à la copie ;-)
Cordialement
Hugues
Le jeu. 15 sept. 2022 à 22:47, hamster <hamster@suna.fdn.fr> a écrit :
Le 15/09/2022 à 21:02, Hugues MORIN-TRENEULE a écrit :
Bonsoirpas
Vous m'avez tous déjà bien aidé à sortir d'une sacrée galère dont je >> > cherchais la solution depuis un bout de temps ;-)
Merci :)
Sinon, est ce que ce problème de taille de secteur logique/physique qui >> > n'est pas optimal, peut être un problème important?
Ou est-ce juste une optimisation qui devrait être faite mais qui n'a
de conséquence importante sur le système et la sécurité du stockage de >> > données?
Pas important du tout. Ca ralentit un peu la vitesse d'ecriture et ca
fait un peu plus travailler le disque, c'est tout. Tu peux très bien
vivre avec.
Si t'a envie de comprendre : le secteur c'est la plus petite quantité
qu'on peut manipuler sur le disque. On peut lire ou ecrire un secteur,
ou meme plusieurs secteurs, mais pas un demi secteur.
Historiquement, les disques avaient des secteurs de 512 octets. Les
disques récents sont devenus plus gros et ca fait un grand nombre de
secteurs, alors les secteurs ont été agrandis a 4096 octets (8 fois plus >> grands).
Quand tu a un formattage 512 sur un disque 4096, le microcontroleur
intégré dans le disque se charge de gerer le truc.
Si tu veux lire un secteur de 512, le microcontroleur va lire le secteur
4096 qui contiens ce que tu demande, puis il découpe ce qu'il a lu en 8
et te donne le bon morceau.
Si tu veux ecrire un secteur de 512, le microcontroleur calcule dans
quel secteur 4096 la zone que tu veux écrire va tomber, il lit ce
secteur 4096, il remplace la bonne zone 512 par ce que tu veux écrire
puis il re-ecrit le secteur 4096.
Bon, c'est quand meme rare qu'on ecrive juste un secteur 512. Ca arrive
surtout au début ou a la fin d'un fichier, donc au total ca fait une
grande quantité de secteurs 4096 écris (par groupes de 8 secteurs 512)
et un petit nombre de fois ou il fait cette gymnastique.
Quelle est sa fonction dans le processus de copie?</div><div><br></div><div>Cordialement</div><div>Hugues</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 16 sept. 2022 à  10:51, Hugues MORIN-TRENEULE <<a href="mailto:morinh@gmail.com">morinh@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Salut</div><div><br></div><div>Merci pour
Salut
Dans la commande
rsync -aPv /xxx/yyy/source /vvv/zzz/destination && sync
Le "sync" correspond bien à cette commande: http://manpagesfr.free.fr/man/man8/sync.8.html <http://manpagesfr.free.fr/man/man8/sync.8.html>
J'ai compris qu'elle permettait de s'assurer que le contenu en
mémoire soit bien inscrit sur le disque mais je ne comprends pas bien pourquoi on l'appelle après rsync?
Quelle est sa fonction dans le processus de copie?
Un moyen simple de le faire, c'est de ne pas aller écrire chaque chose a écrire au fur et a mesure mais de les grouper. Il y a donc une mémoire cache.
Merci beaucoup pour cette réponse à une question que je ne me posais pas forcément.
Le 16/09/2022 à 11:49, Hugues MORIN-TRENEULE a écrit :
Salut
Dans la commande
rsync -aPv /xxx/yyy/source /vvv/zzz/destination && sync
Le "sync" correspond bien à cette commande: http://manpagesfr.free.fr/man/man8/sync.8.html <http://manpagesfr.free.fr/man/man8/sync.8.html>
J'ai compris qu'elle permettait de s'assurer que le contenu en
mémoire soit bien inscrit sur le disque mais je ne comprends pas bien pourquoi on l'appelle après rsync?
Quelle est sa fonction dans le processus de copie?
Dans un disque mécanique, il y a une tete le lecture qui bouge. Plus on
la fait bouger, plus le mécanisme s'use. C'est donc une bonne idée d'économiser les mouvements de cette tete de lecture.
Un moyen simple de le faire, c'est de ne pas aller écrire chaque chose a écrire au fur et a mesure mais de les grouper. Il y a donc une mémoire cache. Quand tu écris quelque chose sur le disque, en fait c'est pas
écrit directement sur le disque mais dans la mémoire cache. Quand cette mémoire cache est pleine, tout son contenu est écrit en une fois sur le disque. Et puis ca recommence.
Comme le système fait beaucoup de toutes petites écritures (a savoir rajouter une ligne dans un fichier de log) le fait de grouper ainsi les écritures fait économiser beaucoup de mouvements de la tete de lecture,
et prolonge d'autant la durée de vie du disque.
Mais ca a aussi un défaut : quand tu écris quelque chose sur le disque,
en fait ca s'écrit pas, ca attend que le cache soit plein pour s'écrire vraiment. Typiquement si tu écris un gros fichier, ca remplit le cache,
ca l'écrit sur le disque, ca re-remplit le cache, ca l'écrit sur le
disque, etc… un certain nombre de fois. Et puis arrive la fin du
fichier. Le dernier morceau du fichier n'est pas assez gros pour remplir
le cache, alors il est pas écrit tout de suite. Et tu te retrouve
pendant un certain temps avec un fichier qui est écrit sur le disque,
sauf la toute fin. Combien de temps dure ce "certain temps" ? Jusqu'a ce
que tu ait écrit suffisamment d'autres trucs pour finir de remplir le
cache.
La commande sync force l'écriture de ce qui est dans le cache, meme si
il n'est pas plein. Tu peux la lancer a la main, et elle est aussi
lancée automatiquement quand tu démonte un truc. C'est pour ca qu'il ne faut pas débrancher un disque externe sans l'éjecter au préalable. Quand tu éjecte le disque externe, ca lance sync pour vider le cache et ca le démonte. Tu peux alors le débrancher sans qu'il n'y ait le dernier bout
du dernier fichier écrit qui reste oublié dans le cache.
PS : les clef USB, les cartes mémoire, les disque SSD (tout ce qui est
de la mémoire flash en fait) n'ont pas de tete de lecture qui bouge.
Grouper ainsi les écritures n'économise en rien leur usure. Dans ce cas,
le cache est plus une source d'ennui qu'autre chose. Ca oblige a faire
une action manuelle pour prévenir le système qu'on va débrancher. Ca
fait des fichiers corrompus en cas de débranchement intempestif. Qui n'a jamais eu de faux contact dans une prise USB ???
Et puis ca empeche de faire une barre de progression réaliste pour les
trucs avec une vitesse d'écriture un peu lente.
Tu a peut etre remarqué que quand tu écris un gros fichier sur une clef USB, au début la barre de progression avance super vite. Tu te dis
"super, ca va pas durer longtemps". Et puis la barre de progression
ralentit brusquement et sur la fin du fichier elle avance comme un
escargot, pendant que tu fulmine en disant "et alors, qu'est-ce que ca attend, ca allait vite au début". Quand la copie est enfin terminée, tu fais "ejecter la clef" et la ca se met a te faire poireauter encore un
bon moment avant de te dire "ca y est, vous pouvez retirer la clef sans risque".
Tout ca c'est la faute du cache. Au début ca va super vite parce que ca n'écrit pas sur la clef mais dans le cache. Quand de cache est plein, ca
se met a écrire vraiment sur la clef, et la barre de progression
ralentit beaucoup. Ce n'est qu'a ce moment la que tu vois la vraie
vitesse d'écriture de la clef. Quand ca t'affiche que la copie est
finie, en fait ca veut dire que ca a fini d'écrire le fichier dans le
cache. Quand tu éjecte, ca force a écrire ce qui reste dans le cache,
c'est pour ca que ca met des plombes avant de te dire "vous pouvez
retirer sans risque".
Je rève d'un système qui sache faire la différence entre les disques mécaniques et les mémoires flash, pour utiliser automatiquement un cache d'écriture sur les disques mécaniques mais PAS sur la mémoire flash.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:11:38 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,566 |