~$ sudo mkfs.ext3 -v /dev/sdb
mke2fs 1.42.13 (17-May-2015)
résolution de fs_types pour mke2fs.conf : 'ext3'
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
« Stride » = 0 blocs, « Stripe width » = 0 blocs
5029888 i-noeuds, 20104560 blocs
1005228 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=4294967296
614 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8192 i-noeuds par groupe
UUID de système de fichiers=195f614b-f2cd-4fe3-b8c0-71e4f2a68127
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424
Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Création du journal (32768 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété
Les disques durs ont un stock de secteurs supplémentaires. Si on commence à voir des secteurs défectueux, c'est que ce stock est épuisé, donc qu'il y a déjà beaucoup de secteurs réellement défectueux.
Pas forcément. J'ai vu passer un tas de disques qui avaient des secteurs illisibles (Current_Pending_Sector ou Offline_Uncorrectable > 0 mais un nombre de secteurs réalloués (Reallocated_Sector_Ct) faible, donc un stock de réserve important. La raison est simple : afin de ne pas effacer de données à cause d'une erreur de lecture transitoire, un secteur défectueux n'est réalloué que lors d'une lecture ultérieure réussie (les données pouvant être transférées dans le secteur de remplacement) ou lors d'une écriture (les anciennes données n'étant plus pertinentes).
Le 29/10/2016 à 20:59, Nicolas George a écrit :
Les disques durs ont un stock de secteurs supplémentaires. Si on
commence à voir des secteurs défectueux, c'est que ce stock est épuisé,
donc qu'il y a déjà beaucoup de secteurs réellement défectueux.
Pas forcément. J'ai vu passer un tas de disques qui avaient des secteurs
illisibles (Current_Pending_Sector ou Offline_Uncorrectable > 0 mais un
nombre de secteurs réalloués (Reallocated_Sector_Ct) faible, donc un
stock de réserve important.
La raison est simple : afin de ne pas effacer de données à cause d'une
erreur de lecture transitoire, un secteur défectueux n'est réalloué que
lors d'une lecture ultérieure réussie (les données pouvant être
transférées dans le secteur de remplacement) ou lors d'une écriture (les
anciennes données n'étant plus pertinentes).
Les disques durs ont un stock de secteurs supplémentaires. Si on commence à voir des secteurs défectueux, c'est que ce stock est épuisé, donc qu'il y a déjà beaucoup de secteurs réellement défectueux.
Pas forcément. J'ai vu passer un tas de disques qui avaient des secteurs illisibles (Current_Pending_Sector ou Offline_Uncorrectable > 0 mais un nombre de secteurs réalloués (Reallocated_Sector_Ct) faible, donc un stock de réserve important. La raison est simple : afin de ne pas effacer de données à cause d'une erreur de lecture transitoire, un secteur défectueux n'est réalloué que lors d'une lecture ultérieure réussie (les données pouvant être transférées dans le secteur de remplacement) ou lors d'une écriture (les anciennes données n'étant plus pertinentes).
Nicolas George
"Th.A.C" , dans le message <58152d2d$0$7121$, a écrit :
Évidement je ne parle pas des secteurs déja réalloués puisqu'on ne sait pas ou ils sont... La zone est quand même valide puisque je ne parle que des secteurs qu'on a détecté comme défectueux ou en passe de le devenir.
Tu sembles ne toujours pas avoir compris le problème, alors je reformule : Ça sert à quoi d'avoir une « zone de sécurité » autour du 1001e secteur défectueux alors qu'on en a déjà 1000 un peu partout indétectables car réalloués ?
Pour le cas qui nous occupe, j'ai clairement dit: ------------------ "je reste quand même persuadé que seul badblocks suivi d'un control smart pourra donner une évaluation acceptable du disque. Il faudra aussi regarder si le message d'erreur n'apparaît plus après avoir réinitialisé le partitionnement du disque." ------------------
Même si le problème disparaît après une écriture, le disque est bon pour la poubelle, parce que le problème peut réapparaître. Tu sembles faire de l'autopsie de ce disque mort un but en soi. La plupart des gens s'en fichent : un disque, ça meurt au bout d'un temps, c'est déjà un miracle qu'un 80 Go soit toujours opérationnel de nos jours. L'important pour la plupart des gens, c'est l'intégrité des données, et secondairement les efforts dépensés. Eh bien dans la situation actuelle, l'intégrité des données exige que ce disque soit mis au rebut, et les efforts dépensés au delà le sont en pure perte.
"Th.A.C" , dans le message <58152d2d$0$7121$426a74cc@news.free.fr>, a
écrit :
Évidement je ne parle pas des secteurs déja réalloués puisqu'on ne sait
pas ou ils sont...
La zone est quand même valide puisque je ne parle que des secteurs qu'on
a détecté comme défectueux ou en passe de le devenir.
Tu sembles ne toujours pas avoir compris le problème, alors je
reformule :
Ça sert à quoi d'avoir une « zone de sécurité » autour du 1001e secteur
défectueux alors qu'on en a déjà 1000 un peu partout indétectables car
réalloués ?
Pour le cas qui nous occupe, j'ai clairement dit:
------------------
"je reste quand même persuadé que seul badblocks suivi d'un control
smart pourra donner une évaluation acceptable du disque.
Il faudra aussi regarder si le message d'erreur n'apparaît plus après
avoir réinitialisé le partitionnement du disque."
------------------
Même si le problème disparaît après une écriture, le disque est bon pour
la poubelle, parce que le problème peut réapparaître.
Tu sembles faire de l'autopsie de ce disque mort un but en soi. La
plupart des gens s'en fichent : un disque, ça meurt au bout d'un temps,
c'est déjà un miracle qu'un 80 Go soit toujours opérationnel de nos
jours.
L'important pour la plupart des gens, c'est l'intégrité des données, et
secondairement les efforts dépensés.
Eh bien dans la situation actuelle, l'intégrité des données exige que ce
disque soit mis au rebut, et les efforts dépensés au delà le sont en
pure perte.
"Th.A.C" , dans le message <58152d2d$0$7121$, a écrit :
Évidement je ne parle pas des secteurs déja réalloués puisqu'on ne sait pas ou ils sont... La zone est quand même valide puisque je ne parle que des secteurs qu'on a détecté comme défectueux ou en passe de le devenir.
Tu sembles ne toujours pas avoir compris le problème, alors je reformule : Ça sert à quoi d'avoir une « zone de sécurité » autour du 1001e secteur défectueux alors qu'on en a déjà 1000 un peu partout indétectables car réalloués ?
Pour le cas qui nous occupe, j'ai clairement dit: ------------------ "je reste quand même persuadé que seul badblocks suivi d'un control smart pourra donner une évaluation acceptable du disque. Il faudra aussi regarder si le message d'erreur n'apparaît plus après avoir réinitialisé le partitionnement du disque." ------------------
Même si le problème disparaît après une écriture, le disque est bon pour la poubelle, parce que le problème peut réapparaître. Tu sembles faire de l'autopsie de ce disque mort un but en soi. La plupart des gens s'en fichent : un disque, ça meurt au bout d'un temps, c'est déjà un miracle qu'un 80 Go soit toujours opérationnel de nos jours. L'important pour la plupart des gens, c'est l'intégrité des données, et secondairement les efforts dépensés. Eh bien dans la situation actuelle, l'intégrité des données exige que ce disque soit mis au rebut, et les efforts dépensés au delà le sont en pure perte.
Nicolas George
Sergio , dans le message <5815898f$0$3340$, a écrit :
badblocks, c'était au siècle dernier : pouvoir continuer à utiliser un disque qu'on sait endommagé. De nos jours, le fonctionnement des disques fait que le premier secteur défectueux visible est signe que le disque
^^^^^^^
Non. Les secteurs défectueux sont réalloués dans une zone spécifique par l'électronique du disque lui-même. Quand il n'y a plus de place dans la zone, là, le disque n'est plus content ! (voir les détails des infos smart, ligne 5).
Tu redis la même chose que moi, juste avec plus de détails. Tu as probablement loupé le mot « visible » dans ma phrase. Je l'ai souligné pour toi.
Sergio , dans le message <5815898f$0$3340$426a34cc@news.free.fr>, a
écrit :
badblocks, c'était au siècle dernier : pouvoir continuer à utiliser un
disque qu'on sait endommagé. De nos jours, le fonctionnement des disques
fait que le premier secteur défectueux visible est signe que le disque
^^^^^^^
Non. Les secteurs défectueux sont réalloués dans une zone spécifique
par l'électronique du disque lui-même. Quand il n'y a plus de place
dans la zone, là, le disque n'est plus content ! (voir les détails des
infos smart, ligne 5).
Tu redis la même chose que moi, juste avec plus de détails. Tu as
probablement loupé le mot « visible » dans ma phrase. Je l'ai souligné
pour toi.
Sergio , dans le message <5815898f$0$3340$, a écrit :
badblocks, c'était au siècle dernier : pouvoir continuer à utiliser un disque qu'on sait endommagé. De nos jours, le fonctionnement des disques fait que le premier secteur défectueux visible est signe que le disque
^^^^^^^
Non. Les secteurs défectueux sont réalloués dans une zone spécifique par l'électronique du disque lui-même. Quand il n'y a plus de place dans la zone, là, le disque n'est plus content ! (voir les détails des infos smart, ligne 5).
Tu redis la même chose que moi, juste avec plus de détails. Tu as probablement loupé le mot « visible » dans ma phrase. Je l'ai souligné pour toi.
Pascal Hambourg
Le 30/10/2016 à 03:33, Dominique a écrit :
Je peux monter mon disque et accéder à son contenu. Pour autant, dmesg annonce toujours une erreur : -------------------------------------------------------- [ 9285.985536] blk_update_request: critical medium error, dev sdb, sector 160836480 [ 9285.985539] Buffer I/O error on dev sdb, logical block 160836480, async page read Le dernier secteur paraît corrompu pour de bon. J'ai réduit sdb1 afin d'isoler 0.5 GO à la fin dont le secteur défectueux mais ça ne change rien à ce message d'erreur.
Evidemment. Ce n'est pas lors du montage du système de fichiers que ce secteur est lu mais lors de la recherche de méta-données à la détection du disque. Si tu veux voir quelle zone est défectueuse, tu peux utiliser badblocks comme on te l'a déjà suggéré. Et si cette zone est vraiment localisée à la fin, une possibilité est d'utiliser hdparm -N pour définir une HPA (host protected area) qui couvre cette zone, tronquant le disque.
-------------------------------------------------------- e2fsck bougonne toujours malgré ce repartitionnement : -------------------------------------------------------- sudo e2fsck -c /dev/sdb1 [sudo] Mot de passe de ubuntu : e2fsck 1.42.13 (17-May-2015) ext2fs_open2: Numéro magique invalide dans le super-bloc e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage... e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdb1
Est-ce sdb ou sdb1 qui est monté (voir mount ou df) ? As-tu recréé un système de fichiers dans sdb1 après avoir créé la partition ? Sinon, le système de fichiers est toujours dans sdb et la réponse de e2fsck est normale. Ext2/3/4 n'utilise pas le premier secteur (PBR ou MBR) d'un volume, donc la création d'une table de partition dans celui-ci n'altère pas les méta-données du système de fichiers qui reste utilisable.
"-d scsi" ne me semble pas être la bonne option pour un disque connecté via un pont (S)ATA/USB.
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. -------------------------------------------------------- Lorsque je mets une option -T permissive, il me dit que j'ai 2 device sdb ou sdb1.
On pourrait avoir le message exact et complet ?
Le 30/10/2016 à 03:33, Dominique a écrit :
Je peux monter mon disque et accéder à son contenu. Pour autant, dmesg
annonce toujours une erreur :
--------------------------------------------------------
[ 9285.985536] blk_update_request: critical medium error, dev sdb,
sector 160836480
[ 9285.985539] Buffer I/O error on dev sdb, logical block 160836480,
async page read
Le dernier secteur paraît corrompu pour de bon. J'ai réduit sdb1 afin
d'isoler 0.5 GO à la fin dont le secteur défectueux mais ça ne change
rien à ce message d'erreur.
Evidemment. Ce n'est pas lors du montage du système de fichiers que ce
secteur est lu mais lors de la recherche de méta-données à la détection
du disque.
Si tu veux voir quelle zone est défectueuse, tu peux utiliser badblocks
comme on te l'a déjà suggéré. Et si cette zone est vraiment localisée à
la fin, une possibilité est d'utiliser hdparm -N pour définir une HPA
(host protected area) qui couvre cette zone, tronquant le disque.
sudo e2fsck -c /dev/sdb1
[sudo] Mot de passe de ubuntu :
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Numéro magique invalide dans le super-bloc
e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative
d'ouverture de /dev/sdb1
Est-ce sdb ou sdb1 qui est monté (voir mount ou df) ?
As-tu recréé un système de fichiers dans sdb1 après avoir créé la
partition ? Sinon, le système de fichiers est toujours dans sdb et la
réponse de e2fsck est normale. Ext2/3/4 n'utilise pas le premier secteur
(PBR ou MBR) d'un volume, donc la création d'une table de partition dans
celui-ci n'altère pas les méta-données du système de fichiers qui reste
utilisable.
"-d scsi" ne me semble pas être la bonne option pour un disque connecté
via un pont (S)ATA/USB.
A mandatory SMART command failed: exiting. To continue, add one or more
'-T permissive' options.
--------------------------------------------------------
Lorsque je mets une option -T permissive, il me dit que j'ai 2 device
sdb ou sdb1.
Je peux monter mon disque et accéder à son contenu. Pour autant, dmesg annonce toujours une erreur : -------------------------------------------------------- [ 9285.985536] blk_update_request: critical medium error, dev sdb, sector 160836480 [ 9285.985539] Buffer I/O error on dev sdb, logical block 160836480, async page read Le dernier secteur paraît corrompu pour de bon. J'ai réduit sdb1 afin d'isoler 0.5 GO à la fin dont le secteur défectueux mais ça ne change rien à ce message d'erreur.
Evidemment. Ce n'est pas lors du montage du système de fichiers que ce secteur est lu mais lors de la recherche de méta-données à la détection du disque. Si tu veux voir quelle zone est défectueuse, tu peux utiliser badblocks comme on te l'a déjà suggéré. Et si cette zone est vraiment localisée à la fin, une possibilité est d'utiliser hdparm -N pour définir une HPA (host protected area) qui couvre cette zone, tronquant le disque.
-------------------------------------------------------- e2fsck bougonne toujours malgré ce repartitionnement : -------------------------------------------------------- sudo e2fsck -c /dev/sdb1 [sudo] Mot de passe de ubuntu : e2fsck 1.42.13 (17-May-2015) ext2fs_open2: Numéro magique invalide dans le super-bloc e2fsck : Superbloc invalide, tentons d'utiliser les blocs de sauvetage... e2fsck: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdb1
Est-ce sdb ou sdb1 qui est monté (voir mount ou df) ? As-tu recréé un système de fichiers dans sdb1 après avoir créé la partition ? Sinon, le système de fichiers est toujours dans sdb et la réponse de e2fsck est normale. Ext2/3/4 n'utilise pas le premier secteur (PBR ou MBR) d'un volume, donc la création d'une table de partition dans celui-ci n'altère pas les méta-données du système de fichiers qui reste utilisable.
"-d scsi" ne me semble pas être la bonne option pour un disque connecté via un pont (S)ATA/USB.
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. -------------------------------------------------------- Lorsque je mets une option -T permissive, il me dit que j'ai 2 device sdb ou sdb1.
