Niente supporto RAMDISK su FC20?

Salve ragazzi,

dovendo utilizzare alcuni script che necessitano di molte letture/scritture su HD, per rendere il tutto più veloce ed efficiente
volevo sfruttare la creazione di uno spazio ram dedicato allo scopo, in modo tale da far girare tutto in un, appunto “ramdisk”.

Controllando il supporto per ramdisk ho visto che a differenza ad esempio del vecchio fc12, il comando

ls -al /dev/ram*

restituisce:
ls: impossibile accedere a /dev/ram*: File o directory non esistente :frowning:

Con fc12 avevo un elenco del tipo:
brw-rw----. 1 root disk 1, 0 27 set 11:38 /dev/ram0
brw-rw----. 1 root disk 1, 1 27 set 11:38 /dev/ram1
brw-rw----. 1 root disk 1, 10 27 set 11:38 /dev/ram10
brw-rw----. 1 root disk 1, 11 27 set 11:38 /dev/ram11
brw-rw----. 1 root disk 1, 12 27 set 11:38 /dev/ram12
brw-rw----. 1 root disk 1, 13 27 set 11:38 /dev/ram13
brw-rw----. 1 root disk 1, 14 27 set 11:38 /dev/ram14
brw-rw----. 1 root disk 1, 15 27 set 11:38 /dev/ram15
brw-rw----. 1 root disk 1, 2 27 set 11:38 /dev/ram2
brw-rw----. 1 root disk 1, 3 27 set 11:38 /dev/ram3
brw-rw----. 1 root disk 1, 4 27 set 11:38 /dev/ram4
brw-rw----. 1 root disk 1, 5 27 set 11:38 /dev/ram5
brw-rw----. 1 root disk 1, 6 27 set 11:38 /dev/ram6
brw-rw----. 1 root disk 1, 7 27 set 11:38 /dev/ram7
brw-rw----. 1 root disk 1, 8 27 set 11:38 /dev/ram8
brw-rw----. 1 root disk 1, 9 27 set 11:38 /dev/ram9

Come si può attivare il supporto ramdisk anche in fc20?

Grazie.

Ciao

RamFS è oramai obsoleto ed è stato sostituito da TmpFS che fa più o meno le stesse cose ma molto meglio.

Un tipico comando di montaggio può essere:

mount -t tmpfs -o size=512m tmpfs /mnt/ramdisk

/mnt/ramdisk si comporta logicamente come un qualsiasi disco con tanto di messaggi Disk Full.

P.S. se dai il comando df, vedrai che la maggior parte dei filesystem montati sono di tipo TmpFS.

Ciao Ciao, Moreno

Ciao Moreno, grazie!

Dunque, ho proceduto così:

mkdir -p /mnt/myramdisk
mount -t tmpfs -o size=512M tmpfs /mnt/myramdisk

Poi però ho effettuato un test di “velocità” con questo semplice script (dopo aver fatto un mkdir test all’interno di /mnt/myramdisk):

#!/bin/bash

clear

workdir="/home/master/Scrivania"
#workdir="/myramdisk/test"

count=1000

cd ${workdir}

date

for (( i=0;i<$count;i++ ))
do

  rm -f $workdir/prova.txt
  touch $workdir/prova.txt
  echo "Prova RAMDISK!" > $workdir/prova.txt

done

date

exit

Usando in un caso l’accesso a “/home/master/Scrivania” (e quindi all’HD) e nell’altro “/myramdisk/test” e quindi al ramdisk ottengo gli stessi risultati: 5 secondi (su un portatilino, un vecchio flybook). Nulla cambia nei tempi eppure si tratta di una semplice sequenza rimuovi file, crea file, scrivi nel file…

Tenuto conto che lo script che devo far girare è molto più complesso e usa anche operazioni grafiche (tipo convert) temo che non ci siamo. Ho già provato proprio con convert a fare delle operazioni grafiche nella ramdisk ma anche in questo caso ottengo gli stessi tempi.
Ho addirittura provato a spostare i binari di convert, rm, touch nella ramdisk (richiamandoli poi con path assoluta), ma niente…

Cosa ne pensi?

Non è un test significativo (la quantità dei dati su cui lavori è irrilevante e non sei sicuro siano stati scritti - vedasi fsync, fflush, politiche del filesystem come writeback ecc.). Prova questo (ho preso spunto dal tuo per quanto riguarda i path):

[code]#!/bin/bash

for d in /home/master/Scrivania /myramdisk/test; do
echo “# Performance su $d”
time dd if=/dev/zero of=$d/test bs=1M count=100 conv=fdatasync
done
[/code]

Ciao

Mi viene il forte sospetto che la partizione non sia stata montata e quindi, giustamente, i tempi di test sono identici.
Verifica l’effettivo montaggio con df.

Ho fatto il test di FraFra con risultati decisamente differenti:

# Performance su /
100+0 record dentro
100+0 record fuori
104857600 byte (105 MB) copiati, 1,39699 s, 75,1 MB/s

real    0m1.424s
user    0m0.001s
sys     0m0.275s
# Performance su /mnt/ramdisk
100+0 record dentro
100+0 record fuori
104857600 byte (105 MB) copiati, 0,123077 s, 852 MB/s

Una velocità di oltre 10 volte superiore, mica caramelle.

[postedit]
Ho fatto anche il tuo test che effettivamente non evidenzia grosse differenze di prestazioni.
Alzando il count a 10000 trovo il test in TmpFS più veloce del 15% (16 sec contro 19 sec)
[/postedit]

Ciao Ciao, Moreno

Ciao

Ho scoperto che RamDisk in realtà non è morto basta usare ramfs al posto di tmpfs

mount -t ramfs -o size=512M ramfs /mnt/myramdisk

La gestione è radicalmente diversa ed infatti il ramdisk non compare in df

Nel Test di FraFra le differenze sono vertiginose (con il RamFS si raggiungono i 2,4GB/Sec) mentre il tuo test non da alcuna differenza di prestazioni (sempre 16 secondi).

A quanto pare l’infrastruttura di gestione di tmpfs ne riduce parecchio le prestazioni.

Ciao Ciao, Moreno

bello, non conoscevo questa funzionalità (mi ricorda i tempi dell’Amiga)
però con “ramfs” la cartella “/mnt/myramdisk” è modificabile solo da root. mentre con “tmpfs” anche da utente normale.

Ciao

Ho fatto qualche altro test, in realtà non ci sono differenze significative di prestazione fra RamFS e TmpFS.

Ho riscritto lo script così:

#!/bin/bash

mount -t tmpfs -o size=512m tmpfs /mnt/tmpdisk
mount -t ramfs -o size=512m ramfs /mnt/ramdisk

for d in / /mnt/ramdisk /mnt/tmpdisk ; do
    echo "# Performance su $d"
    time dd if=/dev/zero of=$d/test bs=1M count=100 conv=fdatasync
done

umount -t ramfs /mnt/ramdisk
umount -t tmpfs /mnt/tmpdisk

ed il risultato del test è:

# Performance su /
100+0 record dentro
100+0 record fuori
104857600 byte (105 MB) copiati, 1,38532 s, 75,7 MB/s

real    0m1.391s
user    0m0.002s
sys     0m0.181s
# Performance su /mnt/ramdisk
100+0 record dentro
100+0 record fuori
104857600 byte (105 MB) copiati, 0,0697413 s, 1,5 GB/s

real    0m0.074s
user    0m0.001s
sys     0m0.064s
# Performance su /mnt/tmpdisk
100+0 record dentro
100+0 record fuori
104857600 byte (105 MB) copiati, 0,0594817 s, 1,8 GB/s

I risultati sui dischi ram sono comunque molto variabili, probabilmente sono molto sensibili al carico della CPU.

Ciao Ciao, Moreno

Ciao ragazzi! Allora, seguendo i vostri suggerimenti ho ottenuto quanto segue.

Per quanto riguarda il test di FraFra:

# Performance su /home/master/Scrivania
100+0 record dentro
100+0 record fuori
104857600 byte (105 MB) copiati, 3,01679 s, 34,8 MB/s

real	0m3.045s
user	0m0.000s
sys	0m0.199s
# Performance su /mnt/myramdisk/test
100+0 record dentro
100+0 record fuori
104857600 byte (105 MB) copiati, 0,0825553 s, 1,3 GB/s

real	0m0.084s
user	0m0.000s
sys	0m0.083s

Che abbia lavorato anche in ramdisk è confermato dal fatto che df -h fornisce:

tmpfs                                512M  100M    412M  20% /mnt/myramdisk

e quindi non solo è stato montato, ma come si vede è stato anche scritto. Stessi risultati anche in ramfs. E fin qui ok.

A questo punto ho riprovato il mio script di lettura/scrittura, con un for da 50000 cicli. Si nota chiaramente l’uso “intensivo” dell’HD quando lo si usa, spia praticamente spenta invece quando si usa la ramdisk. Tuttavia i tempi sono stati di 101 secondi esatti sia con l’HD sia con la ramdisk (sia tmpfs che ramfs). L’unico vantaggio quindi è la possibilità di stressare molto poco l’HD, ma nessun vantaggio in termini prestazionali…

Perciò a questo punto ho tagliato la testa al toro e ho provato il mio script di lavoro completo per entrambi i casi. In fondo è lui che poi deve girare. Il risultato è un nulla di fatto. Lo script in pratica prende dei dati alfanumerici da un file di circa 100MB e sulla base di questi dati “decide” dei simboli meteo (in png) da inserire su una mappa geografica (in png). Le elaborazioni grafiche avvengono tramite convert di imagemagick. Sono diversi cicli in cui a ogni passo viene fatta la sequenza suddetta.

So già che lo script in se non è efficiente, facendo molto uso anche di comandi come sed, grep e awk, ma pensavo, essendoci continui accessi all’HD (che infatti risulta molto impegnato) di poter comunque tagliare i tempi in modo significativo visti gli accessi continui alle varie png e al file da 100MB … e invece nisba. Addirittura tempi uguali al secondo (ma con impegno dell’HD opposto nei due casi)…

Non so che pensare. Anche se lo script non sarà efficiente e ottimizzato, questa identità di risultati mi lascia perplesso…