Pourquoi ai-je autant de disques RAM?

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

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.

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

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.