Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Linux 5.10 fera du problème de l'an 2038 le problème de l'an 2486,
Le réglage de l'horodatage XFS prolonge le temps des systèmes UNIX de quelques siècles

Le , par Bill Fassinou

45PARTAGES

5  0 
Linux 5.9 a été publié la semaine dernière et l’équipe de développement a déjà démarré les travaux sur la prochaine version du noyau, Linux 5.10. L’équipe continue toujours d’étudier des alternatives pour résoudre le problème de l’an 2038, censé ramener les systèmes Unix en 1901. Pour ce faire, Darrick J. Wong, le responsable du système de fichiers XFS, a soumis des correctifs pour XFS pour Linux 5.10 qui devraient retarder le problème de l'an 2038 pour XFS de 448 années supplémentaires. Cela devrait être suffisant pour trouver une véritable solution à long terme.

C’est depuis la version 5.6 du noyau, publié en mars dernier, que l’équipe a commencé à proposer des correctifs pour résoudre le problème de l’année 2038. Il s’agit en effet d’un bogue détecté il y a longtemps dans l’encodage du temps sur les systèmes de type Unix, dont Linux, Mac OS, et d’autres systèmes d’exploitation compatibles POSIX. Sur ces systèmes, le calcul du temps est effectué en fonction des secondes écoulées à partir du 1er janvier 1970 à 00:00:00 UTC (nommée également epoch). Un jour donnera par exemple 86 400 secondes et une année 31 536 000 secondes.

Et plus les années passeront, plus il faudra de nombres pour représenter les dates. Pour effectuer le décompte sur ces systèmes, lorsque la fonction time() est appelée, elle retourne un entier signé de type “time_t​”. Si le système est 32 bits, la valeur retournée est un entier signé 32 bits et si le système est 64 bits, la valeur retournée est 64 bits. Sur un système 64 bits, les limites sont supérieures à 292 milliards d’années. Il n’y a donc pas de soucis à se faire ici (ce sera beaucoup plus que l'âge de notre planète ou l'estimation de son espérance de vie).


Mais sur les systèmes 32 bits, le nombre de secondes total que la fonction peut retourner est 231–1, c’est-à-dire environ 136 ans. La date de référence étant le 1er janvier 1970 à 00:00:00 UTC, la date minimale représentable est le vendredi 13 décembre 1901 et la date maximale représentable est le mardi 19 janvier 2038 à 3 h 14 min 8 s. Lorsqu’il sera 3 h 14 min 8 s le 19 janvier 2038, le système passera au 13 décembre 1901 à la seconde suivante (également appelé le bogue de l’an 2038 abrégé en anglais Y2038). Bien évidemment, ce ne sera pas la fin du monde.

Toutefois, les systèmes 32 bits de la famille UNIX qui seront encore basés sur cet encodage seront fortement perturbés au point de ne plus pouvoir fonctionner correctement puisque le temps est l’un des éléments les plus importants sur les ordinateurs. Avec la version 5.6 du noyau, l’équipe s’est assurée que les systèmes Linux de 32 bits puissent passer l’année 2038 sans ramener l’utilisateur en 1901, mais avec la prochaine version, Linux 5.10, les choses pourraient évoluer encore plus. Mercredi, Wong a envoyé à Linus Torvalds une “grosse pile de nouveaux correctifs pour 5.10”.

Les correctifs pour XFS pour le noyau Linux 5.10 soumis Wong sont prévus pour retarder le bogue de l'an 2038 de 448 années supplémentaires. « Les changements les plus importants sont deux nouvelles fonctionnalités pour les métadonnées sur le disque : une pour enregistrer les tailles des brèves inodes dans l'AG pour augmenter les contrôles de redondance, mais aussi pour améliorer les temps de montage ; et une seconde fonctionnalité pour prendre en charge les horodatages jusqu'en 2486 », a écrit Darrick Wong dans le mail qu’il a adressé à Torvalds mercredi.

Les 448 années supplémentaires devraient être suffisantes pour trouver une solution à long terme pour ce problème concernant le système de fichiers XFS. Il existe deux nouvelles fonctionnalités de métadonnées sur disque pour XFS avec Linux 5.10 dans les correctifs soumis par Wong, que voici :

  • la taille des brèves inodes dans le groupe d'allocation est désormais enregistrée. Cela permet d'augmenter les contrôles de redondance et d'accélérer les temps de montage ;
  • prise en charge des horodatages jusqu'en 2486. Cette fonctionnalité de “gros horodatage” consiste à remanier leurs fonctions d'encodage de l'horodatage et des inodes pour traiter les horodatages comme un compteur de nanosecondes de 64 bits et un décalage de bits pour augmenter la taille effective. Cela permet maintenant à XFS de dépasser largement le bogue de l'an 2038 pour passer maintenant à l'année 2486. La mise en place d'un nouveau système de fichiers XFS avec bigtime activé permet d'obtenir une plage d'horodatage allant de décembre 1901 à juillet 2486 plutôt que de décembre 1901 à janvier 2038. Afin de préserver la rétrocompatibilité, la fonction d'horodatage n'est pas activée par défaut.


Il n'est pas confirmé que les correctifs seront intégrés dans Linux 5.10, mais cela semble très probable. La fenêtre de fusion est ouverte et Darrick J. Wong, employé par Oracle, est le mainteneur XFS, si bien que les correctifs XFS de sa part sont fusionnés par routine.

Source : Darrick J. Wong

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Linux est prêt pour « la fin des temps » : un correctif du bogue de l'an 2038 vient d'être intégré à Linux 5.6 et permettra aux systèmes 32 bits de marcher après 2038, les travaux sont encore en cours

Le «bug de l'an 2000» se reproduira en 2038 dans le monde Linux, mais c'est maintenant qu'il faut s'inquiéter selon Jon Corbet

Linux 5.6 est disponible avec l'implémentation du VPN WireGuard et la prise en charge d'Arm EOPD

Linux 5.9 est disponible. Cette version augmente les performances du processeur avec la prise en charge de FSGSBASE, et comporte diverses nouvelles fonctionnalités et améliorations

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de CaptainDangeax
Membre éprouvé https://www.developpez.com
Le 19/10/2020 à 15:16
Citation Envoyé par Golfy Voir le message
Je ne comprends pas bien les enjeux de cet article, puisque la plupart des machines ont des processeurs 64 bits.
Quels systèmes utilisent encore l'OS en 32 bits ?
Merci d'avance.
Je suis sur un projet de maintien en conditions opérationnelles d'un système de traitement de messages (pas plus de détails). Le système a été développé et mis en production en 2008. Ce produit utilise du perl et des bibliothèques compilées dont le code source a été perdu. Les serveurs d'hébergement étant arrivés en fin de vie, il a fallu les remplacer. Ce n'est pas si simple, on ne peut pas prendre ce vieux logiciel avec ses vieilles librairies et l'installer sur un linux récent comme ça. Le logiciel tourne dans des containers Docker, qui en quelque sorte émulent l'ancienne version 32 bits de l'OS d'origine sur une version 64 bits récente de Linux. Mais ce n'est pas tout : tout le traitement des messages est basé sur leur horodatage, qui utilise le Linux Epoch en 32 bits... Le produit a été laissé sans maintenance pendant 10 ans (c'est costaud Linux) mais à un moment donné il faut se poser des questions. Donc j'ai signalé au CDP et au manager que ce système ne passera pas l'an 2038. Ils m'ont répondu, ça va, c'est loin... N'empêche que la précédente période sans maintenance a duré 10 ans...
Ne crois pas que parce que maintenant tous les CPU sont en 64 bits, que tous les projets peuvent fonctionner comme ça en 64 bits.
4  0 
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 19/10/2020 à 14:19
Il y a pas mal de gens qui font tourner Linux sur des machines 32 bits y compris sur des applications pro.
1  0 
Avatar de ffwill
Membre à l'essai https://www.developpez.com
Le 22/10/2020 à 21:14
Il y'a plein de systèmes linux 32 bits dans les systèmes embarqués. Et du coup avec peu de mise a jour.
( Routeur, serveur d'impression, etc..)
1  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 24/10/2020 à 16:35
Je ne pense pas que ce soit de refiler le problème aux générations futures. Vous pourriez utiliser un stockage plus important pour la date (64 bits -> 128 bits, ou plus), mais cela voudrait dire qu'une grande partie de vos programmes vont devoir manipuler des données plus grandes et vont être ralenti. Il faut donc faire un compromis.
De plus, même si vous utilisez une taille plus grande, il y a toujours un moment où vous avez une taille finie avec une limite. Certes, la limite sera toujours plus loin, mais il y a toujours un développeur dans le futur qui devra faire un nouveau changement.
En bref, 2486, cela me semble rassurant. Pas de problème à venir. Le problème de 2038 a été pris en charge plutôt très tôt (18 ans avant le possible bug) et l'impact stockage/performances est réduit.
1  0 
Avatar de Golfy
Membre régulier https://www.developpez.com
Le 19/10/2020 à 13:46
Je ne comprends pas bien les enjeux de cet article, puisque la plupart des machines ont des processeurs 64 bits.
Quels systèmes utilisent encore l'OS en 32 bits ?
Merci d'avance.
0  0 
Avatar de floyer
Membre habitué https://www.developpez.com
Le 20/10/2020 à 8:32
Citation Envoyé par Golfy Voir le message
Je ne comprends pas bien les enjeux de cet article, puisque la plupart des machines ont des processeurs 64 bits.
Quels systèmes utilisent encore l'OS en 32 bits ?
Merci d'avance.
On peut avoir un traitement en 64bits, mais un stockage en 32bits. Les systèmes de fichiers précise la taille des champs stockés sur disque, ce qui fait que l’on peut récupérer un disque formaté sur un système 32bits sur un système 64bits.

C’est pareil en réseau. Si les équipements ont des champs de taille fixe, une valeur doit être fixée afin que des systèmes différents puissent communiquer (ex : adresses TCP/IP sur 32bits).
0  0 
Avatar de alexetgus
Membre actif https://www.developpez.com
Le 24/10/2020 à 11:41
En deux mots, ça revient à refiler le bébé avec l'eau du bain aux générations futures lointaines.

Reste à savoir si l'humanité existera encore dans 4 siècles.
Et que sera devenu Linux ? Une attraction qu'on trouve dans les musées ?
Le souci du Timestamp sera devenu une histoire drôle pour se moquer des être primitifs que nous étions, à nous taper des lignes de code interminables...
0  0 
Avatar de thanjuzo
Membre à l'essai https://www.developpez.com
Le 01/11/2020 à 11:24
2^31 secondes font 136 ans ?
0  0 
Avatar de floyer
Membre habitué https://www.developpez.com
Le 01/11/2020 à 13:04
Citation Envoyé par thanjuzo Voir le message
2^31 secondes font 136 ans ?
Je compte 68 (2^31/3600/24/365,25)
0  0 
Avatar de Christian_B
Membre averti https://www.developpez.com
Le 09/11/2020 à 13:20
Citation Envoyé par floyer Voir le message
Je compte 68 (2^31/3600/24/365,25)
En effet, il semble qu'on raisonne sur des nombres signés. Cela conduit à représenter les dates antérieures à 1970 comme des dates négatives, ce qui n'a pas grand sens mais ne change pas grand chose en pratique.

Par ailleurs la discussion sur le fait de savoir si 64 bits suffiraient est une plaisanterie. L'article rappelle que cela permet 292 milliards d’années (toujours avec des nombres signés, soit 2^31 s après 1970). Très important pour qui sait voir loin !
La limitation à 2486 tient à une autre raison qui n'est pas expliquée.

J'aime bien l'euphémisme énoncé avec le plus grand sérieux :
Les 448 années supplémentaires devraient être suffisantes pour trouver une solution à long terme pour ce problème concernant le système de fichiers XFS.
D'ici là, s'il y a encore des systèmes informatiques, je pense qu'ils auront un peu changé, comme le note alexetgus.
0  0