specifier une zone d'un disque pour travailler dessus

Le 04-08-2010, Th.A.C <aenleverraivac@free.fr.invalid> a écrit :

Je cherche un moyen de découper un disque (ou de spécifier une zone)
pour pouvoir passer des utilitaires (dd, badblocks, shred, ...) sur
cette zone.

Je ne vois pas trop l'utilité, mais bon.

par exemple, faire un bablocks sur les 10 premiers giga ou du 51eme au
100eme giga du disque.
Avec dd, on peut spécifier un nombre de blocs a sauter, mais rien avec
les autres.

J'utiliserai losetup qui a une option pour sauter à un certain offset.
losetup -o (X Giga) /dev/sda
Puis un
shred /dev/loop0 ou badblocks /dev/loop0
--
Kevin

Salut,

Kevin Denis a écrit :

Le 04-08-2010, Th.A.C <aenleverraivac@free.fr.invalid> a écrit :

Je cherche un moyen de découper un disque (ou de spécifier une zone)
pour pouvoir passer des utilitaires (dd, badblocks, shred, ...) sur
cette zone.

Je ne vois pas trop l'utilité, mais bon.

Un exemple a été fourni juste après :

par exemple, faire un bablocks sur les 10 premiers giga ou du 51eme au
100eme giga du disque.
Avec dd, on peut spécifier un nombre de blocs a sauter, mais rien avec
les autres.

Le but, c'est de ne pas perdre de temps à passer tout le disque pour ne
vérifier/réparer qu'une zone bien délimitée qu'on sait contenir des
blocs suspects. J'ai eu le même souci. C'est long.

J'utiliserai losetup qui a une option pour sauter à un certain offset.
losetup -o (X Giga) /dev/sda

Apparemment losetup ne permet pas de spécifier de taille, donc on se
tape toute la fin du disque à partir de l'offset. Pas très intéressant
si c'est près du début.

Peut-être du côté du device mapper (dmsetup), avec quelque chose du
genre (unité = secteur de 512 octets) :

dmsetup create <device_name> --table 0 <blocks> linear /dev/sdb <offset>

Le contenu est accessible via /dev/device-mapper/<device_name>

Je décline toute responsabilité en cas de perte de données à cause de
cette commande.

On Thu, 05 Aug 2010 13:55:16 +0200, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org>:

Le but, c'est de ne pas perdre de temps à passer tout le disque pour ne
vérifier/réparer qu'une zone bien délimitée qu'on sait contenir des
blocs suspects.

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Le 06/08/2010 18:18, Fabien LE LEZ a écrit :

On Thu, 05 Aug 2010 13:55:16 +0200, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org>:

Le but, c'est de ne pas perdre de temps à passer tout le disque pour ne
vérifier/réparer qu'une zone bien délimitée qu'on sait contenir des
blocs suspects.

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Normalement, le smart s'en occupe. Le disque a des secteurs de réserve.

Après, j'ai 2 disques avec chacun une zone bien délimitée qui est
inutilisable. Dans les 2 cas, ca se situe dans les 5 premiers giga.
J'ai donc créé une partition bidon qui permet de neutraliser cette zone.
Le reste du disque semble nickel et le smart n'est pas inquiétant.


Sinon, en lien avec la fin de mon premier message (logiciel pour voir le
taux de transfert sur une zone), l'avantage d'outils comme dd ou
badblock, c'est d'arriver quelques fois (pas toujours malheureusement),
à 'redresser' la courbe du taux de transfert.

Pour vérifier l'état d'un disque, je regarde déja le smart et je
complète toujours par un test du taux de transfert sur toute la surface
du disque.
On voit immédiatement, si des zones présentent des faiblesses (le taux
de transfert s'effondre immédiatement). Ces faiblesses ne sont pas
détectées (la plupart du temps) par le smart.
On voit aussi immédiatement si la courbe n'est pas plate et régulière.

Avec dd et badblocks, j'arrive quelques fois à redresser/aplatir cette
courbe de taux de transfert.

Sinon, j'ai pas encore pu tester les idées de Kevin et Pascal, mais ca
va venir. Merci à tous les 2.

Th.A.C a écrit :

Le 06/08/2010 18:18, Fabien LE LEZ a écrit :

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Dans un usage professionnel, certes, ça ne vaut pas le coup (ni le coût)
de perdre du temps là-dessus. On remplace et on jette. Mais à titre
personnel, ça peut être intéressant. J'ai "sauvé" à grands coups de
cycles de lecture/écriture plusieurs disques récupérés avec un certain
nombre de secteurs en piteux état qui fonctionnent sans souci depuis.

Normalement, le smart s'en occupe. Le disque a des secteurs de réserve.

Oui, mais le contrôleur n'arrive pas toujours à identifier les secteurs
douteux et à les réparer ou réallouer de façon transparente. Il faut
parfois l'aider un peu.

Sinon, en lien avec la fin de mon premier message (logiciel pour voir le
taux de transfert sur une zone), l'avantage d'outils comme dd ou
badblock, c'est d'arriver quelques fois (pas toujours malheureusement),
à 'redresser' la courbe du taux de transfert.

Quand on demande à lire un secteur défaillant, des erreurs de lecture se
produisent et le contrôleur intégré doit faire plusieurs tentatives de
lecture avant d'y parvenir éventuellement ; ça prend du temps et ça fait
chuter le débit effectif. Ensuite quand on demande à écrire sur ce
secteur, il peut se passer deux choses :
- le secteur est laissé sur place et la réécriture le renforce, il
devient donc facile à lire et le débit redevient normal ;
- l'emplacement est trop endommagé et le secteur est réalloué dans un
secteur de réserve situé ailleurs ; lors d'un accès séquentiel
ultérieur, il faudra donc que la tête de lecture fasse un crochet pour
accéder à ce secteur et ça fait chuter le debit effectif.

On Sat, 07 Aug 2010 00:30:54 +0200
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

> Normalement, le smart s'en occupe. Le disque a des secteurs de réserve.

Oui, mais le contrôleur n'arrive pas toujours à identifier les secteurs
douteux et à les réparer ou réallouer de façon transparente. Il faut
parfois l'aider un peu.

1. Je ne savais pas que le mode S.M.A.R.T pouvait être activé en
fonctionnement normal (perte importance de performance). Une fois le
diagnostic établi et le disque reformaté en fonction des secteurs
deffectueux, est-ce qu'il ne convient pas de désactiver le S.M.A.R.T ?
2. Mode S.M.A.R.T => CM smart compatible, disque smart compatible; BIOS
et OS smart compatible, non ? et on n'a pas toujours tout ça réuni
(pour l'OS et le bios ça doit pouvoir s'arranger, mais pas pour le
disque et la CM)

(suivi sur fcs.pc)

--
attend je suis pas un r3b3lz moi
juste un type ss cervo
-+- underfog in GPJ: C'est lamer qui prends l'homme -+-

Le 07/08/2010 00:30, Pascal Hambourg a écrit :

Quand on demande à lire un secteur défaillant, des erreurs de lecture se
produisent et le contrôleur intégré doit faire plusieurs tentatives de
lecture avant d'y parvenir éventuellement ; ça prend du temps et ça fait
chuter le débit effectif. Ensuite quand on demande à écrire sur ce
secteur, il peut se passer deux choses :
- le secteur est laissé sur place et la réécriture le renforce, il
devient donc facile à lire et le débit redevient normal ;

je me suis également demandé si le fait d'écrire un nombre conséquent de
secteurs en une seule fois ne permettrait pas de rééquilibrer les
secteurs, c'est à dire de les repositionner petit à petit de facon plus
régulière et par conséquence faire pareil pour la zone tampon qui se
trouve entre chaque secteur?

- l'emplacement est trop endommagé et le secteur est réalloué dans un
secteur de réserve situé ailleurs ; lors d'un accès séquentiel
ultérieur, il faudra donc que la tête de lecture fasse un crochet pour
accéder à ce secteur et ça fait chuter le debit effectif.

je pensait plutot à des chutes très importantes qui sont plutot dues à
des difficultés de lecture (le disque doit certainement repositionner sa
tête et tenter une autre lecture ou bien il n'arrive pas à lire une
piste entière en une seule fois et met donc plusieurs tours au lieu d'un
seul).
J'ai quelques disques ou j'ai 'vu' la réallocation de secteurs se faire,
mais la chute de débit était très modérée (moins de 20%)

Sur les vieux disques (idem pour les disquettes), on avait quelques fois
un entralacement des secteurs pour laisser à l'électronique (ou au
système...) le temps de lire/écrire.
Je suppose qu'aujourd'hui ca n'existe plus, mais comme les disques
actuels sont devenus des boites noires... :-)

Comme j'ai très brièvement testé, trois petites précisions/corrections.

dmsetup create <device_name> --table 0 <blocks> linear /dev/sdb <offset>

Le contenu est accessible via /dev/device-mapper/<device_name>

1) Il y a une erreur dans la page de manuel, les périphériques créés
sont en fait dans /dev/mapper/ et non /dev/device-mapper/.

2) L'option --table n'est disponible qu'à partir de la version 1.02.09.
Pour les versions antérieures (comme celle de Debian etch), il faut
spécifier la table soit dans un fichier soit sur l'entrée standard, par
exemple :

echo 0 <blocks> linear /dev/sdb <offset> > dmsetup create <device_name>

3) badblocks a une taille de bloc par défaut de 1 Kio alors que dd a une
taille par défaut de 512 octets (qui peut occasionner une vitesse de
transfert sensiblement plus faible qu'avec les tailles supérieures) et
dmsetup une taille fixe de 512 octets. Attention à la conversion si par
exemple on utilise les numéros de blocs en erreur en sortie de badblocks
pour définir la zone à utiliser avec dmsetup.

Pascal Hambourg a écrit :

Comme j'ai très brièvement testé, trois petites précisions/corrections.

Une de plus...

dmsetup create <device_name> --table 0 <blocks> linear /dev/sdb <offset>

Il faut des guillements autour des paramètres de la table, sinon il
n'est pas content :

dmsetup create <device_name> --table "0 <blocks> linear /dev/sdb <offset>"

Le contenu est accessible via /dev/device-mapper/<device_name>

1) Il y a une erreur dans la page de manuel, les périphériques créés
sont en fait dans /dev/mapper/ et non /dev/device-mapper/.

2) L'option --table n'est disponible qu'à partir de la version 1.02.09.
Pour les versions antérieures (comme celle de Debian etch), il faut
spécifier la table soit dans un fichier soit sur l'entrée standard, par
exemple :

echo 0 <blocks> linear /dev/sdb <offset> > dmsetup create <device_name>

3) badblocks a une taille de bloc par défaut de 1 Kio alors que dd a une
taille par défaut de 512 octets (qui peut occasionner une vitesse de
transfert sensiblement plus faible qu'avec les tailles supérieures) et
dmsetup une taille fixe de 512 octets. Attention à la conversion si par
exemple on utilise les numéros de blocs en erreur en sortie de badblocks
pour définir la zone à utiliser avec dmsetup.

Pascal Hambourg a fait rien qu'à écrire:

Th.A.C a écrit :

Le 06/08/2010 18:18, Fabien LE LEZ a écrit :

Si un bloc est suspect, n'est-ce pas une raison suffisante pour
changer le disque immédiatement ?

Dans un usage professionnel, certes, ça ne vaut pas le coup (ni le coût)
de perdre du temps là-dessus. On remplace et on jette. Mais à titre

Ouaip.. Mais quel gachis. "Ca formate pas ? Ca installe pas ? Tu jettes."

personnel, ça peut être intéressant. J'ai "sauvé" à grands coups de
cycles de lecture/écriture plusieurs disques récupérés avec un certain
nombre de secteurs en piteux état qui fonctionnent sans souci depuis.

(depuis) combien de temps ? Je suis toujours parti du principe (peut-être
à tort) qu'un disk qui commençait de battre de l'aile, ça présageait rien
de bon sur son avenir (et donc pas de remise en exploit').

Normalement, le smart s'en occupe. Le disque a des secteurs de réserve.

Oui, mais le contrôleur n'arrive pas toujours à identifier les secteurs
douteux et à les réparer ou réallouer de façon transparente. Il faut

Quand le kernel dit "read|seek error at LBA sector 0123456789",
c'est donc pas plus fiable / exact que ça ?

parfois l'aider un peu.

Ah:
Est-ce que tu peux détailler la manip.. smartmontools, hdparm, outil maison ?
Petits-doigts-musclés + feeling ?

Et aussi, est-ce que ça marche si tu montes le disk avec un adaptateur USB..
Je suis pas sûr d'avoir bien capté la page de man.

Sinon, en lien avec la fin de mon premier message (logiciel pour voir le
taux de transfert sur une zone), l'avantage d'outils comme dd ou
badblock, c'est d'arriver quelques fois (pas toujours malheureusement),
à 'redresser' la courbe du taux de transfert.

Quand on demande à lire un secteur défaillant, des erreurs de lecture se
produisent et le contrôleur intégré doit faire plusieurs tentatives de
lecture avant d'y parvenir éventuellement ; ça prend du temps et ça fait

Ouaip.. Si c'est comme les diskettes, je suppose que la tête vient se
recalibrer sur le cylindre 0, au moins 3x, d'où le bruit caractéristique
à toute bonne oreille de geek (tac-tac-tac..;)

chuter le débit effectif. Ensuite quand on demande à écrire sur ce
secteur, il peut se passer deux choses :
- le secteur est laissé sur place et la réécriture le renforce, il
devient donc facile à lire et le débit redevient normal ;
- l'emplacement est trop endommagé et le secteur est réalloué dans un
secteur de réserve situé ailleurs ;

Ca, tu le vois en demandant le log du S.M.A.R.T du périph ?..

lors d'un accès séquentiel
ultérieur, il faudra donc que la tête de lecture fasse un crochet pour
accéder à ce secteur et ça fait chuter le debit effectif.

La mesure du temps de lecture est suffisement précise pour en déduire que
le secteur a été relogé, ou c'est juste une indication que quelque chose
s'est passé dans le coin ?

Dans le 1er cas, faut-il tenir soigneusement compte de la géométrie du disk
(et laquelle, celle du bios, ou la "vraie" ?), combien de secteurs faut-il
pour établir une bonne moyenne de temps de lecture, faut-il faire ça par
piste / cylindre, la vitesse du vent & la température influent-elles..


--
christophe.