Ramdisk sous squeeze

Bonjour,

Pour des raisons pédagogiques, j’ai besoin des périphériques ramdisk /dev/ramx avec x=0,1,… sous squeeze.

Ils n’y sont pas par défaut, et je ne parviens pas à voir comment inviter udev à les créer.

MAKEDEV pourrait être une solution s’il n’était pas bloqué par udev.

Quelqu’un aurait-il une piste à me suggérer ?

Dominique

PS : je hais udev.
Noyau : Linux alecto 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux

De ce que je lis dans la doc, ramdisk prend du plomb dans l’aile (“semi-obsolete”) et se fait supplanter par tmpfs.

/usr/src/linux-3.5/Documentation/filesystems/ramfs-rootfs-initramfs.txt

[quote]
ramfs and ramdisk:

The older “ram disk” mechanism created a synthetic block device out of
an area of RAM and used it as backing store for a filesystem. This block
device was of fixed size, so the filesystem mounted on it was of fixed
size. Using a ram disk also required unnecessarily copying memory from the
fake block device into the page cache (and copying changes back out), as well
as creating and destroying dentries. Plus it needed a filesystem driver
(such as ext2) to format and interpret this data.

Compared to ramfs, this wastes memory (and memory bus bandwidth), creates
unnecessary work for the CPU, and pollutes the CPU caches. (There are tricks
to avoid this copying by playing with the page tables, but they’re unpleasantly
complicated and turn out to be about as expensive as the copying anyway.)
More to the point, all the work ramfs is doing has to happen anyway,
since all file access goes through the page and dentry caches. The RAM
disk is simply unnecessary; ramfs is internally much simpler.

Another reason ramdisks are semi-obsolete is that the introduction of
loopback devices offered a more flexible and convenient way to create
synthetic block devices, now from files instead of from chunks of memory.
See losetup (8) for details.

ramfs and tmpfs:

One downside of ramfs is you can keep writing data into it until you fill
up all memory, and the VM can’t free it because the VM thinks that files
should get written to backing store (rather than swap space), but ramfs hasn’t
got any backing store. Because of this, only root (or a trusted user) should
be allowed write access to a ramfs mount.

A ramfs derivative called tmpfs was created to add size limits, and the ability
to write the data to swap space. Normal users can be allowed write access to
tmpfs mounts. See Documentation/filesystems/tmpfs.txt for more information.[/quote]

Bonjour,

Merci pour la suggestion.
Je ne maîtrise pas encore tmpfs et je crains qu’il ne réponde pas à mes besoins.
Visiblement, il est préformaté avec un système de fichiers : lequel ? ext2, vfat ?

J’ai besoin de ramdisk pour un enseignement de systèmes embarqués et je veux pouvoir faire des choses telles que partitionner le périphérique ramdisk ou du data dump pour la création d’images.

J’ai trouvé un contournement : en chargeant le module brd qui est celui qui gère les ramdisk, ces derniers apparaissent miraculeusement dans /dev.

J’imagine que c’est udev qui les crée, mais j’ai l’impression de l’utiliser à l’envers.
J’avais compris qu’udev chargeait les modules au moment de leur création quant on tente d’accéder au périphérique.

Comme j’ai encore l’esprit confus sur ces choses, je ne mets pas la coche verte.

Dominique.

Tant qu’il y aura de la RAM, il y aura moyen de l’exploiter sous nulix …

[code] config BLK_DEV_RAM
tristate “RAM block device support”
—help—
Saying Y here will allow you to use a portion of your RAM memory as
a block device, so that you can make file systems on it, read and
write to it and do all the other things that you can do with normal
block devices (such as hard drives). It is usually used to load and
store a copy of a minimal root file system off of a floppy into RAM
during the initial install of Linux.

  Note that the kernel command line option "ramdisk=XX" is now obsolete.
  For details, read <file:Documentation/blockdev/ramdisk.txt>.

  To compile this driver as a module, choose M here: the
  module will be called rd.

  Most normal users won't need the RAM disk functionality, and can
  thus say N here.

[/code]

Puisque le noyau est insensible à l’argument et ne crée pas de /dev/ram au démarrage, en chargeant le module explicitement,tu remédies à cet inconvénient.

Bonjour,

	Most normal users won't need the RAM disk functionality, and can
	thus say N here.

Je découvre avec tristesse que je ne suis pas un utilisateur normal :cry:

Merci pour vos réponses.

Je clos ce fil et en ouvre un autre sur ramdisk et udev.

Cordialement

Dominique.