opensuse-13.1: RAMDISK-Erzeugung

Hallo,

ich befolge folgende Anweisung, um eine RAM-Disk auf openSUSE-13.1 zu erzeugen:
# In order to configure a RAM disk, perform the following steps:
# 1) Specify the default RAM disk size. The default RAM disk size
# is controlled by a command-line option that is passed to the
# kernel during boot. The kernel command-line option is:
# ramdisk_size=xxxxx, where xxxxx is the size expressed in
# 1024-byte blocks. This is specified in the boot loader
# configuration file (lilo.conf or grub.conf). Choose a
# RAM disk size that is large enough to store the maximum
# number of files that can be in transit simultaneously and
# at the same time is small enough to fit into the free
# physical RAM that is available.

# 2) Reboot the host to enable the new default RAM disk size.

# 3) Specify the RAM disk device in the environment variable
# "RAM_DISK_DEVICE" ("/dev/ram0" will be OK unless other
# RAM disks are in use).
Nur bekomme ich zwar im dmesg die Angabe:
RAMDISK: [mem 0x35436000-0x36a12fff]
Aber ich bekomme kein /dev/ram0, was aber hier erwartet wird.

Was habe ich zu machen?

Dank für helfende Hinweise,
Werner.

PS. Mit YaST habe ich an den Kernel-Aufruf im Bootloader nachgetragen:
ramdisk_size=512000
 
Zuletzt bearbeitet:
Gelöst mit
Code:
/etc/init.d/boot.local => modprobe rd
 
Danke für den Hinweis.

Wie (in welcher Form) habe ich mein Problem dort einzutragen?

Gruß,
Werner.
 
Da gibts unterschiedliche Möglichkeiten:

Unter SuSE wird diese Konfiguration mittels Yast2 durchgeführt:
  • "System > Kernel > INITRD_MODULES" und "System > Kernel > MODULES_LOADED_ON_BOOT" zu konfigurieren.
Bei neueren SuSE Versionen kann die Einstellung mit dem "/etc/sysconfig Editor" von YaST vorgenommen werden.
Ohne YaST müsste eine Anpassung von /etc/sysconfig/kernel ausreichend sein.
Quelle: Automatisches Laden von Linux Kernel Modulen beim Booten


Letzteres ist dann einfach nur die Angabe des Moduls in der INITRD_MODULES-Variable:
Code:
[...]
INITRD_MODULES="rd"
[...]
 
Danke für den Hinweis.

In /etc/sysconfig -> Kernel hatte ich INITRD_MODULES="rd" eingetragen.
Das blieb wirkungslos.

Nun habe ich über YaST -> System -> Editor für /etc/sysconfig -> System
-> Kernel -> DOMU_INITRD_MODULES hier zusätzlich zu xennet xenblk
nun noch rd eingetragen. Jetzt scheint es zu funktionieren.

Gruß,
Werner.
 
Natürlich bleibt der Eintrag wirkungslos, wenn man danach das initrd-Image nicht neu erstellt, was YaST automatisch tut. Mit mkinitrd kann man diesen Schritt aber auch manuell machen.
 
So weit, so gut. Jetzt habe ich sogar mehrere /dev/ramX.
Wie/wo mounte ich jetzt etwa
Code:
mount -t ext4 /dev/ram0 /home/werner/Z/
In meinem Homeverzeichnis -- oder auch irgendwo anderns --
soll das Verzeichnis Z nicht auf der HDD liegen, sondern
ein Teil von RAM sein. Der Mount-Befehl ergibt eine satte Fehler-
meldung:
Code:
mount: /dev/ram0 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/ram0,
        missing codepage or helper program, or other error
        In some cases useful info is found in syslog - try
        dmesg | tail or so.
Gruß,
Werner.
 
Du musst deine RAM-Disk auch noch mit einem Dateisystem formatieren. Ohne Dateisystem kann man eine Partition nicht mounten.
 
Halb-OT:
hm, spricht eigentlich etwas gegen tmpfs (alternativ: ramfs)?
Code:
mount -t tmpfs -o size=512m tmpfs /mnt
bzw. in (meiner) fstab:
Code:
tmpfs	/tmp		tmpfs	rw,noexec,nosuid,size=512M	0	0

Edit: bei ramfs sollte beachtet werden, dass es kein Größenlimit gibt. Kommt also _stark_ auf den Anwendungsfall an.
tmpfs, sofern man Swapping in Kauf nimmt (hätte es jetzt ehrlich gesagt erstmal nicht als Nachteil aufgefasst :) )
hat gegenüber "RAM-Disk + zusätzliches FS" den Vorteil, dass z.B kein mehrfach-Caching/Kopieren stattfindet.
http://sysdocs.stu.qmul.ac.uk/sysdocs/Comment/initramfs-info.htm
 
Halb-OT:
spricht eigentlich etwas gegen tmpfs (alternativ: ramfs)?

tmpfs hat den Nachteil, dass es swappable ist und damit dann doch wieder auf der Platte landen kann. Eine RAM-Disk hingegen wird im Normalfall nicht einfach ausgelagert. ramfs wäre allerdings eine Möglichkeit, denn auch dort findet kein Swapping statt.
 
O.K., so habe ich´s gemacht, und es funktioniert. Über ramfs zu gehen, ist einfacher.
Nur meckert es, dass es kein "block device" sei. Es erscheint auch nicht mit df.

Aber es heißt:
Code:
[FONT=Arial,Helvetica][SIZE=3]A ramdisk (like initrd) is a ram based block device, which means it's a
fixed  size chunk of memory that can be formatted and mounted like a 
disk. [/SIZE][/FONT]
Wie "veredle" ich mein RAM-Disk zum "block device"?

Gruß,
Werner.
 
Hast du das Device gemountet oder kommt der Fehler beim Mounten? Wie wird das Mounten gemacht (genauer Befehl)?
 
Ich habe zunächst alles Bisherige gelöscht:

1) Bootloader-Optionen, hier ramdisk_size=512000 gelöscht.
2) Editor für /etc/sysconfig -> Kernel -> DOMU_INITRD_MODULES, hier rd gelöscht.
3) /etc/init.d/boot.local, hier modprobe rd gelöscht.

Nun nur in /etc/fstab eingetragen:
Code:
ramfs /Z ramfs rw,noexec,nosuid,size=512M 0 0
So habe ich /Z als RAM-Disk bekommen. Sein Inhalt ist nach einem Reboot wie er-
wartet verschwunden. Da nun /Z nicht im df erscheint, habe ich versucht:
Code:
mkfs.ext4 /Z

mke2fs 1.42.8 (20-Jun-2013) /Z ist kein spezielles Block-Gerät. Trotzdem fortsetzen? (j,n)
oder:
Code:
mkfs.exit4 /dev/ram0

mke2fs 1.42.8 (20-Jun-2013) Status für /dev/ram0 konnte nicht ermittelt werden --- 
Datei oder Verzeichnis nicht gefunden.
Das Gerät existiert offensichtlich nicht; haben Sie es richtig angegeben?
Mit der oben beschriebenen Methode mit dem Eintrag in den Boot-Optionen
und rd in /etc/sysconfig/kernel war /Z im df zu sehen.
 
Da nun /Z nicht im df erscheint, habe ich versucht:
Code:
mkfs.ext4 /Z
[/quote]
ramfs und tmpfs sind (spezialisierte) Dateisysteme - dabei wird auf die "Emulation" eines Block-Devices im RAM verzichtet (es gibt also auch kein automatisch erzeugtes /dev/foo)
Also ramfs _ungleich_ RamDisk mit einem Dateisystem drauf.
Für explizite ext4 Nutzung würde mir der Umweg über loopbackdevice einfallen - aber dann sollte man Ram-disk direkt nutzen ;)

Zu df und ramfs:
Was sagt denn "df -a"?
[quote=man]-a, --all
include dummy file systems[/quote]
 
Zu df und ramfs:
Was sagt denn "df -a"?

Code:
Dateisystem         Größe Benutzt Verf. Verw% Eingehängt auf

rootfs                58G    1,5G   56G    3% / 
devtmpfs             7,8G     32K  7,8G    1% /dev 
tmpfs                7,9G     80K  7,9G    1% /dev/shm 
tmpfs                7,9G    5,9M  7,8G    1% /run 
devpts                  0       0     0     - /dev/pts 
/dev/sda2             58G    1,5G   56G    3% / 
/dev/sda5             95G    4,7G   89G    5% /usr 
proc                    0       0     0     - /proc 
sysfs                   0       0     0     - /sys 
securityfs              0       0     0     - /sys/kernel/security 
tmpfs                7,9G       0  7,9G    0% /sys/fs/cgroup 
cgroup                  0       0     0     - /sys/fs/cgroup/systemd 
pstore                  0       0     0     - /sys/fs/pstore 
cgroup                  0       0     0     - /sys/fs/cgroup/cpuset 
cgroup                  0       0     0     - /sys/fs/cgroup/cpu,cpuacct 
cgroup                  0       0     0     - /sys/fs/cgroup/memory 
cgroup                  0       0     0     - /sys/fs/cgroup/devices 
cgroup                  0       0     0     - /sys/fs/cgroup/freezer 
cgroup                  0       0     0     - /sys/fs/cgroup/net_cls 
cgroup                  0       0     0     - /sys/fs/cgroup/blkio 
cgroup                  0       0     0     - /sys/fs/cgroup/perf_event 
cgroup                  0       0     0     - /sys/fs/cgroup/hugetlb 
systemd-1               0       0     0     - /proc/sys/fs/binfmt_misc 
mqueue                  0       0     0     - /dev/mqueue 
debugfs                 0       0     0     - /sys/kernel/debug 
hugetlbfs               0       0     0     - /dev/hugepages 
ramfs                   0       0     0     - /Z 
tmpfs                7,9G    5,9M  7,8G    1% /var/run 
tmpfs                7,9G    5,9M  7,8G    1% /var/lock 
/dev/sdb2            902G     72M  901G    1% /eumetcast 
/dev/sda1            103M     50M   45M   53% /boot 
/dev/sda7            348G    174M  347G    1% /home 
/dev/sda3             92G     64M   91G    1% /tmp 
/dev/sda6             96G    163M   95G    1% /usr/local 
rpc_pipefs              0       0     0     - /var/lib/nfs/rpc_pipefs 
fusectl                 0       0     0     - /sys/fs/fuse/connections 
gvfsd-fuse           0,0K    0,0K  0,0K     - /run/user/1000/gvfs 
gvfsd-fuse           0,0K    0,0K  0,0K     - /var/run/user/1000/gvfs 
192.168.1.2:/archiv  406G    149G  236G   39% /DerGro3e 
binfmt_misc             0       0     0     - /proc/sys/fs/binfmt_misc
Das sieht ja nicht schlecht aus, nur die Gesamtgröße von /Z sehe
ich hieraus leider nicht. Ist sie wirklich 512000 kbyte?
Aus den Eckwerten des reservierten Memory-Bereichs schaffe ich
es nicht, es zu berechnen.
Ich kann wohl die Hex-Differenz berechnen. Dann aber die bytes
daraus?

Und dann will ich mich hiermit nicht verbiegen. Wenn die Tellicast-Programme ihre
in rascher Folge ankommenden Satelliten-Daten in /Z rasch und sicher speichern
und wiedergeben können, dann bin ich´s zufrieden. /Z soll ja nur ein sehr schnell
reagierendes Auslagerungs-Verzeichnis sein, damit keine der ankommenden
Daten verloren geht.
 
Ramfs hat (im Gegensatz zu tmpfs) keinen Größenlimit => es kann/wird wachsen, bis kein RAM mehr verfügbar ist - und da es nicht swappar ist, wird es "unlustig" (andererseits ist die RAM-Disk von vornherein limitiert - d.h u.U "out of space" für die ankommenden Daten).

Also: ramfs, falls man sicher ist, dass der RAM ausreicht
anonsten: tmpfs (und ggf. vm_cache_pressure Wert reduzieren, wobei man es erstmal "ohne Fummelei" probieren sollte ;) ), falls man eine Maximalgröße setzen möchte und Swapping in Kauf nimmt.
Oder: doch die gute alte Ramdisk. Zusätzlich zu den bisherigen Schritten noch "mke2fs -t ext4 -m 0 /dev/ram0" und "mount -t ext4 ..." (ggf mit noatime, noadirtime, sync und was alles noch bei ext4 Sinn macht) in boot.local eintragen.
 
Zurück
Oben