Comment créer un ramdisk Linux de taille fixe qui ne permute jamais sur le disque?

Je veux créer un ramdisk Linux de taille fixe qui ne permute jamais sur le disque. Notez que ma question n'est pas «pourquoi» je veux faire cela (disons, par exemple, que c'est à des fins éducatives ou pour la recherche): la question est de savoir comment le faire.

Si je comprends ramfsbien, la taille ne peut pas être limitée, donc cela ne correspond pas à mon exigence d'avoir un disque virtuel de taille fixe.

Il semble également que tmpfs peut être échangé sur le disque. Cela ne correspond donc pas à mon exigence de ne jamais permuter sur le disque.

Comment pouvez-vous créer un ramdisk Linux de taille fixe qui ne permute jamais sur le disque?

Est-il possible, par exemple, de créer à l' tmpfsintérieur d'un ramfs(une telle solution répondrait-elle à mes exigences) et si oui, comment?

Notez que les performances ne sont pas un problème et que le ramdisk se remplit et déclenche des erreurs "disque plein" n'est pas un problème non plus.

Ce n'est qu'une idée et a plus d'un inconvénient, mais il pourrait être suffisamment utilisable de toute façon.

Que diriez-vous de créer un fichier image et un système de fichiers à l'intérieur au-dessus de ramfs, puis de monter l'image en tant que périphérique de boucle? De cette façon, vous pouvez limiter la taille du disque virtuel en limitant simplement la taille du fichier image. Par exemple:

$ mkdir -p /ram/{ram,loop}
$ mount -t ramfs none /ram/ram
$ dd if=/dev/zero of=/ram/ram/image bs=2M count=1
1+0 records in
1+0 records out
2097152 bytes (2.1 MB) copied, 0.00372456 s, 563 MB/s
$ mke2fs /ram/ram/image
mke2fs 1.42 (29-Nov-2011)
/ram/ram/image is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
256 inodes, 2048 blocks
102 blocks (4.98%) reserved for the super user
First data block=1
Maximum filesystem blocks=2097152
1 block group
8192 blocks per group, 8192 fragments per group
256 inodes per group

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done
$ mount -o loop /ram/ram/image /ram/loop
$ dd if=/dev/zero of=/ram/loop/test bs=1M count=5
dd: writing `/ram/loop/test': No space left on device
2+0 records in
1+0 records out
2027520 bytes (2.0 MB) copied, 0.00853692 s, 238 MB/s
$ ls -l /ram/loop
total 2001
drwx------ 2 root root   12288 Jan 27 17:12 lost+found
-rw-r--r-- 1 root root 2027520 Jan 27 17:13 test

Dans l'exemple (un peu trop long) ci-dessus, le fichier image est créé pour être de 2 mégaoctets et lorsque vous essayez d'écrire plus de 2 mégaoctets dessus, l'écriture échoue simplement car le système de fichiers est plein.

Une réduction évidente de tout cela est bien sûr qu'il y a beaucoup plus de complexité, mais au moins à des fins académiques cela devrait suffire.

Le livre (daté!) "Linux Device Drivers" de Corbet, Rubini et Kroah-Hartman a un exemple de pilote qui alloue juste une zone de mémoire fixe pour faire le tour. Pas un système de fichiers, mais ...

Impossible. Toute la RAM est soumise à la pagination à la fois par la conception matérielle du processeur et la conception du micro-noyau Linux. Il n'y a AUCUNE raison légitime de traiter la mémoire autrement. TOUS les algorithmes logiciels peuvent être adaptés pour utiliser le schéma de mise en cache des fichiers et la mémoire paginée. Le virtuel est TOUJOURS meilleur et plus efficace.

Les disques RAM de taille limitée vont à l'encontre des principes de base du monde virtuel. Vous devez supposer que seules les demandes de fichiers utiles sont envoyées au système de fichiers hôte et que toutes ces demandes ont une importance et une priorité égales dans le monde virtuel (le seul modèle qui compte).

Il a été mathématiquement prouvé que même les processus en temps réel correspondent à cette règle. Si vous avez un problème de vitesse, il NE PEUT JAMAIS être résolu en utilisant de la RAM comme stockage == tout le système hôte doit fonctionner plus rapidement du CPU au bus d'E / S au périphérique de stockage permanent. Tous les problèmes informatiques dégénérés, sauf artificiels, ont suffisamment de branches et d'exigences d'E / S de fichiers pour que l'augmentation de la vitesse moyenne de la mise en cache RAM soit la meilleure que vous puissiez faire.