1) Une clé USB vendue pour disposer de XX Mo de capacité (64 Mo par exemple)
n'en a en fait que XX-2 de disponibles(62 par exemple). 2 Mo sont réservés
pour des programmes et/ou des fichiers cachés. Qui les connait? Et qui sait
comment y accéder?
2) Quelle est dans le détail la séquence d'opérations lancées lors d'un
branchement d'une clé USB alors que l'OS est lancé?
1) Une clé USB vendue pour disposer de XX Mo de capacité (64 Mo par exemple) n'en a en fait que XX-2 de disponibles(62 par exemple). 2 Mo sont réservés pour des programmes et/ou des fichiers cachés. Qui les connait? Et qui sait comment y accéder?
C'est le système de fichiers. Le système de fichier est une sorte de base de donnée qui gère l'endroit où sont les fichiers, il est donc indispensable. On le modifie avec les commandes genre mkreiserfs, mkext2, ... et autres utilitaires semblables. A utiliser avec précaution.
2) Quelle est dans le détail la séquence d'opérations lancées lors d'un branchement d'une clé USB alors que l'OS est lancé?
Ça charge le module usb-storage, qui dit au système que la clé est une unité de stockage comme un disque. Ensuite ça marche comme pour un disque, il faut le monter, etc. Pour le détail voir les fichiers sources de linux (dans le répertoire drivers/usb).
-- Richard
Salut à tous
1) Une clé USB vendue pour disposer de XX Mo de capacité (64 Mo par exemple)
n'en a en fait que XX-2 de disponibles(62 par exemple). 2 Mo sont réservés
pour des programmes et/ou des fichiers cachés. Qui les connait? Et qui sait
comment y accéder?
C'est le système de fichiers. Le système de fichier est une sorte de
base de donnée qui gère l'endroit où sont les fichiers, il est donc
indispensable. On le modifie avec les commandes genre mkreiserfs,
mkext2, ... et autres utilitaires semblables. A utiliser avec précaution.
2) Quelle est dans le détail la séquence d'opérations lancées lors d'un
branchement d'une clé USB alors que l'OS est lancé?
Ça charge le module usb-storage, qui dit au système que la clé est une
unité de stockage comme un disque. Ensuite ça marche comme pour un
disque, il faut le monter, etc.
Pour le détail voir les fichiers sources de linux (dans le répertoire
drivers/usb).
1) Une clé USB vendue pour disposer de XX Mo de capacité (64 Mo par exemple) n'en a en fait que XX-2 de disponibles(62 par exemple). 2 Mo sont réservés pour des programmes et/ou des fichiers cachés. Qui les connait? Et qui sait comment y accéder?
C'est le système de fichiers. Le système de fichier est une sorte de base de donnée qui gère l'endroit où sont les fichiers, il est donc indispensable. On le modifie avec les commandes genre mkreiserfs, mkext2, ... et autres utilitaires semblables. A utiliser avec précaution.
2) Quelle est dans le détail la séquence d'opérations lancées lors d'un branchement d'une clé USB alors que l'OS est lancé?
Ça charge le module usb-storage, qui dit au système que la clé est une unité de stockage comme un disque. Ensuite ça marche comme pour un disque, il faut le monter, etc. Pour le détail voir les fichiers sources de linux (dans le répertoire drivers/usb).
-- Richard
george
"mlbusb" , dans le message <bu71v2$8sb$, a écrit :
1) Une clé USB vendue pour disposer de XX Mo de capacité (64 Mo par exemple) n'en a en fait que XX-2 de disponibles(62 par exemple). 2 Mo sont réservés pour des programmes et/ou des fichiers cachés. Qui les connait? Et qui sait comment y accéder?
C'est faux. Une clef USB vendue comme x Mo va réellement faire x Mo, parfois avec une acception un peu large de « Mo » : parfois ils feront 1000 ko au lieu de 1024. À cette petite excroquerie près, la clef fait exactement la taille annoncée.
Le fait qu'on y voie moins que ça de place libre annoncée tient au fait qu'il est nécessaire de maintenir des structures de données pour organiser les fichiers. Typiquement, la clef est au format FAT, elle a donc déjà une table de 65536×2 octets pour indiquer quels bloc sont utilisés par quel fichier et quels blocs sont libres. Pour permettre la récupération en cas d'erreur, cette table est présente plusieurs fois. Il faut aussi un peu de place pour les noms des fichiers.
Au total, sur l'exemple que j'ai sous les yeux, je vois 544 ko perdus, ce qui est un peu beaucoup, mais un examen plus attentif m'indique que je perds aussi 272 ko parce que le vendeur a éprouvé le besoin de partitionner la clef, ceux-là je vais les récupérer en supprimant la table des partitions. Voilà, c'est fait, je perds au total 65536×2×2 octets pour les deux exemplaires de la FAT, et 12 ko pour les données globales (liste des fichiers dans la racine et taille du filesystem).
Il est possible d'utiliser la totalité de la clef, mais dans ce cas on ne peut la considérer que comme _un_ fichier dont la taille est exactement toute la clef. Toute structure est à mettre en plus. Pour ça on passe par le périphérique bloc directement (/dev/scsi/host*/bus0/target0/lun0/disc). Mais ce n'est probablement pas une bonne idée.
En tout cas il n'y a absolument aucun fichier caché.
2) Quelle est dans le détail la séquence d'opérations lancées lors d'un branchement d'une clé USB alors que l'OS est lancé?
Ça dépend énormément de la configuration. Si l'OS n'a pas les modules pour l'USB chargés, il ne se passe strictement rien. Si le module pour l'USB est chargé, le noyau va recevoir une IRQ, scanner le bus, et voir un nouveau périphérique. Si le module usb-storage est chargé, le noyau va détecter que c'est lui qui est concerné et lui passer la main. Le module usb-storage va alors enregistrer le nouveau block device dans les structures du noyau. Si le noyau utilise devfs ou udev, il va alors envoyer un message (via /dev/.devfsd pour devfs, et je ne sais pas pour udev) au démon concerné, qui va réagir comme indiqué dans sa config (cf. /etc/devfs/devfsd.conf pour devfs). Si ni devfs ni udev n'est utilisé, il se peut que le noyau invoque directement /sbin/hotplug, mais ça je n'ai jamais utilisé (en fait c'est peut-être comme ça que fonctionne udev).
Juste une question : c'était quoi le débat ?
"mlbusb" , dans le message <bu71v2$8sb$1@news-reader5.wanadoo.fr>, a
écrit :
1) Une clé USB vendue pour disposer de XX Mo de capacité (64 Mo par exemple)
n'en a en fait que XX-2 de disponibles(62 par exemple). 2 Mo sont réservés
pour des programmes et/ou des fichiers cachés. Qui les connait? Et qui sait
comment y accéder?
C'est faux. Une clef USB vendue comme x Mo va réellement faire x Mo,
parfois avec une acception un peu large de « Mo » : parfois ils
feront 1000 ko au lieu de 1024. À cette petite excroquerie près, la
clef fait exactement la taille annoncée.
Le fait qu'on y voie moins que ça de place libre annoncée tient au fait
qu'il est nécessaire de maintenir des structures de données pour
organiser les fichiers. Typiquement, la clef est au format FAT, elle a
donc déjà une table de 65536×2 octets pour indiquer quels bloc sont
utilisés par quel fichier et quels blocs sont libres. Pour permettre la
récupération en cas d'erreur, cette table est présente plusieurs fois.
Il faut aussi un peu de place pour les noms des fichiers.
Au total, sur l'exemple que j'ai sous les yeux, je vois 544 ko perdus,
ce qui est un peu beaucoup, mais un examen plus attentif m'indique que
je perds aussi 272 ko parce que le vendeur a éprouvé le besoin de
partitionner la clef, ceux-là je vais les récupérer en supprimant la
table des partitions. Voilà, c'est fait, je perds au total
65536×2×2 octets pour les deux exemplaires de la FAT, et 12 ko pour
les données globales (liste des fichiers dans la racine et taille du
filesystem).
Il est possible d'utiliser la totalité de la clef, mais dans ce cas on
ne peut la considérer que comme _un_ fichier dont la taille est
exactement toute la clef. Toute structure est à mettre en plus. Pour ça
on passe par le périphérique bloc directement
(/dev/scsi/host*/bus0/target0/lun0/disc). Mais ce n'est probablement pas
une bonne idée.
En tout cas il n'y a absolument aucun fichier caché.
2) Quelle est dans le détail la séquence d'opérations lancées lors d'un
branchement d'une clé USB alors que l'OS est lancé?
Ça dépend énormément de la configuration. Si l'OS n'a pas les modules
pour l'USB chargés, il ne se passe strictement rien. Si le module pour
l'USB est chargé, le noyau va recevoir une IRQ, scanner le bus, et voir
un nouveau périphérique. Si le module usb-storage est chargé, le noyau
va détecter que c'est lui qui est concerné et lui passer la main. Le
module usb-storage va alors enregistrer le nouveau block device dans les
structures du noyau. Si le noyau utilise devfs ou udev, il va alors
envoyer un message (via /dev/.devfsd pour devfs, et je ne sais pas pour
udev) au démon concerné, qui va réagir comme indiqué dans sa config (cf.
/etc/devfs/devfsd.conf pour devfs). Si ni devfs ni udev n'est utilisé,
il se peut que le noyau invoque directement /sbin/hotplug, mais ça je
n'ai jamais utilisé (en fait c'est peut-être comme ça que fonctionne
udev).
"mlbusb" , dans le message <bu71v2$8sb$, a écrit :
1) Une clé USB vendue pour disposer de XX Mo de capacité (64 Mo par exemple) n'en a en fait que XX-2 de disponibles(62 par exemple). 2 Mo sont réservés pour des programmes et/ou des fichiers cachés. Qui les connait? Et qui sait comment y accéder?
C'est faux. Une clef USB vendue comme x Mo va réellement faire x Mo, parfois avec une acception un peu large de « Mo » : parfois ils feront 1000 ko au lieu de 1024. À cette petite excroquerie près, la clef fait exactement la taille annoncée.
Le fait qu'on y voie moins que ça de place libre annoncée tient au fait qu'il est nécessaire de maintenir des structures de données pour organiser les fichiers. Typiquement, la clef est au format FAT, elle a donc déjà une table de 65536×2 octets pour indiquer quels bloc sont utilisés par quel fichier et quels blocs sont libres. Pour permettre la récupération en cas d'erreur, cette table est présente plusieurs fois. Il faut aussi un peu de place pour les noms des fichiers.
Au total, sur l'exemple que j'ai sous les yeux, je vois 544 ko perdus, ce qui est un peu beaucoup, mais un examen plus attentif m'indique que je perds aussi 272 ko parce que le vendeur a éprouvé le besoin de partitionner la clef, ceux-là je vais les récupérer en supprimant la table des partitions. Voilà, c'est fait, je perds au total 65536×2×2 octets pour les deux exemplaires de la FAT, et 12 ko pour les données globales (liste des fichiers dans la racine et taille du filesystem).
Il est possible d'utiliser la totalité de la clef, mais dans ce cas on ne peut la considérer que comme _un_ fichier dont la taille est exactement toute la clef. Toute structure est à mettre en plus. Pour ça on passe par le périphérique bloc directement (/dev/scsi/host*/bus0/target0/lun0/disc). Mais ce n'est probablement pas une bonne idée.
En tout cas il n'y a absolument aucun fichier caché.
2) Quelle est dans le détail la séquence d'opérations lancées lors d'un branchement d'une clé USB alors que l'OS est lancé?
Ça dépend énormément de la configuration. Si l'OS n'a pas les modules pour l'USB chargés, il ne se passe strictement rien. Si le module pour l'USB est chargé, le noyau va recevoir une IRQ, scanner le bus, et voir un nouveau périphérique. Si le module usb-storage est chargé, le noyau va détecter que c'est lui qui est concerné et lui passer la main. Le module usb-storage va alors enregistrer le nouveau block device dans les structures du noyau. Si le noyau utilise devfs ou udev, il va alors envoyer un message (via /dev/.devfsd pour devfs, et je ne sais pas pour udev) au démon concerné, qui va réagir comme indiqué dans sa config (cf. /etc/devfs/devfsd.conf pour devfs). Si ni devfs ni udev n'est utilisé, il se peut que le noyau invoque directement /sbin/hotplug, mais ça je n'ai jamais utilisé (en fait c'est peut-être comme ça que fonctionne udev).
parfois avec une acception un peu large de « Mo » : parfois ils feront 1000 ko au lieu de 1024. À cette petite excroquerie près, la clef fait exactement la taille annoncée.
Quelle escroquerie ?
1 Mio = 1024 Ko. 1 Mo = 1000 Ko.
Si en magasin il est affiché 32 Mo, ça fait donc bien 32 000 Ko en vertue des règles internationales actuelles.
-- John Deuf
parfois avec une acception un peu large de « Mo » : parfois ils
feront 1000 ko au lieu de 1024. À cette petite excroquerie près, la
clef fait exactement la taille annoncée.
Quelle escroquerie ?
1 Mio = 1024 Ko.
1 Mo = 1000 Ko.
Si en magasin il est affiché 32 Mo, ça fait donc bien 32 000 Ko en vertue
des règles internationales actuelles.
parfois avec une acception un peu large de « Mo » : parfois ils feront 1000 ko au lieu de 1024. À cette petite excroquerie près, la clef fait exactement la taille annoncée.
Quelle escroquerie ?
1 Mio = 1024 Ko. 1 Mo = 1000 Ko.
Si en magasin il est affiché 32 Mo, ça fait donc bien 32 000 Ko en vertue des règles internationales actuelles.
-- John Deuf
george
John Deuf , dans le message , a écrit :
1 Mio = 1024 Ko. 1 Mo = 1000 Ko.
Pipo complet.
John Deuf , dans le message <Xns947499B6DCB12anus@213.228.0.32>, a
écrit :
Quelle argumentation imparable et sans faille, c'est très convainquant.
Va plutôt consulter les documents de l'IEC (International Electrotechnical Commission). 1 Kibibyte = 1024 bytes, 1 Kilobyte = 1000 bytes.
-- John Deuf
george
John Deuf , dans le message , a écrit :
Va plutôt consulter les documents de l'IEC (International Electrotechnical Commission). 1 Kibibyte = 1024 bytes, 1 Kilobyte = 1000 bytes.
Je fais plus confiance à Foldoc. Ces distinctions a posteriori sont grotesques et complètement non-pertinentes : que nous importe le nombre 1111101000 ?
John Deuf , dans le message <Xns9474B3E676977anus@213.228.0.32>, a
écrit :
Va plutôt consulter les documents de l'IEC (International Electrotechnical
Commission). 1 Kibibyte = 1024 bytes, 1 Kilobyte = 1000 bytes.
Je fais plus confiance à Foldoc. Ces distinctions a posteriori sont
grotesques et complètement non-pertinentes : que nous importe le nombre
1111101000 ?
Va plutôt consulter les documents de l'IEC (International Electrotechnical Commission). 1 Kibibyte = 1024 bytes, 1 Kilobyte = 1000 bytes.
Je fais plus confiance à Foldoc. Ces distinctions a posteriori sont grotesques et complètement non-pertinentes : que nous importe le nombre 1111101000 ?
Irvin Probst
On 2004-01-18, John Deuf wrote:
Pipo complet.
Quelle argumentation imparable et sans faille, c'est très convainquant.
Va plutôt consulter les documents de l'IEC (International Electrotechnical Commission). 1 Kibibyte = 1024 bytes, 1 Kilobyte = 1000 bytes.
C'est amusant mais avant que les constructeurs de disques durs se rendent compte qu'ils pouvaient enfler un tas de gogos^Wclients comme ça, 1ko valait 1024 octets pour tout le monde. D'ailleurs pour ce qui est de la RAM je n'ai jamais entendu parler de Kibibyte. Tout ça c'est du pipotron rajouté à la va vite dans je ne sais quelle norme.
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
On 2004-01-18, John Deuf <nospam@removethis.fr.invalid> wrote:
Pipo complet.
Quelle argumentation imparable et sans faille, c'est très convainquant.
Va plutôt consulter les documents de l'IEC (International Electrotechnical
Commission). 1 Kibibyte = 1024 bytes, 1 Kilobyte = 1000 bytes.
C'est amusant mais avant que les constructeurs de disques durs se
rendent compte qu'ils pouvaient enfler un tas de gogos^Wclients comme
ça, 1ko valait 1024 octets pour tout le monde. D'ailleurs pour ce qui
est de la RAM je n'ai jamais entendu parler de Kibibyte.
Tout ça c'est du pipotron rajouté à la va vite dans je ne sais
quelle norme.
--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.
Quelle argumentation imparable et sans faille, c'est très convainquant.
Va plutôt consulter les documents de l'IEC (International Electrotechnical Commission). 1 Kibibyte = 1024 bytes, 1 Kilobyte = 1000 bytes.
C'est amusant mais avant que les constructeurs de disques durs se rendent compte qu'ils pouvaient enfler un tas de gogos^Wclients comme ça, 1ko valait 1024 octets pour tout le monde. D'ailleurs pour ce qui est de la RAM je n'ai jamais entendu parler de Kibibyte. Tout ça c'est du pipotron rajouté à la va vite dans je ne sais quelle norme.
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
John Deuf
Je fais plus confiance à Foldoc. Ces distinctions a posteriori sont grotesques et complètement non-pertinentes : que nous importe le nombre 1111101000 ?
Il ne s'agit pas de changer la base de calcul. Il s'agit d'avoir un système d'unités international cohérent.
Le préfixe "Kilo" signifie "1000" pour toutes les unités. 1 Kg = 1000 g. Il est logique qu'il siginifie "1000" aussi pour l'octet. D'où la distinction avec l'appellation "Kibi".
-- John Deuf
Je fais plus confiance à Foldoc. Ces distinctions a posteriori sont
grotesques et complètement non-pertinentes : que nous importe le
nombre 1111101000 ?
Il ne s'agit pas de changer la base de calcul. Il s'agit d'avoir un
système d'unités international cohérent.
Le préfixe "Kilo" signifie "1000" pour toutes les unités. 1 Kg = 1000 g.
Il est logique qu'il siginifie "1000" aussi pour l'octet. D'où la
distinction avec l'appellation "Kibi".
Je fais plus confiance à Foldoc. Ces distinctions a posteriori sont grotesques et complètement non-pertinentes : que nous importe le nombre 1111101000 ?
Il ne s'agit pas de changer la base de calcul. Il s'agit d'avoir un système d'unités international cohérent.
Le préfixe "Kilo" signifie "1000" pour toutes les unités. 1 Kg = 1000 g. Il est logique qu'il siginifie "1000" aussi pour l'octet. D'où la distinction avec l'appellation "Kibi".
-- John Deuf
Patrice Karatchentzeff
John Deuf writes:
[...]
Le préfixe "Kilo" signifie "1000" pour toutes les unités. 1 Kg = 1000 g. Il est logique qu'il siginifie "1000" aussi pour l'octet. D'où la distinction avec l'appellation "Kibi".
Le préfixe "Kilo" signifie "1000" pour toutes les unités. 1 Kg = 1000 g.
Il est logique qu'il siginifie "1000" aussi pour l'octet. D'où la
distinction avec l'appellation "Kibi".
Le préfixe "Kilo" signifie "1000" pour toutes les unités. 1 Kg = 1000 g. Il est logique qu'il siginifie "1000" aussi pour l'octet. D'où la distinction avec l'appellation "Kibi".
