Re: Installation de Debian par USB, l’ordinateur se fige
Le 30/11/2018 à 22:28, hamster a écrit :
Le 30/11/2018 à 22:03, Pascal Hambourg a écrit :
En effet, la destination n'est pas un système de fichiers. Par contre la
destination est dans un système de fichiers :
Tu n'as pas l'impression de te contredire dans la même phrase ?
Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle
toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne
contiens pas de contradiction.
Ne pas confondre un fichier spécial de périphérique avec le périphérique
lui-même ou avec un fichier normal. Quand on crée ou écrit dans un
fichier normal comme ton toto, on écrit dans le système de fichiers qui
le contient. Quand on écrit dans un périphérique, on n'écrit pas dans le
système de fichiers qui contient le fichier spécial de périphérique.
Sous unix tout est fichier.
Tout ou presque (pas les interfaces réseau) est traité comme un fichier,
mais tout n'est pas fichier.
Ma phrase
s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.
Je ne vois pas le rapport avec le fait qu'un périphérique bloc n'est pas
dans un système de fichiers.
OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un
système de fichiers, mais il est bien dans un système de fichiers.
Non, c'est le fichier spécial qui est dans le système de fichiers. Pas
le périphérique. Un périphérique bloc est défini par ses nombres majeur
et mineur. Un fichier spécial de périphérique est juste un descripteur
qui contient ces deux numéros, visibles avec ls -l :
$ ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 nov. 30 23:36 /dev/sdb
majeur=8, mineur=16
Si je crée un autre fichier spécial de périphérique bloc contenant les
mêmes nombres avec mknod, c'est un fichier différent (inodes différents,
rien à voir les liens durs qui pointent vers un même inode) mais le même
périphérique.
On peut s'amuser a faire rien que la commande dd. Ca travaille un
moment, puis ca rend le prompt. A ce moment la, on fait a la main la
commande sync, et on voit que de nouveau ca travaille un moment. C'est
le signe qu'il restait des choses a écrire sur la clef dans le cache.
Effectivement ce serait le signe si ça se passait ainsi, mais
justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes
un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute
sync, ça ne clignote pas plus.
Par contre l'écriture n'est pas forcément finie lorsque dd rend la
main. On le voit bien avec le clignotement qui continue. Il y a donc
un cache quelque part, mais distinct de celui sur lequel sync agit.
OK, tu connais mieux que moi les subtilités du fonctionnement d'unix.
Pas besoin de connaître les subtilités. Il me suffit d'observer mon
système et ce que je constate ne colle pas avec ce que tu écris.
Mais je persiste a trouver un avantage a sync : ca permet de savoir
quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce
que meme si le cache concerné n'est pas celui sur lequel agit sync,
cette commande ne rend pas le prompt tant que l'écriture n'est pas
finie, contrairement a dd. A moins que la encore je me trompe ?
Il faut croire. Test effectué à l'instant : la clé continue à clignoter
pendant plusieurs secondes après que sync a rendu la main. Chronométrée
avec time, l'exécution de sync dure environ 0,1 s.
Est-ce que tu as au moins fait l'essai ?
Reply to: