Problème disque dur USB
Le
Louis-Philippe Gauthier
Bonjour,
J'ai un soucis avec un disque dur USB externe Seagate GoFlex de 1To.
J'ai fait un badlocks en root
# badblocks -v /dev/sdc
Vérification des blocs 0 à 976762582
Vérification des blocs défectueux (test en mode lecture seule) :
complété
Passe complétée, 5 blocs défectueux repérés.
Il m'a répertorié 5 blocs défectueux. Est-ce qu'il y a quelque chose =
à
faire par la suite ?
Refaire le test en mode écriture non-destructif (des données ;-) ?
Les blocs défectueux sont indexés et ne seront pas utilisé ?
Cordialement,
--
Louis-Philippe Gauthier
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAMzw4gXTNKoSYU6b1WNRUOK_E=Wv&tFzaZZy4=H+m4eOa6aA@mail.gmail.com
J'ai un soucis avec un disque dur USB externe Seagate GoFlex de 1To.
J'ai fait un badlocks en root
# badblocks -v /dev/sdc
Vérification des blocs 0 à 976762582
Vérification des blocs défectueux (test en mode lecture seule) :
complété
Passe complétée, 5 blocs défectueux repérés.
Il m'a répertorié 5 blocs défectueux. Est-ce qu'il y a quelque chose =
à
faire par la suite ?
Refaire le test en mode écriture non-destructif (des données ;-) ?
Les blocs défectueux sont indexés et ne seront pas utilisé ?
Cordialement,
--
Louis-Philippe Gauthier
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAMzw4gXTNKoSYU6b1WNRUOK_E=Wv&tFzaZZy4=H+m4eOa6aA@mail.gmail.com
Louis-Philippe Gauthier
Comme indiqué dans le man, badblocks n'est pas fait pour
être utilisé directement.
5 blocs sur... 976 millions, ça reste correct.
Quel intérêt? À moins que le HD n'ait déjà un cert ain âge.
Ça, c'est ce que se serait passé si badblocks avait été utilisé
conjointement à mkfs.ext2, 3 ou 4; mais je doute qu'un one shot
déclenche les mécanismes de swap des secteurs défectueux, si tant
est qu'il y ait de tels secteurs.
--
<Romain> : J'kiff trop mon frère
<Romain> : Mes parents lui ont parlé de la petite souris vu
qu'il a perdu une dent de lait
<Romain> : Il a "fabriqué" des piege a souris pour la buter
et lui voler toute sa thune...
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Bzzz a écrit :
Si. Mais sur un disque brut, pas sur un système de fichiers.
Non, ce n'est pas correct car les données qu'on a eu le malheur d'écrire
dans ces secteurs sont perdues. Ce qui serait correct, c'est que les
secteurs défectueux aient été automatiquement réalloués par le
contrôleur du disque avant de devenir illisibles.
Si le système de fichier est de type ext2/3/4, il peut être intéressant
de déterminer à quels fichiers ces blocs appartiennent avec debugfs
(commande icheck pour trouver les inodes contenant ces blocs puis ncheck
pour trouver les chemins correspondants à ces inodes).
Il y a moyen d'exécuter smartctl -A sur ce disque ? Ça ne marche pas
toujours sur les disques USB.
L'intérêt de l'écriture est de pousser la réallocation des secteurs
défectueux. Mais je ne sais pas si le mode non destructif écrit
justement dans les secteurs illisibles - il n'a pas réussi à lire le
contenu, que va-t-il y écrire ?
Si le disque est partitionné, ce n'est pas utilisable directement mais
seulement sur une partition contenant un système de fichiers du type
concerné, donc, avec l'option -c de mkfs ou fsck. Si c'est une partition
de swap, mkswap a bien une option -c mais il n'est pas clair si elle ne
fait que vérifier ou si elle met en quarantaine les blocs défectueux
détectés.
Pour forcer la réallocation des secteurs défectueux par le contrôleur
intégré du disque, il faut les détecter (donc essayer de les lire) puis
les écrire. badblocs -w (écriture destructive) le fait, mais cela écrase
tout le contenu, à moins d'utiliser les bornes de début et fin à partir
de la liste des blocs défectueux affichés par l'analyse en lecture seule
(faut pas se louper et écraser les données du bloc d'à côté).
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
LÃ -dessus, je ne connais pas le fonctionnement intime du HD,
est-ce sa propre logique qui réalloue (et si oui, comment,
sur erreurs ed lecture, d'écriture?) ou si la logique en
question ne contient que des routines destinées à être
appelées par un pgm externe.
J'entends bien, mais c'est rarement utile si le HD est "jeune".
En théorie, tant qu'il n'y a pas eu réallocation et/ou marquage
dans la table des secteurs défectueux, il ne tentera d'écrire
que s'il a lu sans erreur. Reste à savoir ce qui se passe en cas
d'erreur: est-ce que le secteur est réalloué/mis en quarantaine?
(j'en doute) ou bien est-ce que juste un averto est émis?
Apparemment non, le temps de formatage entre mkswap -c et mke2fs -c
étant sensiblement différent.
Par contre, ce que j'aimerais bien savoir, c'est si à la suite d'un
mke2fs -c -c on exécute un mkswap, les éventuels secteurs dé fectueux
sont réintégrés comme valides ou non par le mkswap.
'-n' me parait plus approprié, puisqu'il effectue le même test ma is sans
écraser les données.
--
Axel : Ça sert trop a rien de faire des albums pour Haiti...
Axel : Ils ont plus rien pour les écouter de toute façon.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
La plupart des disques neufs ont des secteurs défectueux, il est
préférable de faire un test en lecture / écriture (destructif) avant de
l'utiliser et que ces secteurs soient découverts avant la mise en
production.
Lorsque je reçois des disques, je créer une partition sur l'ensemble du
disque et je fais tourner pendant une journée un script comme :
while (true) do
mkfs.ext2 -ccv /dev/sda1;
done;
Ensuite, je le partionne et le format pour son usage.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Sources ?
Il est AMA totalement anormal qu'un disque neuf montre des secteurs
défectueux.
D'accord. Et s'il y en a, retour en garantie.
Ça ne teste que les blocs appartenant à la partition, qui ne couvre pas
tout le disque.
Je ne vois pas trop l'intérêt de mkfs par rapport à une simple
vérification destructive sur tout le disque avec
badblocks -w -p <passes> /dev/sda
où <passes> est le nombre de passes à effectuer.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Oui.
Les deux. En lecture, il y a deux cas :
- le secteur a pu être lu correctement malgré des erreurs (après
plusieurs tentatives par exemple), alors il est réalloué et son contenu
transféré, il n'y a pas de perte de données donc c'est transparent pour
le système hôte ;
- le secteur n'a pas pu être lu, alors il est marqué pour être réalloué
à la prochaine écriture, mais entendant le secteur est illisible et son
contenu est perdu, avec une erreur de lecture remontée au système hôte.
L'idéal, c'est de rester dans le premier cas. On peut le voir avec
l'augmentation des attributs SMART "reallocated", mais les attributs
"pending" restent à zéro.
Je ne vois pas en quoi l'âge du disque entre en ligne de compte. Un
disque peut avoir des secteurs défectueux à tout âge, ce n'est pas un
signe de vieillissement normal mais un défaut. Pour moi la seule
influence de l'âge c'est si le disque est encore sous garantie et dans
ce cas il faut la faire jouer.
[badblocks]
C'est indiqué où ? Je n'ai rien vu dans la page de manuel de badblocks.
Badblocks ne s'occupe pas de réallocation (c'est le boulot du disque) ni
de mise en quarantaine (c'est le boulot des outils du système de
fichiers comme mkfs ou e2fsck). Il ne fait qu'écrire, lire et signaler
les erreurs.
De quel ordre ? Surt un volume de taille conséquente je m'attendrais à
ce que la phase la plus longue soit celle de la vérification, donc dure
le même temps pour les deux commandes. Et cela ne dit rien sur une
éventuelle mise en quarantaine, ce n'est pas ça qui prend du temps.
Là, il faut bien être précis et savoir de quoi on parle.
Les secteurs réalloués par le disque lors du mkfs -cc seront à nouveau
lisibles donc mkswap ne les verra pas comme défectueux. Par contre la
liste des secteurs détectés comme illisibles par mkfs ou fsck fait
partie des méta-données du système de fichiers, qui sont bien sûr
écrasées et ignorées par mkswap.
A condition que badblocks -n écrive bien dans les secteurs qu'il n'a pas
pu lire au préalable, ce dont je n'ai pas la certitude. Il se pourrait
qu'il signale le bloc défectueux dès l'échec de la lecture préalable et
saute l'opération d'écriture/vérification.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Je n'ai pas suivi depuis très très longtemps cette question, mais à
priori c'est au contraire totalement normal dans la mesure ou une
magnétisation est rarement totalement parfaite sur toute la surface.
La gestion de ces secteurs est un moyen pragmatique d'optimiser les
techniques/coûts/qualité de production et augmenter la fiabilité pour un
impact minime en terme de perte de volume de stockage.
S'il en plus qu'un très petit pourcentage de secteurs défectueux, ce
n'est plus un défaut de magnétisation local, mais un défaut de surface
ou de mécanique donc l'appareil doit de toute manière être éliminé.
En tout cas c'était le cas à une époque.
Par contre il me semble que les contrôleurs modernes gèrent en interne
ces secteurs, a vérifier. Donc ce je ne sais pas si c'est forcément
visible du système, ce qui pourrait donner une image "0 secteurs
défectueux". Ça doit être vérifiable avec plusieurs disques neufs de la
même série, en comparant la capacité exacte en octet.
Dans le même genre, toujours à vérifier, il me semble que les
contrôleurs gèrent l'allocation de l'espace pour des raisons
d'optimisation/compression/cache ce qui donnerait une image virtuelle du
disque au système qui pourrait différer quelque peu de son image
physique. En tout cas il en était question à l'époque de mes souvenirs.
Je pense que ça serait intéressant de voir chez Seagate, voire de leur
poser la question sur cette gestion de secteurs si la doc n'est pas
accessible. Ou peut-être que Google a publié quelque chose autour de ce
sujet ? Ils on un bon recul sur la question des disques ^_^;
Pour les raisons sus-cité, il me semble que ce qui était indispensable
autrefois est probablement moins vrai aujourd'hui. Par contre, le chic
de ce genre d'appareil électronique étant de tomber en panne dans les
premières heures ou longtemps après, faire ce genre de test doit
probablement faire office de "rodage" et éliminer un risque de défaut de
fabrication (qui pourrait aussi être par exemple un défaut de mémoire,
vu la sophistication des contrôleurs).
Lire les conditions de garanties avant...
Il y a aussi des tests spécifiques pour disques, qui me paraissent
beaucoup plus performants avec des phases aléatoires non-séquentielles.
Si on veut faire de vrai tests, mieux vaut certainement mieux secouer un
peu le disque et non le faire travailler dans des conditions
"optimales".
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Je n'ai pas dû être assez clair : en écrivant "montre", je voulais
parler de secteur défectueux visibles par le système hôte, dont la
lecture ou l'écriture provoque une erreur.
Normalement oui, avec les techniques de réallocation. C'est pourquoi ils
ne devraient pas être visibles par le système hôte.
La capacité des disques d'un même modèle est la même. C'est du commerce
donc c'est contractuel.
Il y a belle lurette que la géométrie cylindres/têtes/secteurs présentée
par le contrôleur intégré est virtuelle et n'a strictement rien à voir
avec la géométrie physique réelle qui est cachée, et qui varie selon les
zones du disque. De toute façon cela n'a plus aucune importance avec
l'adressage linéaire (LBA) où on manipule simplement des numéros de
secteurs de 0 à N-1.
En effet. Fait sur un disque de retour de SAV (visiblement réparé et pas
remplacé par un neuf) , celui-ci a cassé après quelques minutes de ce test.
Cela ne teste pas la même chose. Dans un cas on vérifie la surface, dans
l'autre on vérifie la solidité du bras de têtes.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Jérôme
Non, c'est Pascal qui raison: le test de surface fait partie
de la sortie de ligne de fab.
Et c'est logique pour 2 raisons:
* à quel %age le fabricant pourrait-il déterminer le nb de
secteurs hs à la sortie? question facile à répondre si
c'était le cas: un max.
* les utilisateurs, majoritaires, de w$ se retrouveraient
_tous_ rapidement devant une catastrophe, le formatage
de base étant de type 'rapide'.
C'est aussi la raison pour laquelle les prix ne peuvent
descendre en-dessous d'une certaine barre.
--
Sniper'z: Ca doit être nul d'écrire un roman d'épouvante
Sniper'z: Au début t'as peur de la page blanche
Sniper'z: Après t'as peur de la page remplie
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Bonjour,
Est-ce qu'un ordinateur peut envoyer les données trop rapidement au disqu e
dur USB ? Il est en ext3 et il semble y avoir un problème de mise à jou r du
journal ... Je fais des tests de backups avec Bacula sur ce disque...
peut-il y avoir des configurations particulières (tuning) pour "réduire " le
débit ?
Merci,
Le 20 janvier 2013 07:48, Bzzz
--
Louis-Philippe Gauthier
--bcaec54d46bcbb2de804d3bfabb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Bonjour, <div class="im">On Sun, 20 Jan 2013 11:50:13 +0100<br>
Jérôme < <br>
><br>
> Je n'ai pas suivi depuis très très longtemps cette question, m ais à<br>
> priori c'est au contraire totalement normal dans la mesure ou une< br>
> magnétisation est rarement totalement parfaite sur toute la surface. <br>
<br>
</div>Non, c'est Pascal qui raison: le test de surface fait partie<br>
de la sortie de ligne de fab.<br>
<br>
Et c'est logique pour 2 raisons:<br>
<br>
* à quel %age le fabricant pourrait-il déterminer le nb de<br>
secteurs hs à la sortie? question facile à répondre si<br>
c'était le cas: un max.<br>
<br>
* les utilisateurs, majoritaires, de w$ se retrouveraient<br>
_tous_ rapidement devant une catastrophe, le formatage<br>
de base étant de type 'rapide'.<br>
<br>
C'est aussi la raison pour laquelle les prix ne peuvent<br>
descendre en-dessous d'une certaine barre.<br>
<br>
--<br>
Sniper'z: Ca doit être nul d'écrire un roman d'épouvante< br>
Sniper'z: Au début t'as peur de la page blanche<br>
Sniper'z: Après t'as peur de la page remplie<br>
<div class="im"><br>
--<br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe "<br>
vers En cas de soucis, contactez EN ANGLAIS <br>
</blockquote></div><br><br clear="all"><br>-- <br>Louis-Philippe Gauthier <br>
--bcaec54d46bcbb2de804d3bfabb8--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/