Rendimiento haciendo grabaciones en partición swap

Mirando comparativas entre sistemas de archivos por internet se puede
ver como el que mayor rendimiento ofrece y por bastante es ext2 sobre
cualquier otro, pero se me ha ocurrido no sé si tontería o locura del
rendimiento que podríamos tener haciendo las grabaciones sobre
particiones swap pero no encuentro nada comparando ext2 contra swap
respecto al rendimiento, ¿alguien sabe algo?.

Pero el giga permite grabar sobre partición swap? tengo 2 discos duros igualitos así que no me costaría mucho hacer la prueba.

Como hago la prueba de rendimiento? con el menú ordenes?

Como diría cortocircuito, datos datos datos!!!

Sólo era una idea loca sin fundamento ninguno, pero suponiendo que la swap es una extensión de la RAM en el disco duro entiendo que ofrecerá un mayor rendimiento que los sistemas de archivos convencionales.

Para grabar en la swap te creas una partición swap de varios gigas y creas un directorio que esté en la RAM como /var/swap, te configuras ese directorio como de grabaciones y al ir a grabar y no tener espacio en la RAM los grabará en la swap (aunque no sé si funcionará).

conceptualmente un swap es para lo que es, no para almacenar ficheros y directorios.
Eso que comentais no tiene sentido que funcione.
Cuando apagues el giga no se va a quedar guardado en el swap y si se queda guardado, al reiniciarlo, el kernel, no tiene porque saber como repurar esa informacion, porque es para intercambio de datos de programa en ejecución no para ficheros que perduran en el tiempo.

Ya estaba en que al apagar o al tener un apagón de luz pierdes lo que hubiera grabado, simplemente es una idea de concepto para ver si alguien sabía algo.

Bueno, lo pruebo o no?

pruebalo. :-)

Ok, lo estoy haciendo según he visto en una web, con dd=???? para hacer un fichero swap, supongo que así valdrá no?

Es que no he encontrado como hacer que todo el disco duro en si sea una partición swap.

Eso de crear la swap en un archivo no va a mejorar nada porque el sistema de archivos "padre" será ext2 o el que tenga esa partición y va a tener que usar las rutinas de manejo de archivos para acceder a ese archivo swap en lugar del acceso físico al disco.

Para tener una partición swap creas la partición con el fdisk como si lo hicieras para un disco duro normal y luego cambias el tipo al 82 que es la swap pulsando "t" y 82, guardas con "w" y finalmente la formateas con:

Código:

mkswap -v0 -p 4096 /dev/sda2

Para activar la swap tienes que ejecutar:

Código:

swapon /dev/sda2

Si lo pruebas y funciona sería cuestión de ejecutar un io-test con un archivo de entre 300 y 500 MB en la partición swap y en la ext2 para ver si hay alguna diferencia sustancial.

También podrías probar a desactivarla con:

Código:

swapoff /dev/sda2

y luego al activarla ver si las grabaciones siguen ahí, aunque me temo que no.

Si hay alguna mejora siempre se podía dejar el giga en apagado rápido con un SAI

Hola, había hecho la prueba, pero NO habia hecho el swapon, solo había puesto en el vdr la partición que era swap.
He utilizado un disco vacio que tengo (de cuando se me quemó el giga) y he hecho una partición entera como swap, lo raro es que en el menu información, la particion consta como ext2, pero si lo miras por fdisk es "swap"
Tampoco he hecho el mksap

Conclusión, ahora mismo me pongo y pruebo a hacerlo de nuevo.

Igualmente me decia que no habia espacio (cuando le decia en /var/swap)

Por cierto, yo pasaria este post a Beta no?

Bueno, he seguido todos los pasos (excepto pasar parámetro al mkswap, ya que no me acepta ninguno) y no me funciona.
Le he dicho que como grabación use el /var/swap, reinicio el giga, entro por telnet, vuelvo a crear el directorio ya que lo borra el reiniciar.
En configuracion de discos usb tengo como /dev/sda1 la swap, si entro en información veo que no ha montado ninguna partición (supongo que al ser swap no la monta)

En uso de memoria la cosa es un poco rara, pone lo siguiente:

Mem: 45108 43492 1616
Swap: 156288312 4960 156283352
Total: 156333420 48452 156284968

Da la sensación que ha cogido swap para hacer memoria, ya que tener 43 de 45 "free" no es normal.
Y luego la swap parece estar bien activada, pero al darle a grabar no grabar, y supongo que será que linux trata la swap como lo que es, y no sabe o no quiere grabar sobre ella (creo yo, vamos)

OK, gracias por las pruebas.
Así ya sabemos que no se pueden hacer grabaciones en RAM/Swap que es bastante útil para un tema que estoy mirando ahora y por el que se me había ocurrido esta idea.

Es que ni si quiera empezaba a grabar en /var/swap, directamente decia que no hay espacio, y cuando le dabas a menú, ponia 0:00 libre.

La solución pasará por poner el kernel 2.6 y soporte ext4

Estamos obligados a usar el kernel 2.4 para mantener la compatibilidad con los famosos drivers no liberados y más rendimiento que con ext2 no vas a tener con ningún otro.

Es que me parece que el ext4 tiene mucho más rendimiento que ext3, ext2 pero a costa de usar CPU no?

Igual estoy diciendo una tontería, pero lo que yo he entendido del funcionamiento del Linux embebido es que el rootfs está comprimido en la flash y se descomprime en memoria en el arranque. Para ello se crea un disco virtual, un ram disk, y se descomprime ahí la estructura de directorios y archivos.

Ese ram disk se crea con un tamaño concreto. Recuerdo que no hace mucho se estuvo barajando la posibilidad de reducir el tamaño de dicho disco virtual para dejar más memoria libre y que se pudieran chequear particiones de mayor tamaño, aunque se descartó la idea.

Entonces, cuado escribes en /var/swap, aunque es cierto que estás escribiendo en memoria, en realidad estás escribiendo en un disco (virtual) con un tamaño concreto. En ese disco no quedará mucho espacio libre, 10 o 15 Mb a lo sumo. Por eso el VDR dice que no hay espacio.

Para que al escribir en un directorio en memoria también se usara la swap habría que crear un ram disk de tamaño superior a la memoria real, de forma que parte de él estuviera en la swap. No sé si eso es posible o no (aunque dudo bastante que se pueda hacer), pero tiene otro problema: primero utilizaría toda la memoria física, obligando al resto de procesos a usar también la swap, haciendo caer el rendimiento de todo el sistema.

Con lo cual la única forma viable sería crear todo el disco virtual sobre la swap (posibilidad aún menos probable que la anterior). Pero, incluso en ese caso, supongo que el disco (virtual) tendría que tener algún sistema de archivos (que no sería swap), así que no ganaríamos nada.

El RootFS no se descomprime en memoria, simplemente se crea un disco RAM en "/var" y aquí se meten las cosas temporales o la información de la EPG hasta que se apaga.

Y con lo de la swap tienes toda la razón porque al crear el disco RAM limitará el tamaño y nunca va a ser mayor que la propia RAM (por eso no puede grabar), aunque el sistema de archivos que usamos en el firmware para el disco RAM es tmpfs, en lugar de ramfs como el wavebug ya que uno de los problemas graves del ramfs es que puede crecer por encima de tu RAM y entonces tienes un problema gordo.

En definitiva, que esta idea no tiene sentido ya que volvería inestable el sistema.

bittor escribió:El RootFS no se descomprime en memoria, simplemente se crea un disco RAM en "/var" y aquí se meten las cosas temporales o la información de la EPG hasta que se apaga.

¿Entonces lo que hace es montar la imagen del rootfs como disco y después un chroot?

Pensaba que funcionaba como otros Linux embebidos que había visto, que trabajan con módulos comprimidos (lzm o similares), descomprimiéndolos en RAM.

El giga tiene una Flash-RAM divida en varios bloques mtd donde está el kernel, RootFS, JFFS2, sistema de rescate, kernel del sistema de rescate, etc.

El RootFS usa el sistema de archivos CramFS o SquashFS (según el firm) que está comprimido, pero el kernel tiene soporte para acceder a ellos directamente sin necesidad de descomprimirlo en la RAM.

Aquí tienes información (en alemán) muy detallada sobre este tema:
http://www.open7x0.org/wiki/Flash-RAM

Gracias por el enlace.

Me resulta curioso que el sector de arranque (que supongo que es donde se situará el boot loader) no esté al principio de la flash. Supongo que los dos kernels que se incluyen en ese mtd son el normal y el de rescate, y que será el boot loader el que determine cuál de ellos arrancar.

Sí, yo también supongo eso, pero no lo sé seguro.
Aunque nuestro firmware usa además otro BootLoader porque el kernel que usamos supera el tamaño de un firmware M7x0 normal porque tiene incluidos más módulos y nuevas funcionalidades, por lo que ahora el kernel está comprimido en LZMA y para descomprimirlo se usa un BootLoader que está incluído en la misma imagen del kernel M7x0 (la que va en el firmware que incluye entre otras cosas el nuevo BootLoader, el System.map y la propia imagen del kernel).

Y, aún así, arranca mucho más rápido que el resto de firmwares.