Nettoyé : L'APFS dégrade fortement les performances sur les disques durs, Réactions à la publication du 17/09/2019

[Lionel]

Avec High Sierra, Apple a commencé à introduire un nouveau système de fichier moderne pour remplacer le HFS+, l'APFS.
Ce système de fichier permet de prendre des instantanés, permet de gagner de la place en évitant la redondance de fichiers stockés... Indubitablement, il apporte beaucoup et n'en est qu'au début de son plein emploi (avec Time Machine par exemple).

Sous High Sierra, seuls les SSD supportaient l'APFS tandis que les Fusion Drive et disques durs restaient en HFS+. Avec Mojave, ce sont tous les supports qui passent en APFS.

Mike Bombich a réalisé des tests fort intéressants là dessus.

Il a comparé les performances de deux volumes, un en HFS+ et un en APFS lors de la réalisation de l'énumération de très nombreux fichiers. Il s'agit dans la pratique de demander au système où sont les fichiers sur le disque. Au premier test, l'APFS est moins rapide à ce jeu d'un facteur 3 et atteignait un facteur 10 quand on le répétait.

Le problème est lié à la façon dont les deux systèmes cataloguent les données. Dans le cas du HFS (ainsi que la plupart des autres formats sur d'autres systèmes), le catalogue est placé au centre du disque. Dans le format APFS il n'y a pas de catalogue mais des en-têtes dispersés partout.
Sur un SSD, cela n'a aucune importance. Le contrôleur peut accéder à n'importe quelle zone mémoire sans voir les temps d'accès diminuer. En revanche dans le cas d'un disque dur, cela oblige les têtes à se déplacer dans des tas d'endroits différents au lieu de rester dans la zone catalogue.

L'explication de la baisse terrible de performances est donc là.
Hasard des choses, j'ai eu affaire hier à un iMac sous Mojave qui avait des soucis. Comme souvent dans ce cas, je l'ai démarré en mode Single User et ai lancé une commande FSCK pour vérifier la structure du volume. Mal m'en a pris. Si la chose prend très peu de temps sur un SSD, elle semble sans fin sur un disque dur.

Donc, sachez que l'APFS vous fera perdre en performances sur un disque dur. C'est d'autant plus vrai s'il s'agit du volume de démarrage qui sans cesse doit jongler avec de petits fichiers. Il existe bien un système de défragmentation sous Mojave, mais qu'il soit activé ou pas ne change rien. En revanche, désactiver la prise d'instantanés en totalité ou partiellement ruine encore plus les performances.


Lien vers le billet original

[iAPX]

...
C'est un beau raté de la part d'Apple tout de même. Surtout à une époque où le monde des Unix (et de Linux en particulier) propose des filesystems opensource efficaces.
...

Je ne te souhaite pas d'avoir à réparer un ext4fs qui a merdé, et encore moins mesurer les "performances" d'un zfs (à stockage identique).
Quand un contrôleur merde sur du ext4fs (du vécu sur une workstation Dell), ça devient rapidement épique!

Oui mais non, on le sait depuis le début que APFS n'était pas un file system optimisé pour disque mécanique. D'où le choix de High Sierra de ne pas l'utiliser
Ce qui est plus surprenant, c'est effectivement le choix d'Apple de les forcer .

Je ne crois pas que le terme "optimisé" soit adéquat. APFS n'est optimisé pour rien, sur un SSD il n'est pas spécialement plus rapide que HFS+.
J'ai l'impression qu'APFS est un N-ème greffon d'iOS et optimisé surtout pour la performance boursière d'Apple.

APFS est peut-être le premier filesystem journalisé conçu pour les Unix: il respecte l'idée de prioriser les écriture (la sortie) sur les lectures, il évite la double écriture (ext4fs je te vois! Les SSD adorent, les HD aussi!), en rendant qui plus est celles-ci pseudo-séquentielles (les SSD adorent aussi, les HD aiment!).
D'intéressantes qualité pour les SSD, notamment en terme d'amplification d'écriture, donc de durabilité.
Avec le défaut que les fichiers ne sont pas contigus sur le support, donc des contre-performances énormes en lecture avec un HD et moins rapide que HFS+ sur un SSD toujours en lecture.

“En revanche dans le cas d'un disque dur, cela oblige les têtes à se déplacer dans des tas d'endroits différents au lieu de rester dans la zone catalogue.”

Faut-il aussi envisager une usure prématurée du support ?...

Effectivement, c'est de la mécanique et plus c'est utilisé plus il y a d'usure, je pense que ce filesystem est totalement à déconseiller avec un disque dur.

[vlady]

APFS est peut-être le premier filesystem journalisé conçu pour les Unix: il respecte l'idée de prioriser les écriture (la sortie) sur les lectures, il évite la double écriture (ext4fs je te vois! Les SSD adorent, les HD aussi!), en rendant qui plus est celles-ci pseudo-séquentielles (les SSD adorent aussi, les HD aiment!).
D'intéressantes qualité pour les SSD, notamment en terme d'amplification d'écriture, donc de durabilité.
Avec le défaut que les fichiers ne sont pas contigus sur le support, donc des contre-performances énormes en lecture avec un HD et moins rapide que HFS+ sur un SSD toujours en lecture.

Même HFS+ est journalisé, et je ne parle pas de ZFS, btrfs et tant d'autres.

https://en.wikipedia.org/wiki/Comparison_of_file_systems

Ici on parle de perfs, qui ne sont pas brillantissimes, pour le reste rien de nouveau qui n'existe pas ailleurs.

Ce message a été modifié par vlady - 17 Sep 2019, 19:50.

[iAPX]

APFS est peut-être le premier filesystem journalisé conçu pour les Unix: il respecte l'idée de prioriser les écriture (la sortie) sur les lectures, il évite la double écriture (ext4fs je te vois! Les SSD adorent, les HD aussi!), en rendant qui plus est celles-ci pseudo-séquentielles (les SSD adorent aussi, les HD aiment!).
D'intéressantes qualité pour les SSD, notamment en terme d'amplification d'écriture, donc de durabilité.
Avec le défaut que les fichiers ne sont pas contigus sur le support, donc des contre-performances énormes en lecture avec un HD et moins rapide que HFS+ sur un SSD toujours en lecture.

Même HFS+ est journalisé, et je ne parle pas de ZFS, btrfs et tant d'autres.

https://en.wikipedia.org/wiki/Comparison_of_file_systems

C'est un ensemble de qualités qu'aucun des autres n'a, et qui explique le choix d'Apple. Relis bien

btrfs parfatageant avec zfs des performances dégueulasses quelles que soit le support (lire ici pour btrfs) !

Ce message a été modifié par iAPX - 17 Sep 2019, 19:52.

[vlady]

APFS est peut-être le premier filesystem journalisé conçu pour les Unix: il respecte l'idée de prioriser les écriture (la sortie) sur les lectures, il évite la double écriture (ext4fs je te vois! Les SSD adorent, les HD aussi!), en rendant qui plus est celles-ci pseudo-séquentielles (les SSD adorent aussi, les HD aiment!).
D'intéressantes qualité pour les SSD, notamment en terme d'amplification d'écriture, donc de durabilité.
Avec le défaut que les fichiers ne sont pas contigus sur le support, donc des contre-performances énormes en lecture avec un HD et moins rapide que HFS+ sur un SSD toujours en lecture.

Même HFS+ est journalisé, et je ne parle pas de ZFS, btrfs et tant d'autres.

https://en.wikipedia.org/wiki/Comparison_of_file_systems

C'est un ensemble de qualités qu'aucun des autres n'a, et qui explique le choix d'Apple. Relis bien

Tout dépend de point de vu. Pour moi les perfs ne sont pas extraordinaires, les données ne sont pas "checksumés", je ne vois qu'est ce que cherche d'autre. Et il est absolument claire qu'Apple ne va pas chercher ZFS et ses capacités. APFS c'est pour des gadgets, en tout cas pour le moment. Mais j'apprécie énormément les volumes dynamique et les snapshots....


Ce message a été modifié par vlady - 17 Sep 2019, 19:59.

[iAPX]

APFS est peut-être le premier filesystem journalisé conçu pour les Unix: il respecte l'idée de prioriser les écriture (la sortie) sur les lectures, il évite la double écriture (ext4fs je te vois! Les SSD adorent, les HD aussi!), en rendant qui plus est celles-ci pseudo-séquentielles (les SSD adorent aussi, les HD aiment!).
D'intéressantes qualité pour les SSD, notamment en terme d'amplification d'écriture, donc de durabilité.
Avec le défaut que les fichiers ne sont pas contigus sur le support, donc des contre-performances énormes en lecture avec un HD et moins rapide que HFS+ sur un SSD toujours en lecture.

Même HFS+ est journalisé, et je ne parle pas de ZFS, btrfs et tant d'autres.

https://en.wikipedia.org/wiki/Comparison_of_file_systems

C'est un ensemble de qualités qu'aucun des autres n'a, et qui explique le choix d'Apple. Relis bien

Tout dépend de point de vu. Pour moi les perfs ne sont pas extraordinaires, les données ne sont pas "checksumés", je ne vois qu'est ce que cherche d'autre...

Les données ont naturellement de l'ECC, que ça soit sur un disque dur ou un stockage Flash, et quand c'est toi qui a conçu le contrôleur Flash et son logiciel tu peux t'assurer de ce point à son niveau et non traiter le stockage comme une boîte noire

Pour le chiffrement c'est encore mieux puisque tu peux dédier cela à la puce dialoguant avec le contrôleur, donc T1 ou T2, pour sortir cette problématique de l'équation.
L'intégration a des gros avantages, et c'est ce qui a permis à Apple d'offrir des SSD aux performances incroyables pendant 1 ou 2ans, et encore du meilleur niveau.

Ce message a été modifié par iAPX - 17 Sep 2019, 19:59.

[vlady]

APFS est peut-être le premier filesystem journalisé conçu pour les Unix: il respecte l'idée de prioriser les écriture (la sortie) sur les lectures, il évite la double écriture (ext4fs je te vois! Les SSD adorent, les HD aussi!), en rendant qui plus est celles-ci pseudo-séquentielles (les SSD adorent aussi, les HD aiment!).
D'intéressantes qualité pour les SSD, notamment en terme d'amplification d'écriture, donc de durabilité.
Avec le défaut que les fichiers ne sont pas contigus sur le support, donc des contre-performances énormes en lecture avec un HD et moins rapide que HFS+ sur un SSD toujours en lecture.

Même HFS+ est journalisé, et je ne parle pas de ZFS, btrfs et tant d'autres.

https://en.wikipedia.org/wiki/Comparison_of_file_systems

C'est un ensemble de qualités qu'aucun des autres n'a, et qui explique le choix d'Apple. Relis bien

Tout dépend de point de vu. Pour moi les perfs ne sont pas extraordinaires, les données ne sont pas "checksumés", je ne vois qu'est ce que cherche d'autre...

Les données ont naturellement de l'ECC, que ça soit sur un disque dur ou un stockage Flash, et quand c'est toi qui a conçu le contrôleur Flash et son logiciel tu peux t'assurer de ce point à son niveau et non traiter le stockage comme une boîte noire

Pour le chiffrement c'est encore mieux puisque tu peux dédier cela à la puce dialoguant avec le contrôleur, donc T1 ou T2, pour sortir cette problématique de l'équation.
L'intégration a des gros avantages, et c'est ce qui a permis à Apple d'offrir des SSD aux performances incroyables pendant 1 ou 2ans, et encore du meilleur niveau.

Bien sûr, et les backups (et les copies sur les disques durs entre autres) c'est secondaire... Apple est infaillible... MDR. Arrête de lire les dépliants publicitaires d'Apple.

Ce message a été modifié par vlady - 17 Sep 2019, 20:05.

[iAPX]

...
Les données ont naturellement de l'ECC, que ça soit sur un disque dur ou un stockage Flash, et quand c'est toi qui a conçu le contrôleur Flash et son logiciel tu peux t'assurer de ce point à son niveau et non traiter le stockage comme une boîte noire

Pour le chiffrement c'est encore mieux puisque tu peux dédier cela à la puce dialoguant avec le contrôleur, donc T1 ou T2, pour sortir cette problématique de l'équation.
L'intégration a des gros avantages, et c'est ce qui a permis à Apple d'offrir des SSD aux performances incroyables pendant 1 ou 2ans, et encore du meilleur niveau.

Bien sûr, et les backups (et les copies sur les disques durs entre autres) c'est secondaire... Apple est infaillible... MDR. Arrête de lire les dépliants publicitaires d'Apple.

Connais-tu quelqu'un utilisant un système de fichier avec ECC (ou checksum c'est différent) au quotidien?
Je n'ai jamais vu personne pour ma part, et quand j'ai utilisé du checksum (pas de l'ECC) ça a été à grand échelle sur un site de partage de fichier et ça a évidemment été traité à haut-niveau et non dans les filesystems situés sur les différents supports.

[chombier]

Connais-tu quelqu'un utilisant un système de fichier avec ECC (ou checksum c'est différent) au quotidien?

Bah à peu près tous les firmwares des disques durs depuis trèèès longtemps utilisent l'ECC.
Ça apporte quoi d'en ajouter une couche dans le filesystem, pour eux ?

[iAPX]

Connais-tu quelqu'un utilisant un système de fichier avec ECC (ou checksum c'est différent) au quotidien?

Bah à peu près tous les firmwares des disques durs depuis trèèès longtemps utilisent l'ECC.
Ça apporte quoi d'en ajouter une couche dans le filesystem, pour eux ?

Ben en fait @vlady n'a pas tort d'un certain coté: le firmware des disques durs et SSD font tout ce qu'ils peuvent pour cacher leurs problèmes au lieu de les remonter, pour péter le plus tard possible, avec comme conséquence que c'est irréparable quand ça arrive, et qu'on peut entre-temps avoir des données corrompues (incluant celles du filesystem).
J'ai connu le même comportement voir pire dans des grosses cartes RAID ne remontant pas les pannes, voir des systèmes de stockage (ESILON dans ce cas) cachant aussi leur état réel et renvoyant des données corrompues voir une erreur quand on relisait les fichiers, d'où mon expérience du checksum à haut-niveau (sur des systèmes hétérogènes) puisque ne pouvant avoir aucune confiance même dans des bousins "redondants" à 100 000 €!

On ne peut pas faire confiance à un SSD ou un disque dur pour annoncer qu'il tombe en panne, le SMART ayant été détourné de cet usage initial et préventif, pour permettre de retarder au maximum la possibilité pour le client de réclamer un retour sous garantie, donc limiter les coûts au lieu de rendre service.

PS: @vlady oui c'est fait pour nos stockage Flash soudés, dissuader l'usage de disque dur, etc. C'est Apple quand-même.

Ce message a été modifié par iAPX - 17 Sep 2019, 20:39.

[chombier]

Connais-tu quelqu'un utilisant un système de fichier avec ECC (ou checksum c'est différent) au quotidien?

Bah à peu près tous les firmwares des disques durs depuis trèèès longtemps utilisent l'ECC.
Ça apporte quoi d'en ajouter une couche dans le filesystem, pour eux ?

Ben en fait @vlady n'a pas tort d'un certain coté: le firmware des disques durs et SSD font tout ce qu'ils peuvent pour cacher leurs problèmes au lieu de les remonter, pour péter le plus tard possible, avec comme conséquence que c'est irréparable quand ça arrive, et qu'on peut entre-temps avoir des données corrompues (incluant celles du filesystem).
J'ai connu le même comportement voir pire dans des grosses cartes RAID ne remontant pas les pannes, voir des systèmes de stockage (ESILON dans ce cas) cachant aussi leur état réel et renvoyant des données corrompues voir une erreur quand on relisait les fichiers, d'où mon expérience du checksum à haut-niveau (sur des systèmes hétérogènes) puisque ne pouvant avoir aucune confiance même dans des bousins "redondants" à 100 000 €!

On ne peut pas faire confiance à un SSD ou un disque dur pour annoncer qu'il tombe en panne, le SMART ayant été détourné de cet usage initial et préventif, pour permettre de retarder au maximum la possibilité pour le client de réclamer un retour sous garantie, donc limiter les coûts au lieu de rendre service.

PS: @vlady oui c'est fait pour nos stockage Flash soudés, dissuader l'usage de disque dur, etc. C'est Apple quand-même.

Mais tu n'as pas répondu à ma question.
L'ECC dans le filesystem, ça permet aussi de ne plus mettre de contrôleur dans un SSD, pour faire des économies.
Et accessoirement, de ralentir les accès aux vieux disques durs tellement démodés...
Il faut tout changer !

[iAPX]

Connais-tu quelqu'un utilisant un système de fichier avec ECC (ou checksum c'est différent) au quotidien?

Bah à peu près tous les firmwares des disques durs depuis trèèès longtemps utilisent l'ECC.
Ça apporte quoi d'en ajouter une couche dans le filesystem, pour eux ?

Ben en fait @vlady n'a pas tort d'un certain coté: le firmware des disques durs et SSD font tout ce qu'ils peuvent pour cacher leurs problèmes au lieu de les remonter, pour péter le plus tard possible, avec comme conséquence que c'est irréparable quand ça arrive, et qu'on peut entre-temps avoir des données corrompues (incluant celles du filesystem).
J'ai connu le même comportement voir pire dans des grosses cartes RAID ne remontant pas les pannes, voir des systèmes de stockage (ESILON dans ce cas) cachant aussi leur état réel et renvoyant des données corrompues voir une erreur quand on relisait les fichiers, d'où mon expérience du checksum à haut-niveau (sur des systèmes hétérogènes) puisque ne pouvant avoir aucune confiance même dans des bousins "redondants" à 100 000 €!

On ne peut pas faire confiance à un SSD ou un disque dur pour annoncer qu'il tombe en panne, le SMART ayant été détourné de cet usage initial et préventif, pour permettre de retarder au maximum la possibilité pour le client de réclamer un retour sous garantie, donc limiter les coûts au lieu de rendre service.

PS: @vlady oui c'est fait pour nos stockage Flash soudés, dissuader l'usage de disque dur, etc. C'est Apple quand-même.

Mais tu n'as pas répondu à ma question.
L'ECC dans le filesystem, ça permet aussi de ne plus mettre de contrôleur dans un SSD, pour faire des économies.
Et accessoirement, de ralentir les accès aux vieux disques durs tellement démodés...
Il faut tout changer !

Ben tu sembles indiquer qu'il y a de l'humour, mais formellement...

On aura toujours besoin d'un contrôleur dans un SSD, un peu moins d'un véritable contrôleur (au sens moderne du terme) dans un HD et d'ailleurs les HD IDE ou avant s'en passaient, mais ils réalisent des tâches qui sont intimement liées au matériel de stockage dont l'optimisation des performances de celui-ci, ça n'est pas générique, en sus du remapping. Et pour les SSD bien bien plus, notamment en terme de ECC de plus en plus complexe ainsi que d'analyse fine de signal depuis le MLC (plus encore avec le TLC).

Un disque dur ne sera pas ralenti par un ECC géré par le filesystem, hors logiciels considérant qu'un secteur fait un multiple de 512 octets ou 4096 octets (ou pire si l'ECC ou le checksum est stocké séparément). Il ya un prix à tout.

L'ECC dans le filesystem permet de garantir que les (parties de) fichiers n'ont pas été corrompus par les supports, mais ne garanti pas que le Filesystem lui-même ne corrompt pas les données, pour cela que dans un environnement distribué, voir hétérogène, on ne peut pas faire confiance à ce genre de mécanisme. Du vécu avec du matos ESILON à 100 000 € le bout (et son OS buggé jusqu'à la moelle).
Pour mémoire, je calculais une empreinte du fichier à sa réception, hors stockage, pour avoir une fois pour toute la garantie de détecter toute altération ou corruption même si elle venait du stockage initial, pour assurer une réelle redondance et une information claire en cas de corruption.

En même temps, dans nos OS "modernes" ceux-ci se fichent si un support est visiblement en train de tomber en panne avec des performance (latence, débit, ...) erratiques, et ne remontent absolument pas ce genre d'info, compréhensible pour les OS commerciaux ("vendus" installé sur du matériel) et idiot pour les autres, indiquant qu'on doit rapidement changement le stockage.
Je suis meilleur à déterminer l'état d'un disque dur en posant 2 doigts dessus que macOS 10.53, Windows 15 ou Ubuntu 23.13! WTF?!?

Ce message a été modifié par iAPX - 17 Sep 2019, 21:57.

[chombier]

Un disque dur ne sera pas ralenti par un ECC géré par le filesystem, hors logiciels considérant qu'un secteur fait un multiple de 512 octets ou 4096 octets (ou pire si l'ECC ou le checksum est stocké séparément). Il ya un prix à tout.

Toujours à voir le pire !

Mais en fait, c'est exactement ça.

Tu connais beaucoup de filesystems avec des secteurs différents de 512 ou 4096 octets, sur Mac ?

[edit]
4096, pas 4046.
PS: a ce sujet, iAPX, tu édites beaucoup trop tes messages sans rien dire...
[/edit]

Ce message a été modifié par chombier - 17 Sep 2019, 22:17.

[iAPX]

Un disque dur ne sera pas ralenti par un ECC géré par le filesystem, hors logiciels considérant qu'un secteur fait un multiple de 512 octets ou 4096 octets (ou pire si l'ECC ou le checksum est stocké séparément). Il ya un prix à tout.

Toujours à voir le pire !

Mais en fait, c'est exactement ça.

Tu connais beaucoup de filesystems avec des secteurs différents de 512 ou 4046 octets, sur Mac ?

Aucun secteur ne fait 512 octets ou 4096 octets nulle part, seule la garantie de données stockable fait cette quantité sur des supports physiques (donc disque dur ou SSD).
Les contrôleurs exposent ce type de secteur, mais ça n'a rien de physiquement réel.
Les filesystem masquent tout ça et en fait d'ailleurs n'exposent à haut-niveau que la possibilité de se déplacer ( lseek() par exemple ) et lire ou écrire séquentiellement dans un fichier logique.

Mais certains logiciels, dont les gestionnaires de Databank (appelés improprement Database), s'appuient sur l'idée que les espaces logiques sont des multiples de 512 ou 4096 et agissent en conséquence.
Avec certains filesystem ça peut rentrer lourdement en conflit lors que des metadata (de checksum ou de ECC) sont associées aux données.

Et la base de tout ça c'est d'utiliser des couches logicielles conçues pour des dérouleurs de bande voir des tambours magnétiques des années 60: c'est encore là et c'est profondément idiot!

PS: oui je sais que j'édite, je fais un premier jet qui contient l'idée, je corrige après les fautes de frappe en ajoutant du contenu sans changer l'idée, sans la travestir, surtout si on critique le message initial. Je suis derrière le message initial, j'affine, mais il n'est pas question de tromper.
Je suis vieux et lent, il me faut plusieurs passes pour obtenir quelque-chose qui ne trahi pas ma pensée initiale, ou peut-être suis-je jeune car mon premier jet (sic) est rapide et je dois m'y reprendre à plusieurs fois?!?

Ce message a été modifié par iAPX - 17 Sep 2019, 22:44.

[chombier]

Un disque dur ne sera pas ralenti par un ECC géré par le filesystem, hors logiciels considérant qu'un secteur fait un multiple de 512 octets ou 4096 octets (ou pire si l'ECC ou le checksum est stocké séparément). Il ya un prix à tout.

Toujours à voir le pire !

Mais en fait, c'est exactement ça.

Tu connais beaucoup de filesystems avec des secteurs différents de 512 ou 4046 octets, sur Mac ?

Aucun secteur ne fait 512 octets ou 4096 octets nulle part [...]

Ah bah merde ! J'apprends à l'instant que je ne vis nulle-part !
Tu vis dans le même monde qu'Illiade ?

[iAPX]

Un disque dur ne sera pas ralenti par un ECC géré par le filesystem, hors logiciels considérant qu'un secteur fait un multiple de 512 octets ou 4096 octets (ou pire si l'ECC ou le checksum est stocké séparément). Il ya un prix à tout.

Toujours à voir le pire !

Mais en fait, c'est exactement ça.

Tu connais beaucoup de filesystems avec des secteurs différents de 512 ou 4046 octets, sur Mac ?

Aucun secteur ne fait 512 octets ou 4096 octets nulle part [...]

Ah bah merde ! J'apprends à l'instant que je ne vis nulle-part !
Tu vis dans le même monde qu'Illiade ?

Ben le contrôleur d'un disque dur moderne peut te raconter qu'il stocke 4096 octets dans un secteur physique, mais c'est une garantie et pas une réalité.

Intéresse-toi à la façon dont les disques durs stockent les données et leur façon de les encoder physiquement (avec une longueur variable), et tu t'apercevras que c'est un mensonge (pieux certes!).

Ce message a été modifié par iAPX - 17 Sep 2019, 22:33.

[chombier]

Ben le contrôleur d'un disque dur moderne peut te raconter qu'il stocke 4096 octets dans un secteur physique, mais c'est une garantie et pas une réalité.

Intéresse-toi à la façon dont les disques durs stockent les données et leur façon de les encoder physiquement (avec une longueur variable), et tu t'apercevras que c'est un mensonge (pieux certes!).

Sans dec' ?
D5AA96 ... D5AAAD.
C'est vieux comme le floppy de l'Apple ][.
Je m'intéresse, merci.

[iAPX]

Ben le contrôleur d'un disque dur moderne peut te raconter qu'il stocke 4096 octets dans un secteur physique, mais c'est une garantie et pas une réalité.

Intéresse-toi à la façon dont les disques durs stockent les données et leur façon de les encoder physiquement (avec une longueur variable), et tu t'apercevras que c'est un mensonge (pieux certes!).

Sans dec' ?
D5AA96 ... D5AAAD.
C'est vieux comme le floppy de l'Apple ][.
Je m'intéresse, merci.

On est d'accord, ces technologies sont vieilles comme les disquettes, mini-disquettes, ou le stockage sur bande magnétique.
Ça marche aussi avec le X25/X27 et sa transmission, qui lui aussi interdit trop de bits d'affilés de même valeur, pour les mêmes raisons. Le stockage est une passerelle entre le monde numérique et le monde analogique, même avec le stockage Flash depuis le MLC (avant on avait pas besoin de ADC fins et d'analyse de signal afférent).
Oui un disque dur ou un stockage flash (qui est bizarrement appelé SSD des fois) est purement analogique. Tout l'inverse de ce qui est raconté.

C'est aussi ce qui fait que sur un espace de stockage avec des barrières définies, la capacités maximale garantie est fixée, mais on pourrait dans la plupart des cas stocker plus de données. Surtout avec des données chiffrées, donc stochastiques.

PS: encore édité pour mieux exprimer ma pensée et le rapport entre le stockage numérique et le monde analogique sur lequel il s'appuie et l'impact étrangement psitif du chiffrage sur la compacité de l'encodage de stockage (ça clarifie pour mon @vlady)
Et pour moi aussi Woz était un génie, comme le démontre le design de l'Apple ][ et son horloge à 2Mhz (1Mhz pour la partie framebuffer/rendering, 1Mhz pour la CPU) et son incroyable contrôleur de mini-disquettes (mi-hardwhare, mi-software), avant son accident.

Ce message a été modifié par iAPX - 17 Sep 2019, 23:23.

[chombier]

Ça marche aussi avec le X25/X27 et sa transmission, qui lui aussi interdit trop de bits d'affilés de même valeur, pour les mêmes raisons

Allez, je vais encore faire mon chieur: X.25, c'est au dessus de la couche transport, souvent HDLC, qui, elle, crachait constamment des 0xFF quand elle n'avait rien à dire...