Re: Copier 300GB d'un disque dur a un autre

[Corentin Bardet]

Le 16 Septembre 2022 à 15h38, f6k  a écrit :
> Merci beaucoup pour cette réponse à une question que je ne me posais pas
> forcément.

Même remarque, je vais garder ce courriel dans mes archives.
Très bien écrit et très clair, ça doit être dit. Merci hamster.

Bonne soirée,

-- 
Corentin

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

Salut


Merci Hamster pour cette explication très complète, je comprends mieux a
quoi sert sync et son importance dans le cadre de manipulation de fichier.

La copie de fichier viens de ce finir avec succès :-)))
sent 305,600,616,450 bytes  received 113,919 bytes  67,083,905.25 bytes/sec
total size is 305,525,656,835  speedup is 1.00

J'ai utilisé rsync (sans oublier le sync ;-)
#rsync -aPv /mnt/data/projet /mnt/data2/ && sync

Tout semble fonctionner correctement sur le nouveau disque. Il n'y a plus
qu'à le remplir :D

Je vous adresse a tous un TRES GRAND MERCI :) pour votre aide, vos conseils
et votre assistance, et en particulier à Hamster pour sa disponibilité.


Très cordialement
Hugues



Le ven. 16 sept. 2022 à 13:04, hamster  a écrit :

> 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
> > 
> > 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 

Re: Copier 300GB d'un disque dur a un autre

[f6k]

Bonjour hamster, bonjour la liste,

On 2022-09-16 13:04:25 Fri, hamster wrote:

> 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. Idem pour l'explication sur les secteurs de disques durs (512 et
4096). Très instructif.

-f6k


-- 
~{,_,"> huld.re <",_,}~

Re: Copier 300GB d'un disque dur a un autre

[hamster]

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 

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.

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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
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?

Cordialement
Hugues

Le ven. 16 sept. 2022 à 10:51, Hugues MORIN-TRENEULE  a
écrit :

> 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  a écrit :
>
>> 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.
>>
>>

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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  a écrit :

> 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.
>
>

Re: Copier 300GB d'un disque dur a un autre

[hamster]

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.

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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?

En fonction de votre avis, je passerai à l'étape suivante, à savoir la
copie des 300Gb.

Bonne soirée
Cordialement
Hugues

Le jeu. 15 sept. 2022 à 19:04, hamster  a écrit :

> 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.
>
>

Re: Copier 300GB d'un disque dur a un autre

[hamster]

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.

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

Salut

Merci Steve mais j'ai finalement utilisé GParted et lors de la création de
la partition on peut faire le choix du format de partition (msdos, gpt,
aix, mac,etc...)

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

Périphérique DébutFin   Secteurs Taille Type
/dev/sdc1 2048 1953523711 1953521664 931,5G Système de fichiers Linux

C'est bizarre ... je ne trouve rien qui pourrait mener à une solution sur
le net.
Sur le forum Ubuntu, j'ai trouvé une personne se posant la même question:
https://forum.ubuntu-fr.org/viewtopic.php?id=1000191
Mais ca n'a pas l'air de mener à une solution

Est ce que ca pourrait provenir du modèle du disque?
Seagate Barracuda 1To ST1000DM010-2EP102 (CC46)

Cordialement
Hugues


Le jeu. 15 sept. 2022 à 16:57, steve  a écrit :

> 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
>

Re: Copier 300GB d'un disque dur a un autre

[hamster]

Le 15/09/2022 à 16:39, Hugues MORIN-TRENEULE a écrit :

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.


4 étapes :
- verifier que tu travaille bien sur le bon disque dur (le bouton en 
haut a droite)
- creer une table de partitions (dans le menu "peripheriques") attention 
a le faire sur le bon disque !!!
- creer une nouvelle partition dans l'espace vide et la formatter comme 
tu veux

- appliquer les operations (la coche verte sous la barre de menus)

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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.

Cordialement
Hugues

Le jeu. 15 sept. 2022 à 08:58, Frédéric BOITEUX 
a écrit :

> 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 
> *Envoyé :* mercredi 14 septembre 2022 22:19
> *À :* Liste Debian 
> *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, 2048, 23887872, 71663616, 78675968,
> 10240, 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ébutFin   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  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"
>
>

RE: Copier 300GB d'un disque dur a un autre

[Frédéric BOITEUX]

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 
Envoyé : mercredi 14 septembre 2022 22:19
À : Liste Debian 
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, 2048, 23887872, 71663616, 78675968,
10240, 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ébutFin   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 
mailto:hams...@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"

Re: Copier 300GB d'un disque dur a un autre

[hamster]

Le 14/09/2022 à 22:19, Hugues MORIN-TRENEULE a écrit :

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).


Heu… d'habitude je crée la table de partitions puis partitionne et 
formate avec gparted et il se démerde de faire comme il faut. Infiniment 
plus simple et plus rapide que d'aller fouiller dans les man 
pléthoriques de plusieurs commandes pour essayer de trouver l'aiguille 
dans la botte de foin !

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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, 2048, 23887872, 71663616, 78675968,
10240, 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ébutFin   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  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"
>
>

Re: Copier 300GB d'un disque dur a un autre

[hamster]

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"

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

Salut


Oui ça doit être ça, merci

Cela peut il poser un problème de ne pas créer sdc1?

Cordialement
Hugues

Le mer. 14 sept. 2022 à 13:15, Jérémy Prego  a
écrit :

> 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 16991846681G  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  5859123228G 83 Linux
> /dev/sda9  76173312 115232767  39059456  18,6G 83 Linux
> /dev/sda10115234816 173826047  5859123228G 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  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 GROOO PROBLÈMES =)
>>
>> Bonne soiree
>> Hugues
>>
>> Le mar. 13 sept. 2022 à 12:53, hamster  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.
>>>
>>>
>

Re: Copier 300GB d'un disque dur a un autre

[Jérémy Prego]

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 > 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 GROOO PROBLÈMES =)

Bonne soiree
Hugues

Le mar. 13 sept. 2022 à 12:53, hamster mailto:hams...@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.

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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 16991846681G  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  5859123228G 83 Linux
/dev/sda9  76173312 115232767  39059456  18,6G 83 Linux
/dev/sda10115234816 173826047  5859123228G 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  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 GROOO PROBLÈMES =)
>
> Bonne soiree
> Hugues
>
> Le mar. 13 sept. 2022 à 12:53, hamster  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.
>>
>>

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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 GROOO PROBLÈMES =)

Bonne soiree
Hugues

Le mar. 13 sept. 2022 à 12:53, hamster  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.
>
>

Re: Copier 300GB d'un disque dur a un autre

[err404]

On 9/13/22 12:53, hamster wrote:

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.


il vaut mieux tester avec un autre cable sata avant de vouloir changer la carte 
contrôleur

Re: Copier 300GB d'un disque dur a un autre

[hamster]

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.

Re: Copier 300GB d'un disque dur a un autre

[Rand Pritelrohm]

On Tue, 13 Sep 2022 11:15:58 +0200
"antoine.valmer"  wrote:

[...]
>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
>

OUI pour les solutions de type rsync, cp, scp, ftp (filezilla)

NON pour Clonezilla et dd.
Clonezilla est un "livecd", tu bootes avec.

-- 
Rand Pritelrohm

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

Bonsoir

Merci hamster.
J'ai lancé un smartctl long, je pensais que ça prendrait quelques heures
mais ca c'est fini rapidement.
Je vais arrêter les tests sur ce disque et me concentrer sur l'autre.

Concernant le disque de destination, ça a l'air d'être la catastrophe.
J'ai viré la partition NTFS, refait une partition ext4 et reformaté.
J'ai refait un smartctl long => Échec
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED
 WHEN_FAILED RAW_VALUE
184 End-to-End_Error0x0032   098   098   099Old_age   Always
FAILING_NOW 2

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.
Je vous tiens au courant dés que je le reçois et que je l'ai remplacé


Cordialement
Hugues




Le lun. 12 sept. 2022 à 20:36, hamster  a écrit :

> 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
> > 
> >
> > 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.
>
>

Re: Copier 300GB d'un disque dur a un autre

[hamster]

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 



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.

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

Salut

Merci à tous pour vos explications, j'y vois un peu plus clair.

@hamster: ce sont des disques SATA branché directement sur la CM de la tour
Et pour le cheval tu es vraiment sur ;-) :D :D :D

Je vais commencer par vérifier et corriger le HD source et formater la
destination en ext4.
Ça éliminera déjà un certains nombres de problèmes potentiels.
Puis je retenterai une copie avec rsync.

Voila déjà ce que donne un test rapide avec smartctl.

Le disque source semble ok mais je vais quand même le tester plus
longuement:
# smartctl -H /dev/sdb
smartctl 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

Avant reformatage j'ai cette erreur qui apparait sur le disque de
destination
smartctl -H /dev/sdc
smartctl 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
Please note the following marginal Attributes:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED
 WHEN_FAILED RAW_VALUE
184 End-to-End_Error0x0032   098   098   099Old_age   Always
FAILING_NOW 2

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

Je vais lancer le test du HD source durant la nuit

cordialement
Hugues

Re: Copier 300GB d'un disque dur a un autre

[Haricophile]

Le Mon, 12 Sep 2022 16:44:04 +0200,
"christian.d...@univ-brest.fr"  a écrit :

> 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.

Je suis d'accord avec l'analyse. Avec le système de fichier NTFS il
peut se passer plein de trucs, mais un clonage de disque ou partition
avec DD, CloneZilla ou autre ne doit pas rencontrer de problème s'il n'y
a pas un problème physique (disque, câble, contrôleur...).

Re: Copier 300GB d'un disque dur a un autre

[christian.d...@univ-brest.fr]

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.


Une fois la copie effectuée, un coup de gparted pour retailler les 
partitions à la dimension souhaitée toujours en utilisant un linux live 
( grml, systemrescuecd ... ) et l affaire est dans le sac.


Voici un très bon article sur l utilisation de ddrescue : 
https://linuxfr.org/news/ddrescue-dd_rescue-myrescue-recuperer-ses-donnees-apres-un-crash-disque


Bon courage,


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 /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

Re: Copier 300GB d'un disque dur a un autre

[Rand Pritelrohm]

On Mon, 12 Sep 2022 15:54:57 +0200
hamster  wrote:

[...]

>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".
>

Bien vu pour le "t" : la force de l'habitude sans doute


>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.
>

Bonne remarque !
Je n'ai que des symlinks dans mes synchros, c'est la raison pour
laquelle je n'utilise pas -H.

-- 
Rand Pritelrohm

Re: Copier 300GB d'un disque dur a un autre

[hamster]

Le 12/09/2022 à 15:32, Rand Pritelrohm a écrit :

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


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.

Re: Copier 300GB d'un disque dur a un autre

[Rand Pritelrohm]

On Mon, 12 Sep 2022 14:22:48 +0200
Hugues MORIN-TRENEULE  wrote:

[...]
>
>Et quelle commande me conseillerez vous pour la copie cp, dd ou rsync?
>
[...]

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 pour un test "à blanc"
rsync -aPtvn /xxx/yyy/source /vvv/zzz/destination

Cordialement,
-- 
Rand Pritelrohm

Re: Copier 300GB d'un disque dur a un autre

[hamster]

Le 12/09/2022 à 14:22, Hugues MORIN-TRENEULE a écrit :
Cette "portabilité" n'ayant plus d'intérêt pour moi, pensez vous qu'en 
formatant le disque de destination en ext4 cela fonctionnerait?


Y'a bien des chances que ca se passe mieux. Après, si c'est un problème 
materiel ca le résoudra pas.



Et quelle commande me conseillerez vous pour la copie cp, dd ou rsync?


Ces commandes ne font pas toutes la meme chose.

Si tu veux copier les fichiers, c'est a dire le contenu du système de 
fichiers, tu peux utiliser cp ou rsync :

cp -a /mnt/data/mondossier /mnt/data2/
rsync -aAXH /mnt/data/mondossier /mnt/data2/

Comme déjà évoqué sur cette meme liste, rsync a l'avantage de vérifier 
que la copie s'est bien faite pour chaque fichier, et ca se paye par un 
temps de copie plus long.


Si tu veux copier toute la partition, c'est a dire en faire une image 
bit a bit et ainsi copier le contenu mais aussi le contenant, les 
fichiers mais aussi le système de fichiers et meme l'espace vide et les 
erreurs eventuelles, alors la dd est fait pour ca.


dd bs=4M status=progress if=/dev/sdb1 of=/mnt/data2/fichier-clone.dump

Attention, pour la source tu remarquera que le fichier a copier c'est 
directement le fichier bloc, pas son point de montage. Je te conseille 
d'ailleurs vivement d'utiliser ainsi dd sur une partition non montée.
Tu obtiendra ainsi dans ton disque destination un fichier qui s'appelle 
"fichier-clone.dump" et qui contiendra toute la partition sdb1. Ce 
fichier clone pourra meme etre monté comme si c'était sdb1 grace a 
l'option loop. Bien sur ce fichier clone pesera aussi lourd que la 
partition, dans ton cas 300 G.


Avec cette commande, fais bien attention a ne pas te tromper entre if= 
et of= : une inversion serait catastrophique parce que ca effacerait 
tout ton disque source. if c'est pour Input File et of c'est pour Output 
File.


dd est très pratique pour cloner un système de fichiers qui contiens des 
erreurs (erreurs logicielles). Ca permet de le sauvegarder en l'état 
avant d'essayer de le réparer avec fsck ou ntfsfix.


Si ton disque source a un problème materiel et que tu veux en extraire 
le plus de données possible avant de le jeter, privilégie la commande 
ddrescue qui est faite pour ca. La première chose a faire est donc de 
tester l'état materiel de ton disque source avec smartctl comme ca t'a 
déjà été conseillé.


Je suppose que tes disques sont des disques externes branchés en USB. Tu 
peux donc aussi avoir des soucis de faux contact dans une prise USB ou 
un cable USB. Essaye de changer les cables et les brancher dans d'autres 
prises sur l'ordi.


Enfin, j'ai déjà vu des ordis qui n'avaient pas assez de puissance 
electrique sur leur sortie USB pour alimenter 2 disques externes en meme 
temps, et ca provoquait aussi des erreurs aléatoires au bout d'un 
moment, quand le circuit d'alimentation avait eu le temps de chauffer et 
se mettait a moins bien fonctionner. Si c'est ca il te faut soit 
brancher tes 2 disques externes sur 2 ordis différents, soit mettre un 
des 2 disques en interne dans l'ordi pour n'en avoir qu'un branché en 
USB, soit brancher tes disques sur un hub USB avec alimentation externe.


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?


Haha, en effet ca serait pratique, a ma connaissance c'est meme pas en rêve.

Tiens, petite analogie avec la biologie. Imagine que tu soit le 
coronavirus. Tu fais ta vie dans le poumon d'un humain. Un jour grace a 
un postillon, tu saute dans le poumon d'un autre humain, et ca se passe 
bien. Un autre jour, toujours grace a un postillon, tu saute dans le 
poumon d'un cheval, et la ca se passe très mal pour toi. Alors tu 
demande "est-ce qu'on pourrait pas changer le type d'animal, transformer 
le cheval en humain sans altérer le virus qui est dans les poumons ?".

Re: Copier 300GB d'un disque dur a un autre

[antoine.valmer]

On Monday 12 September 2022 13:14:35 Basile Starynkevitch wrote:
> En effet, NTFS est mal supporté sous Linux, car il n'y aurait pas de 
> pilote en logiciel complètement libre :

Si, libre, il y a "ntfs-3g" que l'on inscrit dans /etc/fstab avant de monter la 
partition NTFS :
/dev/sdXY /media/sdXY ntfs-3g rw,users,noauto,locale=fr_FR@euro 0 0
X = partition et disque dur , Y = disque dur.

A. Valmer

Re: Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

Salut

Merci à tous pour votre aide :)

Comme je vous le disais, j'ai essayé plusieurs solutions. cp, rsync et dd
ont aussi planté sur la copie NTFS a NTFS.
cp est une commande assez banale et quotidienne mais en ce qui concerne
rsync et dd, je ne les connais pas bien et j'ai pu faire une erreur de
paramétrage en les utilisant.

A l'origine, j'avais choisi NTFS afin de garder une certaine "portabilité"
entre linux et windows.
Aujourd'hui, je n'utilise plus du tout windows, je n'ai même plus de
machine démarrant dessus.
Donc la solution de copie sous windows sera compliqué à mettre en œuvre,
toujours faisable mais compliqué.

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?

Très cordialement
Hugues

Le lun. 12 sept. 2022 à 13:27, antoine.valmer  a
écrit :

> > 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.
>
>

Re: Copier 300GB d'un disque dur a un autre

[antoine.valmer]

> 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.

Re: Copier 300GB d'un disque dur a un autre

[mahashakti89]

Le 12 septembre 2022 12:09:39 GMT+02:00, 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 /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
As-tu essayé avec rsync qui en général fait ça très bien ?
Cordialement 
Lumière de tous les Chakras ⚡⚡⚡藍 藍藍

Re: Copier 300GB d'un disque dur a un autre

[Gaëtan Perrier]

Moi je ferais un dd puis ensuite j'agrandirai la partition sur le nouveau 
disque.

Gaëtan 

Le 12 septembre 2022 12:25:28 GMT+02:00, hamster  a écrit :
>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 /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.
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Copier 300GB d'un disque dur a un autre

[Basile Starynkevitch]

On 9/12/22 12:25, hamster wrote:

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.



En effet, NTFS est mal supporté sous Linux, car il n'y aurait pas de 
pilote en logiciel complètement libre.


Une suggestion:


Préparer sur papier un plan d'action.

Lire la documentation de cp(1) 
 puis celle de rsync(1) 



Si les données sources sont très importantes (représentent des semaines 
de travail), considérez l'achat d'un disque externe (en USB) neuf. 
Peut-être les sauvegarder (une deuxième fois) via le réseau (Internet, 
intranet, ).


Si les disques ont plus d'un an (ou moins d'un mois, les premières 
pannes peuvent arriver vite; sur un disque rotatif elles s'entendent par 
un bruit étrange!), on pourrait soupçonner un problème matériel. Après 
avoir démonté les partitions, utilisez smartctl comme expliqué ici 
. 
Dans certains cas, ça dure plus d'une heure.



Vérifier que dmesg 
 donne des 
messages habituels.


D'abord parcourir l'arborescence source, avec par exemple

find /mnt/data/mondossier -type f -ls -exec wc -c '{}' \;

en verifiant préalablement la documentation des commandes find(1) 
 et wc(1) 
 et la syntaxe du GNU 
bash . Si la commande précédente 
marche, c'est qu'on arrive à lire les fichiers sources.


Si possible - et c'est préferable - (par exemple si le disque de 
destination est vierge de données importantes ou chères), reformater le 
disque destination (avec gparted ou fdisk) pour y avoir une partition 
ext4  ou btrfs 
.


Ensuite faire une copie avec cp -va ou rsync.


Bon courage.


PS. Je cherche des partenaires intéressés par RefPerSys en 
http://refpersys.org/



--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Copier 300GB d'un disque dur a un autre

[Rand Pritelrohm]

On Mon, 12 Sep 2022 12:25:28 +0200
hamster  wrote:

[...]

>
>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.

Tout à fait d'accord.

[...]

>
>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.
>

Même si c'est hors sujet ici, tu trouveras ci-dessous une façon de
faire un "miroir" en natif depuis window$ avec son outil intégré :

robocopy "C:\chemin_source" "D:\chemin_destination" ^
/MIR /R:1 /W:1 /XD "$RECYCLE.BIN" "System Volume Information" ^
/NFL /NDL /LOG:D:\scripts\Logs_Robocopy\rapport01.log

À toi d'adapter les chemins et lettres des lecteurs.

Ce script évite les problèmes de noms de fichiers trop longs ou
d'arborescences profondes que tu peux rencontrer lorsque tu fais une
"simple" copie.
Il ne duplique ni la corbeille ni le fichier de gestion des
méta-données disque.
Un journal est généré ce qui te permettra de savoir si la duplication
s'est bien passée.

PS : "^" est l'équivalent batch/dos pour la rupture de ligne

-- 
Rand Pritelrohm

Re: Copier 300GB d'un disque dur a un autre

[hamster]

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 /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.

Re: Copier 300GB d'un disque dur a un autre

[NoSpam]

Bonjour. Test les 2 disques avec smartctl, tu en connaitras leur état exact.

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 /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

Copier 300GB d'un disque dur a un autre

[Hugues MORIN-TRENEULE]

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