Pourquoi ai-je autant de disques RAM?


15

J'ai Arch Linux en cours d'exécution sur mon Raspberry Pi 2.

Juste après l' installation, j'ai couru lsblk, fdisket dfcommandes (malheureusement je ne l' ai pas enregistrer la sortie) mais j'avais un disque, qui est la carte SD et deux partitions sur elle. Ensuite, j'ai mis à niveau le système avec pacman -Syu, installé sudoet configuré ssh. Maintenant, lorsque je lance, fdiskcela montre que j'ai 16 disques RAM en mémoire avec des paramètres:

Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors 

Units: sectors of 1 * 512 = 512 bytes 

Sector size (logical/physical): 512 bytes / 4096 bytes 

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

et toutes sortes de systèmes de fichiers montés à différents points de montage (alors que j'ai personnellement créé seulement /dev/rootet /dev/boot):

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       1.8G  1.1G  557M  67% /
devtmpfs        458M     0  458M   0% /dev
tmpfs           462M     0  462M   0% /dev/shm
tmpfs           462M  328K  462M   1% /run
tmpfs           462M     0  462M   0% /sys/fs/cgroup
tmpfs           462M     0  462M   0% /tmp
/dev/mmcblk0p1  100M   18M   83M  18% /boot
tmpfs            93M     0   93M   0% /run/user/1000

Ma question est donc: quels sont tous ces disques RAM et pourquoi ils sont dans mon système, car je ne les ai certainement pas créés et quels sont ces systèmes de fichiers montés?

Modifier :

cat /proc/partitions production:

major minor  #blocks  name

   1        0       4096 ram0
   1        1       4096 ram1
   1        2       4096 ram2
   1        3       4096 ram3
   1        4       4096 ram4
   1        5       4096 ram5
   1        6       4096 ram6
   1        7       4096 ram7
   1        8       4096 ram8
   1        9       4096 ram9
   1       10       4096 ram10
   1       11       4096 ram11
   1       12       4096 ram12
   1       13       4096 ram13
   1       14       4096 ram14
   1       15       4096 ram15
 179        0   31472640 mmcblk0
 179        1     102400 mmcblk0p1
 179        2    1853439 mmcblk0p2

1
J'ai trouvé cette question connexe . Cette question n'a pas non plus de bonnes réponses, mais un commentaire suggère qu'elle /proc/partitionspourrait être pertinente. Vous devez inclure la sortie de cat /proc/partitionsdans votre question.
kasperd

Vous ne trouverez pas nécessairement de réponses sur un site spécifique au Raspberry Pi aux questions générales sur Linux. Un rapide Google trouve des réponses.
joan

1
@joan Oh, j'ai fait des recherches approfondies sur Google, mais je n'ai pas pu trouver de réponse claire et concise, juste des morceaux.
RusI

1. Ces disques RAM doivent être activés avant de compiler le noyau. 2. Ils ne doivent pas utiliser de RAM avant de monter un FS sur eux.
flakeshake

La raison de l'allocation de ces disques RAM reste un mystère alors ... il semblerait que la raison devrait être: 1) enregistrer les écritures sur la carte SD, et / ou 2) améliorer les performances en réduisant la latence des E / S du disque. personne (crédible) n'a enregistré une telle déclaration.
Seamus

Réponses:


4

Premièrement, les disques RAM ne sont pas la même chose que tmpfs .

Il existe de nombreux répertoires sur votre lecteur racine qui sont utilisés pour stocker des fichiers temporaires. Ces dossiers ont tendance à avoir beaucoup de lecture et d'écriture pendant que les applications créent, modifient puis suppriment les fichiers au cours de leur exécution.

Sur un disque dur mécanique où le nombre de cycles de lecture / écriture n'a pas d'importance, c'est parfaitement bien. Cependant, sur le Raspberry Pi, où le backend de stockage principal est une carte SD où il y a un nombre limité de cycles de lecture / écriture, avoir tellement d'E / S en cours peut épuiser prématurément la carte.

Comme nous n'avons pas besoin de conserver les fichiers dans ces répertoires temporaires lors d'un redémarrage, de nombreuses distributions tentent de réduire l'usure du périphérique de stockage en stockant les fichiers temporaires à fort trafic dans la RAM. Tmpfs est utilisé car c'est un système de fichiers qui utilise la RAM comme backend de stockage. C'est pourquoi vous voyez autant de répertoires montés en tmpfs.

Les disques RAM ne sont absolument pas liés à cela. Ce sont des périphériques blocs qui sont sauvegardés par la RAM alors que tmpfs est un système de fichiers soutenu par la RAM. Les disques RAM sont des périphériques de blocs bruts similaires à /dev/sdaetc ... Vous pouvez créer un système de fichiers au-dessus d'un disque RAM en exécutant mkfs /dev/ramexactement comme vous le feriez sur un périphérique de bloc de disque dur normal.

Je pense que le nombre de disques RAM disponibles est contrôlé par une option de configuration du noyau . Soyez assurés qu'ils ne prennent pas réellement de place tant que vous ne les utilisez / écrivez pas.


7

Ce n'est pas inhabituel.

Les disques RAM sont couramment utilisés pour les systèmes de fichiers temporaires.

Mon ordinateur portable Debian

Filesystem      Size  Used Avail Use% Mounted on
udev            1.5G     0  1.5G   0% /dev
tmpfs           301M   32M  269M  11% /run
/dev/sda2        47G   31G   14G  71% /
tmpfs           1.5G  1.7M  1.5G   1% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           1.5G     0  1.5G   0% /sys/fs/cgroup
tmpfs           1.5G   69M  1.5G   5% /tmp
/dev/sda4       386G  344G   23G  94% /home
tmpfs           301M   12K  301M   1% /run/user/114
tmpfs           301M   76K  301M   1% /run/user/1000

My Raspbian Pi Zero

Filesystem                     Size  Used Avail Use% Mounted on
/dev/root                      7.2G  3.8G  3.1G  56% /
devtmpfs                       214M     0  214M   0% /dev
tmpfs                          218M     0  218M   0% /dev/shm
tmpfs                          218M   17M  202M   8% /run
tmpfs                          5.0M  4.0K  5.0M   1% /run/lock
tmpfs                          218M     0  218M   0% /sys/fs/cgroup
/dev/mmcblk0p1                  56M   20M   37M  36% /boot
tmpfs                          100M  4.0K  100M   1% /ram
tmpfs                           44M     0   44M   0% /run/user/109
mercury.lan:/home/common/code  386G  344G   23G  94% /code
tmpfs                           44M     0   44M   0% /run/user/1000

3
Vous ne répondez pas à la question. La question est de savoir pourquoi /dev/ram15(et probablement 0-14 également) apparaît dans la sortie de fdisk. Votre réponse ne fait que mentionner tmpfsce qui n'a absolument aucun rapport avec /dev/ram*.
kasperd

1
Je ne doute pas de vos déclarations mais je suis vraiment intéressé par la raison pour laquelle ces changements ont eu lieu dans mon système. Alors que je suis juste en train d'étudier Linux et j'ai spécifiquement choisi Arch comme étant "hardcore" pour ainsi dire où vous devez dire explicitement au système d'exploitation ce que vous voulez qu'il fasse, et maintenant j'ai un système qui crée des disques et des systèmes de fichiers et les monte un peu partout - alors qui contrôle ici?
RusI

2

Réponse courte : c'est juste une fdisk particularité sur les dernières versions. Vous pouvez également utiliser partedet lsblk.

Extrait de ce fil sur AskUbuntu:

Sur les versions ultérieures de fdiskla sélection de ce que le programme considère comme périphérique de bloc, il a considérablement changé. Dans le util-linuxpackage, dont fdisk (entre autres) fait partie, la version 2.21, cette décision est basée sur la géométrie du disque signalée tandis que dans la version actuelle (comme pour mai 2017) 2.72.1, la sortie de / proc / partitions est analysée

Et:

Les disques RAM sont dans le noyau depuis longtemps, c'est le comportement de fdisk qui a changé.

Plus de détails et plusieurs solutions de contournement (si ces disques RAM à l'écran vous ennuient) sur le fil mentionné ci-dessus.


"Plus de détails et plusieurs solutions" ??? où ???
ZEE

@Zee, regardez le fil référé sur AskUbuntu. Ils répertorient même certains correctifs pour la source d'origine fdisk.
Sopalajo de Arrierez
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.