26 Sep
2015
26 Sep
'15
6:39 p.m.
Hola gente:
Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
si alguien sabe si hay algo como lo que busco.
En estos momentos tengo una carpeta, digamos "A". Quiero hacer una serie
de operaciones en ella, pero no seré yo, sino una serie de programas,
que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
como quiero poder revertir todo en caso de que alguna operación salga
mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
"A.BACKUP" encima de A.
El problema es que la copia inicial es muy lenta, tarda demasiado
tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
Copy-On-Write. Supongo que la idea sería un sistema de ficheros virtual,
como AUFS. El problema de este es que, aunque me permite conservar el
contenido de una carpeta, y grabar en otra los cambios, no veo que me
permita mezclar los cambios sobre la carpeta original si, al final, todo
fue bien.
Empecé a escribir un sistema de archivos para FUSE, pero antes de seguir
quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
26 Sep
26 Sep
7:43 p.m.
Os filesystems CoW están pensados máis ben para as recuperacións en caso de
interrupción do sistema que escribe neles.
Para o que estás pensando eu usaría LVM snapshots nunha partición onde
estará montado ese directorio onde queres facer rollback ou podes montala
en paralelo no momento do snapshot para facer unha copia de seguridade e
desbotala ao rematar a copia. O downtime é virtualmente 0 ;)
2015-09-26 18:39 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com>om>:
Hola gente:
Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
si alguien sabe si hay algo como lo que busco.
En estos momentos tengo una carpeta, digamos "A". Quiero hacer una serie
de operaciones en ella, pero no seré yo, sino una serie de programas,
que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
como quiero poder revertir todo en caso de que alguna operación salga
mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
"A.BACKUP" encima de A.
El problema es que la copia inicial es muy lenta, tarda demasiado
tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
Copy-On-Write. Supongo que la idea sería un sistema de ficheros virtual,
como AUFS. El problema de este es que, aunque me permite conservar el
contenido de una carpeta, y grabar en otra los cambios, no veo que me
permita mezclar los cambios sobre la carpeta original si, al final, todo
fue bien.
Empecé a escribir un sistema de archivos para FUSE, pero antes de seguir
quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
--
Rafa Couto
GNU/Linux user #99126 - *http://bit.ly/LC-99126 <http://bit.ly/LC-99126>*
GPG key - http://bit.ly/GPG-D76ABDEC
8:47 p.m.
Os snapshots de LVM son demasiado pesados para o que quero. Ademáis,
supón crear unha unidade LVM para cada carpeta na que queira traballar,
e iso é excesivo. Eu preciso que as carpetas nas que traballo estén no
sistema de ficheiros normal.
El 26/09/15 a las 19:43, Rafa Couto escribió:
Os filesystems CoW están pensados máis ben para as recuperacións en
caso de interrupción do sistema que escribe neles.
Para o que estás pensando eu usaría LVM snapshots nunha partición onde
estará montado ese directorio onde queres facer rollback ou podes
montala en paralelo no momento do snapshot para facer unha copia de
seguridade e desbotala ao rematar a copia. O downtime é virtualmente 0 ;)
2015-09-26 18:39 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>>:
Hola gente:
Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
si alguien sabe si hay algo como lo que busco.
En estos momentos tengo una carpeta, digamos "A". Quiero hacer una
serie
de operaciones en ella, pero no seré yo, sino una serie de programas,
que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
como quiero poder revertir todo en caso de que alguna operación salga
mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
"A.BACKUP" encima de A.
El problema es que la copia inicial es muy lenta, tarda demasiado
tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
Copy-On-Write. Supongo que la idea sería un sistema de ficheros
virtual,
como AUFS. El problema de este es que, aunque me permite conservar el
contenido de una carpeta, y grabar en otra los cambios, no veo que me
permita mezclar los cambios sobre la carpeta original si, al
final, todo
fue bien.
Empecé a escribir un sistema de archivos para FUSE, pero antes de
seguir
quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Rafa Couto
GNU/Linux user #99126 - _http://bit.ly/LC-99126_
GPG key - http://bit.ly/GPG-D76ABDEC
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
27 Sep
27 Sep
8:16 p.m.
Igual a nivel de sistema de ficheiros váleche a implementación de BtfFS.
https://www.linux.com/learn/tutorials/767683-how-to-create-and-manage-btrfs…
2015-09-26 20:47 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com>om>:
Os snapshots de LVM son demasiado pesados para o que
quero. Ademáis, supón
crear unha unidade LVM para cada carpeta na que queira traballar, e iso é
excesivo. Eu preciso que as carpetas nas que traballo estén no sistema de
ficheiros normal.
El 26/09/15 a las 19:43, Rafa Couto escribió:
Os filesystems CoW están pensados máis ben para as recuperacións en caso
de interrupción do sistema que escribe neles.
Para o que estás pensando eu usaría LVM snapshots nunha partición onde
estará montado ese directorio onde queres facer rollback ou podes montala
en paralelo no momento do snapshot para facer unha copia de seguridade e
desbotala ao rematar a copia. O downtime é virtualmente 0 ;)
2015-09-26 18:39 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com>om>:
--
Rafa Couto
GNU/Linux user #99126 - *http://bit.ly/LC-99126 <http://bit.ly/LC-99126>*
GPG key - http://bit.ly/GPG-D76ABDEC
Hola gente:
Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
si alguien sabe si hay algo como lo que busco.
En estos momentos tengo una carpeta, digamos "A". Quiero hacer una serie
de operaciones en ella, pero no seré yo, sino una serie de programas,
que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
como quiero poder revertir todo en caso de que alguna operación salga
mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
"A.BACKUP" encima de A.
El problema es que la copia inicial es muy lenta, tarda demasiado
tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
Copy-On-Write. Supongo que la idea sería un sistema de ficheros virtual,
como AUFS. El problema de este es que, aunque me permite conservar el
contenido de una carpeta, y grabar en otra los cambios, no veo que me
permita mezclar los cambios sobre la carpeta original si, al final, todo
fue bien.
Empecé a escribir un sistema de archivos para FUSE, pero antes de seguir
quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
--
Rafa Couto
GNU/Linux user #99126 - * <http://bit.ly/LC-99126>http://bit.ly/LC-99126
<http://bit.ly/LC-99126>*
GPG key - http://bit.ly/GPG-D76ABDEC
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
8:21 p.m.
O problema é que iso só funciona con BTRFS...
El 27/09/15 a las 20:16, Rafa Couto escribió:
Igual a nivel de sistema de ficheiros váleche a implementación de
BtfFS.
https://www.linux.com/learn/tutorials/767683-how-to-create-and-manage-btrfs…
2015-09-26 20:47 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>>:
Os snapshots de LVM son demasiado pesados para o que quero.
Ademáis, supón crear unha unidade LVM para cada carpeta na que
queira traballar, e iso é excesivo. Eu preciso que as carpetas nas
que traballo estén no sistema de ficheiros normal.
El 26/09/15 a las 19:43, Rafa Couto escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
Os filesystems CoW están pensados máis ben para as recuperacións
en caso de interrupción do sistema que escribe neles.
Para o que estás pensando eu usaría LVM snapshots nunha partición
onde estará montado ese directorio onde queres facer rollback ou
podes montala en paralelo no momento do snapshot para facer unha
copia de seguridade e desbotala ao rematar a copia. O downtime é
virtualmente 0 ;)
2015-09-26 18:39 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>>:
Hola gente:
Estoy preparando un proyectillo y quiero mejorar su
rendimiento. A ver
si alguien sabe si hay algo como lo que busco.
En estos momentos tengo una carpeta, digamos "A". Quiero
hacer una serie
de operaciones en ella, pero no seré yo, sino una serie de
programas,
que añadirán, modificarán y borrarán ficheros y carpetas
dentro. Pero
como quiero poder revertir todo en caso de que alguna
operación salga
mal, antes de nada hago una copia de todo a "A.BACKUP". Al
final de
todo, si todo fue bien borro "A.BACKUP", y si hubo algún
error, copio
"A.BACKUP" encima de A.
El problema es que la copia inicial es muy lenta, tarda demasiado
tiempo. Por eso quería saber si hay alguna manera de hacerlo
en plan
Copy-On-Write. Supongo que la idea sería un sistema de
ficheros virtual,
como AUFS. El problema de este es que, aunque me permite
conservar el
contenido de una carpeta, y grabar en otra los cambios, no
veo que me
permita mezclar los cambios sobre la carpeta original si, al
final, todo
fue bien.
Empecé a escribir un sistema de archivos para FUSE, pero
antes de seguir
quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Rafa Couto
GNU/Linux user #99126 - _http://bit.ly/LC-99126_
GPG key - http://bit.ly/GPG-D76ABDEC
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Rafa Couto
GNU/Linux user #99126 - _http://bit.ly/LC-99126_
GPG key - http://bit.ly/GPG-D76ABDEC
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon 
8 a.m.
On Sat, 2015-09-26 at 18:39 +0200, Sergio Costas wrote:
El problema es que la copia inicial es muy lenta,
tarda demasiado
tiempo.
Si tienes un archivo grande y cambias un bit, sólo hay dos posibilidades
para volver a la versión original: sea restituir el bit o sea restituir
el archivo completo. La decisión la tomas tú, en función de tus
prioridades, y cada opción tiene sus implicaciones.
Si tu prioridad es la velocidad, tendrás que trazar la modificación
(sino solo le has cambiado el enfoque al problema) y restituir el bit.
Lo que puede resultar complejo. Personalmente, no sé si hay sistemas de
versionamiento a nivel de contenidos internos de un archivo. Sería
interesante saberlo. Si existen, tu problema está resuelto.
Si tu prioridad es la sencillez, probablemente puedes restituir todo el
archivo, a costo de la lentitud.
La idea de copy on write es buena, pero sólo te lleva a una solución
incompleta. Si modificas un bit sobre un archivo grande, la copia
seguirá causando demoras. Eso sí, parece mucho más fácil. Qué pasa si
llega una nueva modificación al mismo bit?
Por otro lado los sistemas de bases de datos -hasta donde entiendo-
básicamente almacenan un registro de cambios en memoria RAM hasta que
llega el commit, que es cuando se guarda una nuevo estado de la base.
Talvez algún conocedor de DBMS puede darte luces sobre esto. podrías
representar los archivos en una base de datos (dividirlos en small
chunks permitiría manejarlos con rapidez), modificarlos ahí y
simplemente aplicar los commit... Puedo equivocarme en esto, sólo los
conozco a nivel de usuario.
Saludos.
----------------------------------------------
Rodolfo Alcazar Portillo - rodolfoap(a)gmail.com
otbits.blogspot.com / counter.li.org: #367962
----------------------------------------------
Freedom is not to being able to choose options. Freedom is being able to
create options.
11:49 a.m.
Ya, ya lo se :) Aún así, en mi caso la carpeta contiene una mayoría de
archivos de los que sólo se va a leer, no escribir, y muchos son muy
grandes, por lo que un COW, aún a nivel de archivo, haría ganar mucha
velocidad igual. Además, la idea es tener un único snapshot al que
volver, por lo que no importa que se modifique varias veces un mismo
archivo, sólo se copiará una vez para poder volver al inicial, al de
antes de comenzar todas las operaciones.
De todas formas, al final me puse y terminé ya un prototipo de sistema
de ficheros para FUSE que hace lo que quiero. Ahora toca empezar las
pruebas y depurar.
Gracias de todas formas.
El 27/09/15 a las 08:00, NoSpaze escribió:
On Sat, 2015-09-26 at 18:39 +0200, Sergio Costas
wrote:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
El problema es que la copia inicial es muy lenta,
tarda demasiado
tiempo.
Si tienes un archivo grande y cambias un bit, sólo hay dos posibilidades
para volver a la versión original: sea restituir el bit o sea restituir
el archivo completo. La decisión la tomas tú, en función de tus
prioridades, y cada opción tiene sus implicaciones.
Si tu prioridad es la velocidad, tendrás que trazar la modificación
(sino solo le has cambiado el enfoque al problema) y restituir el bit.
Lo que puede resultar complejo. Personalmente, no sé si hay sistemas de
versionamiento a nivel de contenidos internos de un archivo. Sería
interesante saberlo. Si existen, tu problema está resuelto.
Si tu prioridad es la sencillez, probablemente puedes restituir todo el
archivo, a costo de la lentitud.
La idea de copy on write es buena, pero sólo te lleva a una solución
incompleta. Si modificas un bit sobre un archivo grande, la copia
seguirá causando demoras. Eso sí, parece mucho más fácil. Qué pasa si
llega una nueva modificación al mismo bit?
Por otro lado los sistemas de bases de datos -hasta donde entiendo-
básicamente almacenan un registro de cambios en memoria RAM hasta que
llega el commit, que es cuando se guarda una nuevo estado de la base.
Talvez algún conocedor de DBMS puede darte luces sobre esto. podrías
representar los archivos en una base de datos (dividirlos en small
chunks permitiría manejarlos con rapidez), modificarlos ahí y
simplemente aplicar los commit... Puedo equivocarme en esto, sólo los
conozco a nivel de usuario.
Saludos.
----------------------------------------------
Rodolfo Alcazar Portillo - rodolfoap(a)gmail.com
otbits.blogspot.com / counter.li.org: #367962
----------------------------------------------
Freedom is not to being able to choose options. Freedom is being able to
create options.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon 
4:31 p.m.
y digo yo.... te has planteado GIT ?? por que a grandes rasgos hace eso
El 27 de septiembre de 2015, 11:49, Sergio Costas <rastersoft(a)gmail.com>
escribió:
Ya, ya lo se :) Aún así, en mi caso la carpeta
contiene una mayoría de
archivos de los que sólo se va a leer, no escribir, y muchos son muy
grandes, por lo que un COW, aún a nivel de archivo, haría ganar mucha
velocidad igual. Además, la idea es tener un único snapshot al que
volver, por lo que no importa que se modifique varias veces un mismo
archivo, sólo se copiará una vez para poder volver al inicial, al de
antes de comenzar todas las operaciones.
De todas formas, al final me puse y terminé ya un prototipo de sistema
de ficheros para FUSE que hace lo que quiero. Ahora toca empezar las
pruebas y depurar.
Gracias de todas formas.
El 27/09/15 a las 08:00, NoSpaze escribió:
--
<<< this email was written with 100% recyclable electrons>>>
On Sat, 2015-09-26 at 18:39 +0200, Sergio Costas
wrote:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
El problema es que la copia inicial es muy lenta,
tarda demasiado
tiempo.
Si tienes un archivo grande y cambias un bit, sólo hay dos posibilidades
para volver a la versión original: sea restituir el bit o sea restituir
el archivo completo. La decisión la tomas tú, en función de tus
prioridades, y cada opción tiene sus implicaciones.
Si tu prioridad es la velocidad, tendrás que trazar la modificación
(sino solo le has cambiado el enfoque al problema) y restituir el bit.
Lo que puede resultar complejo. Personalmente, no sé si hay sistemas de
versionamiento a nivel de contenidos internos de un archivo. Sería
interesante saberlo. Si existen, tu problema está resuelto.
Si tu prioridad es la sencillez, probablemente puedes restituir todo el
archivo, a costo de la lentitud.
La idea de copy on write es buena, pero sólo te lleva a una solución
incompleta. Si modificas un bit sobre un archivo grande, la copia
seguirá causando demoras. Eso sí, parece mucho más fácil. Qué pasa si
llega una nueva modificación al mismo bit?
Por otro lado los sistemas de bases de datos -hasta donde entiendo-
básicamente almacenan un registro de cambios en memoria RAM hasta que
llega el commit, que es cuando se guarda una nuevo estado de la base.
Talvez algún conocedor de DBMS puede darte luces sobre esto. podrías
representar los archivos en una base de datos (dividirlos en small
chunks permitiría manejarlos con rapidez), modificarlos ahí y
simplemente aplicar los commit... Puedo equivocarme en esto, sólo los
conozco a nivel de usuario.
Saludos.
----------------------------------------------
Rodolfo Alcazar Portillo - rodolfoap(a)gmail.com
otbits.blogspot.com / counter.li.org: #367962
----------------------------------------------
Freedom is not to being able to choose options. Freedom is being able to
create options.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
5:01 p.m.
Lo pense; el problema es la inicialización: cuando hago el primer commit
tiene que copiar todo al repositorio, y eso tarda tanto como una copia a
secas. No sirve.
El 27/09/15 a las 16:31, Odo escribió:
y digo yo.... te has planteado GIT ?? por que a
grandes rasgos hace eso
El 27 de septiembre de 2015, 11:49, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
Ya, ya lo se :) Aún así, en mi caso la carpeta contiene una mayoría de
archivos de los que sólo se va a leer, no escribir, y muchos son muy
grandes, por lo que un COW, aún a nivel de archivo, haría ganar mucha
velocidad igual. Además, la idea es tener un único snapshot al que
volver, por lo que no importa que se modifique varias veces un mismo
archivo, sólo se copiará una vez para poder volver al inicial, al de
antes de comenzar todas las operaciones.
De todas formas, al final me puse y terminé ya un prototipo de sistema
de ficheros para FUSE que hace lo que quiero. Ahora toca empezar las
pruebas y depurar.
Gracias de todas formas.
El 27/09/15 a las 08:00, NoSpaze escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
On Sat, 2015-09-26 at 18:39 +0200, Sergio Costas
wrote:
posibilidades
El problema es que la copia inicial es muy lenta,
tarda demasiado
tiempo.
Si tienes un archivo grande y cambias un bit, sólo hay dos para volver a la versión original: sea restituir
el bit o sea
restituir
el archivo completo. La decisión la tomas tú, en
función de tus
prioridades, y cada opción tiene sus implicaciones.
Si tu prioridad es la velocidad, tendrás que trazar la modificación
(sino solo le has cambiado el enfoque al problema) y restituir
el bit.
Lo que puede resultar complejo. Personalmente, no
sé si hay
sistemas de
versionamiento a nivel de contenidos internos de
un archivo. Sería
interesante saberlo. Si existen, tu problema está resuelto.
Si tu prioridad es la sencillez, probablemente puedes restituir
todo el
archivo, a costo de la lentitud.
La idea de copy on write es buena, pero sólo te lleva a una solución
incompleta. Si modificas un bit sobre un archivo grande, la copia
seguirá causando demoras. Eso sí, parece mucho más fácil. Qué
pasa si
llega una nueva modificación al mismo bit?
Por otro lado los sistemas de bases de datos -hasta donde entiendo-
básicamente almacenan un registro de cambios en memoria RAM
hasta que
llega el commit, que es cuando se guarda una
nuevo estado de la
base.
Talvez algún conocedor de DBMS puede darte luces
sobre esto. podrías
representar los archivos en una base de datos (dividirlos en small
chunks permitiría manejarlos con rapidez), modificarlos ahí y
simplemente aplicar los commit... Puedo equivocarme en esto,
sólo los
conozco a nivel de usuario.
Saludos.
----------------------------------------------
Rodolfo Alcazar Portillo - rodolfoap(a)gmail.com
<mailto:rodolfoap@gmail.com>
otbits.blogspot.com
<http://otbits.blogspot.com> /
counter.li.org
<http://counter.li.org>: #367962
----------------------------------------------
Freedom is not to being able to choose options. Freedom is being
able to
create options.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
<<< this email was written with 100% recyclable electrons>>>
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
7:59 p.m.
Mi gozo en un pozo: a los contenedores no les gusta estar dentro de una
carpeta de FUSE :(
Gracias por las sugerencias, de todos modos.
El 27/09/15 a las 16:31, Odo escribió:
y digo yo.... te has planteado GIT ?? por que a
grandes rasgos hace eso
El 27 de septiembre de 2015, 11:49, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
Ya, ya lo se :) Aún así, en mi caso la carpeta contiene una mayoría de
archivos de los que sólo se va a leer, no escribir, y muchos son muy
grandes, por lo que un COW, aún a nivel de archivo, haría ganar mucha
velocidad igual. Además, la idea es tener un único snapshot al que
volver, por lo que no importa que se modifique varias veces un mismo
archivo, sólo se copiará una vez para poder volver al inicial, al de
antes de comenzar todas las operaciones.
De todas formas, al final me puse y terminé ya un prototipo de sistema
de ficheros para FUSE que hace lo que quiero. Ahora toca empezar las
pruebas y depurar.
Gracias de todas formas.
El 27/09/15 a las 08:00, NoSpaze escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
On Sat, 2015-09-26 at 18:39 +0200, Sergio Costas
wrote:
posibilidades
El problema es que la copia inicial es muy lenta,
tarda demasiado
tiempo.
Si tienes un archivo grande y cambias un bit, sólo hay dos para volver a la versión original: sea restituir
el bit o sea
restituir
el archivo completo. La decisión la tomas tú, en
función de tus
prioridades, y cada opción tiene sus implicaciones.
Si tu prioridad es la velocidad, tendrás que trazar la modificación
(sino solo le has cambiado el enfoque al problema) y restituir
el bit.
Lo que puede resultar complejo. Personalmente, no
sé si hay
sistemas de
versionamiento a nivel de contenidos internos de
un archivo. Sería
interesante saberlo. Si existen, tu problema está resuelto.
Si tu prioridad es la sencillez, probablemente puedes restituir
todo el
archivo, a costo de la lentitud.
La idea de copy on write es buena, pero sólo te lleva a una solución
incompleta. Si modificas un bit sobre un archivo grande, la copia
seguirá causando demoras. Eso sí, parece mucho más fácil. Qué
pasa si
llega una nueva modificación al mismo bit?
Por otro lado los sistemas de bases de datos -hasta donde entiendo-
básicamente almacenan un registro de cambios en memoria RAM
hasta que
llega el commit, que es cuando se guarda una
nuevo estado de la
base.
Talvez algún conocedor de DBMS puede darte luces
sobre esto. podrías
representar los archivos en una base de datos (dividirlos en small
chunks permitiría manejarlos con rapidez), modificarlos ahí y
simplemente aplicar los commit... Puedo equivocarme en esto,
sólo los
conozco a nivel de usuario.
Saludos.
----------------------------------------------
Rodolfo Alcazar Portillo - rodolfoap(a)gmail.com
<mailto:rodolfoap@gmail.com>
otbits.blogspot.com
<http://otbits.blogspot.com> /
counter.li.org
<http://counter.li.org>: #367962
----------------------------------------------
Freedom is not to being able to choose options. Freedom is being
able to
create options.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
<<< this email was written with 100% recyclable electrons>>>
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon 
28 Sep
28 Sep
8:35 a.m.
Puedes tirar de LD_PRELOAD.
Creas una libreria que implemente tu propia funcion write, que lo que haga sea una copia
del fichero que se pasa como parametro a write (en forma de FD).
Tiene la ventaja que valdría para cualqier programa.
Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas <rastersoft(a)gmail.com>
wrote:
Hola gente:
Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
si alguien sabe si hay algo como lo que busco.
En estos momentos tengo una carpeta, digamos "A". Quiero hacer una
serie
de operaciones en ella, pero no seré yo, sino una serie de programas,
que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
como quiero poder revertir todo en caso de que alguna operación salga
mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
"A.BACKUP" encima de A.
El problema es que la copia inicial es muy lenta, tarda demasiado
tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
Copy-On-Write. Supongo que la idea sería un sistema de ficheros
virtual,
como AUFS. El problema de este es que, aunque me permite conservar el
contenido de una carpeta, y grabar en otra los cambios, no veo que me
permita mezclar los cambios sobre la carpeta original si, al final,
todo
fue bien.
Empecé a escribir un sistema de archivos para FUSE, pero antes de
seguir
quería saber si ya existe algo así.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
9:29 a.m.
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
Puedes tirar de LD_PRELOAD.
Creas una libreria que implemente tu propia funcion write, que lo que haga sea una copia
del fichero que se pasa como parametro a write (en forma de FD).
Tiene la ventaja que valdría para cualqier programa.
Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas <rastersoft(a)gmail.com>
wrote:
> Hola gente:
>
> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
> si alguien sabe si hay algo como lo que busco.
>
> En estos momentos tengo una carpeta, digamos "A". Quiero hacer una
> serie
> de operaciones en ella, pero no seré yo, sino una serie de programas,
> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
> como quiero poder revertir todo en caso de que alguna operación salga
> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
> "A.BACKUP" encima de A.
>
> El problema es que la copia inicial es muy lenta, tarda demasiado
> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
> virtual,
> como AUFS. El problema de este es que, aunque me permite conservar el
> contenido de una carpeta, y grabar en otra los cambios, no veo que me
> permita mezclar los cambios sobre la carpeta original si, al final,
> todo
> fue bien.
>
> Empecé a escribir un sistema de archivos para FUSE, pero antes de
> seguir
> quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
9:43 a.m.
Raster,
lo que estas intentando buscar ya existe y se llama Docker.
Con docker lanzas contenedores a partir de imagenes preconstruidas, y
puedes guardar el estado del contenedor como una imagen.
Para la parte de almacenamiento tienes varias opciones, entre ellas
devicemapper usando thin volumes y snapshots, btrfs o aufs.
Un saludo.
El 28 de septiembre de 2015, 9:29, Sergio Costas <rastersoft(a)gmail.com>
escribió:
Eso valdría para un único programa, pero es que quiero
ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
Puedes tirar de LD_PRELOAD.
Creas una libreria que implemente tu propia funcion write, que lo que
haga sea una
copia del fichero que se pasa como parametro a write (en forma
de FD).
Tiene la ventaja que valdría para cualqier programa.
Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas <
rastersoft(a)gmail.com> wrote:
> Hola gente:
>
> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
> si alguien sabe si hay algo como lo que busco.
>
> En estos momentos tengo una carpeta, digamos "A". Quiero hacer una
> serie
> de operaciones en ella, pero no seré yo, sino una serie de programas,
> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
> como quiero poder revertir todo en caso de que alguna operación salga
> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
> "A.BACKUP" encima de A.
>
> El problema es que la copia inicial es muy lenta, tarda demasiado
> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
> virtual,
> como AUFS. El problema de este es que, aunque me permite conservar el
> contenido de una carpeta, y grabar en otra los cambios, no veo que me
> permita mezclar los cambios sobre la carpeta original si, al final,
> todo
> fue bien.
>
> Empecé a escribir un sistema de archivos para FUSE, pero antes de
> seguir
> quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
9:47 a.m.
El problema es que no me deja "mezclar" una imagen con su origen si lo
deseo.
El 28/09/15 a las 09:43, Ungoliant escribió:
Raster,
lo que estas intentando buscar ya existe y se llama Docker.
Con docker lanzas contenedores a partir de imagenes preconstruidas, y
puedes guardar el estado del contenedor como una imagen.
Para la parte de almacenamiento tienes varias opciones, entre ellas
devicemapper usando thin volumes y snapshots, btrfs o aufs.
Un saludo.
El 28 de septiembre de 2015, 9:29, Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>> escribió:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
Puedes tirar de LD_PRELOAD.
Creas una libreria que implemente tu propia funcion write, que
lo que haga sea
una copia del fichero que se pasa como parametro a
write (en forma de FD).
Tiene la ventaja que valdría para cualqier programa.
Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> wrote:
> Hola gente:
>
> Estoy preparando un proyectillo y quiero mejorar su
rendimiento. A ver
> si alguien sabe si hay algo como lo que
busco.
>
> En estos momentos tengo una carpeta, digamos "A". Quiero hacer una
> serie
> de operaciones en ella, pero no seré yo, sino una serie de
programas,
> que añadirán, modificarán y borrarán ficheros
y carpetas
dentro. Pero
> como quiero poder revertir todo en caso de
que alguna operación
salga
> mal, antes de nada hago una copia de todo a
"A.BACKUP". Al final de
> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error,
copio
> "A.BACKUP" encima de A.
>
> El problema es que la copia inicial es muy lenta, tarda demasiado
> tiempo. Por eso quería saber si hay alguna manera de hacerlo en
plan
> Copy-On-Write. Supongo que la idea sería un
sistema de ficheros
> virtual,
> como AUFS. El problema de este es que, aunque me permite
conservar el
> contenido de una carpeta, y grabar en otra
los cambios, no veo
que me
> permita mezclar los cambios sobre la carpeta
original si, al final,
> todo
> fue bien.
>
> Empecé a escribir un sistema de archivos para FUSE, pero antes de
> seguir
> quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
9:48 a.m.
Ah, y además, docker sólo admite imágenes de 64 bits de manera oficial,
y las de 32 bits aún no están nada pulidas :(
El 28/09/15 a las 09:43, Ungoliant escribió:
Raster,
lo que estas intentando buscar ya existe y se llama Docker.
Con docker lanzas contenedores a partir de imagenes preconstruidas, y
puedes guardar el estado del contenedor como una imagen.
Para la parte de almacenamiento tienes varias opciones, entre ellas
devicemapper usando thin volumes y snapshots, btrfs o aufs.
Un saludo.
El 28 de septiembre de 2015, 9:29, Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>> escribió:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
Puedes tirar de LD_PRELOAD.
Creas una libreria que implemente tu propia funcion write, que
lo que haga sea
una copia del fichero que se pasa como parametro a
write (en forma de FD).
Tiene la ventaja que valdría para cualqier programa.
Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> wrote:
> Hola gente:
>
> Estoy preparando un proyectillo y quiero mejorar su
rendimiento. A ver
> si alguien sabe si hay algo como lo que
busco.
>
> En estos momentos tengo una carpeta, digamos "A". Quiero hacer una
> serie
> de operaciones en ella, pero no seré yo, sino una serie de
programas,
> que añadirán, modificarán y borrarán ficheros
y carpetas
dentro. Pero
> como quiero poder revertir todo en caso de
que alguna operación
salga
> mal, antes de nada hago una copia de todo a
"A.BACKUP". Al final de
> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error,
copio
> "A.BACKUP" encima de A.
>
> El problema es que la copia inicial es muy lenta, tarda demasiado
> tiempo. Por eso quería saber si hay alguna manera de hacerlo en
plan
> Copy-On-Write. Supongo que la idea sería un
sistema de ficheros
> virtual,
> como AUFS. El problema de este es que, aunque me permite
conservar el
> contenido de una carpeta, y grabar en otra
los cambios, no veo
que me
> permita mezclar los cambios sobre la carpeta
original si, al final,
> todo
> fue bien.
>
> Empecé a escribir un sistema de archivos para FUSE, pero antes de
> seguir
> quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
9:43 a.m.
HDYS, si exportas la variable LD_PRELOAD, al ponerlas en el entorno, le afecta a todos los
programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas <rastersoft(a)gmail.com>
wrote:
Eso valdría para un único programa, pero es que quiero
ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Puedes tirar de LD_PRELOAD.
Creas una libreria que implemente tu propia funcion write, que lo que
haga sea una
copia del fichero que se pasa como parametro a write (en
forma de FD).
Tiene la ventaja que valdría para cualqier programa.
Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> wrote:
> Hola gente:
>
> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A
ver
> si alguien sabe si hay algo como lo que
busco.
>
> En estos momentos tengo una carpeta, digamos "A". Quiero hacer una
> serie
> de operaciones en ella, pero no seré yo, sino una serie de
programas,
> que añadirán, modificarán y borrarán ficheros
y carpetas dentro.
Pero
> como quiero poder revertir todo en caso de
que alguna operación
salga
> mal, antes de nada hago una copia de todo a
"A.BACKUP". Al final de
> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error,
copio
> "A.BACKUP" encima de A.
>
> El problema es que la copia inicial es muy lenta, tarda demasiado
> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
> virtual,
> como AUFS. El problema de este es que, aunque me permite conservar
el
> contenido de una carpeta, y grabar en otra
los cambios, no veo que
me
> permita mezclar los cambios sobre la carpeta
original si, al final,
> todo
> fue bien.
>
> Empecé a escribir un sistema de archivos para FUSE, pero antes de
> seguir
> quería saber si ya existe algo así.
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
------------------------------------------------------------------------
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
9:50 a.m.
Pero eso obligaría a meterlo dentro de la imagen, y una vez hecho el
"chroot", el código de la biblioteca ya no tendría acceso a la carpeta
donde guardar los cambios, pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
HDYS, si exportas la variable LD_PRELOAD, al ponerlas
en el entorno,
le afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> wrote:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
Puedes tirar de LD_PRELOAD. Creas una libreria que implemente
tu propia funcion write, que lo que haga sea una copia del
fichero que se pasa como parametro a write (en forma de FD).
Tiene la ventaja que valdría para cualqier programa. Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> wrote:
Hola gente: Estoy preparando un proyectillo y quiero
mejorar su rendimiento. A ver si alguien sabe si hay algo
como lo que busco. En estos momentos tengo una carpeta,
digamos "A". Quiero hacer una serie de operaciones en
ella, pero no seré yo, sino una serie de programas, que
añadirán, modificarán y borrarán ficheros y carpetas
dentro. Pero como quiero poder revertir todo en caso de
que alguna operación salga mal, antes de nada hago una
copia de todo a "A.BACKUP". Al final de todo, si todo fue
bien borro "A.BACKUP", y si hubo algún error, copio
"A.BACKUP" encima de A. El problema es que la copia
inicial es muy lenta, tarda demasiado tiempo. Por eso
quería saber si hay alguna manera de hacerlo en plan
Copy-On-Write. Supongo que la idea sería un sistema de
ficheros virtual, como AUFS. El problema de este es que,
aunque me permite conservar el contenido de una carpeta, y
grabar en otra los cambios, no veo que me permita mezclar
los cambios sobre la carpeta original si, al final, todo
fue bien. Empecé a escribir un sistema de archivos para
FUSE, pero antes de seguir quería saber si ya existe algo
así.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
10:45 a.m.
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar lo
que
quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un contenedor a
partir de una imagen, y tras los cambios, si funciona, haces un commit para
crear una imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas <rastersoft(a)gmail.com>
escribió:
Pero eso obligaría a meterlo dentro de la imagen, y
una vez hecho el
"chroot", el código de la biblioteca ya no tendría acceso a la carpeta
donde guardar los cambios, pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
HDYS, si exportas la variable LD_PRELOAD, al ponerlas en el entorno, le
afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <rastersoft(a)gmail.com> wrote:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
>
> Puedes tirar de LD_PRELOAD.
> Creas una libreria que implemente tu propia funcion write, que lo que haga sea una
copia del fichero que se pasa como parametro a write (en forma de FD).
>
> Tiene la ventaja que valdría para cualqier programa.
>
> Un saludo
>
> On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <rastersoft(a)gmail.com> wrote:
>>
>> Hola gente:
>>
>> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
>> si alguien sabe si hay algo como lo que busco.
>>
>> En estos momentos
>> tengo una carpeta, digamos "A". Quiero hacer una
>> serie
>> de operaciones en ella, pero no seré yo, sino una serie de programas,
>> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
>> como quiero poder revertir todo en caso de que alguna operación salga
>> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
>> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
>> "A.BACKUP" encima de A.
>>
>> El problema es que la copia inicial es muy lenta, tarda demasiado
>> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
>> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
>> virtual,
>> como AUFS. El problema de este es que, aunque me permite conservar el
>> contenido de una carpeta, y grabar en otra los cambios, no veo que me
>> permita mezclar los cambios sobre la carpeta original si, al final,
>> todo
>> fue bien.
>>
>> Empecé a
>> escribir un sistema de archivos para FUSE, pero antes de
>> seguir
>> quería saber si ya existe algo así.
>
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
10:49 a.m.
Si, la parte de las imágenes podría solucionarlo. El problema sigue
siendo los 32 bits. Hay imágenes no oficiales, pero dado que docker en
sí no funciona en modo 32 bits, y parece que tiene que copiar su propio
ejecutable dentro de la imagen, obliga a que el contenedor funcione en
modo 64 bits aunque todo el código interno sea de 32. Y eso me puede dar
problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar lo
que quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un contenedor
a partir de una imagen, y tras los cambios, si funciona, haces un
commit para crear una imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>> escribió:
Pero eso obligaría a meterlo dentro de la imagen, y una vez hecho
el "chroot", el código de la biblioteca ya no tendría acceso a la
carpeta donde guardar los cambios, pues se supone que estaría
fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
HDYS, si exportas la variable LD_PRELOAD, al
ponerlas en el
entorno, le afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero
supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <mailto:rastersoft@gmail.com> wrote:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
Puedes tirar de LD_PRELOAD. Creas una libreria que
implemente tu propia funcion write, que lo que haga sea
una copia del fichero que se pasa como parametro a write
(en forma de FD). Tiene la ventaja que valdría para
cualqier programa. Un saludo On September 26, 2015
6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <mailto:rastersoft@gmail.com> wrote:
Hola gente: Estoy preparando un proyectillo y quiero
mejorar su rendimiento. A ver si alguien sabe si hay
algo como lo que busco. En estos momentos tengo una
carpeta, digamos "A". Quiero hacer una serie de
operaciones en ella, pero no seré yo, sino una serie
de programas, que añadirán, modificarán y borrarán
ficheros y carpetas dentro. Pero como quiero poder
revertir todo en caso de que alguna operación salga
mal, antes de nada hago una copia de todo a
"A.BACKUP". Al final de todo, si todo fue bien borro
"A.BACKUP", y si hubo algún error, copio "A.BACKUP"
encima de A. El problema es que la copia inicial es
muy lenta, tarda demasiado tiempo. Por eso quería
saber si hay alguna manera de hacerlo en plan
Copy-On-Write. Supongo que la idea sería un sistema
de ficheros virtual, como AUFS. El problema de este
es que, aunque me permite conservar el contenido de
una carpeta, y grabar en otra los cambios, no veo que
me permita mezclar los cambios sobre la carpeta
original si, al final, todo fue bien. Empecé a
escribir un sistema de archivos para FUSE, pero antes
de seguir quería saber si ya existe algo así.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
10:59 a.m.
Ya tienes que tener una muy buena razón para no migrar a un entorno de 64
bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se empieza a ver cada
vez mas software en el cual la version 32bit se queda rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas <rastersoft(a)gmail.com>
escribió:
Si, la parte de las imágenes podría solucionarlo. El
problema sigue siendo
los 32 bits. Hay imágenes no oficiales, pero dado que docker en sí no
funciona en modo 32 bits, y parece que tiene que copiar su propio
ejecutable dentro de la imagen, obliga a que el contenedor funcione en modo
64 bits aunque todo el código interno sea de 32. Y eso me puede dar
problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar lo
que
quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un contenedor a
partir de una imagen, y tras los cambios, si funciona, haces un commit para
crear una imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas <rastersoft(a)gmail.com>
escribió:
Pero eso obligaría a meterlo dentro de la imagen,
y una vez hecho el
"chroot", el código de la biblioteca ya no tendría acceso a la carpeta
donde guardar los cambios, pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
HDYS, si exportas la variable LD_PRELOAD, al ponerlas en el entorno, le
afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft@gmail.com><rastersoft@gmail.com> <rastersoft(a)gmail.com>
wrote:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
>
> Puedes tirar de LD_PRELOAD.
> Creas una libreria que implemente tu propia funcion write, que lo que haga sea una
copia del fichero que se pasa como parametro a write (en forma de FD).
>
> Tiene la ventaja que valdría para cualqier programa.
>
> Un saludo
>
> On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <rastersoft(a)gmail.com> wrote:
>>
>> Hola gente:
>>
>> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
>> si alguien sabe si hay algo como lo que busco.
>>
>> En estos momentos
>> tengo una carpeta, digamos "A". Quiero hacer una
>> serie
>> de operaciones en ella, pero no seré yo, sino una serie de programas,
>> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
>> como quiero poder revertir todo en caso de que alguna operación salga
>> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
>> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
>> "A.BACKUP" encima de A.
>>
>> El problema es que la copia inicial es muy lenta, tarda demasiado
>> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
>> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
>> virtual,
>> como AUFS. El problema de este es que, aunque me permite conservar el
>> contenido de una carpeta, y grabar en otra los cambios, no veo que me
>> permita mezclar los cambios sobre la carpeta original si, al final,
>> todo
>> fue bien.
>>
>> Empecé a
>> escribir un sistema de archivos para FUSE, pero antes de
>> seguir
>> quería saber si ya existe algo así.
>
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
11:23 a.m.
A ver, lo explico mejor: se trata de mejorar el rendimiento de mi
programa MULTIPACKAGER, que me permite generar paquetes para cualquier
distro y arquitectura. Hoy en día me genera sin problemas paquetes de 32
y 64 bits para debian, ubuntu, fedora y arch, tanto en 32 como 64 bits,
y dado que está todo automatizado me parece absurdo discriminar a los 32
bits, cuando aún hoy siguen teniendo uso (marginal, sí, pero es que ya
digo que el proceso de generación está automatizado, y una vez que tengo
listos los 64 bits, los 32 no suponen trabajo alguno). Si meto docker
(que haría que fuese algo más rápido) perdería la ventaja de generar
paquetes de 32 bits.
Ese es el motivo de no querer renunciar a los 32 bits.
El 28/09/15 a las 10:59, Ungoliant escribió:
Ya tienes que tener una muy buena razón para no migrar a un entorno de
64 bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se empieza a ver
cada vez mas software en el cual la version 32bit se queda rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
Si, la parte de las imágenes podría solucionarlo. El problema
sigue siendo los 32 bits. Hay imágenes no oficiales, pero dado que
docker en sí no funciona en modo 32 bits, y parece que tiene que
copiar su propio ejecutable dentro de la imagen, obliga a que el
contenedor funcione en modo 64 bits aunque todo el código interno
sea de 32. Y eso me puede dar problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar
lo que quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un
contenedor a partir de una imagen, y tras los cambios, si
funciona, haces un commit para crear una imagen a partir del
contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
Pero eso obligaría a meterlo dentro de la imagen, y una vez
hecho el "chroot", el código de la biblioteca ya no tendría
acceso a la carpeta donde guardar los cambios, pues se supone
que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon HDYS, si exportas la variable LD_PRELOAD,
al ponerlas en el
entorno, le afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero
supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <mailto:rastersoft@gmail.com> wrote:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
Puedes tirar de LD_PRELOAD. Creas una libreria que
implemente tu propia funcion write, que lo que haga
sea una copia del fichero que se pasa como parametro
a write (en forma de FD). Tiene la ventaja que
valdría para cualqier programa. Un saludo On
September 26, 2015 6:39:33 PM GMT+02:00, Sergio
Costas <rastersoft(a)gmail.com>
<mailto:rastersoft@gmail.com> wrote:
Hola gente: Estoy preparando un proyectillo y
quiero mejorar su rendimiento. A ver si alguien
sabe si hay algo como lo que busco. En estos
momentos tengo una carpeta, digamos "A". Quiero
hacer una serie de operaciones en ella, pero no
seré yo, sino una serie de programas, que
añadirán, modificarán y borrarán ficheros y
carpetas dentro. Pero como quiero poder revertir
todo en caso de que alguna operación salga mal,
antes de nada hago una copia de todo a
"A.BACKUP". Al final de todo, si todo fue bien
borro "A.BACKUP", y si hubo algún error, copio
"A.BACKUP" encima de A. El problema es que la
copia inicial es muy lenta, tarda demasiado
tiempo. Por eso quería saber si hay alguna
manera de hacerlo en plan Copy-On-Write. Supongo
que la idea sería un sistema de ficheros
virtual, como AUFS. El problema de este es que,
aunque me permite conservar el contenido de una
carpeta, y grabar en otra los cambios, no veo
que me permita mezclar los cambios sobre la
carpeta original si, al final, todo fue bien.
Empecé a escribir un sistema de archivos para
FUSE, pero antes de seguir quería saber si ya
existe algo así.
--
Sent from my Android device with K-9 Mail. Please excuse my
brevity.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
1:04 p.m.
Sergio, sinceramente, y sin interes niguno de desanimarte, sino todo lo
contrario, por que a mi tambien me pasa de querer perfeccionar demasiado
las cosas.
creo en mi humilde opinion, que para el caso que estas descriviendo el
esfuerzo de la mejora es superior al beneficio y resultaría mejor dejarlo
tal y como esta y dedicar tu tiempo y esfuerzo a una tarea que tenga un
beneficio mayor.
El 28 de septiembre de 2015, 11:23, Sergio Costas <rastersoft(a)gmail.com>
escribió:
A ver, lo explico mejor: se trata de mejorar el
rendimiento de mi programa
MULTIPACKAGER, que me permite generar paquetes para cualquier distro y
arquitectura. Hoy en día me genera sin problemas paquetes de 32 y 64 bits
para debian, ubuntu, fedora y arch, tanto en 32 como 64 bits, y dado que
está todo automatizado me parece absurdo discriminar a los 32 bits, cuando
aún hoy siguen teniendo uso (marginal, sí, pero es que ya digo que el
proceso de generación está automatizado, y una vez que tengo listos los 64
bits, los 32 no suponen trabajo alguno). Si meto docker (que haría que
fuese algo más rápido) perdería la ventaja de generar paquetes de 32 bits.
Ese es el motivo de no querer renunciar a los 32 bits.
El 28/09/15 a las 10:59, Ungoliant escribió:
Ya tienes que tener una muy buena razón para no migrar a un entorno de 64
bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se empieza a ver cada
vez mas software en el cual la version 32bit se queda rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas <rastersoft(a)gmail.com>
escribió:
--
<<< this email was written with 100% recyclable electrons>>>
Si, la parte de las imágenes podría solucionarlo.
El problema sigue
siendo los 32 bits. Hay imágenes no oficiales, pero dado que docker en sí
no funciona en modo 32 bits, y parece que tiene que copiar su propio
ejecutable dentro de la imagen, obliga a que el contenedor funcione en modo
64 bits aunque todo el código interno sea de 32. Y eso me puede dar
problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar lo
que
quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un contenedor a
partir de una imagen, y tras los cambios, si funciona, haces un commit para
crear una imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas < <rastersoft(a)gmail.com>
rastersoft(a)gmail.com> escribió:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Pero eso obligaría a meterlo dentro de la imagen,
y una vez hecho el
"chroot", el código de la biblioteca ya no tendría acceso a la carpeta
donde guardar los cambios, pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
HDYS, si exportas la variable LD_PRELOAD, al ponerlas en el entorno, le
afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que
si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft@gmail.com><rastersoft@gmail.com> <rastersoft(a)gmail.com>
wrote:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
>
> Puedes tirar de LD_PRELOAD.
> Creas una libreria que implemente tu propia funcion write, que lo que haga sea una
copia del fichero que se pasa como parametro a write (en forma de FD).
>
> Tiene la ventaja que valdría para cualqier programa.
>
> Un saludo
>
> On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <rastersoft(a)gmail.com> wrote:
>>
>> Hola gente:
>>
>> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
>> si alguien sabe si hay algo como lo que busco.
>>
>> En estos momentos
>> tengo una carpeta, digamos "A". Quiero hacer una
>> serie
>> de operaciones en ella, pero no seré yo, sino una serie de programas,
>> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
>> como quiero poder revertir todo en caso de que alguna operación salga
>> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
>> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
>> "A.BACKUP" encima de A.
>>
>> El problema es que la copia inicial es muy lenta, tarda demasiado
>> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
>> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
>> virtual,
>> como AUFS. El problema de este es que, aunque me permite conservar el
>> contenido de una carpeta, y grabar en otra los cambios, no veo que me
>> permita mezclar los cambios sobre la carpeta original si, al final,
>> todo
>> fue bien.
>>
>> Empecé a
>> escribir un sistema de archivos para FUSE, pero antes de
>> seguir
>> quería saber si ya existe algo así.
>
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
1:23 p.m.
Estoy de acuerdo...
El 28/09/15 a las 13:04, Odo escribió:
Sergio, sinceramente, y sin interes niguno de
desanimarte, sino todo
lo contrario, por que a mi tambien me pasa de querer perfeccionar
demasiado las cosas.
creo en mi humilde opinion, que para el caso que estas descriviendo
el esfuerzo de la mejora es superior al beneficio y resultaría mejor
dejarlo tal y como esta y dedicar tu tiempo y esfuerzo a una tarea que
tenga un beneficio mayor.
El 28 de septiembre de 2015, 11:23, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
A ver, lo explico mejor: se trata de mejorar el rendimiento de mi
programa MULTIPACKAGER, que me permite generar paquetes para
cualquier distro y arquitectura. Hoy en día me genera sin
problemas paquetes de 32 y 64 bits para debian, ubuntu, fedora y
arch, tanto en 32 como 64 bits, y dado que está todo automatizado
me parece absurdo discriminar a los 32 bits, cuando aún hoy siguen
teniendo uso (marginal, sí, pero es que ya digo que el proceso de
generación está automatizado, y una vez que tengo listos los 64
bits, los 32 no suponen trabajo alguno). Si meto docker (que haría
que fuese algo más rápido) perdería la ventaja de generar paquetes
de 32 bits.
Ese es el motivo de no querer renunciar a los 32 bits.
El 28/09/15 a las 10:59, Ungoliant escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
Ya tienes que tener una muy buena razón para no migrar a un
entorno de 64 bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se empieza a
ver cada vez mas software en el cual la version 32bit se queda
rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
Si, la parte de las imágenes podría solucionarlo. El problema
sigue siendo los 32 bits. Hay imágenes no oficiales, pero
dado que docker en sí no funciona en modo 32 bits, y parece
que tiene que copiar su propio ejecutable dentro de la
imagen, obliga a que el contenedor funcione en modo 64 bits
aunque todo el código interno sea de 32. Y eso me puede dar
problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
<<< this email was written with 100% recyclable electrons>>>
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Combinando el proceso de "crear" y el de "lanzar" puedes
mezclar lo que quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un
contenedor a partir de una imagen, y tras los cambios, si
funciona, haces un commit para crear una imagen a partir del
contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
Pero eso obligaría a meterlo dentro de la imagen, y una
vez hecho el "chroot", el código de la biblioteca ya no
tendría acceso a la carpeta donde guardar los cambios,
pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon HDYS, si exportas la variable
LD_PRELOAD, al ponerlas
en el entorno, le afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn
pero supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio
Costas <rastersoft(a)gmail.com>
<mailto:rastersoft@gmail.com> wrote:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
Puedes tirar de LD_PRELOAD. Creas una libreria
que implemente tu propia funcion write, que lo
que haga sea una copia del fichero que se pasa
como parametro a write (en forma de FD). Tiene
la ventaja que valdría para cualqier programa.
Un saludo On September 26, 2015 6:39:33 PM
GMT+02:00, Sergio Costas <rastersoft(a)gmail.com>
<mailto:rastersoft@gmail.com> wrote:
Hola gente: Estoy preparando un proyectillo
y quiero mejorar su rendimiento. A ver si
alguien sabe si hay algo como lo que busco.
En estos momentos tengo una carpeta,
digamos "A". Quiero hacer una serie de
operaciones en ella, pero no seré yo, sino
una serie de programas, que añadirán,
modificarán y borrarán ficheros y carpetas
dentro. Pero como quiero poder revertir
todo en caso de que alguna operación salga
mal, antes de nada hago una copia de todo a
"A.BACKUP". Al final de todo, si todo fue
bien borro "A.BACKUP", y si hubo algún
error, copio "A.BACKUP" encima de A. El
problema es que la copia inicial es muy
lenta, tarda demasiado tiempo. Por eso
quería saber si hay alguna manera de
hacerlo en plan Copy-On-Write. Supongo que
la idea sería un sistema de ficheros
virtual, como AUFS. El problema de este es
que, aunque me permite conservar el
contenido de una carpeta, y grabar en otra
los cambios, no veo que me permita mezclar
los cambios sobre la carpeta original si,
al final, todo fue bien. Empecé a escribir
un sistema de archivos para FUSE, pero
antes de seguir quería saber si ya existe
algo así.
--
Sent from my Android device with K-9 Mail. Please
excuse my brevity.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
14 Apr
14 Apr
10:15 a.m.
Ao final o tes solucionado? Exploraches a opción de UnionFS nun kernel 32
bits? (ou sexa, degradar docker a 32bits ;)
2015-09-28 11:23 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com>om>:
A ver, lo explico mejor: se trata de mejorar el
rendimiento de mi programa
MULTIPACKAGER, que me permite generar paquetes para cualquier distro y
arquitectura. Hoy en día me genera sin problemas paquetes de 32 y 64 bits
para debian, ubuntu, fedora y arch, tanto en 32 como 64 bits, y dado que
está todo automatizado me parece absurdo discriminar a los 32 bits, cuando
aún hoy siguen teniendo uso (marginal, sí, pero es que ya digo que el
proceso de generación está automatizado, y una vez que tengo listos los 64
bits, los 32 no suponen trabajo alguno). Si meto docker (que haría que
fuese algo más rápido) perdería la ventaja de generar paquetes de 32 bits.
Ese es el motivo de no querer renunciar a los 32 bits.
El 28/09/15 a las 10:59, Ungoliant escribió:
Ya tienes que tener una muy buena razón para no migrar a un entorno de 64
bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se empieza a ver cada
vez mas software en el cual la version 32bit se queda rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas <rastersoft(a)gmail.com>
escribió:
--
Rafa Couto
GNU/Linux user #99126 - *http://bit.ly/LC-99126 <http://bit.ly/LC-99126>*
GPG key - http://bit.ly/GPG-D76ABDEC
Si, la parte de las imágenes podría solucionarlo.
El problema sigue
siendo los 32 bits. Hay imágenes no oficiales, pero dado que docker en sí
no funciona en modo 32 bits, y parece que tiene que copiar su propio
ejecutable dentro de la imagen, obliga a que el contenedor funcione en modo
64 bits aunque todo el código interno sea de 32. Y eso me puede dar
problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar lo
que
quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un contenedor a
partir de una imagen, y tras los cambios, si funciona, haces un commit para
crear una imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas < <rastersoft(a)gmail.com>
rastersoft(a)gmail.com> escribió:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Pero eso obligaría a meterlo dentro de la imagen,
y una vez hecho el
"chroot", el código de la biblioteca ya no tendría acceso a la carpeta
donde guardar los cambios, pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
HDYS, si exportas la variable LD_PRELOAD, al ponerlas en el entorno, le
afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que
si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft@gmail.com><rastersoft@gmail.com> <rastersoft(a)gmail.com>
wrote:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
>
> Puedes tirar de LD_PRELOAD.
> Creas una libreria que implemente tu propia funcion write, que lo que haga sea una
copia del fichero que se pasa como parametro a write (en forma de FD).
>
> Tiene la ventaja que valdría para cualqier programa.
>
> Un saludo
>
> On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <rastersoft(a)gmail.com> wrote:
>>
>> Hola gente:
>>
>> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
>> si alguien sabe si hay algo como lo que busco.
>>
>> En estos momentos
>> tengo una carpeta, digamos "A". Quiero hacer una
>> serie
>> de operaciones en ella, pero no seré yo, sino una serie de programas,
>> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
>> como quiero poder revertir todo en caso de que alguna operación salga
>> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final de
>> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error, copio
>> "A.BACKUP" encima de A.
>>
>> El problema es que la copia inicial es muy lenta, tarda demasiado
>> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
>> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
>> virtual,
>> como AUFS. El problema de este es que, aunque me permite conservar el
>> contenido de una carpeta, y grabar en otra los cambios, no veo que me
>> permita mezclar los cambios sobre la carpeta original si, al final,
>> todo
>> fue bien.
>>
>> Empecé a
>> escribir un sistema de archivos para FUSE, pero antes de
>> seguir
>> quería saber si ya existe algo así.
>
>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
16 Apr
16 Apr
2:55 p.m.
Sergio, agora q Rafa trae o tema de volta, lembreime de unha cousa que me
mostrou un tipo da oficina hai un par de semanas:
http://blog.hypriot.com/getting-started-with-docker-on-your-arm-device/
Se Docker funciona nas RPi 1 e 2, en ARM 32bit, malo sera que non funcione
en x86 32 bit.
Unha aperta.
El 14 de abril de 2016, 10:15, Rafa Couto <rafacouto(a)gmail.com> escribió:
Ao final o tes solucionado? Exploraches a opción de UnionFS nun kernel 32
bits? (ou sexa, degradar docker a 32bits ;)
2015-09-28 11:23 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com>om>:
A ver, lo explico mejor: se trata de mejorar el
rendimiento de mi
programa MULTIPACKAGER, que me permite generar paquetes para cualquier
distro y arquitectura. Hoy en día me genera sin problemas paquetes de 32 y
64 bits para debian, ubuntu, fedora y arch, tanto en 32 como 64 bits, y
dado que está todo automatizado me parece absurdo discriminar a los 32
bits, cuando aún hoy siguen teniendo uso (marginal, sí, pero es que ya digo
que el proceso de generación está automatizado, y una vez que tengo listos
los 64 bits, los 32 no suponen trabajo alguno). Si meto docker (que haría
que fuese algo más rápido) perdería la ventaja de generar paquetes de 32
bits.
Ese es el motivo de no querer renunciar a los 32 bits.
El 28/09/15 a las 10:59, Ungoliant escribió:
Ya tienes que tener una muy buena razón para no migrar a un entorno de 64
bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se empieza a ver cada
vez mas software en el cual la version 32bit se queda rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas <rastersoft(a)gmail.com>
escribió:
--
Rafa Couto
GNU/Linux user #99126 - *http://bit.ly/LC-99126 <http://bit.ly/LC-99126>*
GPG key - http://bit.ly/GPG-D76ABDEC
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Si, la parte de las imágenes podría solucionarlo.
El problema sigue
siendo los 32 bits. Hay imágenes no oficiales, pero dado que docker en sí
no funciona en modo 32 bits, y parece que tiene que copiar su propio
ejecutable dentro de la imagen, obliga a que el contenedor funcione en modo
64 bits aunque todo el código interno sea de 32. Y eso me puede dar
problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
Combinando el proceso de "crear" y el de "lanzar" puedes mezclar lo
que
quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas un contenedor a
partir de una imagen, y tras los cambios, si funciona, haces un commit para
crear una imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas <
<rastersoft@gmail.com>rastersoft@gmail.com> escribió:
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Pero eso obligaría a meterlo dentro de la imagen,
y una vez hecho el
"chroot", el código de la biblioteca ya no tendría acceso a la carpeta
donde guardar los cambios, pues se supone que estaría fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
HDYS, si exportas la variable LD_PRELOAD, al ponerlas en el entorno, le
afecta a todos los programas afectados.
No se si se puede poner el entorno en el system-spawn pero supongo que
si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio Costas
<rastersoft@gmail.com><rastersoft@gmail.com> <rastersoft(a)gmail.com>
wrote:
>
> Eso valdría para un único programa, pero es que quiero ejecutar
> contenedores usando systemd-nspawn.
>
> El 28/09/15 a las 08:35, Mario Teijeiro escribió:
>>
>> Puedes tirar de LD_PRELOAD.
>> Creas una libreria que implemente tu propia funcion write, que lo que haga sea
una copia del fichero que se pasa como parametro a write (en forma de FD).
>>
>> Tiene la ventaja que valdría para cualqier programa.
>>
>> Un saludo
>>
>> On September 26, 2015 6:39:33 PM GMT+02:00, Sergio Costas
<rastersoft(a)gmail.com> <rastersoft(a)gmail.com> wrote:
>>>
>>> Hola gente:
>>>
>>> Estoy preparando un proyectillo y quiero mejorar su rendimiento. A ver
>>> si alguien sabe si hay algo como lo que busco.
>>>
>>> En estos momentos
>>> tengo una carpeta, digamos "A". Quiero hacer una
>>> serie
>>> de operaciones en ella, pero no seré yo, sino una serie de programas,
>>> que añadirán, modificarán y borrarán ficheros y carpetas dentro. Pero
>>> como quiero poder revertir todo en caso de que alguna operación salga
>>> mal, antes de nada hago una copia de todo a "A.BACKUP". Al final
de
>>> todo, si todo fue bien borro "A.BACKUP", y si hubo algún error,
copio
>>> "A.BACKUP" encima de A.
>>>
>>> El problema es que la copia inicial es muy lenta, tarda demasiado
>>> tiempo. Por eso quería saber si hay alguna manera de hacerlo en plan
>>> Copy-On-Write. Supongo que la idea sería un sistema de ficheros
>>> virtual,
>>> como AUFS. El problema de este es que, aunque me permite conservar el
>>> contenido de una carpeta, y grabar en otra los cambios, no veo que me
>>> permita mezclar los cambios sobre la carpeta original si, al final,
>>> todo
>>> fue bien.
>>>
>>> Empecé a
>>> escribir un sistema de archivos para FUSE, pero antes de
>>> seguir
>>> quería saber si ya existe algo así.
>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing listGALPon@listas.galpon.orghttps://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)raster(a)rastersoft.com
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
24 Apr
24 Apr
10:32 p.m.
O verdadeiro problema é executar un docker de 32bits nunha máquina de 64.
El 16/04/16 a las 14:55, Ungoliant escribió:
Sergio, agora q Rafa trae o tema de volta, lembreime
de unha cousa que
me mostrou un tipo da oficina hai un par de semanas:
http://blog.hypriot.com/getting-started-with-docker-on-your-arm-device/
Se Docker funciona nas RPi 1 e 2, en ARM 32bit, malo sera que non
funcione en x86 32 bit.
Unha aperta.
El 14 de abril de 2016, 10:15, Rafa Couto <rafacouto(a)gmail.com
<mailto:rafacouto@gmail.com>> escribió:
Ao final o tes solucionado? Exploraches a opción de UnionFS nun
kernel 32 bits? (ou sexa, degradar docker a 32bits ;)
2015-09-28 11:23 GMT+02:00 Sergio Costas <rastersoft(a)gmail.com
<mailto:rastersoft@gmail.com>>:
A ver, lo explico mejor: se trata de mejorar el rendimiento de
mi programa MULTIPACKAGER, que me permite generar paquetes
para cualquier distro y arquitectura. Hoy en día me genera sin
problemas paquetes de 32 y 64 bits para debian, ubuntu, fedora
y arch, tanto en 32 como 64 bits, y dado que está todo
automatizado me parece absurdo discriminar a los 32 bits,
cuando aún hoy siguen teniendo uso (marginal, sí, pero es que
ya digo que el proceso de generación está automatizado, y una
vez que tengo listos los 64 bits, los 32 no suponen trabajo
alguno). Si meto docker (que haría que fuese algo más rápido)
perdería la ventaja de generar paquetes de 32 bits.
Ese es el motivo de no querer renunciar a los 32 bits.
El 28/09/15 a las 10:59, Ungoliant escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com http://www.rastersoft.com
Ya tienes que tener una muy buena razón para no migrar a un
entorno de 64 bit.
Por ejemplo, RHEL7 ya no esta soportada en 32 bit y se
empieza a ver cada vez mas software en el cual la version
32bit se queda rezagada.
El 28 de septiembre de 2015, 10:49, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>> escribió:
Si, la parte de las imágenes podría solucionarlo. El
problema sigue siendo los 32 bits. Hay imágenes no
oficiales, pero dado que docker en sí no funciona en modo
32 bits, y parece que tiene que copiar su propio
ejecutable dentro de la imagen, obliga a que el
contenedor funcione en modo 64 bits aunque todo el código
interno sea de 32. Y eso me puede dar problemas :(
El 28/09/15 a las 10:45, Ungoliant escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Rafa Couto
GNU/Linux user #99126 - _http://bit.ly/LC-99126_
GPG key - http://bit.ly/GPG-D76ABDEC
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
https://listas.galpon.org/listinfo/galpon
Combinando el proceso de "crear" y el de "lanzar" puedes
mezclar lo que quieras.
Por ejemplo, creas una imagen a partir de otra. O lanzas
un contenedor a partir de una imagen, y tras los
cambios, si funciona, haces un commit para crear una
imagen a partir del contenedor.
Sobre 32 bit ... no creo que la situación mejore.
Ya nos contaras como lo solucionas :-)
Un saludo.
El 28 de septiembre de 2015, 9:50, Sergio Costas
<rastersoft(a)gmail.com <mailto:rastersoft@gmail.com>>
escribió:
Pero eso obligaría a meterlo dentro de la imagen, y
una vez hecho el "chroot", el código de la
biblioteca ya no tendría acceso a la carpeta donde
guardar los cambios, pues se supone que estaría
fuera de dicho chroot
El 28/09/15 a las 09:43, Mario Teijeiro escribió:
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon HDYS, si exportas la variable
LD_PRELOAD, al
ponerlas en el entorno, le afecta a todos los
programas afectados.
No se si se puede poner el entorno en el
system-spawn pero supongo que si.
Un saludo
On September 28, 2015 9:29:01 AM GMT+02:00, Sergio
Costas <rastersoft(a)gmail.com>
<mailto:rastersoft@gmail.com> wrote:
Eso valdría para un único programa, pero es que quiero ejecutar
contenedores usando systemd-nspawn.
El 28/09/15 a las 08:35, Mario Teijeiro escribió:
Puedes tirar de LD_PRELOAD. Creas una
libreria que implemente tu propia funcion
write, que lo que haga sea una copia del
fichero que se pasa como parametro a write
(en forma de FD). Tiene la ventaja que
valdría para cualqier programa. Un saludo
On September 26, 2015 6:39:33 PM GMT+02:00,
Sergio Costas <rastersoft(a)gmail.com>
<mailto:rastersoft@gmail.com> wrote:
Hola gente: Estoy preparando un
proyectillo y quiero mejorar su
rendimiento. A ver si alguien sabe si
hay algo como lo que busco. En estos
momentos tengo una carpeta, digamos
"A". Quiero hacer una serie de
operaciones en ella, pero no seré yo,
sino una serie de programas, que
añadirán, modificarán y borrarán
ficheros y carpetas dentro. Pero como
quiero poder revertir todo en caso de
que alguna operación salga mal, antes
de nada hago una copia de todo a
"A.BACKUP". Al final de todo, si todo
fue bien borro "A.BACKUP", y si hubo
algún error, copio "A.BACKUP" encima de
A. El problema es que la copia inicial
es muy lenta, tarda demasiado tiempo.
Por eso quería saber si hay alguna
manera de hacerlo en plan
Copy-On-Write. Supongo que la idea
sería un sistema de ficheros virtual,
como AUFS. El problema de este es que,
aunque me permite conservar el
contenido de una carpeta, y grabar en
otra los cambios, no veo que me permita
mezclar los cambios sobre la carpeta
original si, al final, todo fue bien.
Empecé a escribir un sistema de
archivos para FUSE, pero antes de
seguir quería saber si ya existe algo así.
--
Sent from my Android device with K-9 Mail. Please
excuse my brevity.
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
<mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
--
Nos leemos
RASTER (Linux user #228804)
raster(a)rastersoft.com <mailto:raster@rastersoft.com>
http://www.rastersoft.com
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org
<mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
_______________________________________________
GALPon mailing list
GALPon(a)listas.galpon.org <mailto:GALPon@listas.galpon.org>
https://listas.galpon.org/listinfo/galpon
3360
days inactive
3571
days old
25 comments
6 participants
participants (6)
-
Mario Teijeiro -
NoSpaze -
Odo -
Rafa Couto -
Sergio Costas -
Ungoliant