Mac OS calcule comment ?

[Pascal 77]

Ayant récemment remis mon PM G4 en service sous Mac OS X 10.5.8 "Server", je commence à faire le ménage sur le disque interne de mon Mac en transférant sur le serveur tout ce qui ne sert pas souvent.

Là, j'ai eu la surprise de constater que d'un disque à l'autre (mais simultanément sur le même Mac), le même nombre d'octets ne générait pas le même nombre de Go. quelqu'un a une explication à ce curieux phénomène ?

 

[Pascal_TTH]

Très curieux, si on fait le conversion : 18,9660987 Go. Le 18,98 Go est assez farfelu et ne correspond à rien de sensé.

 

[bompi]

Les deux partitions ont-elles le même format ?

 

[Pascal 77]

Les deux partitions ont-elles le même format ?

Absolument, HFS+ journalisé pour les deux, mais ça n'explique pas, puisque le nombre d'octets st le même, si ça tenait au format de partition, la place occupée pourrait variée (tailles de blocs différents), mais là, ça n'est pas la place occupée mais bien la taille exacte du fichier qui est indiquée, et dans les deux cas, la taille en Go est calculée sur la même machine (l'illustre n'est pas un montage, les deux fenêtres d'infos étaient réellement côte à côte sur mon écran quand j'ai fais le screenshot), et la différence ne tient vraiment qu'au mode de calcul des multiples, or là, ce calcul est fait par la même machine au même moment.

la fenêtre de gauche, le dossier est sur la partition Mac OS du disque interne de mon MBP, et celle de droite, il est sur une partition de 480 Go constituée par trois disques de 160 Go en RAID entrelacé qui sont en interne sur mon PM G4. Le MBP est en 10.5.8, et le G4 en 10.5.8 "server". MBP et G4 sont reliés en ethernet (100 baseT, je n'ai pas de switch "gigabit", et internet (freebox en mode routeur située à l'étage en dessous et sous un mauvais angle pour la desserte de mon bureau en WiFi ) arrive par ce switch via un couple de CPL).

Sa taille réelle en Go est (ainsi que Pascal_TTH l'a calculée) de 18,96609871462 Go, ce qui, selon les règles communément admises pour les arrondis correspond bien à 18,97 Go avec deux décimales.

 

[Pascal_TTH]

C'est totalement abscon comme situation. Peu importe le format de fichier, 20 364 693 428 octets deoivent toujours représenter autant de Mo que de Go. C'est comme convertir des m/s en km/h. Ici, on doit simplement diviser par 1024 trois fois de suite.

19 887 395,9258 Ko
19 421,2850838 Mo
18,9660987146 Go

Je viens de faire des tests, en arrondissant à deux puis aucune décimale voire en prenant uniquement la partie entière, je n'arrive jamais à 18,98 Go.

Bref :

As-tu essayé de relire les informations plusieurs fois ?

Une chose m'intrigue dans la capture : la police est plus noire du côté droit. Je pensais initialement à deux images différentes.


PS : Je croyais que le bug FDIV n'avait affecté que les Pentium P5 et P54C. :rateau:

 

[Pascal 77]

Une chose m'intrigue dans la capture : la police est plus noire du côté droit. Je pensais initialement à deux images différentes.

Fais le test sur ton Mac, tu verras que c'est pareil, la fenêtre de droite avait le focus, pas celle de gauche, il ne peut y en avoir qu'une seule qui l'ait à la fois !

 

[Pascal_TTH]

En fait, ça se voit à peine sur le MacBook Air 11 pouces.

Sinon, je n'ai toujours pas trouvé de raison logique...

Peux-tu voir ces deux disques depuis une autre machine pour reproduire le problème ?

 

[Leyry Hynemonth]

Si j'ai bien compris, tu accède aux données de l'un des deux dossier via le réseau (AFP, SMB ou autre).

Il se trouve que dans les protocoles réseau, pour éviter une surcharge de trafic, l'information sur la taille des dossiers, la place dispos dans un dossier ect, ne sont pas transmises à chaque fois. De plus, les protocoles ne répondent pas eux-mêmes à toutes les requêtes du client distant.

Par exemple, quand le client demande la taille d'un élément dans un format basique (xxx.xx ko, mo, go, to ...) le protocole SMB (ou le protocole utilisé) répond de lui-même une valeur qu'il aura obtenu/calculé comme bon lui semble.

Mais si le client demande le détail des octets alors que le protocole SMB n'en à rien à faire de cette info (soit il n'en a pas l'utilité, soit c'est une charge supplémentaire qu'il n'inflige pas systématiquement à l'ordi/au réseau), il transmet la demande au système, qui va la transmettre au système de fichier, et qui va remonter l'information en octets.

Bref, dans la mesure ou le système de fichier / la méthode d'accès aux données de chaque ordi met à disposition des méthodes pour récupérer ce genre d'infos, il ne faut pas croire que c'est la bibliothèque qui génère la fenêtre d'information qui calcule à partir de la quantité en octets, la quantité dans une unité utile.

À partir de là, on ne peux pas déterminer le nombre d'arrondis fait sur cette valeur en octets.
Donc on peut se retrouver avec ce genre de couacs.


Enfin, c'est mon avis du soir. :rose:

 

[PA5CAL]

Bonjour

Dans Finder, le chiffre indiqué en haut (ici en Go) et celui indiqué en bas (en octets) ne se réfèrent pas forcément au même nombre.

La taille en octets donne la taille des données contenues dans les fichiers.

La taille indiquée au-dessus est quant-à-elle le reflet du nombre de secteurs occupés. Ainsi, un fichier de 23733 octets (≈23,18 Ko) n'occupe pas 23Ko ni même 24Ko, mais 25Ko dans le cas de secteurs de 512o (25Ko ≈ 48 secteurs de 512o).


NB : mais par ailleurs, il ne semble pas que ces nombres tiennent compte du volume occupé par les ressources associées et les répertoires, ni du fait que les fichiers puissent être compressés par le système.

 

[Pascal 77]

Peux-tu voir ces deux disques depuis une autre machine pour reproduire le problème ?

Peux plus, j'avais ouvert ces deux fenêtres pour vérifier que tout avait bien été copié, depuis, j'ai supprimé le dossier "source".

Bonjour

Dans Finder, le chiffre indiqué en haut (ici en Go) et celui indiqué en bas (en octets) ne se réfèrent pas forcément au même nombre.

La taille en octets donne la taille des données contenues dans les fichiers.

La taille indiquée au-dessus est quant-à-elle le reflet du nombre de secteurs occupés. Ainsi, un fichier de 23733 octets (≈23,18 Ko) n'occupe pas 23Ko ni même 24Ko, mais 25Ko dans le cas de secteurs de 512o (25Ko ≈ 48 secteurs de 512o).


NB : mais par ailleurs, il ne semble pas que ces nombres tiennent compte du volume occupé par les ressources associées et les répertoires, ni du fait que les fichiers puissent être compressés par le système.

Oui, mais là, non, la taille en Go correspond exactement au nombre d'octets indiqué dans une des fenêtres, et pas avec un écart suffisant pour correspondre à ce que tu dis dans la seconde, donc, ces deux chiffres représentent bien la taille effective des fichiers, et pas la place disque (à raison de 4 Ko par bloc, sur 800 et quelques fichiers, l'écart serait plus conséquent).

 

[Dos Jones]

Oui, mais là, non, la taille en Go correspond exactement au nombre d'octets indiqué dans une des fenêtres, et pas avec un écart suffisant pour correspondre à ce que tu dis dans la seconde, donc, ces deux chiffres représentent bien la taille effective des fichiers, et pas la place disque (à raison de 4 Ko par bloc, sur 800 et quelques fichiers, l'écart serait plus conséquent).

C'est avec ce genre de calcul que la France va perdre son triple A… :mouais:

 

[PA5CAL]

Oui, mais là, non, la taille en Go correspond exactement au nombre d'octets indiqué dans une des fenêtres, et pas avec un écart suffisant pour correspondre à ce que tu dis dans la seconde, donc, ces deux chiffres représentent bien la taille effective des fichiers, et pas la place disque (à raison de 4 Ko par bloc, sur 800 et quelques fichiers, l'écart serait plus conséquent).

Heu... l'écart insuffisant indique seulement que cette différence de comptage ne peut pas être la seule explication au problème (avec des blocs de 4Ko, on peut passer de 18,9661 Go à un maximum de 18,9694 Go, soit toujours 18,96 Go en arrondissant pas défaut)... du moins tant que la taille des blocs n'atteint pas 8Ko.

En revanche, le fait que le premier nombre corresponde à la taille occupée par les blocs et le second au seul contenu des fichiers, c'est une certitude.

 

[Pascal 77]

Heu... l'écart insuffisant indique seulement que cette différence de comptage ne peut pas être la seule explication au problème (avec des blocs de 4Ko, on peut passer de 18,9661 Go à un maximum de 18,9694 Go, soit toujours 18,96 Go en arrondissant pas défaut)... du moins tant que la taille des blocs n'atteint pas 8Ko.

En revanche, le fait que le premier nombre corresponde à la taille occupée par les blocs et le second au seul contenu des fichiers, c'est une certitude.

Ben, ton explication ne tient pas, en voici la démonstration :

Je n'ai plus le dossier "source mais voici (un montage, cette fois ci) les fenêtres d'infos du dossier cible : à gauche, la fenêtre d'infos sur ce dossier vu depuis mon Mac (Mac OS 10.5.8 "client"), et à droite, le même dossier, vu cette fois directement sur l'écran du serveur (Mac OS 10.5.8 "server").

Donc, à priori, le problème tient bien à la vision "à travers le réseau"

 

[PA5CAL]

Donc, à priori, le problème tient bien à la vision "à travers le réseau"

Je ne dis pas le contraire (j'ai bien indiqué que, pris isolément, ça ne semblait pas expliquer le problème). Mais je voulais indiquer que le chiffre du haut provenait bel et bien du nombre entier de blocs utilisés, et non pas des seuls octets appartenant aux fichiers.

Cela dit, si la taille des blocs transmise par le serveur au client ou bien utilisée par défaut par le client est erronée, il n'est pas impossible que cette explication puisse quand même tenir la route. Imagine par exemple que le client fasse le calcul en considérant des blocs de 8Ko et que le serveur utilise en réalité des blocs de 4Ko ou moins...

Il est également possible que le calcul de cette taille, du fait de la différence d'origine, ne donne pas un résultat arrondi de la même manière à partir du nombre de blocs (par exemple un arrondi à la valeur inférieure sur le serveur, et un arrondi à la valeur la plus proche sur le client).

---------- Nouveau message ajouté à 11h06 ---------- Le message précédent a été envoyé à 10h48 ----------

Quoi qu'il en soit, j'arrive aussi à reproduire ce comportement entre mes deux Macs Mini au travers du « partage Mac ».

Sur mon Mac Intel sous SL, un dossier partagé de mon Mac G4 sous Tiger apparaît avec la taille suivante :

8,04 Go sur le disque
(7 963 259 111 octets)
pour 34*187 éléments

mais directement sur le Mac G4, la taille indiquée est :

7,49 Go sur le disque
(7 963 259 111 octets)

 

[Pascal_TTH]

Effectivement, ça pourrait être un mixe d'informations. Windows est nettement plus clair sur le sujet et donne la taille des fichiers en octets et en Mo ou Go et l'espace occupé sur le disque en octets et en Mo ou Go. La différence vient bien entendu de la taille du cluster sur le disque.

Je n'ai pas le temps d'essayer des combinaisons mais il peut arriver que la taille et la taille sur le disque en Mo (Go) diffèrent après la virgule.

OS X afficherait en Mo ou Go la taille sur le disque (donc en tenant compte du système de fichiers) et en octets entre parenthèses la taille des fichiers (sans tenir compte d'un système de fichier).

 

[Leyry Hynemonth]

Sur windows, entre ne jeux aussi la notion de fichiers qui sont automatiquement compressés. La taille est alors la taille non compressée, et la taille sur le disque... ben vous devinez quoi

 

[Pascal 77]

Il est également possible que le calcul de cette taille, du fait de la différence d'origine, ne donne pas un résultat arrondi de la même manière à partir du nombre de blocs (par exemple un arrondi à la valeur inférieure sur le serveur, et un arrondi à la valeur la plus proche sur le client).

Ça déjà, on peut éliminer, parce que la plus petite des deux valeurs est déjà un arrondi à la valeur supérieure

Quoi qu'il en soit, j'arrive aussi à reproduire ce comportement entre mes deux Macs Mini au travers du « partage Mac ».

Sur mon Mac Intel sous SL, un dossier partagé de mon Mac G4 sous Tiger apparaît avec la taille suivante :

8,04 Go sur le disque
(7 963 259 111 octets)
pour 34*187 éléments

mais directement sur le Mac G4, la taille indiquée est :

7,49 Go sur le disque
(7 963 259 111 octets)

Oui, mais ça, c'est plus facile à expliquer : pour Snow Leopard et Lion, 1 Go = 10 puissance 9 octets (1 000 000 000 octets), alors que pour Leopard et Tiger (et tous ceux avant), 1 Go = 2 puissance 30 octets (1 073 741 824 octets).

Sur mon MBP, j'ai Leopard sur le disque interne, et Snow Leopard sur un disque externe en Fw800. Pour Leo, mes disques font respectivement 298,1 Go et 189,9 Go, alors que pour SL, ils font 320 et 200 Go.

 

[PA5CAL]

Ça déjà, on peut éliminer, parce que la plus petite des deux valeurs est déjà un arrondi à la valeur supérieure

Oui, mais ça, c'est plus facile à expliquer : pour Snow Leopard et Lion, 1 Go = 10 puissance 9 octets (1 000 000 000 octets), alors que pour Leopard et Tiger (et tous ceux avant), 1 Go = 2 puissance 30 octets (1 073 741 824 octets).

Bon, le dossier en question fait 15 686 336 blocs, soit 8 031 404 032 octets, ce qui, selon Snow Leopard et avec un arrondi à la valeur supérieure, correspond bien à 8,04 Go.

Selon Tiger, ces 8 031 404 032 octets devraient représenter 7,4798 Go, qu'on arrondit au maximum à 7,48 Go, et non pas à 7,49 Go comme il est indiqué actuellement.

Je vois donc bien un problème quelque peu similaire au tien dans mon cas.


Je commence à me demander si le calcul n'est pas mené à l'emporte-pièce, en utilisant un coefficient imprécis pour passer des milliards d'octets aux Go, ou bien en procédant à plusieurs arrondis successif.

Tout ce que ce je retiens de cela , c'est que l'information donnée n'est que très vaguement indicative, et qu'il ne faut surtout pas l'utiliser pour en tirer des conclusions sur la taille réelle des éléments, pas même pour faire des comparaisons.

 

[Pascal 77]

Bon, le dossier en question fait 15 686 336 blocs, soit 8 031 404 032 octets, ce qui, selon Tiger et avec un arrondi à la valeur supérieure, correspond bien à 8,04 Go.

Selon Snow Leopard, ces 8 031 404 032 octets devraient représenter 7,4798 Go, qu'on arrondit au maximum à 7,48 Go, et non pas à 7,49 Go comme il est indiqué actuellement.

Euuh … Tu n'aurais pas intervertit les deux félins, là, parce que tes 8,04 Go c'est bien 8 031 404 032 divisé par 10 puissance 9, et c'est Tiger, qui doit trouver un peu moins de 7,5 Go ?

 

[PA5CAL]

Euuh … Tu n'aurais pas intervertit les deux félins, là, parce que tes 8,04 Go c'est bien 8 031 404 032 divisé par 10 puissance 9, et c'est Tiger, qui doit trouver un peu moins de 7,5 Go ?

Oups... oui, je corrige.