Bonjour,
 
Je souhaite créer des buffer circulaire de taille importante (~1Go )en C enmanipulant des fichiers et je me demandais s'il y avais une taille limite au fichiers, selon l'OS?
 
 
 
   
 
environnement: windows XP ou Ubuntu 9.04

salut,  
 
celé dépend plutôt du format du système de fichier.  
 
En FAT32 tu seras limité en principe à 4Go, alors qu'en NTFS il n'y a en pratique pas de limite (2^64). Pour Ubuntu cela depend aussi du FS, en ext3 c'est variable selon le formatage.

À mon avis tu seras plus vite limité par la taille de ta RAM que par les limites du FS (à moins que comme l'a dit jagstang, tu utilises FAT ou un autre FS obsolète/exotique)

il fait un buffer circulaire à l'aide du FS, c'est justement pour aller au délà des limites de la RAM

Ok mais je suppose que plus gros est le buffer, meilleures sont les performances non?

Jusqu'à un certain point. Pour ce genre de situation, autant mapper le fichier.

Et tu fais ça comment? J'veux dire, qu'est-ce que ça implique du point de vue le la gestion de RAM & co (je demande pas quelles fonctions C/C++ faut utiliser, juste savoir comment marche le mécanisme)

Ben justement, c'est ton noyau qui gère ça au mieux. Toi tu te contentes d'écrire tes données dans ton tableau et le noyau vide ça vers le disque à sa guise.

D'accord Merci

Si tu ne peux pas mapper l'intégralité du fichier (genre gros fichier en 32bits), ça reste quand même intéressant de mapper des segments, genre une fenêtre glissante.

Pourquoi tu peux pas le mapper complètement?  
(Désolé pour les questions connes, j'ai jamais eu à faire à ce genre de soucis)

 
tout à fait,
car il 'y aurais pas un fichier de 1GO mais plusieur, l'dée étant de faire un serveur de TV, il y aurais environ une cinquantaine de fichier du genre, et ça m'embeterais un tout petit peu de mettre 50Go de RAM^^

mmapper un fichier fait une correspondance entre ce fichier et une partie de la mémoire virtuelle de ton process. Donc la taille de fichier mmappable dépend de la vmem disponible dans la limite de ta plateforme.

En 32b, sous Windows tu as 2Go de VMEM max (ou 3Go avec le switch kivabien, mais tu peux pas en être certain) sous la majorité des unices tu as 4Go, donc la taille de fichier mmappable c'est cette limite - la vmem que tu utilises déjà (code, données internes de ton soft, …)

Après, si tu as besoin de plus tu peux switcher entre plusieurs fichiers mmappés qui ont la taille qui va bien pour tenir dans ta limite (1Go~1.5Go si tu as besoin de compat windows, 3Go~3.5Go pour les unices)

En 64b, l'espace d'addressage théorique est 16EB (note: les OS n'atteignent pas nécessairement cette limite, sous windows ATM c'est 16TB) donc tu peux mmapper des ISO blu-ray si ça t'amuse.

En pratique, sous Linux 32 bits, au-dela de 1,4Go en mmap, tu commences à voir des emmerdes avec des allocs qui foirent pour cause de fractionnement, sous Windows 32 bits, c'est pire. Mais si c'est juste pour un buffer circulaire, destiné à enregistrer du texte, on n'a certainement pas besoin de ça, on doit pouvoir s'en sortir honorablement en mmappant quelques dizaines ou centaines de ko de mémoire. Si c'est pour un clone de Photoshop, par contre, c'est un peu différent. D'ailleurs, je ne serais pas surpris qu'il y ait déjà des API C pour gérer des buffers circulaires dans les libs standard du style Glib C.

c'est pour de la video (du MPEG2)

OK, donc là, tu vas devoir gérer la mémoire assez finement, je pense, pour éviter ces problèmes. Sauf si la cible est en 64 bits, auquel cas tu n'as pratiquement pas de limite. Tu peux éventuellement aller voir le source de libs comme FFmpeg, pour t'en inspirer, ou intégrer la lib si la licence le permet.