Je fais régulièrement une copie sur disque dur externe. J'utilise rdiff-
backup.
J'ai un problème avec un de mes disques durs externes: au bout de quelques
minutes de sauvegarde, j'obtients des erreurs:
IOError: [Errno 5] Input/output error
Et la sauvegarde s'arrête.
Si ensuite je démonte le disque, et que je fais:
$ fsck.ext3 -y /dev/dm-5
e2fsck 1.41.14 (22-Dec-2010)
/dev/dm-5 contains a file system with errors, check forced.
[...]
La réparation semble fonctionner, mais quand je relance rdiff-backup,
j'obtiens à nouveau une IOError. Puis je fais à nouveau un fsck.ext3, et
ainsi de suite. La seule solution que j'ai trouvée est alors de formater le
disque. Une dizaine de copies se passent alors ensuite correctement (grosso-
modo, 3 semaines de copies), puis à nouveau j'obtiens une IOError. J'ai
essayé en EXT3 et en EXT4, même comportement. Que faire?
Merci par avance,
TP
Note 1: aujourd'hui, nouveau comportement: j'obtiens une IOError, mais quand
je fais fsck.ext3 ensuite, fsck.ext3 ne trouve pas d'erreurs sur le disque,
donc rend directement la main:
Le Thu, 26 Jan 2012 10:07:32 +0100, Lucas Levrel a écrit :
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
Vu le nombre d'erreurs déjà trouvées à la lecture, commence par mke2fs -c !
-cc est plus "méchant" que -c : il fait un test en écriture+lecture alors que -c ne fait qu'un test en lecture... (dixit le man)
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
wcth
Le 25/01/2012 23:11, TP a écrit :
Bonjour à tous,
Je fais régulièrement une copie sur disque dur externe. J'utilise rdiff- backup. J'ai un problème avec un de mes disques durs externes: au bout de quelques minutes de sauvegarde, j'obtients des erreurs:
IOError: [Errno 5] Input/output error
Et la sauvegarde s'arrête. Si ensuite je démonte le disque, et que je fais:
$ fsck.ext3 -y /dev/dm-5 e2fsck 1.41.14 (22-Dec-2010) /dev/dm-5 contains a file system with errors, check forced. [...]
La réparation semble fonctionner, mais quand je relance rdiff-backup, j'obtiens à nouveau une IOError. Puis je fais à nouveau un fsck.ext3, et ainsi de suite. La seule solution que j'ai trouvée est alors de formater le disque. Une dizaine de copies se passent alors ensuite correctement (grosso- modo, 3 semaines de copies), puis à nouveau j'obtiens une IOError. J'ai essayé en EXT3 et en EXT4, même comportement. Que faire?
Merci par avance,
TP
Note 1: aujourd'hui, nouveau comportement: j'obtiens une IOError, mais quand je fais fsck.ext3 ensuite, fsck.ext3 ne trouve pas d'erreurs sur le disque, donc rend directement la main:
Note 2: le disque externe est crypté. Peut-être est-ce une information importante.
Normalement smartctl peut servir à diagnostiquer le disque.
smartctl -a /dev/sd....
Le 25/01/2012 23:11, TP a écrit :
Bonjour à tous,
Je fais régulièrement une copie sur disque dur externe. J'utilise rdiff-
backup.
J'ai un problème avec un de mes disques durs externes: au bout de quelques
minutes de sauvegarde, j'obtients des erreurs:
IOError: [Errno 5] Input/output error
Et la sauvegarde s'arrête.
Si ensuite je démonte le disque, et que je fais:
$ fsck.ext3 -y /dev/dm-5
e2fsck 1.41.14 (22-Dec-2010)
/dev/dm-5 contains a file system with errors, check forced.
[...]
La réparation semble fonctionner, mais quand je relance rdiff-backup,
j'obtiens à nouveau une IOError. Puis je fais à nouveau un fsck.ext3, et
ainsi de suite. La seule solution que j'ai trouvée est alors de formater le
disque. Une dizaine de copies se passent alors ensuite correctement (grosso-
modo, 3 semaines de copies), puis à nouveau j'obtiens une IOError. J'ai
essayé en EXT3 et en EXT4, même comportement. Que faire?
Merci par avance,
TP
Note 1: aujourd'hui, nouveau comportement: j'obtiens une IOError, mais quand
je fais fsck.ext3 ensuite, fsck.ext3 ne trouve pas d'erreurs sur le disque,
donc rend directement la main:
Je fais régulièrement une copie sur disque dur externe. J'utilise rdiff- backup. J'ai un problème avec un de mes disques durs externes: au bout de quelques minutes de sauvegarde, j'obtients des erreurs:
IOError: [Errno 5] Input/output error
Et la sauvegarde s'arrête. Si ensuite je démonte le disque, et que je fais:
$ fsck.ext3 -y /dev/dm-5 e2fsck 1.41.14 (22-Dec-2010) /dev/dm-5 contains a file system with errors, check forced. [...]
La réparation semble fonctionner, mais quand je relance rdiff-backup, j'obtiens à nouveau une IOError. Puis je fais à nouveau un fsck.ext3, et ainsi de suite. La seule solution que j'ai trouvée est alors de formater le disque. Une dizaine de copies se passent alors ensuite correctement (grosso- modo, 3 semaines de copies), puis à nouveau j'obtiens une IOError. J'ai essayé en EXT3 et en EXT4, même comportement. Que faire?
Merci par avance,
TP
Note 1: aujourd'hui, nouveau comportement: j'obtiens une IOError, mais quand je fais fsck.ext3 ensuite, fsck.ext3 ne trouve pas d'erreurs sur le disque, donc rend directement la main:
Note 2: le disque externe est crypté. Peut-être est-ce une information importante.
Normalement smartctl peut servir à diagnostiquer le disque.
smartctl -a /dev/sd....
Lucas Levrel
Le 26 janvier 2012, Sergio a écrit :
Le Thu, 26 Jan 2012 10:07:32 +0100, Lucas Levrel a écrit :
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
Vu le nombre d'erreurs déjà trouvées à la lecture, commence par mke2fs -c !
-cc est plus "méchant" que -c : il fait un test en écriture+lecture alors que -c ne fait qu'un test en lecture... (dixit le man)
Précisément : badblocks, par défaut, fait le test en lecture et il trouve déjà plein d'erreurs. Vu que (dixit le man) -cc est beaucoup plus lent (logique !), autant commencer par enlever rapidement (-c) toutes ces erreurs de lecture avant de chercher les erreurs à l'écriture !
-- LL
Le 26 janvier 2012, Sergio a écrit :
Le Thu, 26 Jan 2012 10:07:32 +0100, Lucas Levrel a écrit :
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
Vu le nombre d'erreurs déjà trouvées à la lecture, commence par mke2fs
-c !
-cc est plus "méchant" que -c : il fait un test en écriture+lecture alors
que -c ne fait qu'un test en lecture... (dixit le man)
Précisément : badblocks, par défaut, fait le test en lecture et il trouve
déjà plein d'erreurs. Vu que (dixit le man) -cc est beaucoup plus lent
(logique !), autant commencer par enlever rapidement (-c) toutes ces
erreurs de lecture avant de chercher les erreurs à l'écriture !
Le Thu, 26 Jan 2012 10:07:32 +0100, Lucas Levrel a écrit :
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
Vu le nombre d'erreurs déjà trouvées à la lecture, commence par mke2fs -c !
-cc est plus "méchant" que -c : il fait un test en écriture+lecture alors que -c ne fait qu'un test en lecture... (dixit le man)
Précisément : badblocks, par défaut, fait le test en lecture et il trouve déjà plein d'erreurs. Vu que (dixit le man) -cc est beaucoup plus lent (logique !), autant commencer par enlever rapidement (-c) toutes ces erreurs de lecture avant de chercher les erreurs à l'écriture !
-- LL
Fabien LE LEZ
On Fri, 27 Jan 2012 07:54:30 +0100, wcth :
Normalement smartctl peut servir à diagnostiquer le disque.
SMART sert à prévoir les problèmes. Il peut te dire "Attention, le disque commence à fatiguer, mieux vaut le changer avant de perdre des données".
Si tu soupçonnes que c'est trop tard, et que ton disque dur est déjà mort, mieux vaut utiliser l'utilitaire de test fourni par le constructeur. Tu feras d'une pierre deux coups : d'une part, tu vérifieras le disque ; d'autre part, si le disque est défectueux, tu obtiendras un code diagnostique à indiquer au constructeur pour la garantie.
On Fri, 27 Jan 2012 07:54:30 +0100, wcth <wcth241@yahoo.fr>:
Normalement smartctl peut servir à diagnostiquer le disque.
SMART sert à prévoir les problèmes. Il peut te dire "Attention, le
disque commence à fatiguer, mieux vaut le changer avant de perdre des
données".
Si tu soupçonnes que c'est trop tard, et que ton disque dur est déjà
mort, mieux vaut utiliser l'utilitaire de test fourni par le
constructeur. Tu feras d'une pierre deux coups : d'une part, tu
vérifieras le disque ; d'autre part, si le disque est défectueux, tu
obtiendras un code diagnostique à indiquer au constructeur pour la
garantie.
Normalement smartctl peut servir à diagnostiquer le disque.
SMART sert à prévoir les problèmes. Il peut te dire "Attention, le disque commence à fatiguer, mieux vaut le changer avant de perdre des données".
Si tu soupçonnes que c'est trop tard, et que ton disque dur est déjà mort, mieux vaut utiliser l'utilitaire de test fourni par le constructeur. Tu feras d'une pierre deux coups : d'une part, tu vérifieras le disque ; d'autre part, si le disque est défectueux, tu obtiendras un code diagnostique à indiquer au constructeur pour la garantie.
Sergio
Le Fri, 27 Jan 2012 07:54:30 +0100, wcth a écrit :
Sergio , dans le message <4f22aebf$0$15697$, a écrit :
smartctl utilise les données SMART, qui, en général, ne sont pas gérés par les disques externes...
Plus exactement, par les contrôleurs USB->ATA. Je soupçonne qu'un disque dur en eSATA peut sans problème être interrogé en SMART.
Arnaud Gomes-do-Vale
Nicolas George <nicolas$ writes:
Plus exactement, par les contrôleurs USB->ATA. Je soupçonne qu'un disque dur en eSATA peut sans problème être interrogé en SMART.
Ça dépend (tm). J'ai des adaptateurs SATA-eSATA qui laissent passer SMART, d'autres non. À vue de new les premiers se contentent d'assurer la liaison électrique (et d'alimenter le disque mais c'est une fonction totalement séparée) tandis que les autres sont intelligents.
Même chose pour les adaptateurs USB-SATA d'ailleurs (à part que c'est de toute façon un peu plus compliqué que SATA-eSATA).
-- Arnaud http://blogs.glou.org/arnaud/
Nicolas George <nicolas$george@salle-s.org> writes:
Plus exactement, par les contrôleurs USB->ATA. Je soupçonne qu'un disque dur
en eSATA peut sans problème être interrogé en SMART.
Ça dépend (tm). J'ai des adaptateurs SATA-eSATA qui laissent passer
SMART, d'autres non. À vue de new les premiers se contentent d'assurer
la liaison électrique (et d'alimenter le disque mais c'est une fonction
totalement séparée) tandis que les autres sont intelligents.
Même chose pour les adaptateurs USB-SATA d'ailleurs (à part que c'est de
toute façon un peu plus compliqué que SATA-eSATA).
Plus exactement, par les contrôleurs USB->ATA. Je soupçonne qu'un disque dur en eSATA peut sans problème être interrogé en SMART.
Ça dépend (tm). J'ai des adaptateurs SATA-eSATA qui laissent passer SMART, d'autres non. À vue de new les premiers se contentent d'assurer la liaison électrique (et d'alimenter le disque mais c'est une fonction totalement séparée) tandis que les autres sont intelligents.
Même chose pour les adaptateurs USB-SATA d'ailleurs (à part que c'est de toute façon un peu plus compliqué que SATA-eSATA).
-- Arnaud http://blogs.glou.org/arnaud/
Hugolino
Le 26-01-2012, TP a écrit :
Pour l'instant, je n'ai essayé que badblocks, et il n'a pas fini au bout d'une nuit:
badblocks /dev/dm-5
[...]
J'ai déjà testé un 250 Go avec badblocks en lecture/écriture avec 'badblocks -w -p 2 -s -v /dev/hdb6' : le test dure 24 heures : compte donc 1 heure par dizaine de Go.
Note pour les analphabêtes de la page de manuel : CE TEST EST DESTRUCTIF POUR LE FS !!!!!!!!!!!!!!!!!!!!
HTH
-- Because Microsoft offers you windows, and Linux the whole house. Hugo (né il y a 1 507 146 303 secondes)
Le 26-01-2012, TP <TP@frenoespam.fr.invalid> a écrit :
Pour l'instant, je n'ai essayé que badblocks, et il n'a pas fini au bout
d'une nuit:
badblocks /dev/dm-5
[...]
J'ai déjà testé un 250 Go avec badblocks en lecture/écriture avec
'badblocks -w -p 2 -s -v /dev/hdb6' : le test dure 24 heures : compte
donc 1 heure par dizaine de Go.
Note pour les analphabêtes de la page de manuel : CE TEST EST DESTRUCTIF
POUR LE FS !!!!!!!!!!!!!!!!!!!!
HTH
--
Because Microsoft offers you windows, and Linux the whole house.
Hugo (né il y a 1 507 146 303 secondes)
Pour l'instant, je n'ai essayé que badblocks, et il n'a pas fini au bout d'une nuit:
badblocks /dev/dm-5
[...]
J'ai déjà testé un 250 Go avec badblocks en lecture/écriture avec 'badblocks -w -p 2 -s -v /dev/hdb6' : le test dure 24 heures : compte donc 1 heure par dizaine de Go.
Note pour les analphabêtes de la page de manuel : CE TEST EST DESTRUCTIF POUR LE FS !!!!!!!!!!!!!!!!!!!!
HTH
-- Because Microsoft offers you windows, and Linux the whole house. Hugo (né il y a 1 507 146 303 secondes)
TP
TP wrote:
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
J'ai donc appliqué cette commande, qui a tourné pendant presque 4 jours:
$ mke2fs -cc -t ext4 /dev/dm-5 mke2fs 1.41.14 (22-Dec-2010) Filesystem label OS type: Linux Block (log=2) Fragment (log=2) Stride=0 blocks, Stripe width=0 blocks 30531584 inodes, 122095872 blocks 6104793 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocksB94967296 3727 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000 Testing with pattern 0xaa: done Reading and comparing: done Testing with pattern 0x55: done Reading and comparing: done Testing with pattern 0xff: done Reading and comparing: done Testing with pattern 0x00: done Reading and comparing: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 36 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. You have new mail in /var/mail/root
A la suite de ceci, j'ai lancé à nouveau badblocks:
$ badblocks /dev/dm-5
qui a tourné pendant 1 jour ou 2.
Et cette fois-ci, aucun badblock détecté. Est-ce un comportement attendu?
Merci,
TP
TP wrote:
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
J'ai donc appliqué cette commande, qui a tourné pendant presque 4 jours:
$ mke2fs -cc -t ext4 /dev/dm-5
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label OS type: Linux
Block size@96 (log=2)
Fragment size@96 (log=2)
Stride=0 blocks, Stripe width=0 blocks
30531584 inodes, 122095872 blocks
6104793 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocksB94967296
3727 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
You have new mail in /var/mail/root
A la suite de ceci, j'ai lancé à nouveau badblocks:
$ badblocks /dev/dm-5
qui a tourné pendant 1 jour ou 2.
Et cette fois-ci, aucun badblock détecté.
Est-ce un comportement attendu?
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
J'ai donc appliqué cette commande, qui a tourné pendant presque 4 jours:
$ mke2fs -cc -t ext4 /dev/dm-5 mke2fs 1.41.14 (22-Dec-2010) Filesystem label OS type: Linux Block (log=2) Fragment (log=2) Stride=0 blocks, Stripe width=0 blocks 30531584 inodes, 122095872 blocks 6104793 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocksB94967296 3727 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000 Testing with pattern 0xaa: done Reading and comparing: done Testing with pattern 0x55: done Reading and comparing: done Testing with pattern 0xff: done Reading and comparing: done Testing with pattern 0x00: done Reading and comparing: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 36 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. You have new mail in /var/mail/root
A la suite de ceci, j'ai lancé à nouveau badblocks:
$ badblocks /dev/dm-5
qui a tourné pendant 1 jour ou 2.
Et cette fois-ci, aucun badblock détecté. Est-ce un comportement attendu?
Merci,
TP
Pascal Hambourg
Salut,
TP a écrit :
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
J'ai donc appliqué cette commande, qui a tourné pendant presque 4 jours:
[...]
Testing with pattern 0xaa: done Reading and comparing: done Testing with pattern 0x55: done Reading and comparing: done Testing with pattern 0xff: done Reading and comparing: done Testing with pattern 0x00: done Reading and comparing: done
Donc plus d'erreurs à la lecture de vérification.
A la suite de ceci, j'ai lancé à nouveau badblocks:
Ce n'était pas vraiment utile, vu le résultat précédent.
$ badblocks /dev/dm-5
qui a tourné pendant 1 jour ou 2.
Et cette fois-ci, aucun badblock détecté. Est-ce un comportement attendu?
Oui. Cf. la réponse de Nicolas. C'est une methode que j'utilise parfois pour tenter de forcer la détection et la réparation ou la réallocation des blocs défectueux.
Salut,
TP a écrit :
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
J'ai donc appliqué cette commande, qui a tourné pendant presque 4 jours:
[...]
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Donc plus d'erreurs à la lecture de vérification.
A la suite de ceci, j'ai lancé à nouveau badblocks:
Ce n'était pas vraiment utile, vu le résultat précédent.
$ badblocks /dev/dm-5
qui a tourné pendant 1 jour ou 2.
Et cette fois-ci, aucun badblock détecté.
Est-ce un comportement attendu?
Oui. Cf. la réponse de Nicolas. C'est une methode que j'utilise parfois
pour tenter de forcer la détection et la réparation ou la réallocation
des blocs défectueux.
Je vais tester le formatage "mke2fs -cc" recommandé par Sergio.
J'ai donc appliqué cette commande, qui a tourné pendant presque 4 jours:
[...]
Testing with pattern 0xaa: done Reading and comparing: done Testing with pattern 0x55: done Reading and comparing: done Testing with pattern 0xff: done Reading and comparing: done Testing with pattern 0x00: done Reading and comparing: done
Donc plus d'erreurs à la lecture de vérification.
A la suite de ceci, j'ai lancé à nouveau badblocks:
Ce n'était pas vraiment utile, vu le résultat précédent.
$ badblocks /dev/dm-5
qui a tourné pendant 1 jour ou 2.
Et cette fois-ci, aucun badblock détecté. Est-ce un comportement attendu?
Oui. Cf. la réponse de Nicolas. C'est une methode que j'utilise parfois pour tenter de forcer la détection et la réparation ou la réallocation des blocs défectueux.
