Topic des lève-tôt [partie 12]

GR 34 · Le 18/12/2019, à 13:08

L_d_v_c@ a écrit :

Ce matin l'hôpital en consultation j'ai été reçu par Antoine, Romain, Éric, et Simon.
C'est marrant car les initiales font ARÉS.
ARÈS et ma ville natale sur le bassin d'Arcachon...

Joue au Loto !
Ou pas !

moko138 · Le 18/12/2019, à 13:39

Antoine, d'accord,
Romain, d'accord. Mais où étaient passés
Claudie,
Albert,
Charles,
Hamid,
Omar et
Noémie ?

Quelle est la probabilité pour que ça se produise quand on est né à
Saint-Remy-en-Bouzemont-Saint-Genest-et-Isson, ou à
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch, ou sur la colline de
Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu ?

GR 34 · Le 18/12/2019, à 15:17

moko138 a écrit :

Antoine, d'accord,
Romain, d'accord. Mais où étaient passés
Claudie,
Albert,
Charles,
Hamid,
Omar et
Noémie ?

Quelle est la probabilité pour que ça se produise quand on est né à
Saint-Remy-en-Bouzemont-Saint-Genest-et-Isson, ou à
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch, ou sur la colline de
Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu ?

Plus facile : Y (80190)

Compte supprimé · Le 18/12/2019, à 16:10

moko138 a écrit :

Antoine, d'accord,
Romain, d'accord. Mais où étaient passés
Claudie,
Albert,
Charles,
Hamid,
Omar et
Noémie ?

Quelle est la probabilité pour que ça se produise quand on est né à
Saint-Remy-en-Bouzemont-Saint-Genest-et-Isson, ou à
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch, ou sur la colline de
Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu ?

Compte supprimé · Le 18/12/2019, à 16:22

Wahou ! La réponse de monsieur Christian DELAIR aux 9223 Po de ddrescue…

moi a écrit :

Bonjour Christian !
encore un bogue : ddrescue
> root@LibraZiK2:~# ddrescue --force /dev/zero /dev/sdb GNU ddrescue
> 1.21 Press Ctrl-C to interrupt
ipos: 7243 MB, non-trimmed: 0 B, current rate: 31850 kB/s opos: 7243
MB, non-scraped: 0 B, average
rate: 36956 kB/s non-tried: 9223 PB, errsize: 0 B, run time: 3m 16s
rescued: 7243 MB, errors: 0,
remaining time: n/a percent rescued: 0.00% time since last successful
read: 0s Copying non-tried
blocks... Pass 1 (forwards)|
Ça fait combien de Mo 9223 PB ?
…
… donc ça
m'étonnerait que ce disque SATA contienne
autant. Il doit y avoir un bogue dans la commande *ddrescue*.
++
Ludovic

Christian DELAIR a écrit :

Ludo,
...9223 PB... Je ne pense pas, et je suis même sûr que cela soit un bug
de "ddrescue".
Si tu veux bien, on va profiter ce cette *erreur* pour faire deux
minutes d'arithmétique, d'informatique et un peu de philosophie ;-))
# 1) Arithmétique :
D'abord, 9223 PB est un nombre très très connu des programmeurs, hé
oui, c'est juste notre bon vieux 255 (2^8 -1) à la mode 64 bits !
c'est : 2^63 -1
Si tu veux le vérifier à la mode CLI, tu tapes juste cette simple
commande dans un shell : echo "2^63-1" | bc
J'espère que ta ta machine n'a pas de bug CPU, et elle te donnera donc
ce nombre : 9223372036854775807
Cette valeur est la constante "LLONG_MAX" en C++ et en C (depuis 1999)
# Programmation C/Types de base
https://fr.wikibooks.org/wiki/Programma … es_de_base
# LLONG_MAX
https://www.includehelp.com/cpp-tutoria … ample.aspx

# 2) Informatique :
Ce qui est génial, c'est qu'avec les logiciels libres, tu as la liberté
d'étudier le code, car tu as accès au code source.
Alors, juste pour voir, ramène les sources de "ddrescue" en v1.21 :
http://mirror.ibcp.fr/pub/gnu/ddrescue/ … .21.tar.lz
Regarde le code, et cherche "LLONG_MAX". Tu le retrouveras à différents
endroits dans les sources, par exemple dans : block.cc block.h
ddrescuelog.cc main.cc main_common.cc rational.cc rescuebook.cc
La valeur en bytes de LLONG_MAX est donc de 9223372036854775807
ce qui fait bien 9223 millions de milliards d'octets, soit 9223 PB
C'est effectivement un grand nombre.
"ddrescue" : Sa page man le décrit comme un "data recovery tool" en bon
français : "Un outil de récupération de données".
Cette page indique aussi que "ddrescue" doit être utilisé sous la forme
suivante : ddrescue [options] infile outfile [mapfile]
Donc, dans ta commande : ddrescue --force /dev/zero /dev/sdb
tu as choisi de spécifier : "/dev/zero" comme "infile".
Pourquoi ? je pense le comprendre, on verra à la fin de cet email.
Mais, "ddrescue" est fait pour lire un "disque endommagé" en entrée et
pour y récupérer le maximum de données avant que ce disque ne devienne
totalement illisible.
"ddrescue" N'EST PAS fait pour lire "/dev/zero" en entrée.
# 3) Philosophie
Bien que cela n'ai absolument aucun sens d'utiliser "/dev/zero" comme
"infile" avec "ddrescue" !
Hé bien avec GNU/Linux (ou Unix), tu peux quand même le faire ! à tes
risques et péril, certes, et là, je fais référence à cette citation
assez géniale de "Douglas Gwyn" :
"Unix n'a pas été conçu pour empêcher ses utilisateurs de commettre des
actes stupides, car cela les empêcherait aussi de réaliser des actes
ingénieux." - Douglas Gwyn http://www.azquotes.com/quote/669659
Donc, GNU/Linux ne t'empêche pas de faire des choses stupides !
C'est ainsi, car cela fait partie de la philosophie d'Unix.
Pour une fois qu'un OS nous permet de philosopher, on ne va pas se
plaindre.
# 4) Tentative d'explication :
"/dev/zero" n'est pas un device en mode bloc. C'est un "pseudo device"
spécial qui renvoie le caractère Ascii "NUL" 0x00 lors d'une lecture.
Lorsque "ddrescue" lit le fichier d'entrée "infile" il essaie de
récupérer l'ensemble du *device*.
Mais, problème, dans ton cas : le "infile" c'est "/dev/zero" !
Je ne suis plus assez bon en C pour vérifier cela dans les sources,
mais, je pense que "ddrescue" en lisant "/dev/zero" n'arrive pas à
déterminer la taille du disque (infile) ou bien, il croit que le disque
indique une mauvaise taille (ce qui peut être tout à fait normal sur un
disque endommagé).
Donc si "ddrescue" considère que ce disque est défaillant, dans son
algorithme, il doit sans doute lire le device infile (ici "/dev/zero")
jusqu'à LLONG_MAX (9223 PB). Les systèmes physiques ne sont pas
infinis, il faut bien des limites...
# 5) Ta participation à l'amélioration du logiciel libre
Si tu penses que c'est un bug, ou que ce comportement n'est pas normal,
ou que cela pourrait être modifié ou amélioré, et bien là, tu as un
immense avantage avec le logiciel libre :
Tu as la possibilité d'écrire à l'auteur de "ddrescue" : Antonio Diaz
Diaz. Tu as cet email (Report bugs to bug-ddrescue at gnu.org) en faisant
un : man ddrescue
# 6) Le "Bon outil" pour la "bonne tâche"
Là, je reviens au *pourquoi* tu as utilisé "/dev/zero" avec "ddrescue"
Ludo, sous GNU/Linux/Unix il y a toujours le "bon outil" pour la "bonne
tâche", je crois que tu as simplement dû confondre "ddrescue" avec "dd"
Si tu voulais simplement et rapidement effacer totalement ton disque
dur /dev/sdb, il ne fallait PAS utiliser "ddrescue" qui n'est pas du
tout adapté à cette tâche.
Le bon outil pour cet effacement de disque dur, c'est la l'outil "dd"
en utilisant des gros blocs de 32M ou même plus, comme dans cet exemple
dd if=/dev/zero of=/dev/sdb bs=32M
Amicalement,
A+

Depuis le temps que je dis que je ne suis pas informaticien ! Je ne connaissais pas 9223372036854775807 (=2^63-1) !

Dernière modification par Compte supprimé (Le 18/12/2019, à 16:30)

PPdM · Le 18/12/2019, à 17:54

Mais cela confirme ce que je te disais plus haut ton disque est agonisant !

moko138 · Le 18/12/2019, à 18:43

Ludovic,
Merci d'avoir partagé cette réponse enrichissante !

PPdM,
En quoi ?
Si j'ai bien compris les explications de Ch. Delair, ddrescue, en lisant en boucle /dev/zero jusqu'à plus soif, n'est même pas arrivé à /dev/sdb. Donc son retour ne dit rien de sdb. Je me trompe ?

PPdM · Le 18/12/2019, à 18:58

Si j'ai bien compris DDrescue lit a l'infini le disque ce qui n'est pas possible

Donc si "ddrescue" considère que ce disque est défaillant, dans son
algorithme, il doit sans doute lire le device infile (ici "/dev/zero")
jusqu'à LLONG_MAX (9223 PB). Les systèmes physiques ne sont pas
infinis, il faut bien des limites...

donc on en revient à

non-tried:    9223 PB,     errsize:        0 B,      run time:      3m 16s

disque en fin de vie, j'en ai déja eut comme ça, j'ai cru les récupérer, mais il sont repartis en couilles dès que j'y ai mis un OS, le seul truc a faire mais c'est au pif, trouver la zone morte (si c'est un souci de surface, si c'est électronique c'est mort), et faire une partition avant et après en laissant la zone HS vide, mais vu le prix des disques aujourd'hui c'est prendre des risques pour rien, si Ludo a besoin de disque mel moi!

Dernière modification par PPdM (Le 18/12/2019, à 19:00)

moko138 · Le 18/12/2019, à 19:26

Ch. Delair a écrit :

il doit sans doute lire le device infile (ici "/dev/zero")

Ce n'est pas le disque sdb qu'il lit !

4) Tentative d'explication :
"/dev/zero" n'est pas un device en mode bloc. C'est un "pseudo device"
spécial qui renvoie le caractère Ascii "NUL" 0x00 lors d'une lecture.

Compte supprimé · Le 18/12/2019, à 21:16

Bonsoir.
La commande ddrescue /dev/zero /dev/sdb s'est bien finie au bout de 2h40.
J'étais juste étonné que ddrescue ne calcule pas la place restante dans /dev/sdb mais il a affiché pratiquement 298Gio je crois, c'est à dire la taille du disque donc il n'a pas bouclé à l'infinie.

Compte supprimé · Le 18/12/2019, à 21:18

ddrescue me donne un indicateur d'avancement que je ne sais pas faire avec dd.

moko138 · Le 18/12/2019, à 22:43

L_d_v_c@,
Pour un indicateur d'avancement, vois dcfldd

Compte supprimé · Le 18/12/2019, à 23:04

moko138 a écrit :

L_d_v_c@,
Pour un indicateur d'avancement, vois dcfldd

Merci moko138.

https://doc.ubuntu-fr.org/dcfldd

moko138 · Le 19/12/2019, à 05:08

Bonjour à tous !

F50 · Le 19/12/2019, à 07:42

Hola

Compte supprimé · Le 19/12/2019, à 10:59

Bonjour à tous !

NB por moko138 : Quand je lis des commandes inhumaines mais utiles comme dcfldd, j'ai l'impression de devoir apprendre l'orthographe de Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch…

Compte supprimé · Le 19/12/2019, à 11:29

J'aime bien ces deux commandes pour faire du ménage dans mes disques avant reformatage (pour simplifier l'arborescence en vue de sauvegardes) :

root@LibraZiK2:/media/ludovic# find . -empty -type f -delete #efface les fichiers de taille nulle
root@LibraZiK2:/media/ludovic# find . -empty -type d -delete #efface les répertoires vides
root@LibraZiK2:/media/ludovic# #ceci est le path de mes disques externes

Compte supprimé · Le 19/12/2019, à 12:05

En fait mes sauvegardes sont faites mais avant de formater chaque disque, je compare l'intégrité de chaque copie puisque GNU/Linux semble écrire sans relire ce qu'il vient d'écrire ! Un comble !

Autrefois, toutes les commandes d'écritures telles que copies relisaient l'écriture et vérifiait la nouvelle écriture avec ce que c'était censé être.
C'était 2 fois plus lent (cycle écriture-relecture-comparaison) mais c'était 100% sécurisé et permettait de détecter des erreurs de disques par exemple.

C'est *peut-être* par ce mécanisme que le sous-programme bad-block récupérait les blocs défectueux des disques et les ajoutait automatiquement dans la BBL (la bad-block-list).

Mais d'après ce document User’s Guide Amiga Hard Drive l'initialisation de la bad-block-list était manuelle…

Je ne me souvenait que de la réparation automatique : lorsque l'ordinateur trouvait un mauvais bloc et l'insérer automatiquement dans la bad-block-list et remplaçait le bloc défectueux par un bloc de réserve (ce qui fragmentait physiquement le disque sans le fragmenter logiquement, et pouvait faire perdre de la vitesse de lecture s'il y avait trop de blocs remplacés par les blocs de réserve).

moko138 · Le 19/12/2019, à 12:05

[HS] Ludovic,
J'ai retrouvé la carte microSD de 8 Go !
(Je m'en étais servi pour graver une iso de Xubuntu avec persistance).
[/HS]

Compte supprimé · Le 19/12/2019, à 12:08

moko138 a écrit :

[HS] Ludovic,
J'ai retrouvé la carte microSD de 8 Go !
(Je m'en étais servi pour graver une iso de Xubuntu avec persistance).
[/HS]

Je te conseille :
Ubuntu MATE for the Raspberry Pi Model B 2, 3 and 3+
https://ubuntu-mate.org/raspberry-pi/

La bonne archive pour le RPi2 et son sha256sum :
https://ubuntu-mate.org/raspberry-pi/ub … xt4.img.xz

Download Size 1.2 GB
SHA256SUM Checksum bb74b607da2f4d417851e006fadd5de1304f84681db9c4bd8f17ff1b1d410995

https://ubuntu-mate.org/how-to-verify-downloads/

Compte supprimé · Le 19/12/2019, à 12:36

moko138, j'ai mesuré la consommation électrique du Raspberry Pi 2B (à la prise secteur) entre 1,9 watt ±5% et 4,3 watts +5% selon l'utilisation processeur quad-core.

Dernière modification par Compte supprimé (Le 19/12/2019, à 13:06)

moko138 · Le 19/12/2019, à 12:37

Merci !

rogn... · Le 19/12/2019, à 13:55

L_d_v_c@ a écrit :

J'aime bien ces deux commandes pour faire du ménage dans mes disques avant reformatage (pour simplifier l'arborescence en vue de sauvegardes) :
root@LibraZiK2:/media/ludovic# find . -empty -type f -delete #efface les fichiers de taille nulle
root@LibraZiK2:/media/ludovic# find . -empty -type d -delete #efface les répertoires vides
root@LibraZiK2:/media/ludovic# #ceci est le path de mes disques externes

S'tun peu dangereux, tu risques par exemple fiche en l'air l'écriture de logs.

Compte supprimé · Le 19/12/2019, à 15:16

rogn... a écrit :

L_d_v_c@ a écrit :
J'aime bien ces deux commandes pour faire du ménage dans mes disques avant reformatage (pour simplifier l'arborescence en vue de sauvegardes) :
root@LibraZiK2:/media/ludovic# find . -empty -type f -delete #efface les fichiers de taille nulle
root@LibraZiK2:/media/ludovic# find . -empty -type d -delete #efface les répertoires vides
root@LibraZiK2:/media/ludovic# #ceci est le path de mes disques externes
S'tun peu dangereux, tu risques par exemple fiche en l'air l'écriture de logs.

Salut rogn…
1) Je ne fais ça que sur mes unités externes.
2) Parfois les fichiers vides (tailles 0 octets) me gênent dans le décompte des fichiers à vérifier. Puis même un log de 0 octet doit pouvoir s'effacer sans gravité. Non ? contre-exemple ?

Dernière modification par Compte supprimé (Le 19/12/2019, à 15:20)

rogn... · Le 19/12/2019, à 16:17

Le problème est que bien des programmes travaillent avec des dossiers vides pour y caler par exemple des fichiers logs, des fichiers en sortie (conversion vidéo par ex), etc... Si tu supprimes ces dossiers vides, les programmes travaillant avec seront paumés. Certains les recréent automatiquement, d'autres non.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#8626 Le 18/12/2019, à 13:08

Re : Topic des lève-tôt [partie 12]

#8627 Le 18/12/2019, à 13:39

Re : Topic des lève-tôt [partie 12]

#8628 Le 18/12/2019, à 15:17

Re : Topic des lève-tôt [partie 12]

#8629 Le 18/12/2019, à 16:10

Re : Topic des lève-tôt [partie 12]

#8630 Le 18/12/2019, à 16:22

Re : Topic des lève-tôt [partie 12]

#8631 Le 18/12/2019, à 17:54

Re : Topic des lève-tôt [partie 12]

#8632 Le 18/12/2019, à 18:43

Re : Topic des lève-tôt [partie 12]

#8633 Le 18/12/2019, à 18:58

Re : Topic des lève-tôt [partie 12]

#8634 Le 18/12/2019, à 19:26

Re : Topic des lève-tôt [partie 12]

#8635 Le 18/12/2019, à 21:16

Re : Topic des lève-tôt [partie 12]

#8636 Le 18/12/2019, à 21:18

Re : Topic des lève-tôt [partie 12]

#8637 Le 18/12/2019, à 22:43

Re : Topic des lève-tôt [partie 12]

#8638 Le 18/12/2019, à 23:04

Re : Topic des lève-tôt [partie 12]

#8639 Le 19/12/2019, à 05:08

Re : Topic des lève-tôt [partie 12]

#8640 Le 19/12/2019, à 07:42

Re : Topic des lève-tôt [partie 12]

#8641 Le 19/12/2019, à 10:59

Re : Topic des lève-tôt [partie 12]

#8642 Le 19/12/2019, à 11:29

Re : Topic des lève-tôt [partie 12]

#8643 Le 19/12/2019, à 12:05

Re : Topic des lève-tôt [partie 12]

#8644 Le 19/12/2019, à 12:05

Re : Topic des lève-tôt [partie 12]

#8645 Le 19/12/2019, à 12:08

Re : Topic des lève-tôt [partie 12]

#8646 Le 19/12/2019, à 12:36

Re : Topic des lève-tôt [partie 12]

#8647 Le 19/12/2019, à 12:37

Re : Topic des lève-tôt [partie 12]

#8648 Le 19/12/2019, à 13:55

Re : Topic des lève-tôt [partie 12]

#8649 Le 19/12/2019, à 15:16

Re : Topic des lève-tôt [partie 12]

#8650 Le 19/12/2019, à 16:17

Re : Topic des lève-tôt [partie 12]

Pied de page des forums