[résolu] Booter Debian en RAMDISK, possible ?

Derinhger · 19-11-2016 18:21:05

Salut les Tux

Petite question est il possible de faire booter son Debian en RAMDISK, cela me semble compliqué à première vue:
modification de initrd
script pour création du ramdisk au démarrage + copie des partitions système avant que initrd ne boot sur les dites partitions.
script pour enregistré les modification avant reboot/halt sur disque

Après y aura t'il un vrai gain de performance dans l'OS ?
Ce qui est sur en tout cas c'est que cela ralentira fortement les démarrage et arrêt.

Enfin v'la google n'est pas vraiment mon amis cette fois

mais comme j'ai environ 40G de ram inutilisé sur une de mes machines, je me suis dit pourquoi pas essayé

Merci d'avance, si vous avez des idées, perso je me crée une petite VM pour tester

Dernière modification par Derinhger (20-11-2016 17:23:02)

raleur · 19-11-2016 18:40:42

L'utilisation d'un ramdisk pour contenir un système de fichiers est obsolète. Il vaut mieux utiliser un tmpfs.

Note :
L'initramfs, successeur de l'initrd (qui était basé sur un ramdisk), est une racine initiale basée sur rootfs, version simplifiée de tmpfs.

Derinhger · 19-11-2016 18:44:54

Oui je pensais bien a tmpfs, cependant "ramdisk" est plus parlant je trouve

Sinon perso dans mon /boot j'ai bien un initrd, mais pas de initramfs, je vais regarder de ce coté

raleur · 19-11-2016 18:49:42

Le fichier s'appelle toujours "initrd", mais en fait c'est un initramfs. On peut lister son contenu avec lsinitramfs.

domainedeleau · 19-11-2016 19:20:22

Un truc du genre :

mkdir /mnt/mon_tmpfs
chmod 777 /mnt/mon_tmpfs
mount -t tmpfs -o size=30 G tmpfs /mnt/mon_tmpfs
tmpfs /mnt/mon_tmpfs tmpfs defaults,size=10 G 0 0

+ swapoff

Dernière modification par domainedeleau (19-11-2016 21:09:16)

Derinhger · 19-11-2016 20:50:38

Bon j'ai farfouiller un peu sur la toile et est trouvé quelque chose de pas trop mal, mais des amélioration son a apporter:
http://reboot.pro/topic/14547-linux-loa … d-boot-it/

Point positif :
- Sa ne prend que la partition / (certainement possible d'adapter en fonction des besoins, mais pour moi c'est parfait pour l'heure).
- Les traitements sur fichiers sont ultra rapide

Point négatif:
- Si ont modifie quoi que se soit dans la / c'est perdu au reboot
- Temps de boot plus long (~30sec sur une VM debian vierge)
- fdisk ne voie pas le ramdisk (tmpfs), je ne voie donc pas comment sauvegardé les modification faite sur /

root@debian:~# fdisk -l

Device     Boot   Start      End  Sectors  Size Id Type

/dev/sda1  *       2048  5156863  5154816  2,5G 83 Linux

/dev/sda2       5158910 16775167 11616258  5,6G  5 Extended

/dev/sda5       5158912  5787647   628736  307M 82 Linux swap / Solaris

/dev/sda6       5789696 16775167 10985472  5,2G 83 Linux

root@debian:~# cat /etc/fstab

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

/dev/sda1 /               ext4    errors=remount-ro 0       1

/dev/sda6 /home           ext4    defaults        0       2

/dev/sda5 none            swap    sw              0       0

none    /     tmpfs   defaults  0   0

root@debian:~#

reste donc plus qu'a fixé ce problème de sauvegarde sur /

EDIT:
Ok, ont peut accéder a la partition / du disque et y faire des modification, exemple:

root@debian:~# ls

test

root@debian:~# rm test

root@debian:~# ls

root@debian:~# mount /dev/sda1 /mnt

root@debian:~# cd /mnt/root/

root@debian:/mnt/root# ls

test

root@debian:/mnt/root#

du coup script pour "backup" différentiel devrais le faire au reboot de la machine

Dernière modification par Derinhger (20-11-2016 16:56:20)

domainedeleau · 19-11-2016 21:09:44

vous booter avec GRUB ? menu.lst: kernel /boot/linux root=/dev/sda1

Dernière modification par domainedeleau (19-11-2016 21:12:32)

Derinhger · 20-11-2016 01:24:57

domainedeleau a écrit :

vous booter avec GRUB ? menu.lst: kernel /boot/linux root=/dev/sda1

Oui GRUB, part contre menu.lst sa fait longtemp que j'avais pas vue.

Sinon pour la synchro RAMDISK > DISQUE sa fonctionne correctement avec un bon vieux rsync:

mount /dev/sda1 /mnt

rsync -rltgoDh --progress --delete --filter "- /mnt/" --filter "- /proc/" --filter "- /sys/" --filter "- /tmp/"  / /mnt/

Edit à toto :
C'est mieux en utilisant les balises du forum :
Edit à Derinhger :
Merci, fixé

part contre pas moyen de le lancer en auto a l'arrêt de la machine
Voila ou j'ai mis les scripts:

/etc/rc0.d/K99arret

/etc/rc6.d/K99arret

et le script:

#! /bin/sh

### BEGIN INIT INFO

# Provides:          arret

# Required-Start:    rsync

# Required-Stop:     rsync

# Default-Start:

# Default-Stop:      0 6

### END INIT INFO

/bin/mount /dev/sda1 /mnt

/usr/bin/rsync -rltgoDh --delete --progress --filter "- /mnt/" --filter "- /proc/" --filter "- /sys/" --filter "- /tmp/"  / /mnt/

exit 0

En même temps vue l'heure j'ai plus forcement les yeux en face des trous et c'est la première fois que je fais sa depuis longtemps , donc pour ce soir

EDIT:
une fois dans le lit ont réfléchi, il a un peut raller, mais sa fonctionne, vas falloir peaufiner sa

update-rc.d arret defaults

insserv: warning: script is corrupt or invalid: /etc/init.d/../rc0.d/K99arret

insserv: warning: script is corrupt or invalid: /etc/init.d/../rc6.d/K99arret

Edit à toto :
Idem...
Edit à Derinhger :
Merci, fixé aussi

Dernière modification par Derinhger (20-11-2016 16:55:35)

raleur · 20-11-2016 09:26:49

domainedeleau a écrit :

mkdir /mnt/mon_tmpfs
chmod 777 /mnt/mon_tmpfs
mount -t tmpfs -o size=30 G tmpfs /mnt/mon_tmpfs
tmpfs /mnt/mon_tmpfs tmpfs defaults,size=10 G 0 0

+ swapoff

Peux-tu expliquer la raison du chmod sur le point de montage et du swapoff ?
Les permissions sur un point de montage sont masquées par les permissions de la racine du système de fichiers monté, donc je n'en vois pas l'intérêt.
Le tmpfs peut utiliser le swap en cas de manque de mémoire disponible, je trouve donc risqué de désactiver le swap.

Derinhger a écrit :

- Les traitements sur fichiers sont ultra rapide
- Temps de boot plus long (~30sec sur une VM debian vierge)

En réalité, tu ne fais que regagner plus tard lors du premier accès à un fichier le temps que tu as perdu au démarrage pour copier ce fichier dans le tmpfs. Dans le cas normal, le fichier serait de toute façon mis en cache donc les accès suivants seraient tout aussi rapide que dans un tmpfs (en fait tmpfs utilise le cache de fichiers normal mais sans périphérique de stockage sous-jacent). Par contre le temps perdu au démarrage à copier les fichiers qui ne seront pas utilisés ne sera pas regagné.

Il y a des alternatives : les programmes de type readahead ou preload ne préchargent que les fichiers qui ont le plus de chances d'être utilisés.

Derinhger a écrit :

- fdisk ne voie pas le ramdisk (tmpfs), je ne voie donc pas comment sauvegardé les modification faite sur /

Evidemment fdisk ne voit pas les tmpfs (pas plus que /proc ou /sys ou les systèmes de fichiers en réseau du type NFS ou SMB) puisque ce ne sont pas des périphériques bloc mais des systèmes de fichiers. Il doit voir un ramdisk qui est un périphérique bloc, mais si ce dernier n'est pas partitionné (c'est possible de partitionner un ramdisk, mais peu courant) je n'en vois pas l'intérêt. Dans tous les cas je ne vois pas le rapport entre fdisk, qui est un programme de manipulation de table de partition, et la possibilité de sauvegarder les modifications.

Quel est ton objectif exactement ?

Dernière modification par raleur (20-11-2016 09:28:25)

Derinhger · 20-11-2016 14:58:51

Mon objectif, tout simplement tester, apprendre et découvrir

Ne l'ayant jamais fait, savoir si c'est possible et exploitable.

Je voie que c'est faisable, maintenant niveau exploitation a voir ce que sa donne, je vais tester de mettre sa en prod sur une de mes machines servant principalement a faire du traitement de fichiers.

Ensuite utilisant beaucoup de VM, le plus simple et de créer un script créant un tmpfs, qui transfert les VMs vers ce dernier avant de les lancées, je pense que pour de la base de données sa peut être pas mal.

domainedeleau · 20-11-2016 19:17:06

Oui GRUB, part contre menu.lst sa fait longtemp que j'avais pas vue.

Au passage je suis preneur d'une doc a jour sur GRUB ou d'autre bootloader

raleur · 20-11-2016 20:12:47

Bien sûr c'est faisable. Mais je ne pense pas que l'utilisation que tu en fais, à savoir synchroniser avec un système de fichiers sur disque soit la meilleur façon d'exploiter une racine en ramdisk ou en tmpfs, Après tout, ça existe déjà par défaut : ça s'appelle le "cache de page" (pagecache), appelé familièrement "cache disque". Par défaut le noyau ne charge en mémoire que les morceaux de fichiers dont il a besoin, les garde en cache aussi longtemps qu'il n'a pas besoin de libérer de la mémoire, et écrit les modifications dans le périphérique de stockage sous-jacent. Cela me semble correspondre à ce que tu cherches à faire, et ce mécanisme bénéficie d'années d'optimisations des développeurs du noyau.

D'autre part, attendre l'arrêt du système pour synchroniser toutes les modifications me semble assez risqué.

Une utilisation plus rationnelle d'une racine en mémoire, à mon avis, consiste à ne pas répercuter les modifications vers le périphérique ou le fichier sous-jacent, mais au contraire à reconstruire le contenu de ce dernier lorsqu'on souhaite modifier la racine, comme on le fait pour l'initrd/initramfs ou un système live, et à stocker le contenu de la racine dans un format qui ne soit pas un système de fichiers générique mais dans un format optimisé pour être lu d'une traite aussi rapidement que possible comme c'est le cas de l'initramfs qui est simplement une archive compressée. Ainsi on bénéficie d'une part de la compression qui réduit le volume de données à lire à partir du disque et d'autre part la lecture peut être séquentielle contrairement à un système de fichiers où il faudra lire les méta-données et les fichiers à l'endroit où ils se trouvent, induisant des temps d'accès.

Alors bien sûr ces deux cas d'utilisation n'ont pas du tout les mêmes applications. La première question à se poser est donc : pour quoi faire ?

Derinhger · 20-11-2016 21:10:03

Comme dit plus haut, c'est surtout du test et je ne pense pas utilisé sa sur des machines critiques.
Ensuite c'est sur que le système de cache disque est très performant et je ne cherche pas as réinventer la roue.

A la base c'est juste venu d'une discutions avec un collègue sur le possible ou pas, avantages vs inconvénients

Debian-facile

#1 19-11-2016 18:21:05

[résolu] Booter Debian en RAMDISK, possible ?

#2 19-11-2016 18:40:42

Re : [résolu] Booter Debian en RAMDISK, possible ?

#3 19-11-2016 18:44:54

Re : [résolu] Booter Debian en RAMDISK, possible ?

#4 19-11-2016 18:49:42

Re : [résolu] Booter Debian en RAMDISK, possible ?

#5 19-11-2016 19:20:22

Re : [résolu] Booter Debian en RAMDISK, possible ?

#6 19-11-2016 20:50:38

Re : [résolu] Booter Debian en RAMDISK, possible ?

#7 19-11-2016 21:09:44

Re : [résolu] Booter Debian en RAMDISK, possible ?

#8 20-11-2016 01:24:57

Re : [résolu] Booter Debian en RAMDISK, possible ?

#9 20-11-2016 09:26:49

Re : [résolu] Booter Debian en RAMDISK, possible ?

#10 20-11-2016 14:58:51

Re : [résolu] Booter Debian en RAMDISK, possible ?

#11 20-11-2016 19:17:06

Re : [résolu] Booter Debian en RAMDISK, possible ?

#12 20-11-2016 20:12:47

Re : [résolu] Booter Debian en RAMDISK, possible ?

#13 20-11-2016 21:10:03

Re : [résolu] Booter Debian en RAMDISK, possible ?

Pied de page des forums