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.
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.
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.
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.
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.
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 04-08-2010, Th.A.C 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
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
Le 04-08-2010, Th.A.C 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
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.
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.
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.
On Thu, 05 Aug 2010 13:55:16 +0200, Pascal Hambourg
: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 ?
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 ?
On Thu, 05 Aug 2010 13:55:16 +0200, Pascal Hambourg
: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 :
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.
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.
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 ?
Normalement, le smart s'en occupe. Le disque a des secteurs de réserve.
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.
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 ?
Normalement, le smart s'en occupe. Le disque a des secteurs de réserve.
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.
> 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.
> 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.
> 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.
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.
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.
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.
dmsetup create <device_name> --table 0 <blocks> linear /dev/sdb <offset>
Le contenu est accessible via /dev/device-mapper/<device_name>
dmsetup create <device_name> --table 0 <blocks> linear /dev/sdb <offset>
Le contenu est accessible via /dev/device-mapper/<device_name>
dmsetup create <device_name> --table 0 <blocks> linear /dev/sdb <offset>
Le contenu est accessible via /dev/device-mapper/<device_name>
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.
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.
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.
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.
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.
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.