Existe-t-il des problèmes de fichiers volumineux en HD dans un système 32 bits?

2

Je sais que dans les systèmes 32 bits, la mémoire la plus importante que nous puissions avoir est de 4 Go (2 ^ 32). Mais je ne suis pas sûr de ce que cela implique en termes de fichiers.
Je pense que nous pouvons avoir des fichiers de taille arbitraire dans nos disques durs, non? Beaucoup plus que 4Go. Alors, y at-il des mises en garde dans les systèmes 32 bits et les fichiers volumineux?
Je suppose que certains programmes 32 bits ne pourraient pas charger des fichiers de plus de 4 Go ou est-ce que je me trompe?

Jim
la source
les programmes ne lisent pas le fichier immédiatement dans la mémoire, cela se fait en morceaux, de sorte que vous pouvez toujours ouvrir et lire le fichier.
magicandre1981

Réponses:

7

Cela n'a d'importance que si vous avez une application qui tente de charger la totalité du fichier en mémoire.
Un programmeur qui fait cela pour de si gros fichiers devrait être tourné. Il y a de meilleures façons.

Certains logiciels peuvent écraser des fichiers très volumineux (ce qui signifie plus de 2 gigaoctets), mais un tel logiciel le fera généralement aussi sur les systèmes 64 bits.
Dans la plupart des cas, cela est dû au fait que le logiciel a été conçu et testé avec des fichiers plus petits. Le logiciel contient des erreurs de logique l'empêchant de fonctionner correctement avec des fichiers très volumineux. Ce n'est pas une limitation du système d'exploitation lui-même.
(Un exemple très courant consiste à utiliser un numéro 32 signé pour garder une trace de la position dans le fichier, ce qui donne des problèmes à la limite de 2 Go.)

Dans le cas de votre exemple de vidéo: seule une petite partie (la partie en cours de lecture et plusieurs secondes supplémentaires de mise en mémoire tampon) est généralement chargée en mémoire. Habituellement pas plus de 2-3 Mo à la fois.

En ce qui concerne les fichiers de taille arbitraire sur un disque dur: ce n'est pas vrai.
Chaque système de fichiers a des limites sur la taille maximale de chaque fichier.
Par exemple, dans le cas de Fat32, cette limite est de 4 Go par fichier. NTFS a une limite de 16 To. Le système de fichiers Linux ext3 a une limite de 16 Go, 256 Go ou 2 To selon que le système de fichiers utilise des blocs de 1K, 2K ou 4K.

Tonny
la source
16GB, 256GB or 2TB limit depending on whether the filesystem uses 1K, 2K or 4K blocksComment la taille du bloc affecte-t-elle la limite des fichiers?
Jim
@Jim Le système de fichiers ext3 gère les fichiers en unités de blocs. La limite est donc déterminée par le nombre de blocs qu'un fichier peut avoir. Vous devez ensuite le multiplier par le nombre d'octets d'un bloc pour obtenir la taille maximale du fichier. Ce n'est pas inhabituel. Presque chaque système de fichiers traite en interne des blocs et tire ses limites supérieures du nombre de blocs qu'il peut gérer par fichier. Certains systèmes de fichiers définissent la limite réelle inférieure au maximum théorique. Cela peut être pour des raisons de performances ou pour des raisons commerciales (vous devez acheter une licence plus chère si vous avez besoin d’une prise en charge de fichiers très volumineux).
Tonny
4

Je sais que dans les systèmes 32 bits, la mémoire la plus importante que nous puissions avoir est de 4 Go (2 ^ 32).

C'est faux; il est parfaitement possible qu'un processeur 32 bits utilise plus de 4 Go de RAM, tout comme un processeur 16 bits peut utiliser plus de 64 Ko de RAM. Rappelez-vous que le 80286 16 bits pouvait adresser 16 Mo par son bus d’adresse 24 bits (à l’époque, on considérait qu’il occupait une énorme quantité de mémoire; le 80286 est devenu disponible en 1982 et l’année 1983 a vu l’introduction du premier disque dur 3.5 " , disposant d’une capacité de stockage de 10 Mo , le IBM PC AT , conçu autour du processeur Intel 80286, était doté d’un minimum de 256 Ko de RAM) et le processeur Intel 8086, datant de 1979, disposait d’un espace adresse de 1 Mio (et fournissait le capacité de calcul du PC IBM 5150 d'originepouvant être mis à niveau avec la même quantité de RAM de 256 Ko, bien au-delà de la limite native d’une adresse 16 bits de 64 Ko). Techniques de recherche telles que l' extension d'adresse physique , la commutation de banque (qui, bien que nécessitant une attention particulière de la part du programmeur, étaient courantes dans les premiers PC et les anciens ordinateurs électroniques en raison de la simplicité de sa mise en œuvre; le Apollo Guidance Computer était une conception à commutation de banque ) et des modèles de mémoire segmentés tels que le modèle de segmentation mémoire x86 .

Le facteur limitant ultime en ce qui concerne la quantité de mémoire pouvant être adressée sans recourir à de telles techniques est la largeur du bus d’adresses natif de la CPU , qui est indépendante de la largeur de mot native de la CPU ou de la résolution en bits, comme il est normalement indiqué . Il serait parfaitement possible de créer un processeur qui fonctionne avec des données en morceaux de 64 bits (ce qui en ferait un processeur de 64 bits) même s’il possède un bus d’adresse de 16 bits; Je ne vois pas de réelle application pour quelque chose comme ça, mais ce n'est pas techniquement une contradiction.

Maintenant, beaucoup de gens ne s’embarrassent pas de ces techniques sur les processeurs 32 bits, car à l’époque où ils étaient courants sur les PC, 4 Gio étaient vraiment tout ce dont vous aviez besoin, et les processeurs 32 bits disposaient généralement de suffisamment de bus d’adresses pour ne c'est une préoccupation; même la capacité réduite 80386SX avait un bus d'adressage utilisable 24 bits , ce qui permet 16 MiB d'espace d'adressage en 1988 lorsque la même année a vu la mise en place d' une installation sur le disque dur de 20 Mo . N'ayant pas à vous préoccuper de la segmentation, PAE et des techniques similaires facilitent grandement la vie du programmeur. Le logiciel serveur 32 bits, cependant, était généralement écrit pour gérer plus de 4 Go de RAM.

Et, bien entendu, les logiciels 16 bits utilisaient régulièrement des fichiers de plus de 65 536 octets. Cela prend un peu de réflexion si vous voulez que votre logiciel fonctionne de manière native avec des fichiers trop volumineux pour tenir dans un bloc de mémoire alloué individuellement, mais ce n'est certainement pas impossible.

Mais je ne suis pas sûr de ce que cela implique en termes de fichiers. Je pense que nous pouvons avoir des fichiers de taille arbitraire dans nos disques durs, non? Beaucoup plus que 4Go.

Non, vous ne pouvez pas avoir des fichiers de taille arbitraire , même s’ils sont limités par l’espace de stockage physique disponible: au niveau logique le plus bas, le système de fichiers limite le stockage des fichiers volumineux, simplement parce qu’il doit pouvoir stocker la taille du fichier. déposer quelque part. La limite exacte varie avec le système de fichiers et parfois avec les paramètres. Avec les systèmes de fichiers modernes tels que NTFS, ext4, etc., les limites sont suffisamment élevées pour qu'il soit peu probable que vous les frappiez avec un seul disque, bien que cela puisse être un problème si vous avez une grande baie de stockage. Par exemple, NTFS (le système de fichiers) prend en charge des fichiers d’une taille maximale de 16 EIB, bien que l’ implémentation NTFS dans Windows soit actuellement limitée (artificiellement). jusqu'à une taille de fichier maximale d'à peine 256 To (augmentée de 16 To par la version de Windows 8 et Windows Server 2012).

16 TiB n'est pas une quantité de stockage excessivement grande; vous pouvez y accéder en exécutant, par exemple, 7 disques de 4 To chacun en RAID-6, ce qui est certainement à la portée financière, même des individus.

La même chose a été faite avec différentes éditions de Windows, limitant artificiellement la quantité de RAM utilisable même si l'architecture sous-jacente en permettait l'utilisation beaucoup plus.

Alors, y at-il des mises en garde dans les systèmes 32 bits et les fichiers volumineux? Je suppose que certains programmes 32 bits ne pourraient pas charger des fichiers de plus de 4 Go ou est-ce que je me trompe?

Cela dépend du logiciel et, dans une moindre mesure, de la manière dont il fonctionne avec ses fichiers de données. Par conséquent, si les mots clés sont certains programmes 32 bits, votre hypothèse est presque certainement correcte. Là encore, certains programmes 64 bits risquent de ne pas bien gérer d’énormes fichiers. Je rencontre cela de temps en temps au travail; Par exemple, Microsoft Word 2010 refusera pour moi de charger tout fichier de plus de 512 Mo, même si ma mémoire est bien plus grande que celle qui n’est disponible que si c’est pour essayer de l’utiliser.

Si le logiciel tente de charger le fichier entier en mémoire en une fois (ce qu'il ne devrait vraiment pas faire) et qu'il n'a pas de limites artificielles, le facteur limitant avec les systèmes d'exploitation actuels sera la taille de la mémoire virtuelle disponible. (Remarque: mémoire virtuelle et échange sont deux choses complètement différentes. Vous devez également tenir compte de la surconsommation de la mémoire .) Par contre, le logiciel ne charge en mémoire qu'une partie du fichier à la fois, à condition que le système d'exploitation lui-même facilités pour accéder à des parties du fichier au-delà de la limite de taille de 32 bits de 4 Go et que le système de fichiers peut traiter la taille du fichier, la taille réelle du fichier ne devrait pratiquement pas être un problème, et si c'est le cas, , c’est probablement un bogue logiciel de l’utilisateur.

un CVn
la source
Vous l'avez formulé mieux et plus vaste que moi. Agréable!
Tonny
@ Tonny Cela a commencé comme un commentaire, mais j'ai ensuite décidé que c'était mieux comme réponse à part entière.
un CVn
C'est mieux ainsi. Je suis d'accord :-)
Tonny