Respuestas:
Esto es perfectamente normal en los sistemas Linux. Es una especie de acción preparatoria para el caso de que se requieran los discos RAM. Cada uno de ellos tiene un tamaño de 64 MiB, un valor muy bajo. Si es necesario, el tamaño se incrementará automáticamente.
Por qué de repente 16 discos RAM están disponibles en Wily, solo se pueden explicar con dificultad.
He probado los discos RAM predeterminados en:
El controlador de disco RAM es una forma de usar la memoria del sistema principal como un dispositivo de bloque. Es necesario para initrd, un sistema de archivos inicial que se utiliza si necesita cargar módulos para acceder al sistema de archivos raíz (consulte Documentation / initrd.txt). También se puede usar para un sistema de archivos temporal para el trabajo criptográfico, ya que los contenidos se borran al reiniciar.
El disco RAM crece dinámicamente a medida que se requiere más espacio. Lo hace mediante el uso de RAM de la memoria caché del búfer. El controlador marca los buffers que está utilizando como sucios para que el subsistema VM no intente recuperarlos más tarde.
El disco RAM admite hasta 16 discos RAM de forma predeterminada, y puede reconfigurarse para admitir un número ilimitado de discos RAM (bajo su propio riesgo). Simplemente cambie el símbolo de configuración BLK_DEV_RAM_COUNT en el menú de configuración de Controladores de bloque y (re) compile el núcleo.
No tengo idea de por qué fdisk de repente informa / dev / ram.
Sin embargo, puede decirle a fdisk que solo informe dispositivos específicos.
fdisk -l /dev/sd*
Enumerará las unidades reales.
Alternativamente, también puede usar parted y lsblk.
Salida separada para una unidad aquí.
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
Salida de lsblk correspondiente
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 /
Sé que este hilo es viejo, pero lo encontré recientemente. Después de instalar Slackware 14.2 obtuve los mismos 16 discos RAM en la salida de
fdisk -l. Investigué un poco más y descubrí que en el paquete 'util-linux', del cual forma parte fdisk (entre otros), la selección de lo que fdisk considera como dispositivo de bloque cambió sustancialmente. En la versión 2.21 del paquete util-linux, esta decisión se basa en la geometría del disco informada, mientras que en la versión actual 2.72 se analiza la salida de / proc / partitions. Según mis búsquedas en Internet, los ramdisks han estado allí en Linux desde el kernel 2.4, fdisk simplemente no los mostró. Como me molesta la lista de muchos "discos", que no son discos reales, hice un parche para 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;
Tal vez esto ayude a otros ...
La publicación de Johannes es correcta. Los discos ram han estado en el kernel durante mucho tiempo, lo que cambió fue el comportamiento de fdisk. En lugar de parchear fdisk, escribí un simple script perl (5 líneas de código, 6 líneas de comentarios) para manejar el problema. Lo puse ~/bin/fdisk-ly ahora solo recuerdo no poner un espacio entre fdisky -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, $_);A partir de abril de 2017, los discos RAM ya no aparecen de forma predeterminada con el kernel actual de Ubuntu, por lo que este problema se resuelve. Ver: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1593293
Este comportamiento se rige por las opciones del núcleo que solo puede cambiar volviendo a compilar un núcleo personalizado. Puede cambiar el tamaño de los dispositivos ram * utilizando un parámetro GRUB ramdisk_size pero no el recuento. Esto es inútil, porque incluso si tiene mucha memoria, cada disco RAM aumentará al tamaño que establezca. Entonces, por ejemplo, si desea un disco RAM de 8GB, que es lo que hago, vea a continuación, obtendrá 16x 8GB de instancias. No sé si esto es inofensivo si no usa la mayoría de ellos, pero soy reacio a bloquear mi sistema si no lo es.
Quiero usar un dispositivo de 8GB / dev / ram para duplicar con una partición de disco duro de 8GB con el propósito específico de poner un área de disco caliente en él. Mi aplicación escribirá automáticamente los bloques en el almacenamiento regular en función del espacio libre, por lo que no importa que sea pequeño.
Con la escritura en segundo plano bajo mdadm, esto debería tener el efecto de hacer que las escrituras sean increíblemente rápidas si están rotas, con el lado del HDD del espejo poniéndose al día cuando las cosas están más tranquilas para proporcionar al menos algo de protección de datos. He usado esta configuración con Solaris, pero parece que no es posible con Linux, ya que viene de fábrica.
Como la RAM es mucho más rápida que la SSD, esto debería ser una victoria, pero no puedo probarlo. Como otros han notado, si construye un RAID1 con tmpfs, no se volverá a armar en el arranque porque el paso que inicializa tmpfs es demasiado tarde en el proceso de arranque, en el montaje. Sus mds están bien y realmente construidos para entonces, por lo que falla, y debe reconstruirlo manualmente.
Los dispositivos OTOH / dev / ram * serían perfectos para esto, si pudieras configurarlos. Son lo primero que se configura, y ram0 es el sistema de archivos / inicial.