Re: Disque dur défaillant : résolu (pour l'instant)

[ajh-valmer]

On Thursday 14 December 2023 13:48:31 raivac wrote:
> Il me semble qu'on peut justement récupérer le numéro de série 
> du disque avec smartctl. Après il n'y a plus qu'à regarder sur l'étiquette
> du disque.  

On Thursday 14 December 2023 11:56:58 didier gaumet wrote:
> Le 14/12/2023 à 10:52, ajh-valmer a écrit :
> > Depuis peu, un de mes 2 disques durs n'apparaît plus dans le Bios.
> > De plus, le boot est très lent.
> > Les 2 sont de marque Toshiba.
> > Comment savoir lequel semble tomber en panne et comment les tester ?
> > Merci, bonne journée.
> > A. Valmer
> Tu peux toujours regarder du côté de smartmontools, il y a un tutoriel 
> en français sur Debian Facile: https://forum-debian.fr/wiki/Smartmontools

Merci de votre aide.
En ouvrant le capot, j'ai repositionné les 2 disques durs SSD.
Au reboot, le BIOS les indiquait, j'ai fait un test du matériel = OK,
sans warning et le système s'établit avec la connexion internet 
comme avant càd 5 secondes.
Cependant, je pense à un problème de pile ronde qui a vieilli.
Bonne soirée.

Re: Disque dur défaillant

[raivac]

Il me semble qu'on peut justement récupérer le numéro de série du disque avec 
smartctl. Après il n'y a plus qu'à regarder sur l'étiquette du disque.
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: Disque dur défaillant

[didier gaumet]

Le 14/12/2023 à 10:52, ajh-valmer a écrit :

Bonjour à tous,
Depuis peu, un de mes 2 disques durs n'apparaît plus dans le Bios.
De plus, le boot est très lent.
Les 2 sont de marque Toshiba.
Comment savoir lequel semble tomber en panne et comment les tester ?
Merci, bonne journée.
A. Valmer


Bonjour,

Tu peux toujours regarder du côté de smartmontools, il y a un tutoriel 
en français sur Debian Facile:

https://forum-debian.fr/wiki/Smartmontools

Disque dur défaillant

[ajh-valmer]

Bonjour à tous,
Depuis peu, un de mes 2 disques durs n'apparaît plus dans le Bios.
De plus, le boot est très lent.
Les 2 sont de marque Toshiba.
Comment savoir lequel semble tomber en panne et comment les tester ?
Merci, bonne journée.
A. Valmer

Re: Message d'erreur au boot sur disque dur

[Informatique BILLARD]

Bonsoir,

Oui je l'ai fait mais il me faudra approfondir l'analyse des résultats.

Cordialement

François-Marie

Le 11/10/2023 à 09:49, Basile Starynkevitch a écrit :


On 10/11/23 08:55, Informatique BILLARD wrote:

Bonjour

j'ai parfois ce message au boot sur un portable, quand il est en 
autonomie sur la batterie.


COMRESET failed (errno=-16)

Ce problème semble ne pas apparaître quand il est sur le secteur.

Dois-je m’inquiéter quand à la santé de mon disque dur SSD.



L'utilitaire à installer et à lancer (de temps en temps) est smartctl. 
Voir


https://lecrabeinfo.net/verifier-etat-de-sante-tester-secteurs-defectueux-disque-dur-ssd-sur-linux.html 



Librement.


PS. Je cherche des contributeurs ou des suggestions d'exemples au 
moteur d'inférences libre https://github.com/RefPerSys/RefPerSys/

Re: Message d'erreur au boot sur disque dur

[Informatique BILLARD]

Bonjour

merci je vais effectuer quelques tests pour approfondir l'analyse.

François-Marie

Le 11/10/2023 à 09:25, David P. a écrit :

Bonjour,
Il y a plusieurs cas possibles pour avoir ce message.
Sinon devant le peu d'informations, je ne peux que mettre un lien d'un 
forum : https://forum-francophone-linuxmint.fr/viewtopic.php?t=9772
Une check-list sera donc nécessaire pour pouvoir cibler le pb précis, 
par ex, si multiboot grub, les MàJ windows sont souvent la raison 
après upgrade.

À suivre donc...
Librement vôtre,
David P.



Le 11 oct. 2023, à 09:05, Informatique BILLARD 
 a écrit:


Bonjour

j'ai parfois ce message au boot sur un portable, quand il est en
autonomie sur la batterie.

COMRESET failed (errno=-16)

Ce problème semble ne pas apparaître quand il est sur le secteur.

Dois-je m’inquiéter quand à la santé de mon disque dur SSD.

Merci

François-Marie

Re: Message d'erreur au boot sur disque dur

[Basile Starynkevitch]

On 10/11/23 08:55, Informatique BILLARD wrote:

Bonjour

j'ai parfois ce message au boot sur un portable, quand il est en 
autonomie sur la batterie.


COMRESET failed (errno=-16)

Ce problème semble ne pas apparaître quand il est sur le secteur.

Dois-je m’inquiéter quand à la santé de mon disque dur SSD.



L'utilitaire à installer et à lancer (de temps en temps) est smartctl. Voir

https://lecrabeinfo.net/verifier-etat-de-sante-tester-secteurs-defectueux-disque-dur-ssd-sur-linux.html

Librement.


PS. Je cherche des contributeurs ou des suggestions d'exemples au moteur 
d'inférences libre https://github.com/RefPerSys/RefPerSys/


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

Re: Message d'erreur au boot sur disque dur

[David P.]

Bonjour,
Il y a plusieurs cas possibles pour avoir ce message.
Sinon devant le peu d'informations, je ne peux que mettre un lien d'un forum : 
https://forum-francophone-linuxmint.fr/viewtopic.php?t=9772
Une check-list sera donc nécessaire pour pouvoir cibler le pb précis, par ex, 
si multiboot grub, les MàJ windows sont souvent la raison après upgrade.
À suivre donc...
Librement vôtre,
David P.





Le 11 oct. 2023 à 09:05, à 09:05, Informatique BILLARD 
 a écrit:
>Bonjour
>
>j'ai parfois ce message au boot sur un portable, quand il est en
>autonomie sur la batterie.
>
>COMRESET failed (errno=-16)
>
>Ce problème semble ne pas apparaître quand il est sur le secteur.
>
>Dois-je m’inquiéter quand à la santé de mon disque dur SSD.
>
>Merci
>
>François-Marie

Message d'erreur au boot sur disque dur

[Informatique BILLARD]

Bonjour

j'ai parfois ce message au boot sur un portable, quand il est en 
autonomie sur la batterie.


COMRESET failed (errno=-16)

Ce problème semble ne pas apparaître quand il est sur le secteur.

Dois-je m’inquiéter quand à la santé de mon disque dur SSD.

Merci

François-Marie

Re: disque dur mort ?

[linux.debian.user.french]

Le dimanche 17 septembre 2023 à 12:30:04 UTC+2, Klaus Becker a écrit :
> Télécharger BlueMail pour Android
> Le 13 sept. 2023, à 18:16, hamster  a écrit:
> Le 13/09/2023 à 11:50, Klaus Becker a écrit :
>  Salut,
>  
>  Mon dd sata est reconnu par le bios, mais sinon inaccessible. Au 
>  démarrage, grub apparaît, mais il refuse de booster. Il dit qu'il n'y a 
>  pas de disque système.
>  Sous Knoppix, j'ai essayé avec cfdisk, gparted, smartmontools, montage 
>  manuel, rien à faire. Une clé USB avec une image ISO d'installation 
>  Debian ne reconnaît pas le dd non plus.
>  Thunar sous Knoppix affiche les partitions du dd, mais il ne peut pas 
>  les monter.
>  
>  Je crains devoir faire le deuil de ce dd, mais je suis preneur pour des 
>  conseils
> 
> Ce que tu dis pas c'est si y'a des données importantes a récupérer ou si 
> tu cherche juste a savoir si le disque est mort.
> 
> A faire sous knopix ou autre sytème live :
> 
> ### Cas ou tu te fous des données, tu veux juste juger la santé du disque :
> 
> - Verifier que le disque est vu avec la comande lsblk (a priori oui vu 
> que thunar voit les partitions).
> - Regarder les données smart, si ca dit qu'il y a plein de messages 
> d'erreur, c'est pas bon.
> - Lancer badblocks sur ce disque (avec les options -s et -w).
> 
> ### Cas ou tu cherche a récupérer les données :
> 
> - Verifier que le disque est vu avec la comande lsblk (a priori oui vu 
> que thunar voit les partitions).
> 
> - Regarder les données smart, si ca dit qu'il y a plein de messages 
> d'erreur, c'est pas bon.
> 
> - Essayer de cloner ce disque avec ddrescue. Une fois le clone fait ne 
> plus toucher au disque.
> 
> - Faire une copie du clone.
> 
> - Essayer de réparer les systèmes de fichiers qui sont dans les 
> partitions avec fsck sur la copie du clone. Si ca marche tant mieux, t'a 
> accès a tes données. Si ca marche pas, tu peux supprimer la copie du 
> clone, en faire une autre, re-essayer fsck.
> 
> - Si ca marche toujours pas, tu peux essayer de lancer photorec sur le 
> clone.
> 
> - Une fois que tu a soit récupéré tes données, soit atteint la certitude 
> qu'elles sont perdues, tu peux retourner a l'étape ### cas ou tu te fous 
> des données.
> 
> - Quand tu aura soit
> Merci de tous ces conseils, mais aucune commande ci-dessus ne reconnait le 
> dd, il doit vraiment etre mort.
> J'ai une sauvegarde. Elle date de plusieurs jours, mais la perte de donnees 
> ne sera pas enorme.
> Aussi je n'ai jamais utilise de raid sur mon pc et je n'ai pas cette option 
> dans mon Bios.
> J'ai plus qu'a acheter un nouveau dd et copier mes sauvegardes dessus.
> Bye bye
> Klaus

Si il est reconnu dans le bios ...
C'est que le chipset du disque dur communique avec la carte mere !
Donc je ne vois pas pourquoi il serait mort, par contre je sais qu'il y a des 
commandes specifique par exemple essaye de lire les inodes (man 01)

Bon courage, (ici les personnes ne sont pas competentes, mais y a des commandes 
bas niveau en HEX, et tu peux regareder il ya de la rom sur la carte du DD)

-- 
Ptilou

Re: disque dur mort ?

[Klaus Becker]

⁣Télécharger BlueMail pour Android ​

Le 13 sept. 2023, 18:16, à 18:16, hamster  a écrit:
>Le 13/09/2023 à 11:50, Klaus Becker a écrit :
>> Salut,
>>
>> Mon dd sata est reconnu par le bios, mais sinon inaccessible. Au
>> démarrage, grub apparaît, mais il refuse de booster. Il dit qu'il n'y
>a
>> pas de disque système.
>> Sous Knoppix, j'ai essayé avec cfdisk, gparted, smartmontools,
>montage
>> manuel, rien à faire. Une clé USB avec une image ISO d'installation
>> Debian ne reconnaît pas le dd non plus.
>> Thunar sous Knoppix affiche les partitions du dd, mais il ne peut pas
>
>> les monter.
>>
>> Je crains devoir faire le deuil de ce dd, mais je suis preneur pour
>des
>> conseils
>
>Ce que tu dis pas c'est si y'a des données importantes a récupérer ou
>si
>tu cherche juste a savoir si le disque est mort.
>
>A faire sous knopix ou autre sytème live :
>
>### Cas ou tu te fous des données, tu veux juste juger la santé du
>disque :
>
>- Verifier que le disque est vu avec la comande lsblk (a priori oui vu
>que thunar voit les partitions).
>- Regarder les données smart, si ca dit qu'il y a plein de messages
>d'erreur, c'est pas bon.
>- Lancer badblocks sur ce disque (avec les options -s et -w).
>
>### Cas ou tu cherche a récupérer les données :
>
>- Verifier que le disque est vu avec la comande lsblk (a priori oui vu
>que thunar voit les partitions).
>
>- Regarder les données smart, si ca dit qu'il y a plein de messages
>d'erreur, c'est pas bon.
>
>- Essayer de cloner ce disque avec ddrescue. Une fois le clone fait ne
>plus toucher au disque.
>
>- Faire une copie du clone.
>
>- Essayer de réparer les systèmes de fichiers qui sont dans les
>partitions avec fsck sur la copie du clone. Si ca marche tant mieux,
>t'a
>accès a tes données. Si ca marche pas, tu peux supprimer la copie du
>clone, en faire une autre, re-essayer fsck.
>
>- Si ca marche toujours pas, tu peux essayer de lancer photorec sur le
>clone.
>
>- Une fois que tu a soit récupéré tes données, soit atteint la
>certitude
>qu'elles sont perdues, tu peux retourner a l'étape ### cas ou tu te
>fous
>des données.
>
>- Quand tu aura soit

disque dur mort ?

[Th.A.C]

Au cas ou, vérifier que le bios n'est pas en mode raid pour les disques 
sata.

Si c'est le cas, le (re)mettre en ahci.

Re: disque dur mort ?

[Basile Starynkevitch]

On 9/13/23 18:16, hamster wrote:

Le 13/09/2023 à 11:50, Klaus Becker a écrit :

Salut,

Mon dd sata est reconnu par le bios, mais sinon inaccessible. Au 
démarrage, grub apparaît, mais il refuse de booster. Il dit qu'il n'y 
a pas de disque système.
Sous Knoppix, j'ai essayé avec cfdisk, gparted, smartmontools, 
montage manuel, rien à faire. Une clé USB avec une image ISO 
d'installation Debian ne reconnaît pas le dd non plus.
Thunar sous Knoppix affiche les partitions du dd, mais il ne peut pas 
les monter.


Je crains devoir faire le deuil de ce dd, mais je suis preneur pour 
des conseils


Ce que tu dis pas c'est si y'a des données importantes a récupérer ou 
si tu cherche juste a savoir si le disque est mort.



Dans l'hypothèse désagréable où il y a des données importantes (par 
exemple le code d'un logiciel sur lequel on travaille depuis des mois, 
le texte d'une thèse à soutenir, ) il existe des entreprises qui 
facturent cher (plus de 1000€) la récupération d'une partie des données 
d'un disque rotatif SATA (en salle blanche).



Bonne chance.


PS mon projet logiciel libre est RefPerSys (sous Debian, en GPLv3+) sur 
https://github.com/RefPerSys/RefPerSys/ - un futur moteur d'inférences.


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

Re: disque dur mort ?

[hamster]

Le 13/09/2023 à 11:50, Klaus Becker a écrit :

Salut,

Mon dd sata est reconnu par le bios, mais sinon inaccessible. Au 
démarrage, grub apparaît, mais il refuse de booster. Il dit qu'il n'y a 
pas de disque système.
Sous Knoppix, j'ai essayé avec cfdisk, gparted, smartmontools, montage 
manuel, rien à faire. Une clé USB avec une image ISO d'installation 
Debian ne reconnaît pas le dd non plus.
Thunar sous Knoppix affiche les partitions du dd, mais il ne peut pas 
les monter.


Je crains devoir faire le deuil de ce dd, mais je suis preneur pour des 
conseils


Ce que tu dis pas c'est si y'a des données importantes a récupérer ou si 
tu cherche juste a savoir si le disque est mort.


A faire sous knopix ou autre sytème live :

### Cas ou tu te fous des données, tu veux juste juger la santé du disque :

- Verifier que le disque est vu avec la comande lsblk (a priori oui vu 
que thunar voit les partitions).
- Regarder les données smart, si ca dit qu'il y a plein de messages 
d'erreur, c'est pas bon.

- Lancer badblocks sur ce disque (avec les options -s et -w).

### Cas ou tu cherche a récupérer les données :

- Verifier que le disque est vu avec la comande lsblk (a priori oui vu 
que thunar voit les partitions).


- Regarder les données smart, si ca dit qu'il y a plein de messages 
d'erreur, c'est pas bon.


- Essayer de cloner ce disque avec ddrescue. Une fois le clone fait ne 
plus toucher au disque.


- Faire une copie du clone.

- Essayer de réparer les systèmes de fichiers qui sont dans les 
partitions avec fsck sur la copie du clone. Si ca marche tant mieux, t'a 
accès a tes données. Si ca marche pas, tu peux supprimer la copie du 
clone, en faire une autre, re-essayer fsck.


- Si ca marche toujours pas, tu peux essayer de lancer photorec sur le 
clone.


- Une fois que tu a soit récupéré tes données, soit atteint la certitude 
qu'elles sont perdues, tu peux retourner a l'étape ### cas ou tu te fous 
des données.


- Quand tu aura soit

disque dur mort ?

[Klaus Becker]

Salut,

Mon dd sata est reconnu par le bios, mais sinon inaccessible. Au démarrage,
grub apparaît, mais il refuse de booster. Il dit qu'il n'y a pas de disque
système.
Sous Knoppix, j'ai essayé avec cfdisk, gparted, smartmontools, montage
manuel, rien à faire. Une clé USB avec une image ISO d'installation Debian
ne reconnaît pas le dd non plus.
Thunar sous Knoppix affiche les partitions du dd, mais il ne peut pas les
monter.

Je crains devoir faire le deuil de ce dd, mais je suis preneur pour des
conseils.

Cordialement
Klaus

Resolu: Quels Outils pour lire sur un disque dur rétif.

[Billard François-Marie]

Bonjour

merci pour ces pistes, je vais creuser le sujet.

Cordialement

Bon week-end.

François-Marie

Le 23/06/2023 à 14:58, Billard François-Marie a écrit :

Bonjour

J'ai eu cette semaine une demande pour un disque dur externe en USB 
sur lequel nous ne pouvions plus rien lire.


Sous linux j'ai juste réussi à le voir avec un lsusb comme présent 
mais après qu'est il possible de faire, existe-t-il des outils plus 
spécifiques ?


Merci

François-Marie

Re: Quels Outils pour lire sur un disque dur rétif.

[hamster]

23 juin 2023 14:58 "Billard François-Marie" 
 a écrit:
> Bonjour
> 
> J'ai eu cette semaine une demande pour un disque dur externe en USB sur 
> lequel nous ne pouvions
> plus rien lire.
> 
> Sous linux j'ai juste réussi à le voir avec un lsusb comme présent mais après 
> qu'est il possible de
> faire, existe-t-il des outils plus spécifiques ?

Si tu le vois avec lsusb mais pas avec lsblk, je sais pas quoi faire.

Si tu le vois aussi avec lsblk, la premiere priorite c'est de cloner le disque 
avec ddrescue.

Ensuite, je considere ce disque comme mort et je n'y touche plus.

Je fais donc une sauvegarde du clone, puis j'essaye fsck, testdik et photorec. 
Quand un de ces 3 trucs plante en ayant modifié des choses, je restaure le 
clone a partir de la sauvegarde et j'essaye autrement.

Re: Quels Outils pour lire sur un disque dur rétif.

[Sébastien NOBILI]

Bonjour,

Le 2023-06-23 14:58, Billard François-Marie a écrit :
J'ai eu cette semaine une demande pour un disque dur externe en USB sur 
lequel nous ne pouvions plus rien lire.


Sous linux j'ai juste réussi à le voir avec un lsusb comme présent mais 
après qu'est il possible de faire, existe-t-il des outils plus 
spécifiques ?


As-tu essayé (pas toujours possible) d'extraire le disque de son boîtier 
et de le lire

en direct ou via un autre boîtier ?

Parfois le disque se porte très bien dans le boîtier qui flanche…

Sébastien

Re: Quels Outils pour lire sur un disque dur rétif.

[didier gaumet]

Bonjour,

on peut aussi mentionner gpart mais deux classiques (empaquetés dans 
Debian) en fonction du contexte sont:

- testdisk (intro sur le truc: https://www.cgsecurity.org/wiki/TestDisk_FR)
- photorec (intro sur le truc: https://www.cgsecurity.org/wiki/PhotoRec_FR)

Quels Outils pour lire sur un disque dur rétif.

[Billard François-Marie]

Bonjour

J'ai eu cette semaine une demande pour un disque dur externe en USB sur 
lequel nous ne pouvions plus rien lire.


Sous linux j'ai juste réussi à le voir avec un lsusb comme présent mais 
après qu'est il possible de faire, existe-t-il des outils plus spécifiques ?


Merci

François-Marie

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) 
<https://man7.org/linux/man-pages/man1/cp.1.html> puis celle de rsync(1) 
<https://man7.org/linux/man-pages/man1/rsync.1.html>


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 
<https://www.malekal.com/smartctl-verifier-son-disque-en-ligne-de-commandes-linux/>. 
Dans certains cas, ça dure plus d'une heure.



Vérifier que dmesg 
<https://www.man7.org/linux/man-pages/man1/dmesg.1.html> 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) 
<https://man7.org/linux/man-pages/man1/find.1.html> et wc(1) 
<https://man7.org/linux/man-pages/man1/wc.1.html> et la syntaxe du GNU 
bash <https://www.gnu.org/software/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 <https://man7.org/linux/man-pages/man5/ext4.5.html> ou btrfs 
<https://man7.org/linux/man-pages/man8/btrfs.8.html>.


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

Re: Problème de montage d'un disque dur "ZFS"

[Gaëtan Perrier]

Le mercredi 07 juillet 2021 à 00:50 +0200, Nicolas FRANCOIS a écrit :
> Le Tue, 06 Jul 2021 23:13:57 +0200,
> Gaëtan Perrier  a écrit :
> 
> > Bonjour,
> > 
> > J'avoue ne pas tout comprendre de ce que tu indiques. 
> > GPT et ZFS ne sont pas antinomiques. GPT est un format de table de
> > partitions alors que ZFS est un système de fichier pour une partition.
> > Tu peux donc très bien avoir un disque avec une table GPT qui
> > contient des partitions ZFS.
> 
> Jusque là, je comprends.
>  
> > Ensuite tu dis que gparted l'identifie comme étant ZFS mais dans la
> > copie de sortie de gparted je ne vois pas trace de quelque chose en
> > ZFS ... Le disque semble effectivement avoir une table de partitions
> > en GPT et des partitions en ext4, une de swap et la première qui ne
> > semble pas formatée.
> 
> gparted l'identifie comme un bloc zfs, point, voir fichier joint.
> 
> parted me donne d'autres résultats, et voit les partitions à
> l'intérieur, mais je ne peux pas les monter.

Ok je ne pensais pas que les sorties de parted et gparted puissent être
différentes alors qu'ils se basent tous les deux libparted2.

J'ai pensais, à tort, que ta copie de parted illustrait ton propos sur gparted.

Toutes mes confuses,

Gaëtan






signature.asc
Description: This is a digitally signed message part

Re: Problème de montage d'un disque dur "ZFS"

[didier gaumet]

Le mercredi 07 juillet 2021 à 19:13 +0200, Bernard Schoenacker a
écrit :
> 

> Bonjour Didier,
> 
> Je suis vraiment navré de devoir jouer le chieur de petits 
> points
[...]

Ben , faut pas être navré: quand je raconte des conn... des fadaises,
j'aime bien qu'on rectifie gentiment, donc merci pour les précisions 
:-) 

Re: Problème de montage d'un disque dur "ZFS"

[Bernard Schoenacker]

- Mail original -
> De: "didier gaumet" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mercredi 7 Juillet 2021 16:38:25
> Objet: Re: Re: Problème de montage d'un disque dur "ZFS"
> 
> et puis tout à coup je me rappelle avoir lu quelque part que Freenas
> avait abandonné FreeBSD pour Debian il y a peu de temps. Donc si ton
> Freenas était basé sur Debian, tout ce que j'ai raconté était hors
> propos...
> 

Bonjour Didier,

Je suis vraiment navré de devoir jouer le chieur de petits 
points, mais ce que tu affirmes ne concerne n'est pas encore
en route complètement, pour mémoire voici la page de 
Wikipedia sur TrueNas :

https://fr.wikipedia.org/wiki/TrueNas

En revanche, la prochaine version de TrueNas se basera sur une Debian
version 11 et je viens de vérifier la nouvelle via "ars technica"

https://arstechnica.com/gadgets/2020/06/truenas-isnt-abandoning-bsd-but-it-is-adopting-linux/

et l'annonce de la préversion téléchargeable :
https://www.cachem.fr/truenas-core-12-disponible-rc-scale/

Par conséquent, la version Debian nommée Scale ne sera opérationnelle
et stabilisée qu'à partir de la fin de l'été (c'est mon impression 
personnelle) ...

Voici l'ensemble des versions pour TrueNas :


TrueNAS Core: FreeBSD
TrueNAS Enterprise: FreeBSD
TrueNAS SCALE: Linux


Merci pour ton aimable billet 

Bien à toi

Bernard

Re: Re: Problème de montage d'un disque dur "ZFS"

[didier . gaumet]

et puis tout à coup je me rappelle avoir lu quelque part que Freenas
avait abandonné FreeBSD pour Debian il y a peu de temps. Donc si ton
Freenas était basé sur Debian, tout ce que j'ai raconté était hors
propos...

Re: Re: Problème de montage d'un disque dur "ZFS"

[didier gaumet]

Pour compléter ce qui a été dit et bien que je sois vraiment pas très
connaisseur de toutes ces choses (donc ne pas accepter mes
élucubrations comme parles d'évangile),

je me demanderais si la table GPT est véritablement corrompue ou si le
parted de Debian la désigne comme telle: Freenas/Truenas c'est du BSD,
je pense que le monde BSD s'est mis à GPT plus tard que le monde Linux
et qu'il traîne potentiellement avec lui des éléments anciens (slices,
couche de compatibilité MBR dans le GPT). De plus en termes de systèmes
de fichiers on évoque possiblement la récupération avec l'OpenZFS de
Debian de données crées avec le ZFS de Freenas (si j'ai bien compris,
au début mais ça a changé récemment, d'origine SunOS/Solaris,
différente de la branche OpenZFS), donc avec de possibles(?)
incohérences.

Dans un premier temps, j'essaierais d'utiliser un live*BSD récent
(NomadBSD? déjà que je n'étais pas très au courant de *BSD, ça fait des
années que j'ai décroché) pour voir si je peux voir mes données et les
sauvegarder sous une forme récupérable de manière fiable sous Debian.
Au cas où les données ne seraient pas visibles, j'essaierais un support
*BSD plus ancien si le Freenas qui a été utilisé pour créer les données
était ancien aussi.

Bon, ceci dit, compte-tenu de mon immense expertise du domaine, je
comprendrais que mes suggestions soient accueillies  par un haussement
d'épaules ;-)

Re : Re: Problème de montage d'un disque dur "ZFS"

[Hugues Larrive]

Bonjour,

Le mercredi 7 juillet 2021 à 00:50, Nicolas FRANCOIS  
a écrit :

> gparted l'identifie comme un bloc zfs, point, voir fichier joint.
> parted me donne d'autres résultats, et voit les partitions à
> l'intérieur, mais je ne peux pas les monter.

Vu qu'à la base tu dis avoir partitionné en gpt, je pense que gparted
dis n'importe quoi parce que la table principale est corrompue. C'est
aussi pour cette raison que linux ne crée pas les périphériques
correctement.

Comme tu veux juste récupérer les donnée, tu peux essayer de créer
les périphériques dont tu as besoin avec losetup en utilisant les
option --offset et --sizelimit (en octets donc il faut multiplier les
valeurs données par fdisk par la taille de secteur). Cette commande
n'est pas dangereuse en elle même, ça crée juste des nœuds de
périphérique de type block /dev/loop* utilisables comme des
/dev/sd*. Bien sûr tu ne pourras pas utiliser --partscan qui s'appuie
sur la détection des partitions par le noyau.

Autrement tu peux voir s'il est possible de restaurer le backup sur la
table principale avec parted ou fdisk (je pense qu'il suffit de
sauvegarder vu qu'ils ont l'air de la charger tout seuls) mais il y a
un risque si le disque a effectivement été "converti" en zfs, ce qui
me semble peu probable.

Maintenant que j'y pense, testdisk te permettrait peut-être de monter
tes partitions de manière assistée, c'est probablement l'outil le
plus adapté pour résoudre ton problème (mais moins "fun" que losetup).

Cordialement
Hugues

Re: Problème de montage d'un disque dur "ZFS"

[Nicolas FRANCOIS]

Le Tue, 06 Jul 2021 23:13:57 +0200,
Gaëtan Perrier  a écrit :

> Bonjour,
> 
> J'avoue ne pas tout comprendre de ce que tu indiques. 
> GPT et ZFS ne sont pas antinomiques. GPT est un format de table de
> partitions alors que ZFS est un système de fichier pour une partition.
> Tu peux donc très bien avoir un disque avec une table GPT qui
> contient des partitions ZFS.

Jusque là, je comprends.
 
> Ensuite tu dis que gparted l'identifie comme étant ZFS mais dans la
> copie de sortie de gparted je ne vois pas trace de quelque chose en
> ZFS ... Le disque semble effectivement avoir une table de partitions
> en GPT et des partitions en ext4, une de swap et la première qui ne
> semble pas formatée.

gparted l'identifie comme un bloc zfs, point, voir fichier joint.

parted me donne d'autres résultats, et voit les partitions à
l'intérieur, mais je ne peux pas les monter.
 
> Donc normalement tu dois pourvoir monter sda 3 à 6 avec un simple
> mount.

Sauf que j'ai essayé, avec un truc du genre 

mount -t ext4 /dev/sda3 /mnt/sda3

et que ça ne fonctionne pas :

sudo mount -t ext4 /dev/sda6 /mnt/zfs6
mount: /mnt/zfs6: échec de l’appel système mount(2) : La structure a
besoin d'un nettoyage.

J'ai essayé un fsck sur une partition que je pouvais sacrifier, et ça
me l'a nettoyée... complètement !

Donc j'hésite avec cette partition que je voudrais bien conserver...

Suis-je plus clair ? J'espère :-(

Merci pour ton aide :-)

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin

Re: Problème de montage d'un disque dur "ZFS"

[Gaëtan Perrier]

Le mardi 06 juillet 2021 à 17:56 +0200, Nicolas FRANCOIS a écrit :
> Bonjour.
> 
> J'ai un souci avec un disque dur dont je voudrais récupérer les
> données. Celui-ci est identifié par gparted comme étant de type "zfs".
> Ce qui est étrange, parce que, si je l'ai bien utilisé il y a quelques
> temps pour essayer FreeNas, il servait depuis dans une bête station
> Debian dans laquelle je suis sûr de l'avoir formaté en gpt. Je l'ai
> installé dans ma nouvelle Debian Buster (avec backports), et je
> voudrais en récupérer les données pour les transférer sur mon nouveau
> NAS (un OpenMediaVault). J'y ai installé zfs-fuse, d'une part, et
> zfsutils-linux d'autre part, depuis le dépôt backports.
> 
> Voici le résultat de la commande print de parted :
> 
> nico@fantasio:~$ sudo parted /dev/sda
> [sudo] Mot de passe de nico : 
> GNU Parted 3.2
> Using /dev/sda
> Welcome to GNU Parted! Type 'help' to view a list of commands.
> (parted) p
> Error: The primary GPT table is corrupt, but the backup appears OK,
> so that will be used.
> OK/Cancel?
> OK Model: ATA WDC WD20EZRX-00D (scsi)
> Disk /dev/sda: 2000GB
> Sector size (logical/physical): 512B/4096B
> Partition Table: gpt
> Disk Flags: 
> 
> Number  Start   End Size    File system Name  Flags
>  1  17,4kB  40,0GB  40,0GB  Root  msftdata
>  2  40,0GB  44,0GB  4000MB  linux-swap(v1)
>  3  44,0GB  300GB   256GB   ext4    SaveNico
>  4  300GB   690GB   390GB   ext4    Music
>  5  690GB   1010GB  320GB   ext4    Divers
>  6  1010GB  2000GB  990GB   ext4    Partage   msftdata
> 
> Et celui de la commande fdisk -l (ce qui concerne ce disque) :
> 
> La table de partitions GPT primaire est corrompue, mais la sauvegarde
> semble fonctionnelle, elle sera donc utilisée. 
> Disque /dev/sda : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
> Modèle de disque : WDC WD20EZRX-00D 
> 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 : A7528C40-AC86-11E2-822B-003005BB6B8B
> 
> Périphérique  Début    Fin   Secteurs Taille Type
> /dev/sda1    34   78125034   78125001  37,3G Données de base
> Microsoft /dev/sda2  78125035   85937535    7812501   3,7G
> Partition d'échange Linux /dev/sda3  85938176  585936895  48720
> 238,4G Système de fichiers Linux /dev/sda4 585936896 1347655679
> 761718784 363,2G Système de fichiers Linux /dev/sda5    1347655680
> 1973372927  625717248 298,4G Système de fichiers Linux /dev/sda6
> 1973374336 3906948479 1933574144   922G Données de base Microsoft
> 
> La partition 1 ne commence pas sur une frontière de cylindre physique.
> La partition 2 ne commence pas sur une frontière de cylindre physique.
> 
> Quand j'essaye de monter les partitions /dev/sdax, on me répond que le
> périphérique en question n'existe pas. Mais quand j'essaye de monter le
> disque en zfs, en utilisant zfs-fuse (méthode décrite à la page
> https://frommelmak.com/how-to-mount-a-zfs-drive-in-linux.html), je n'ai
> pas de réponse à la commande "zpool import".
> 
> Si j'essaye de suivre les instructions de la page
> https://www.infotrucs.fr/monter-partition-zfs-sous-debian/, tout se
> passe bien, mais que je crée un unique pool pour /dev/sda, ou un pool
> par partition, les points de montage demeurent vides, alors que je sais
> pertinemment qu'il y a plus de 1.5To de données sur ce disque.
> 
> Qu'est-ce que je fais de traviolle ? Quelqu'un peut m'aider ?
> 
> \bye
> 


Bonjour,

J'avoue ne pas tout comprendre de ce que tu indiques. 
GPT et ZFS ne sont pas antinomiques. GPT est un format de table de partitions
alors que ZFS est un système de fichier pour une partition.
Tu peux donc très bien avoir un disque avec une table GPT qui contient des
partitions ZFS.

Ensuite tu dis que gparted l'identifie comme étant ZFS mais dans la copie de
sortie de gparted je ne vois pas trace de quelque chose en ZFS ... Le disque
semble effectivement avoir une table de partitions en GPT et des partitions en
ext4, une de swap et la première qui ne semble pas formatée.

Donc normalement tu dois pourvoir monter sda 3 à 6 avec un simple mount.

Gaëtan


signature.asc
Description: This is a digitally signed message part

Problème de montage d'un disque dur "ZFS"

[Nicolas FRANCOIS]

Bonjour.

J'ai un souci avec un disque dur dont je voudrais récupérer les
données. Celui-ci est identifié par gparted comme étant de type "zfs".
Ce qui est étrange, parce que, si je l'ai bien utilisé il y a quelques
temps pour essayer FreeNas, il servait depuis dans une bête station
Debian dans laquelle je suis sûr de l'avoir formaté en gpt. Je l'ai
installé dans ma nouvelle Debian Buster (avec backports), et je
voudrais en récupérer les données pour les transférer sur mon nouveau
NAS (un OpenMediaVault). J'y ai installé zfs-fuse, d'une part, et
zfsutils-linux d'autre part, depuis le dépôt backports.

Voici le résultat de la commande print de parted :

nico@fantasio:~$ sudo parted /dev/sda
[sudo] Mot de passe de nico : 
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: The primary GPT table is corrupt, but the backup appears OK,
so that will be used.
OK/Cancel?
OK Model: ATA WDC WD20EZRX-00D (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End SizeFile system Name  Flags
 1  17,4kB  40,0GB  40,0GB  Root  msftdata
 2  40,0GB  44,0GB  4000MB  linux-swap(v1)
 3  44,0GB  300GB   256GB   ext4SaveNico
 4  300GB   690GB   390GB   ext4Music
 5  690GB   1010GB  320GB   ext4Divers
 6  1010GB  2000GB  990GB   ext4Partage   msftdata

Et celui de la commande fdisk -l (ce qui concerne ce disque) :

La table de partitions GPT primaire est corrompue, mais la sauvegarde
semble fonctionnelle, elle sera donc utilisée. 
Disque /dev/sda : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Modèle de disque : WDC WD20EZRX-00D 
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 : A7528C40-AC86-11E2-822B-003005BB6B8B

Périphérique  DébutFin   Secteurs Taille Type
/dev/sda134   78125034   78125001  37,3G Données de base
Microsoft /dev/sda2  78125035   859375357812501   3,7G
Partition d'échange Linux /dev/sda3  85938176  585936895  48720
238,4G Système de fichiers Linux /dev/sda4 585936896 1347655679
761718784 363,2G Système de fichiers Linux /dev/sda51347655680
1973372927  625717248 298,4G Système de fichiers Linux /dev/sda6
1973374336 3906948479 1933574144   922G Données de base Microsoft

La partition 1 ne commence pas sur une frontière de cylindre physique.
La partition 2 ne commence pas sur une frontière de cylindre physique.

Quand j'essaye de monter les partitions /dev/sdax, on me répond que le
périphérique en question n'existe pas. Mais quand j'essaye de monter le
disque en zfs, en utilisant zfs-fuse (méthode décrite à la page
https://frommelmak.com/how-to-mount-a-zfs-drive-in-linux.html), je n'ai
pas de réponse à la commande "zpool import".

Si j'essaye de suivre les instructions de la page
https://www.infotrucs.fr/monter-partition-zfs-sous-debian/, tout se
passe bien, mais que je crée un unique pool pour /dev/sda, ou un pool
par partition, les points de montage demeurent vides, alors que je sais
pertinemment qu'il y a plus de 1.5To de données sur ce disque.

Qu'est-ce que je fais de traviolle ? Quelqu'un peut m'aider ?

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin

[resolu] Re: disque dur externe se coupe tout seul

[Gaëtan Perrier]

Le jeudi 29 avril 2021 à 20:48 +0200, Gaëtan Perrier a écrit :
> Bonjour,
> 
> Je viens de changer un de mes disques de sauvegardes par un modèle plus gros
> dans un boitier Advance 3.5" connecté en USB3 avec alim externe.
> Ma sauvegarde est faite par rsync et mon problème est que le disque s'éteint
> tout seul en cours de sauvegarde ...
> 
> Auriez-vous déjà rencontré ce phénomène ?
> 
> Gaëtan


Bonjour,

Finalement c'était un problème matériel. Le bloc d'alim déconnait ...

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: disque dur externe se coupe tout seul

[benoit]

>
> Auriez-vous déjà rencontré ce phénomène ?
>
Il m'est arrivé un truc du genre et je n'ai pas capté tout de suite, mais ça 
s'est passé en modifiant ma config avec laptop-mode-tools qui déconnecte les 
USB.

https://packages.debian.org/buster/laptop-mode-tools

--
Benoit

Re: disque dur externe se coupe tout seul

[Haricophile]

Le Thu, 29 Apr 2021 20:48:26 +0200,
Gaëtan Perrier  a écrit :

> Auriez-vous déjà rencontré ce phénomène ?

Un problème de température ? quand j'écris beaucoup sur un disque
externe, je mets un peu de ventilation (pas besoin de beaucoup).

disque dur externe se coupe tout seul

[Gaëtan Perrier]

Bonjour,

Je viens de changer un de mes disques de sauvegardes par un modèle plus gros
dans un boitier Advance 3.5" connecté en USB3 avec alim externe.
Ma sauvegarde est faite par rsync et mon problème est que le disque s'éteint
tout seul en cours de sauvegarde ...

Auriez-vous déjà rencontré ce phénomène ?

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: Disque dur qui ne se monte pas...

[Raphaël POITEVIN]

david...@mailo.com writes:

> Est-ce que tu peux m'expliquer rapidement quelle serait l'origine du
> problème ?

Possible que ça soit un problème de permissions. L’interface graphique
essaie en tant qu’utilisateur non administrateur de monter un système de
fichiers ext4 sans en avoir les droits. C’est pourquoi il était plus
simple de le monter en tant qu’administrateur.
-- 
Raphaël
www.leclavierquibave.fr

Re: Disque dur qui ne se monte pas...

[david427]

j'ai l'impression que ça marche ! (c'est en cours de copie)

merci beaucoup !



Est-ce que tu peux m'expliquer rapidement quelle serait l'origine du problème ?



De : Raphaël POITEVIN 
À : debian-user-french@lists.debian.org
Sujet : Re: Disque dur qui ne se monte pas...
Date : 19/01/2021 13:13:46 Europe/Paris

Bonjour,

david...@mailo.com writes:

> Quand je le branche sur ma debian 10, j'ai le message suivant :
>
> error monting /dev/sdf3 at /media/moi/Docs: fs type, wrong bad option, bad
> superblock on /dev/sdf3, missing codepage or helper program, or other error
>
> Gparted me dit : Can't have a partition outside the disk!
> si j'ignore cet avertissement, je peux voir la structure du disque dur :
>
> -> sdf1, ext4 de de 46.62 Gio : c'est l'endroit ou est installé le système
> (debian 10 ou LMDE3 je ne sais plus)
> -> sdf2 c'est le swap (2.79 Gio + 1 Mio non alloué)
> -> sdf3, ext4 de 183,47 Gio : ce sont les documents
>
> ce qui m'étonne, c'est qu'en temps habituel j'aurais monté sdf3 en /home,
> mais là je ne le vois pas apparaître sur Gparted (j'ai peut-être fait une
> erreur pendant l'installation ?)

Vu que tu veux lire ce disque en tant que périphérique externe, il ne
faut pas monter la partition dans home.
>
> Les données que j'aimerai récupérer sont vraissemblablement sur sdf3 
>
> Auriez-vous par hasard une idée pour récupérer ces données ?

Essaie :
sudo mkdir /mnt/extern
sudo mount /dev/sdf3 /mnt/extern
puis copier vers un dossier :
mkdir ~/sauvegarde
sudo cp -av /mnt/extern/* ~/sauvegarde/
sudo chown -R ton_nom_utilisateur ~/sauvegarde/
puis quand c’est fini :
sudo umount /mnt/extern

Espérant aider,
-- 
Raphaël
www.leclavierquibave.fr

Re: Disque dur qui ne se monte pas...

[Raphaël POITEVIN]

Bonjour,

david...@mailo.com writes:

> Quand je le branche sur ma debian 10, j'ai le message suivant :
>
> error monting  /dev/sdf3 at /media/moi/Docs: fs type, wrong bad option, bad
> superblock on /dev/sdf3, missing codepage or helper program, or other error
>
> Gparted me dit : Can't have a partition outside the disk!
> si j'ignore cet avertissement, je peux voir la structure du disque dur :
>
> -> sdf1, ext4 de de 46.62 Gio : c'est l'endroit ou est installé le système
> (debian 10 ou LMDE3 je ne sais plus)
> -> sdf2 c'est le swap (2.79 Gio + 1 Mio non alloué)
> -> sdf3, ext4 de 183,47 Gio : ce sont les documents
>
> ce qui m'étonne, c'est qu'en temps habituel j'aurais monté sdf3 en /home,
> mais là je ne le vois pas apparaître sur Gparted (j'ai peut-être fait une
> erreur pendant l'installation ?)

Vu que tu veux lire ce disque en tant que périphérique externe, il ne
faut pas monter la partition dans home.
>
> Les données que j'aimerai récupérer sont vraissemblablement sur sdf3 
>
> Auriez-vous par hasard une idée pour récupérer ces données ?

Essaie :
sudo mkdir /mnt/extern
sudo mount /dev/sdf3 /mnt/extern
puis copier vers un dossier :
mkdir ~/sauvegarde
sudo cp -av /mnt/extern/* ~/sauvegarde/
sudo chown -R ton_nom_utilisateur ~/sauvegarde/
puis quand c’est fini :
sudo umount /mnt/extern

Espérant aider,
-- 
Raphaël
www.leclavierquibave.fr

Re: Disque dur qui ne se monte pas...

[david427]

Le message commençait par : Bonjour et bonne année à tous

(il faut le rajouter, je n'aime pas passer pour un goujat :) )

David



De : david...@mailo.com
À : debian-user-french@lists.debian.org
Sujet : Disque dur qui ne se monte pas...
Date : 19/01/2021 12:55:57 Europe/Paris

L'ordinateur portable de mon fils ne démarrant plus, j'ai voulu récupérer son 
disque dur pour récupérer ses données (essentiellement le travail qu'il devait 
rendre hier et dont il n'a pas fait de sauvegarde...)



C'est un disque-dur SATA

Quand je le branche sur ma debian 10, j'ai le message suivant :



error monting  /dev/sdf3 at /media/moi/Docs: fs type, wrong bad option, bad 
superblock on /dev/sdf3, missing codepage or helper program, or other error





Gparted me dit : Can't have a partition outside the disk!

si j'ignore cet avertissement, je peux voir la structure du disque dur :



-> sdf1, ext4 de de 46.62 Gio : c'est l'endroit ou est installé le système 
(debian 10 ou LMDE3 je ne sais plus)

-> sdf2 c'est le swap (2.79 Gio + 1 Mio non alloué)

-> sdf3, ext4 de 183,47 Gio : ce sont les documents



ce qui m'étonne, c'est qu'en temps habituel j'aurais monté sdf3 en /home, mais 
là je ne le vois pas apparaître sur Gparted (j'ai peut-être fait une erreur 
pendant l'installation ?)



Les données que j'aimerai récupérer sont vraissemblablement sur sdf3 





Auriez-vous par hasard une idée pour récupérer ces données ?



Je me suis demandé si le problème ne vient pas du fait que tous les ordinateurs 
de la maison ont les mêmes identifiants d'users (c'est plus simple à gérer pour 
nous...) et donc ça pourrait peut-être la raison du problème ?



D'avance merci pour votre aide,

David

Disque dur qui ne se monte pas...

[david427]

L'ordinateur portable de mon fils ne démarrant plus, j'ai voulu récupérer son 
disque dur pour récupérer ses données (essentiellement le travail qu'il devait 
rendre hier et dont il n'a pas fait de sauvegarde...)



C'est un disque-dur SATA

Quand je le branche sur ma debian 10, j'ai le message suivant :



error monting  /dev/sdf3 at /media/moi/Docs: fs type, wrong bad option, bad 
superblock on /dev/sdf3, missing codepage or helper program, or other error





Gparted me dit : Can't have a partition outside the disk!

si j'ignore cet avertissement, je peux voir la structure du disque dur :



-> sdf1, ext4 de de 46.62 Gio : c'est l'endroit ou est installé le système 
(debian 10 ou LMDE3 je ne sais plus)

-> sdf2 c'est le swap (2.79 Gio + 1 Mio non alloué)

-> sdf3, ext4 de 183,47 Gio : ce sont les documents



ce qui m'étonne, c'est qu'en temps habituel j'aurais monté sdf3 en /home, mais 
là je ne le vois pas apparaître sur Gparted (j'ai peut-être fait une erreur 
pendant l'installation ?)



Les données que j'aimerai récupérer sont vraissemblablement sur sdf3 





Auriez-vous par hasard une idée pour récupérer ces données ?



Je me suis demandé si le problème ne vient pas du fait que tous les ordinateurs 
de la maison ont les mêmes identifiants d'users (c'est plus simple à gérer pour 
nous...) et donc ça pourrait peut-être la raison du problème ?



D'avance merci pour votre aide,

David

Re : Re: [Hors-sujet] Durée de vie des données sur un disque dur mécanique

[k6dedijon]

Bonjour,
Le problème majeur des disques mécanique vient principalement du secteur de 
démarrage.
Certains fabricants ne portent pas assez attention à ce secteur qui est 
sollicité à chaque démarrage et redémarrage du disque.
Si ce secteur est endommagé, il faut monter le disque en esclave pour accéder à 
son contenu.

Bon courage
Cassis




- Mail d'origine -
De: benoit 
À: liste.debian 
Envoyé: Tue, 12 Jan 2021 20:25:28 +0100 (CET)
Objet: Re: [Hors-sujet] Durée de vie des données sur un disque dur mécanique

Bonjour,

Merci pour vos réponses.
J'ai perdu des données d'un disque mécanique conservé quelques années (de 
l'époque des disques IDE, c'est pas si vieux).
Ce n'est donc pas une perte de magnétisme, mais un autre problème.

Ca m'arrange bien de savoir que ce n'est pas une mauvaise solution de stockage 
moyenne durée. C'est l'option la moins chère au To.

--
Benoit

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
Le mardi 12 janvier 2021 14:38, BERTRAND Joël  a 
écrit :

> benoit a écrit :
>
> > Bonjour à toutes et tous,
> > Sur un disque dur mécanique, est-ce que les données finissent par se «
> > démagnétiser » après un stockage de plusieurs années sans que le disque
> > soit alimenté en électricité ?
> > Ou peut-il conserver les données « écrites » indéfiniment tant qu'elles
> > ne sont pas exposée à un champ magnétique ?
>
> Bonjour,
>
> Le ST506 de 5 Mo (oui, z'avez bien lu) de mon Goupil G3 est encore
> parfaitement lisible. Il date de 1984. L'ESDI de mon PS/2 P70 aussi.
> J'ai aussi fait récemment de la spéléologie dans des disques ODS2 de VAX
> sans problème. Il y a plus de risques que les têtes soient collées ou
> qu'un composant saute au démarrage que de perte de données.
>
> Je pense que tant qu'ils ne seront pas soumis à des champs magnétiques
> intenses, cela devrait aller. Je ne sais pas si les disques modernes
> sont plus enclins à perdre leur magnétisme (pour cela, je ferais une
> distinction entre les CRM et les SRM), mais en tout état de cause, la
> durée de rétention est largement supérieure à celle des SSD.
>
> Bien cordialement,
>
> JKB

Re: [Hors-sujet] Durée de vie des données sur un disque dur mécanique

[Wallace]

Bonjour,

Le problème des disques mis à l'arrêt c'est que la mécanique et 
l'électronique peuvent s'abimer.


J'ai déjà eu des disques durs stockés neufs en spare en attente 
d'intégration en cas d'incidents ne pas fonctionner après 2 ans de 
stockage, vu le bruit on pensait que c'était le graissage de l'axe des 
plateaux qui avait grippé ou alors le moteur qui est devenu faiblard.


Les disques tiennent plus longtemps s'ils restent allumés H24 sans mise 
en veille, ils sont fait pour ça.


Pour du stockage longue période, si les CD / DVD auraient pu faire des 
miracles dans les faits les 100 ans ne sont pas là et de la moisissure 
apparait souvent entre le substrat et le plastique, il reste 
malheureusement que le stockage sur bande magnétique, l'avantage c'est 
que les données sont accessibles sans aucune dépendance mécanique ou 
électronique sur le stockage, tout est dans le lecteur.


Sinon vois pour utiliser du stockage à froid en ligne comme C14 de 
Scaleway qui a un coup au To assez intéressant.



Le 12/01/2021 à 20:25, benoit a écrit :

Bonjour,

Merci pour vos réponses.
J'ai perdu des données d'un disque mécanique conservé quelques années (de 
l'époque des disques IDE, c'est pas si vieux).
Ce n'est donc pas une perte de magnétisme, mais un autre problème.

Ca m'arrange bien de savoir que ce n'est pas une mauvaise solution de stockage 
moyenne durée. C'est l'option la moins chère au To.

--
Benoit

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
Le mardi 12 janvier 2021 14:38, BERTRAND Joël  a 
écrit :


benoit a écrit :


Bonjour à toutes et tous,
Sur un disque dur mécanique, est-ce que les données finissent par se «
démagnétiser » après un stockage de plusieurs années sans que le disque
soit alimenté en électricité ?
Ou peut-il conserver les données « écrites » indéfiniment tant qu'elles
ne sont pas exposée à un champ magnétique ?

Bonjour,

Le ST506 de 5 Mo (oui, z'avez bien lu) de mon Goupil G3 est encore
parfaitement lisible. Il date de 1984. L'ESDI de mon PS/2 P70 aussi.
J'ai aussi fait récemment de la spéléologie dans des disques ODS2 de VAX
sans problème. Il y a plus de risques que les têtes soient collées ou
qu'un composant saute au démarrage que de perte de données.

Je pense que tant qu'ils ne seront pas soumis à des champs magnétiques
intenses, cela devrait aller. Je ne sais pas si les disques modernes
sont plus enclins à perdre leur magnétisme (pour cela, je ferais une
distinction entre les CRM et les SRM), mais en tout état de cause, la
durée de rétention est largement supérieure à celle des SSD.

Bien cordialement,

JKB

Re: [Hors-sujet] Durée de vie des données sur un disque dur mécanique

[BERTRAND Joël]

benoit a écrit :
> Bonjour,
> 
> Merci pour vos réponses.
> J'ai perdu des données d'un disque mécanique conservé quelques années (de 
> l'époque des disques IDE, c'est pas si vieux).
> Ce n'est donc pas une perte de magnétisme, mais un autre problème.
> 
> Ca m'arrange bien de savoir que ce n'est pas une mauvaise solution de 
> stockage moyenne durée. C'est l'option la moins chère au To.

Attention, un disque, c'est fiable (enfin, en fonction des marques...)
à deux conditions :
- CRM (et pas SRM) ;
- alimentés 24h/24.

La partie mécanique d'un disque ne saute pas sans préavis (sauf à
martyriser le disque). Contrairement à ce qu'on pense, c'est tout aussi
fiable qu'un SSD (voire plus selon mes propres statistiques). En
revanche, je ne serais pas aussi affirmatif avec l'électronique. Et pour
avoir déjà dû récupérer des données de clients sur des disques d'une
marque que je ne citerais pas, tu peux te retrouver avec des disques de
même référence fabricant, mais avec des cartes électroniques
incompatibles. Comme tu peux avoir le firmware dudit disque sur le
premier cylindre ou un identifiant permettant de savoir que la carte
électronique est bien celle d'origine (coucou Seagate).

Ça fonctionne très bien dans des NAS avec du Bacula par dessus et du
Raid, mais ça n'aime pas être démarré (électriquement parlant). Pour des
vrais archivages, rien ne vaut la bande. Et ce qui est cher dans la
bande, ce n'est pas le consommable, mais le lecteur, quoique les prix
aient sensiblement baissés (à capacité comparable). Un LTO-8 externe (12
To par bande) se trouve à prix public à 3500 € TTC avec des consommables
au prix du To de disque. J'ai des bandes SLR de 30 ans qui sont toujours
lisibles.

Bien cordialement,

JKB

Re: [Hors-sujet] Durée de vie des données sur un disque dur mécanique

[benoit]

Bonjour,

Merci pour vos réponses.
J'ai perdu des données d'un disque mécanique conservé quelques années (de 
l'époque des disques IDE, c'est pas si vieux).
Ce n'est donc pas une perte de magnétisme, mais un autre problème.

Ca m'arrange bien de savoir que ce n'est pas une mauvaise solution de stockage 
moyenne durée. C'est l'option la moins chère au To.

--
Benoit

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
Le mardi 12 janvier 2021 14:38, BERTRAND Joël  a 
écrit :

> benoit a écrit :
>
> > Bonjour à toutes et tous,
> > Sur un disque dur mécanique, est-ce que les données finissent par se «
> > démagnétiser » après un stockage de plusieurs années sans que le disque
> > soit alimenté en électricité ?
> > Ou peut-il conserver les données « écrites » indéfiniment tant qu'elles
> > ne sont pas exposée à un champ magnétique ?
>
> Bonjour,
>
> Le ST506 de 5 Mo (oui, z'avez bien lu) de mon Goupil G3 est encore
> parfaitement lisible. Il date de 1984. L'ESDI de mon PS/2 P70 aussi.
> J'ai aussi fait récemment de la spéléologie dans des disques ODS2 de VAX
> sans problème. Il y a plus de risques que les têtes soient collées ou
> qu'un composant saute au démarrage que de perte de données.
>
> Je pense que tant qu'ils ne seront pas soumis à des champs magnétiques
> intenses, cela devrait aller. Je ne sais pas si les disques modernes
> sont plus enclins à perdre leur magnétisme (pour cela, je ferais une
> distinction entre les CRM et les SRM), mais en tout état de cause, la
> durée de rétention est largement supérieure à celle des SSD.
>
> Bien cordialement,
>
> JKB

Re: [Hors-sujet] Durée de vie des données sur un disque dur mécanique

[BERTRAND Joël]

benoit a écrit :
> Bonjour à toutes et tous,
> 
> Sur un disque dur mécanique, est-ce que les données finissent par se «
> démagnétiser » après un stockage de plusieurs années sans que le disque
> soit alimenté en électricité ?
> Ou peut-il conserver les données « écrites » indéfiniment tant qu'elles
> ne sont pas exposée à un champ magnétique ?

Bonjour,

Le ST506 de 5 Mo (oui, z'avez bien lu) de mon Goupil G3 est encore
parfaitement lisible. Il date de 1984. L'ESDI de mon PS/2 P70 aussi.
J'ai aussi fait récemment de la spéléologie dans des disques ODS2 de VAX
sans problème. Il y a plus de risques que les têtes soient collées ou
qu'un composant saute au démarrage que de perte de données.

Je pense que tant qu'ils ne seront pas soumis à des champs magnétiques
intenses, cela devrait aller. Je ne sais pas si les disques modernes
sont plus enclins à perdre leur magnétisme (pour cela, je ferais une
distinction entre les CRM et les SRM), mais en tout état de cause, la
durée de rétention est largement supérieure à celle des SSD.

Bien cordialement,

JKB

[Hors-sujet] Durée de vie des données sur un disque dur mécanique

[benoit]

Bonjour à toutes et tous,

Sur un disque dur mécanique, est-ce que les données finissent par se « 
démagnétiser » après un stockage de plusieurs années sans que le disque soit 
alimenté en électricité ?
Ou peut-il conserver les données « écrites » indéfiniment tant qu'elles ne sont 
pas exposée à un champ magnétique ?

Merci

--
Benoit

Sent with [ProtonMail](https://protonmail.com) Secure Email.

système de fichier crypté (sur disque dur local) partageant la clef avec SSH

[Basile Starynkevitch]

Bonjour la liste,


Je cherche un système de fichier crypté sur une partition vierge d'un 
disque local (d'un portable récent, voir ceci 
) dont la clef serait 
partagée avec SSH.



Autrement dit, après un ssh-add je souhaiterais avoir accès à ce système 
de fichier.



Bien sûr, il y a sshfs  configuré en 
local, mais il y a-t-il d'autres solutions?


Techniquement mon portable est sous Ubuntu 19.10, mais s'il fallait y 
installer Debian/Sid (ou Debian/Buster), je pourrais le faire.



Librement


Basile Starynkevitch - http://starynkevitch.net/Basile/
Bourg La Reine, France  
opinions are only mine - les opinions sont seulement miennes

Re: Linux sur le 1er disque dur et windows sur le 2ème

[Jean-Philippe MENGUAL]

Bonjour,

A priori cela ne devrait pas poser de souci. update-grub lance os-prober 
donc devrait détecter tous les OS, sur les partitions montées, et faire 
le menu en conséquence.


Je ne garantis pas concernant UFI par contre.


Cordialement,



Jean-Philippe MENGUAL
Le 29/05/2019 à 00:39, ajh-valmer a écrit :

Bonsoir,

Grub va t-il accepter de booter Windows sur le disque 2 (sdb1),
et Linux installé sur le disque dur 1 (sda1) ?

Merci,

a. Valmer

Linux sur le 1er disque dur et windows sur le 2ème

[ajh-valmer]

Bonsoir,

Grub va t-il accepter de booter Windows sur le disque 2 (sdb1),
et Linux installé sur le disque dur 1 (sda1) ?

Merci,

a. Valmer

Re: [HS] Conseil changer disque dur portable pour un ssd

[Belaïd]

Bonjour,

Généralement les Sata 3 sont compatibles avec les Sata 2 , hormis  quelques
exceptions.  Je suis déjà tomber sur une marque SSD chinoise pas connu (de
moi en tous cas) en sata 3 qui n'était pas directement  compatible sur du
Sata 2, il fallait charger un pilote compatible (La marque SSD Sunbow par
exemple,  exotique mais qui ne m'a pas déçu pour le moment).


Le mer. 17 avr. 2019 12:40, ajh-valmer  a écrit :

> On Wednesday 17 April 2019 11:15:23 F. Wong wrote:
> > Les SSD sont vendus avec le nécessaire pour le maintien parfait en lieu
> > et place du disque dur 2,5 pouces existant.
>
> Merci pour toutes vos réponses.
>
> Y a t-il une compatibilité entre les connecteurs disques durs,
> SATA-2 et SATA-3 ?
> Les DD SSD demandent une connexion SATA-3, semble t-il,
> et mon portable est en SATA-2.
> Interface stockage : Serial ATA II
>
> Merci.
>
>
> > Le 17/04/2019 à 10:49, ajh-valmer a écrit :,
> > > J'ai un portable Acer 7741G.
> > > Je souhaite remplacer le disque actuel par un SSD.
> > > Je crains que le SSD soit plus petit,
> > > donc, comment le maintenir dans le boîtier ? :
> > > les attaches vissées de l'ancien DD risquent de ne plus
> > > correspondre avec celles du nouveau.
>
>

Re: [HS] Conseil changer disque dur portable pour un ssd

[didier gaumet]

Le 17/04/2019 à 12:39, ajh-valmer a écrit :

> Merci pour toutes vos réponses.
> 
> Y a t-il une compatibilité entre les connecteurs disques durs,
> SATA-2 et SATA-3 ?
> Les DD SSD demandent une connexion SATA-3, semble t-il,
> et mon portable est en SATA-2.
> Interface stockage : Serial ATA II 

D'après Wikipedia(1), je cite:
- "Un élément SATA I, II ou III peut être branché sur une carte mère
SATA I, II ou III. Le débit obtenu sera alors celui de l'élément le plus
lent.
Par exemple, un disque dur SATA III sur une carte mère SATA II aura un
débit limité par la carte mère à 300 Mo/s3."
- "En 2012, une part croissante des SSD saturent le débit maximal offert
que ce soit en lecture ou en écriture. En raison de la démocratisation
des SSD, équipant au moins les PC moyenne gamme en disque système, la
norme SATA III tend à devenir obsolète, à peine généralisée. Ainsi, le
PCI Express semble être le successeur du SATA, au moins pour les SSD"

D'après Wikipedia(2), il a des SSD SATA et des SSD PCI-E, les seconds
plus performants que les premiers à cause de l'inreface

Tout ceci d'après moi, qui ne possède pas encore de SSD, donc pas très
au courant de tout ça (donc: à vérifier) ;-)

1) https://fr.wikipedia.org/wiki/Serial_ATA#Compatibilit%C3%A9
2)
https://fr.wikipedia.org/wiki/SSD_(Informatique)#Diff%C3%A9rentes_formes_de_SSD

Re: [HS] Conseil changer disque dur portable pour un ssd

[ajh-valmer]

On Wednesday 17 April 2019 11:15:23 F. Wong wrote:
> Les SSD sont vendus avec le nécessaire pour le maintien parfait en lieu 
> et place du disque dur 2,5 pouces existant.

Merci pour toutes vos réponses.

Y a t-il une compatibilité entre les connecteurs disques durs,
SATA-2 et SATA-3 ?
Les DD SSD demandent une connexion SATA-3, semble t-il,
et mon portable est en SATA-2.
Interface stockage : Serial ATA II 

Merci.


> Le 17/04/2019 à 10:49, ajh-valmer a écrit :,
> > J'ai un portable Acer 7741G.
> > Je souhaite remplacer le disque actuel par un SSD.
> > Je crains que le SSD soit plus petit,
> > donc, comment le maintenir dans le boîtier ? :
> > les attaches vissées de l'ancien DD risquent de ne plus
> > correspondre avec celles du nouveau.

Re: [HS] Conseil changer disque dur portable pour un ssd

[Michel]

Le 17/04/2019 à 11:00, ajh-valmer a écrit :
> Bonjour,
> 
> J'ai un portable Acer 7741G.
> 
> Je souhaite remplacer le disque actuel par un SSD.
> 
> Je crains que le SSD soit plus petit,
> donc, comment le maintenir dans le boîtier ? :
> les attaches vissées de l'ancien DD risquent de ne plus 
> correspondre avec celles du nouveau.
> 
> Merci d'un conseil.
> 
> A. Valmer
> 
As tu la référence du SSD? La plupart sont en 2.5", comme les HDD.

Re: [HS] Conseil changer disque dur portable pour un ssd

[Michel Memeteau - EKIMIA]

Si ton DD etait 9.5 mm , le SSD est 7 mm don  oui il te faut une cale
souvent livré avec SSD , sinon des simple mousses suffisent
<-->
Michel Memeteau  - Directeur.


Notre Boutique Ordinateurs GNU/Linux : http://shop.ekimia.fr
Batiment Cambuza Rond Point plaine de joucques 13420 Gemenos - France.
Fixe :  +33 (0) 972308334   Mobile : +33(0) 624808051
<-->


Le mer. 17 avr. 2019 à 10:50, ajh-valmer  a écrit :

> Bonjour,
>
> J'ai un portable Acer 7741G.
>
> Je souhaite remplacer le disque actuel par un SSD.
>
> Je crains que le SSD soit plus petit,
> donc, comment le maintenir dans le boîtier ? :
> les attaches vissées de l'ancien DD risquent de ne plus
> correspondre avec celles du nouveau.
>
> Merci d'un conseil.
>
> A. Valmer
>
>

[HS] Conseil changer disque dur portable pour un ssd

[ajh-valmer]

Bonjour,

J'ai un portable Acer 7741G.

Je souhaite remplacer le disque actuel par un SSD.

Je crains que le SSD soit plus petit,
donc, comment le maintenir dans le boîtier ? :
les attaches vissées de l'ancien DD risquent de ne plus 
correspondre avec celles du nouveau.

Merci d'un conseil.

A. Valmer

Re: installation Debian avec home sur disque dur usb

[hamster]

Le 25/03/2019 à 10:08, Erwann Le Bras a écrit :
> Le 24/03/2019 à 20:29, hamster a écrit :
>> Le 24/03/2019 à 20:14, alex.pad...@laposte.net a écrit :
>>>
>>> Bonsoir à tous,
>>>
>>>
>>> Je souhaiterai faire une installation Debian sur un mini-pc avec un
>>> disque dur SSD, Debian sera installé sur le disque SSD tandis que mon
>>> home devra être installer impérativement sur un disque dur usb externe.
>>>
>>> Je souhaiterai que mon home soit crypté ou chiffré.
>>>
>>> Comment faire tout cela à l'installation du système.
>>>
>> Tout cela est prévu dans l'installeur. Autant le fait de chiffrer que de
>> séparer le /home sur une partition de ton choix.
>>
>
> Tout à fait : faire une install classique avec le disque externe en
> place pour préciser, au moment du partitionnement (choisir
> "personnalisé") la cible et l'état des partitions.

J'ajoute que chiffrer le /home ne suffit pas. Quand tu va utiliser ton
ordi, tu va taper ta phrase de passe pour acceder a tes données. Cette
phrase va etre stockée en mémoire vive. Si a ce moment la tu hiberne, le
contenu de la mémoire vive (avec ta phrase de passe) sera copié dans la
swap. Il faut donc chiffrer aussi la swap. Et tant que t'y est, si tu
chiffre aussi la partition système c'est pas plus mal.

Re: installation Debian avec home sur disque dur usb

[Erwann Le Bras]

Le 24/03/2019 à 20:29, hamster a écrit :

Le 24/03/2019 à 20:14, alex.pad...@laposte.net a écrit :


Bonsoir à tous,


Je souhaiterai faire une installation Debian sur un mini-pc avec un
disque dur SSD, Debian sera installé sur le disque SSD tandis que mon
home devra être installer impérativement sur un disque dur usb externe.

Je souhaiterai que mon home soit crypté ou chiffré.

Comment faire tout cela à l'installation du système.


Tout cela est prévu dans l'installeur. Autant le fait de chiffrer que de
séparer le /home sur une partition de ton choix.



Tout à fait : faire une install classique avec le disque externe en 
place pour préciser, au moment du partitionnement (choisir 
"personnalisé) la cible et l'état des partitions.


Bien réfléchir avant car selon le point de montage et la protection mise 
sur le disque externe, le système pourrait ne pas démarrer sans le 
disque externe ou le disque externe pas pouvoir être lu sur un autre 
système.


Erwann

Re: installation Debian avec home sur disque dur usb

[hamster]

Le 24/03/2019 à 20:14, alex.pad...@laposte.net a écrit :
>
>
> Bonsoir à tous,
>
>
> Je souhaiterai faire une installation Debian sur un mini-pc avec un
> disque dur SSD, Debian sera installé sur le disque SSD tandis que mon
> home devra être installer impérativement sur un disque dur usb externe.
>
> Je souhaiterai que mon home soit crypté ou chiffré.
>
> Comment faire tout cela à l'installation du système.
>

Tout cela est prévu dans l'installeur. Autant le fait de chiffrer que de
séparer le /home sur une partition de ton choix.

installation Debian avec home sur disque dur usb

[alex . padoly]

Bonsoir à tous, 




Je souhaiterai faire une installation Debian sur un mini-pc avec un disque dur 
SSD, Debian sera installé sur le disque SSD tandis que mon home devra être 
installer impérativement sur un disque dur usb externe. 


Je souhaiterai que mon home soit crypté ou chiffré. 

Comment faire tout cela à l'installation du système. 





Je vous remercie pour vos conseils. 

Alex 

Re: Disque Dur SSD

[Sébastien Dinot]

Bonjour,

- Mail original -
> Ne pas oublier que pas mal de SSD récents ont une zone tampon
> beaucoup plus rapide que le reste du SSD. Tant que les transferts
> ont une taille plus petite que cette zone tout va bien ça boost
> par contre quand ça déborde les perf diminuent fortement...

Je ne sais pas quelle est la taille de ce cache en général. En ce qui me 
concerne, le test a été effectué avec un disque NVMe de type PC401 NVMe SK 
hynix 512GB, mais je n'ai pas trouvé l'information sur la fiche de 
spécifications :

https://www.skhynix.com/eng/product/ssdClient.jsp

Et j'ai utilisé un fichier de 3,4 Go.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !