Réponses:
Ceci est parfaitement normal sur les systèmes Linux. C'est une sorte d'action préparatoire pour le cas où les disques RAM devraient être requis. Chacun d'eux a une taille de 64 Mio, une valeur très faible. Si nécessaire, la taille sera augmentée automatiquement.
Pourquoi tout à coup 16 disques RAM sont disponibles dans Wily, ne peut être expliqué qu'avec difficulté.
J'ai testé les disques RAM par défaut sur:
Le pilote de disque RAM est un moyen d'utiliser la mémoire système principale comme périphérique de bloc. Il est requis pour initrd, un système de fichiers initial utilisé si vous devez charger des modules pour accéder au système de fichiers racine (voir Documentation / initrd.txt). Il peut également être utilisé pour un système de fichiers temporaire pour le travail de cryptographie, car le contenu est effacé au redémarrage.
Le disque RAM se développe dynamiquement à mesure que plus d'espace est requis. Pour ce faire, il utilise la RAM du cache tampon. Le pilote marque les tampons qu'il utilise comme étant sales afin que le sous-système VM n'essaye pas de les récupérer ultérieurement.
Le disque RAM prend en charge jusqu'à 16 disques RAM par défaut et peut être reconfiguré pour prendre en charge un nombre illimité de disques RAM (à vos risques et périls). Modifiez simplement le symbole de configuration BLK_DEV_RAM_COUNT dans le menu de configuration des pilotes de bloc et (re) construisez le noyau.
Aucune idée pourquoi fdisk signale soudainement / dev / ram.
Vous pouvez cependant demander à fdisk de ne signaler que des périphériques spécifiques.
fdisk -l /dev/sd*
Liste les vrais disques.
Vous pouvez également utiliser parted et lsblk.
Sortie séparée pour un lecteur ici.
Model: ATA Samsung SSD 840 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 2096kB 120GB 120GB extended boot
7 2097kB 26.2GB 26.2GB logical ext4
5 26.2GB 36.7GB 10.5GB logical ext4
6 36.7GB 47.2GB 10.5GB logical ext4
Sortie lsblk correspondante
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 1K 0 part
├─sda5 8:5 0 9.8G 0 part /mnt/Links
├─sda6 8:6 0 9.8G 0 part
└─sda7 8:7 0 24.4G 0 part /
Je sais que ce fil est ancien, mais je ne l'ai rencontré que récemment. Après avoir installé Slackware 14.2, j'ai eu les mêmes 16 disques RAM en sortie de
fdisk -l. J'ai étudié un peu plus loin et j'ai constaté que dans le package 'util-linux', dont fdisk (entre autres) faisait partie, la sélection de ce que fdisk considère comme un périphérique de bloc a considérablement changé. Dans la version 2.21 du paquet util-linux, cette décision est basée sur la géométrie du disque signalée tandis que dans la version 2.72 actuelle, la sortie de / proc / partitions est analysée. Selon mes recherches sur Internet, les ramdisks existent depuis Linux depuis le noyau 2.4, fdisk ne les a tout simplement pas montrés. Comme je suis ennuyé par la liste de nombreux "disques", qui ne sont pas de vrais disques, j'ai fait un patch pour fdisk:
diff -Nur util-linux-2.27.1_ori/disk-utils/fdisk-list.c util-linux-2.27.1_fdisk-no-ram-disks/disk-utils/fdisk-list.c
--- util-linux-2.27.1_ori/disk-utils/fdisk-list.c 2015-10-06 08:59:51.572589724 +0200
+++ util-linux-2.27.1_fdisk-no-ram-disks/disk-utils/fdisk-list.c 2016-08-16 15:55:14.840952091 +0200
@@ -312,6 +312,10 @@
if (devno <= 0)
continue;
+ /* dont list RAM disks */
+ if (strstr(line, "ram") && devno >= 256)
+ continue;
+
if (sysfs_devno_is_lvm_private(devno) ||
sysfs_devno_is_wholedisk(devno) <= 0)
continue;
Peut-être que cela aide certains autres ...
Le message de Johannes est correct. Les disques RAM sont dans le noyau depuis longtemps, c'est le comportement de fdisk qui a changé. Au lieu de patcher fdisk, j'ai écrit un simple script perl (5 lignes de code, 6 lignes de commentaire) pour gérer le problème. Je l'ai mis dans ~/bin/fdisk-l, et maintenant je me souviens juste de ne pas mettre d'espace entre fdisket -l.
#! /usr/bin/perl -w
# Run fdisk -l and filter out the 16 /dev/ram devices.
# Sun Mar 5 16:13:45 2017. Jeff Norden, jeff(at)math.tntech.edu
$_=`sudo fdisk -l`; #include sudo we don't have to be root
# weed out ram disks. The seemingly contradictory s (single) and m (multiline)
# flags allow "." to match "\n" and "^" to match at all beginning-of-lines.
s|^Disk /dev/ram.*?\n\n\n||smg;
# Do better than blank lines separating devices. Handle odd cases when there
# are more than two blank lines between devices or none at the end.
$hrule= '='x60 . "\n";
s/(\n\n\n+)|(\n+$)/\n$hrule/g;
print($hrule, $_);Depuis avril 2017, les disques RAM n'apparaissent plus par défaut avec le noyau Ubuntu actuel, donc ce problème est résolu. Voir: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1593293
Ce comportement est régi par les options du noyau que vous ne pouvez modifier qu'en recompilant un noyau personnalisé. Vous pouvez modifier la taille des périphériques ram * en utilisant un paramètre GRUB ramdisk_size mais pas le nombre. Cela est inutile, car même si vous avez beaucoup de mémoire, chaque ramdisk augmentera jusqu'à la taille que vous définissez. Donc, par exemple, si vous voulez un ramdisk de 8 Go - ce que je fais, voir ci-dessous - vous obtiendrez 16 instances de 8 Go. Je ne sais pas si cela est inoffensif si vous n'en utilisez pas la plupart, mais je suis réticent à brique mon système s'il ne l'est pas.
Je souhaite utiliser un périphérique 8 Go / dev / ram pour créer un miroir avec une partition de disque dur de 8 Go dans le but spécifique de mettre une zone de disque dur dessus. Mon application écrit automatiquement les blocs sur un stockage normal en fonction de l'espace libre, donc peu importe qu'il soit petit.
Avec l'écriture différée sous mdadm, cela devrait avoir pour effet de rendre les écritures flamboyantes rapidement si elles sont éclatantes, le côté HDD du miroir rattrapant lorsque les choses sont plus silencieuses pour fournir au moins une certaine protection des données. J'ai utilisé cette configuration avec Solaris, mais cela ne semble pas être possible avec Linux dès sa sortie de l'emballage.
Étant donné que la RAM est plus rapide que le SSD, cela devrait être une victoire, mais je ne peux pas l'essayer. Comme d'autres l'ont remarqué, si vous construisez un RAID1 avec tmpfs, il ne se réassemblera pas au démarrage car l'étape qui initialise tmpfs est beaucoup trop tard dans le processus de démarrage - à mountall. Vos mds sont bel et bien construits d'ici là, donc il échoue, et vous devez le reconstruire manuellement.
Les périphériques OTOH / dev / ram * seraient parfaits pour cela - si vous pouviez les configurer. Ils sont la toute première chose qui est configurée, et ram0 est le système de fichiers / initial.