Y a-t-il des problèmes à avoir des fichiers énormes sur le disque dur dans un système 32 bits ?

Cela n'a d'importance que si vous avez une application qui essaie de charger le fichier entier en mémoire.
Un programmeur qui fait cela pour des fichiers aussi volumineux devrait être abattu. Il existe de meilleures méthodes.

Certains logiciels peuvent roter sur des fichiers très volumineux (volumineux signifie > 2 gigaoctets), mais ces logiciels le font généralement aussi sur les systèmes 64 bits.
Dans la plupart des cas, cela est dû au fait que le programmeur a conçu et testé le logiciel pour des fichiers plus petits. Le logiciel contient des erreurs de logique qui l'empêchent de fonctionner correctement avec de très gros fichiers. Il ne s'agit pas d'une limitation du système d'exploitation lui-même.
(Un exemple très courant est l'utilisation d'un nombre signé de 32 pour garder la 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 un certain nombre de secondes supplémentaires de mise en mémoire tampon) est généralement chargée en mémoire. En général, pas plus de 2-3 mégaoctets à la fois.

Comme pour 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 TB. 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.

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

C'est faux ; il est parfaitement possible pour une unité centrale 32 bits d'utiliser plus de 4 Go de RAM, tout comme il est possible pour une unité centrale 16 bits d'utiliser plus de 64 KiB de RAM. Rappelons que le 16-bit 80286 pouvait adresser 16 MiB grâce à son bus d'adresse de 24 bits (à l'époque, cela était considéré comme une quantité énorme de mémoire ; le 80286 est devenu disponible en 1982, et En 1983, le premier disque dur de 3,5 pouces, doté d'une capacité de 10 Mo, est lancé. stockage capacité ; le IBM PC AT conçu autour du processeur Intel 80286 et doté d'un minimum de 256 Ko de mémoire vive), et l'ordinateur de 1979 L'Intel 8086 avait un espace d'adressage de 1 MiB. (et à condition que la capacité de calcul de la PC original IBM 5150 qui pouvait être mis à niveau vers la même quantité de RAM de 256 KiB, bien au-delà de la limite native d'une adresse 16 bits de 64 KiB). Consultez des techniques telles que Extension de l'adresse physique , commutation de banque (qui, bien que nécessitant une attention particulière de la part du programmeur, était courant dans les premiers PC et les premiers ordinateurs électroniques en raison de sa relative simplicité de mise en œuvre ; l'ordinateur de guidage d'Apollo était un modèle à commutation bancaire. ) et des modèles de mémoire segmentée tels que le Modèle de segmentation de la mémoire x86 .

Le facteur limitant ultimement la quantité de mémoire pouvant être adressée sans recourir à de telles techniques est la largeur de la mémoire native du CPU. bus d'adresses qui est indépendant de la largeur de mot native du processeur, ou bitness comme on l'appelle normalement . Il serait parfaitement possible de fabriquer une unité centrale de traitement qui travaille avec des données par tranches de 64 bits (ce qui en ferait une unité centrale de traitement de 64 bits) même si elle dispose d'un bus d'adresses de 16 bits ; je ne vois pas d'application réelle pour une telle chose, mais ce n'est pas techniquement une contradiction.

Beaucoup de gens ne se soucient pas de ces techniques sur les processeurs 32 bits, car à l'époque où ils étaient courants dans les PC, 4 Go étaient vraiment tout ce dont on avait besoin, et les processeurs 32 bits avaient généralement des bus d'adresses suffisamment larges pour ne pas poser de problème. Le 80386SX avait un bus d'adresse utilisable de 24 bits. permettant de disposer d'un espace d'adressage de 16 Mio en 1988. une configuration de disque dur de 20 Mo . Ne pas avoir à se préoccuper de la segmentation, du PAE et d'autres techniques similaires rend la vie plus facile. beaucoup plus facile pour le programmeur. Les logiciels serveurs 32 bits, cependant, étaient généralement écrits pour gérer plus de 4 Go de RAM.

Et bien sûr, pour la perspective, les logiciels 16 bits travaillaient régulièrement avec des fichiers de plus de 65 536 octets. Il faut un peu de réflexion si vous voulez que votre logiciel fonctionne en natif 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 vois pas bien ce que cela implique en termes de dossiers. Je pense que nous pouvons avoir des fichiers de taille arbitraire sur nos disques durs, non ? Bien plus que 4 Go.

Non, vous ne pouvez pas avoir arbitrairement les fichiers volumineux, 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 impose des limites à la taille des fichiers, tout simplement parce qu'il doit pouvoir stocker la taille du fichier quelque part. La limite exacte varie selon le système de fichiers et parfois selon 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 atteigniez avec un seul disque, bien qu'il soit possible de les atteindre. mai être un problème si vous avez un grand réseau de stockage. Par exemple, NTFS (le système de fichiers) prend en charge des tailles de fichiers allant jusqu'à 16 EiB, bien que l'option Mise en œuvre de NTFS dans Windows est actuellement (artificiellement) limitée à une taille maximale de fichier d'un peu moins de 256 TiB (contre 16 TiB à l'époque de Windows 8 et Windows Server 2012).

16 TiB n'est pas une quantité de stockage excessivement importante ; vous pouvez y arriver en utilisant par exemple 7 disques de 4 TB chacun en RAID-6, ce qui est certainement à la portée financière même des particuliers.

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

Les systèmes 32 bits et les fichiers volumineux présentent-ils des inconvénients ? Je suppose que certains programmes 32 bits ne seraient pas en mesure de charger des fichiers de plus de 4 Go ou je me trompe ?

Cela dépend du logiciel et, dans une moindre mesure, de la façon dont il fonctionne avec ses fichiers de données, donc oui, si les mots clés sont certains programmes 32 bits alors votre hypothèse est presque certainement correcte. Mais encore une fois, certains programmes 64 bits pourrait ne pas bien gérer les gros fichiers non plus. Je rencontre ce problème occasionnellement au travail ; par exemple, Microsoft Word 2010 refuse de charger tout fichier dont la taille est supérieure à 512 Mo, alors que j'ai bien plus de mémoire que cela à ma disposition si seulement il essayait de l'utiliser.

Si le logiciel essaie de charger tout le fichier en mémoire en une seule fois (ce qui ne devrait vraiment pas être le cas) et 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. (Note : mémoire virtuelle et l'échange sont deux choses complètement différentes. Vous devez également prendre en compte surcommissionnement de la mémoire .) Si, d'autre part, le logiciel ne charge qu'une partie du fichier en mémoire à un moment donné, tant que le système d'exploitation lui-même permet d'accéder aux parties du fichier au-delà de la limite de taille 32 bits de 4 Go et que le système de fichiers peut gérer la taille du fichier, la taille réelle du fichier ne devrait pas être un problème du tout, et si c'est le cas, il s'agit probablement d'un bogue du logiciel de l'utilisateur.