[opensuse-es] Sistemas de ficheros ext3
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hola: Fijaos en esto, del disco de mi cacharrín de la tele (es linux), que he enchufado a mi PC para comprobación: nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Pass 4: Checking reference counts Pass 5: Checking group summary information Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ # ¿No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso sólo le pasa al windows :-P - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqQHgsACgkQtTMYHG2NR9UW4QCfULQarFrnTMc/9Pnail0upBw+ rLIAn2zNmO2fFCNe8jk/yE36mMRNf4+V =IQ/E -----END PGP SIGNATURE-----
2009/8/22, Carlos E. R.:
Fijaos en esto, del disco de mi cacharrín de la tele (es linux), que he enchufado a mi PC para comprobación:
nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced.
(...)
Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ #
¿No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso sólo le pasa al windows :-P
(pensando en voz alta...) La unidad de disco del cacharrín no ha sido diseñada teniendo en mente la conexión a un equipo con linux, principalmente, luego no me explico cómo... a) El aparato no dispone de una rutina de autocomprobación autónoma que verifique el estado del disco cada "x" tiempo. b) Pueden aguantar el "tute" que se le da a estos chismes con esa fragmentación y seguir funcionando como si nada. Me pregunto en qué estado se encontrarán el resto de unidades que no se verifican nunca... :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Saturday 22 August 2009 23:45:30 Camaleón wrote:
2009/8/22, Carlos E. R.:
Fijaos en esto, del disco de mi cacharrín de la tele (es linux), que he enchufado a mi PC para comprobación:
nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced.
(...)
Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ #
¿No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso sólo le pasa al windows :-P
(pensando en voz alta...)
La unidad de disco del cacharrín no ha sido diseñada teniendo en mente la conexión a un equipo con linux, principalmente, luego no me explico cómo...
a) El aparato no dispone de una rutina de autocomprobación autónoma que verifique el estado del disco cada "x" tiempo.
b) Pueden aguantar el "tute" que se le da a estos chismes con esa fragmentación y seguir funcionando como si nada.
Me pregunto en qué estado se encontrarán el resto de unidades que no se verifican nunca...
En un cacharro multimedia. ¿Es importante el tiempo de acceso? No lo se, solo lo pregunto. Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia. Estar fragmentado, no es bueno ni malo, depende del uso que se le da. Además, solo debe aguantar dos años, hasta que se acabe la garantía. -- Saludos Lluis
El 2009-08-23 a las 00:44 +0200, Lluis Martínez escribió:
On Saturday 22 August 2009 23:45:30 Camaleón wrote:
2009/8/22, Carlos E. R.:
Fijaos en esto, del disco de mi cacharrín de la tele (es linux), que he enchufado a mi PC para comprobación:
nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced.
(...)
Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ #
¿No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso sólo le pasa al windows :-P
(pensando en voz alta...)
La unidad de disco del cacharrín no ha sido diseñada teniendo en mente la conexión a un equipo con linux, principalmente, luego no me explico cómo...
a) El aparato no dispone de una rutina de autocomprobación autónoma que verifique el estado del disco cada "x" tiempo.
b) Pueden aguantar el "tute" que se le da a estos chismes con esa fragmentación y seguir funcionando como si nada.
Me pregunto en qué estado se encontrarán el resto de unidades que no se verifican nunca...
En un cacharro multimedia. ¿Es importante el tiempo de acceso? No lo se, solo lo pregunto.
Pues el modelo concreto de Carlos E. R. no sé cuál es y por tanto desconozco las funcionalidades que tiene :-?, pero la mayoría de PVR son para grabar y reproducir videos, música o programar la grabación de los programas de la TDT, así que entiendo que sí, el tiempo de acceso a los datos debe ser importante.
Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia. Estar fragmentado, no es bueno ni malo, depende del uso que se le da.
También es posible que la fragmentación sea elevada porque el tamaño de los archivos es grande (supongo que hablamos de gigas)... en ext3 no sé cómo irá eso, pero en ntfs el archivo de paginación que se utiliza para el sistema (y que suele ser de gran tamaño) si está fragmentado y analizas el disco con el defrag, resulta en un porcentaje de fragmentación elevado (16-20%) cuando realmente sólo se trata de un único archivo el que está fragmentado.
Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Sunday 23 August 2009 11:46:12 Camaleón wrote:
El 2009-08-23 a las 00:44 +0200, Lluis Martínez escribió:
On Saturday 22 August 2009 23:45:30 Camaleón wrote:
2009/8/22, Carlos E. R.:
Fijaos en esto, del disco de mi cacharrín de la tele (es linux), que he enchufado a mi PC para comprobación:
nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced.
(...)
Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ #
¿No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso sólo le pasa al windows :-P
(pensando en voz alta...)
La unidad de disco del cacharrín no ha sido diseñada teniendo en mente la conexión a un equipo con linux, principalmente, luego no me explico cómo...
a) El aparato no dispone de una rutina de autocomprobación autónoma que verifique el estado del disco cada "x" tiempo.
b) Pueden aguantar el "tute" que se le da a estos chismes con esa fragmentación y seguir funcionando como si nada.
Me pregunto en qué estado se encontrarán el resto de unidades que no se verifican nunca...
En un cacharro multimedia. ¿Es importante el tiempo de acceso? No lo se, solo lo pregunto.
Pues el modelo concreto de Carlos E. R. no sé cuál es y por tanto desconozco las funcionalidades que tiene :-?, pero la mayoría de PVR son para grabar y reproducir videos, música o programar la grabación de los programas de la TDT, así que entiendo que sí, el tiempo de acceso a los datos debe ser importante.
Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia. Estar fragmentado, no es bueno ni malo, depende del uso que se le da.
También es posible que la fragmentación sea elevada porque el tamaño de los archivos es grande (supongo que hablamos de gigas)...
El problema no es tanto el tamaño del fichero en sí sino el crear borrar ficheros y el espacio libre. Por ejemplo, si tengo un disco de 100 GB y 1 fichero de 10 GB, la fragmentación es 0 (o deería serlo ;) Ahora grabo 5 ficheros de 10 GB. Por ahora no pasa nada. Bueno, lo más seguro es que haya fragmentación del espacio libre, pero no de los ficheros. Si ahora borro uno de los ficheros y escribo uno de 30 GB, puede que no haya 30 GB secuenciales libres sino entre los ficheros de 10 GB. En este caso se fragmentaría el fichero de 30 GB. Lo mismo puede ocurrir con ficheros pequeños, pero es más fácil poner el ejemplo con ficheros grandes 0;) Hace tiempo escribí esto, por si ayuda en algo: http://www.muylinux.com/2008/06/03/fragmentacion-ese-gran-desconocido/
en ext3 no sé cómo irá eso, pero en ntfs el archivo de paginación que se utiliza para el sistema (y que suele ser de gran tamaño) si está fragmentado y analizas el disco con el defrag, resulta en un porcentaje de fragmentación elevado (16-20%) cuando realmente sólo se trata de un único archivo el que está fragmentado.
Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-)
Saludos,
-- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-23 a las 11:46 +0200, Camaleón escribió:
En un cacharro multimedia. ¿Es importante el tiempo de acceso? No lo se, solo lo pregunto.
Sí lo es. Necesitaría acceso en tiempo real.
Pues el modelo concreto de Carlos E. R. no sé cuál es y por tanto desconozco las funcionalidades que tiene :-?,
Siemens Gigaset M740 AV (Carrefour).
pero la mayoría de PVR son para grabar y reproducir videos, música o programar la grabación de los programas de la TDT, así que entiendo que sí, el tiempo de acceso a los datos debe ser importante.
Tiene dos sintonizadores TDT que pueden funcionar simultaneamente, ambos grabando. Puedes estar viendo uno de los dos con, y con timeshift, o puedes ver una peli grabada previamente. Es una carga importante, con transporte USB. Ah, y puedes acceder via red para bajarte otra peli por ftp, pero eso no estaba soportado originalmente.
Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia. Estar fragmentado, no es bueno ni malo, depende del uso que se le da.
También es posible que la fragmentación sea elevada porque el tamaño de los archivos es grande (supongo que hablamos de gigas)...
No, tiene cientos de ficheros de megas. [root@MORIA:~]# ls -l /usb/Recordings/.rec/0001E3FAE280_1251121209.fmpg - -rw-r--r-- 1 root root 2048 Aug 24 15:54 0001E3FAE280_1251121209.fmpg - -rw-r--r-- 1 root root 86376448 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg - -rw-r--r-- 1 root root 6024 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.idx - -rw-r--r-- 1 root root 72 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.midx - -rw-r--r-- 1 root root 85721088 Aug 24 15:44 0001E3FAE280_1251121209.fmpg.001.mpg - -rw-r--r-- 1 root root 6000 Aug 24 15:44 0001E3FAE280_1251121209.fmpg.001.mpg.idx - -rw-r--r-- 1 root root 72 Aug 24 15:44 0001E3FAE280_1251121209.fmpg.001.mpg.midx - -rw-r--r-- 1 root root 80609280 Aug 24 15:46 0001E3FAE280_1251121209.fmpg.002.mpg - -rw-r--r-- 1 root root 5880 Aug 24 15:46 0001E3FAE280_1251121209.fmpg.002.mpg.idx - -rw-r--r-- 1 root root 72 Aug 24 15:46 0001E3FAE280_1251121209.fmpg.002.mpg.midx - -rw-r--r-- 1 root root 80609280 Aug 24 15:48 0001E3FAE280_1251121209.fmpg.003.mpg - -rw-r--r-- 1 root root 5904 Aug 24 15:48 0001E3FAE280_1251121209.fmpg.003.mpg.idx - -rw-r--r-- 1 root root 72 Aug 24 15:48 0001E3FAE280_1251121209.fmpg.003.mpg.midx - -rw-r--r-- 1 root root 80216064 Aug 24 15:50 0001E3FAE280_1251121209.fmpg.004.mpg
en ext3 no sé cómo irá eso, pero en ntfs el archivo de paginación que se utiliza para el sistema (y que suele ser de gran tamaño) si está fragmentado y analizas el disco con el defrag, resulta en un porcentaje de fragmentación elevado (16-20%) cuando realmente sólo se trata de un único archivo el que está fragmentado.
Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-)
No creo que eso tenga que ver. Es linux. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqSnE8ACgkQtTMYHG2NR9VDIwCghb80YbP6CCFMZBU8zbsoC9wp w8cAnj8u8PpZ6ndj8kxkBfXS5HxFKgiC =Kbzn -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-24 a las 15:57 +0200, Carlos E. R. escribió:
El 2009-08-23 a las 11:46 +0200, Camaleón escribió:
En un cacharro multimedia. ¿Es importante el tiempo de acceso? No lo se, solo lo pregunto.
Sí lo es.
Necesitaría acceso en tiempo real.
Pues el modelo concreto de Carlos E. R. no sé cuál es y por tanto desconozco las funcionalidades que tiene :-?,
Siemens Gigaset M740 AV (Carrefour).
pero la mayoría de PVR son para grabar y reproducir videos, música o programar la grabación de los programas de la TDT, así que entiendo que sí, el tiempo de acceso a los datos debe ser importante.
Tiene dos sintonizadores TDT que pueden funcionar simultaneamente, ambos grabando. Puedes estar viendo uno de los dos con, y con timeshift, o puedes ver una peli grabada previamente. Es una carga importante, con transporte USB. Ah, y puedes acceder via red para bajarte otra peli por ftp, pero eso no estaba soportado originalmente.
Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia. Estar fragmentado, no es bueno ni malo, depende del uso que se le da.
También es posible que la fragmentación sea elevada porque el tamaño de los archivos es grande (supongo que hablamos de gigas)...
No, tiene cientos de ficheros de megas.
[root@MORIA:~]# ls -l /usb/Recordings/.rec/0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 2048 Aug 24 15:54 0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 86376448 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg -rw-r--r-- 1 root root 6024 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.idx -rw-r--r-- 1 root root 72 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.midx -rw-r--r-- 1 root root 85721088 Aug 24 15:44 0001E3FAE280_1251121209.fmpg.001.mpg -rw-r--r-- 1 root root 6000 Aug 24 15:44 0001E3FAE280_1251121209.fmpg.001.mpg.idx -rw-r--r-- 1 root root 72 Aug 24 15:44 0001E3FAE280_1251121209.fmpg.001.mpg.midx -rw-r--r-- 1 root root 80609280 Aug 24 15:46 0001E3FAE280_1251121209.fmpg.002.mpg -rw-r--r-- 1 root root 5880 Aug 24 15:46 0001E3FAE280_1251121209.fmpg.002.mpg.idx -rw-r--r-- 1 root root 72 Aug 24 15:46 0001E3FAE280_1251121209.fmpg.002.mpg.midx -rw-r--r-- 1 root root 80609280 Aug 24 15:48 0001E3FAE280_1251121209.fmpg.003.mpg -rw-r--r-- 1 root root 5904 Aug 24 15:48 0001E3FAE280_1251121209.fmpg.003.mpg.idx -rw-r--r-- 1 root root 72 Aug 24 15:48 0001E3FAE280_1251121209.fmpg.003.mpg.midx -rw-r--r-- 1 root root 80216064 Aug 24 15:50 0001E3FAE280_1251121209.fmpg.004.mpg
en ext3 no sé cómo irá eso, pero en ntfs el archivo de paginación que se utiliza para el sistema (y que suele ser de gran tamaño) si está fragmentado y analizas el disco con el defrag, resulta en un porcentaje de fragmentación elevado (16-20%) cuando realmente sólo se trata de un único archivo el que está fragmentado.
Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-)
No creo que eso tenga que ver. Es linux.
Estoy pensando que la fragmentación sea intencionada: que graba en el primer sector que encuentra, o en el que esté más cercano a la posición actual del cabezal, porque puede estar haciendo time-shift de la tele. Es decir, que sea un algoritmo para minimizar el tiempo de escritura, no el de lectura. Lo cierto es que funciona. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqlfGQACgkQtTMYHG2NR9UUMwCff+fy0ipS4YneBqBU06qlPzll dacAnjDxiQVkOCM/WrzIxZqoBqerAoeJ =lUSh -----END PGP SIGNATURE-----
El 2009-09-07 a las 23:34 +0200, Carlos E. R. escribió:
El 2009-08-24 a las 15:57 +0200, Carlos E. R. escribió:
El 2009-08-23 a las 11:46 +0200, Camaleón escribió:
En un cacharro multimedia. ¿Es importante el tiempo de acceso? No lo se, solo lo pregunto.
Sí lo es.
Necesitaría acceso en tiempo real.
Claro, sobre todo para renderizar el teletexto (:-P
Pues el modelo concreto de Carlos E. R. no sé cuál es y por tanto desconozco las funcionalidades que tiene :-?,
Siemens Gigaset M740 AV (Carrefour).
Ah, ese. Vale, no me acordaba :-)
pero la mayoría de PVR son para grabar y reproducir videos, música o programar la grabación de los programas de la TDT, así que entiendo que sí, el tiempo de acceso a los datos debe ser importante.
Tiene dos sintonizadores TDT que pueden funcionar simultaneamente, ambos grabando. Puedes estar viendo uno de los dos con, y con timeshift, o puedes ver una peli grabada previamente. Es una carga importante, con transporte USB. Ah, y puedes acceder via red para bajarte otra peli por ftp, pero eso no estaba soportado originalmente.
¿Y conectarlo vía ethernet, no sería más sencillo o te carga demasiado el ordenador? :-?
Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia. Estar fragmentado, no es bueno ni malo, depende del uso que se le da.
También es posible que la fragmentación sea elevada porque el tamaño de los archivos es grande (supongo que hablamos de gigas)...
No, tiene cientos de ficheros de megas.
[root@MORIA:~]# ls -l /usb/Recordings/.rec/0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 2048 Aug 24 15:54 0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 86376448 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg -rw-r--r-- 1 root root 6024 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.idx -rw-r--r-- 1 root root 72 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.midx
(...) Hay algo que no entiendo de estos chismes. Si la mayoría de las unidades que integran el disco duro (PVR o videograbadores) usan un formato FAT32 ¿cómo se las apañan con las grabaciones en HD? ¿parten el archivo cada 4 GB? >:-?
Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-)
No creo que eso tenga que ver. Es linux.
¿Y que sea linux le exime de que tenga un fallo mecánico? No creo >:-)
Estoy pensando que la fragmentación sea intencionada: que graba en el primer sector que encuentra, o en el que esté más cercano a la posición actual del cabezal, porque puede estar haciendo time-shift de la tele.
Es decir, que sea un algoritmo para minimizar el tiempo de escritura, no el de lectura.
Lo cierto es que funciona.
Bueno, el manual del aparato dice que el formato que usa para el el disco usb debe ser fat32 y además tiene una utilidad de defragmentado incluida en el chisme, o sea que lo tiene cotemplado (en el caso de que no se tuviera un equipo desde el que defragmentar). Por cierto, el tema de fragmentación lo comentan en los foros: Defragmentar En Ext3 http://www.todopvr.com/foro/desfragmentar-en-ext3-vt2658.html Se ve que no está muy fino el Siemens en ese aspecto >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-07 a las 23:34 +0200, Carlos E. R. escribió:
El 2009-08-24 a las 15:57 +0200, Carlos E. R. escribió:
El 2009-08-23 a las 11:46 +0200, Camaleón escribió:
En un cacharro multimedia. ¿Es importante el tiempo de acceso? No lo se, solo lo pregunto.
Sí lo es.
Necesitaría acceso en tiempo real.
Claro, sobre todo para renderizar el teletexto (:-P
Ya, claro :-p
Pues el modelo concreto de Carlos E. R. no sé cuál es y por tanto desconozco las funcionalidades que tiene :-?,
Siemens Gigaset M740 AV (Carrefour).
Ah, ese. Vale, no me acordaba :-)
pero la mayoría de PVR son para grabar y reproducir videos, música o programar la grabación de los programas de la TDT, así que entiendo que sí, el tiempo de acceso a los datos debe ser importante.
Tiene dos sintonizadores TDT que pueden funcionar simultaneamente, ambos grabando. Puedes estar viendo uno de los dos con, y con timeshift, o puedes ver una peli grabada previamente. Es una carga importante, con transporte USB. Ah, y puedes acceder via red para bajarte otra peli por ftp, pero eso no estaba soportado originalmente.
¿Y conectarlo vía ethernet, no sería más sencillo o te carga demasiado el ordenador? :-?
Si, pero... espera, que te lías. | | | | | ordenador | | PVR | | HD | -----------+ +----------+ +-----+ | | | | | \____________/ \__________/ eth usb Este PVR puede grabar mediante samba en el ordenador, o tener un disco duro externo por USB; no tiene disco interno. También funciona sin disco, pero claro, perdiendo mucha funcionalidad.
los archivos es grande (supongo que hablamos de gigas)...
No, tiene cientos de ficheros de megas.
[root@MORIA:~]# ls -l /usb/Recordings/.rec/0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 2048 Aug 24 15:54 0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 86376448 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg -rw-r--r-- 1 root root 6024 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.idx -rw-r--r-- 1 root root 72 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.midx
(...)
Hay algo que no entiendo de estos chismes. Si la mayoría de las unidades que integran el disco duro (PVR o videograbadores) usan un formato FAT32 ¿cómo se las apañan con las grabaciones en HD? ¿parten el archivo cada 4 GB? >:-?
El mio parte antes de los 100 megas, lo ves arriba. Pero no todos usan FAT, muchos usan formatos Linux, sobre todo si el disco es interno. Uno que he visto usa varios tipos de formatos Linux, y otra partición FAT para compartir (como disco de backup en red y mediante USB).
Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-)
No creo que eso tenga que ver. Es linux.
¿Y que sea linux le exime de que tenga un fallo mecánico? No creo >:-)
Creo recordar que me refería a la parte anterior del párrafo.
Estoy pensando que la fragmentación sea intencionada: que graba en el primer sector que encuentra, o en el que esté más cercano a la posición actual del cabezal, porque puede estar haciendo time-shift de la tele.
Es decir, que sea un algoritmo para minimizar el tiempo de escritura, no el de lectura.
Lo cierto es que funciona.
Bueno, el manual del aparato dice que el formato que usa para el el disco usb debe ser fat32 y además tiene una utilidad de defragmentado incluida en el chisme, o sea que lo tiene cotemplado (en el caso de que no se tuviera un equipo desde el que defragmentar).
Si le dejas que lo formatee él mismo, efectivamente lo hace en FAT. Pero si lo haces externamente, o desde telnet, puedes hacerlo en ext3, y de hecho, su rendimiento aumenta. Además, yo no uso el firmware original, sino la variante comunitaria siesta-lemmi: MORIA login: root Password: - ----------------------------------------- Host: MORIA Version FW: 2.3.61 Version SIESTA: 2.3.61.SL06beta6 SIESTA-Lemmi-06 Actualización: 2008-10-30 11:00:00 - ----------------------------------------- [root@MORIA:~]# Sé que puede hacer una comprobación del disco, pero no la uso (muy lenta). Ignoro si desfragmenta (en fat). Entre los programas que tiene veo un dosfsck, pero no el e2fsck. Sí tiene mke2fs. Aunque también hay un "mgr-fsck", un script que llama a... e2fsck? then echo "----- e2fsck $dev -----" txt2osd -s25 -d0 -x140 -y90 -f0xffffff00 -b0xff000000 -r "Fw $LEMMI_FIRMWARE_VERSION" txt2osd -s18 -d0 -x140 -y150 -f0xffffff00 -b0xff000000 "e2fsck $dev" /data/osd_progress "e2fsck -y -v $coj$dev" sleep 3s else echo "----- dosfsck $dev -----" txt2osd -s25 -d0 -x140 -y90 -f0xffffff00 -b0xff000000 -r "Fw $LEMMI_FIRMWARE_VERSION" txt2osd -s18 -d0 -x140 -y150 -f0xffffff00 -b0xff000000 "dosfsck $dev" /data/osd_progress "dosfsck -a -v -w $dev" sleep 3s fi Que no puede ser el programa original de siemens. Ah, el e2fsck está en "/data/local/bin/e2fsck".
Por cierto, el tema de fragmentación lo comentan en los foros:
Defragmentar En Ext3 http://www.todopvr.com/foro/desfragmentar-en-ext3-vt2658.html
Ah, pues eso concretamente no lo he mirado, pero no me extraña. A ver, leamos.... ¡huy! Pues están totalmente equivocados: #2 ] En ext3 el disco no se fragmenta, con lo que no es necesari ] defragmentar. Eso es lo que sabemos de Linux, pero no es lo que ocurre en este caso concreto. [...] Ah, claro, el truco de reescribirlo todo para desfragmentar, es el más rápido, si tienes otro disco para ello.
Se ve que no está muy fino el Siemens en ese aspecto >:-)
Yo creo que no es eso. Es un Linux normal, si fragmenta es porque han tocado algo, y probablemente a propósito. Esa es mi hipótesis. Si están usando un Linux (kernel 2.4.21), y el Linux se sabe que no fragmenta, pero este sí lo hace, es que han cambiado algo. No creo que sea accidental. Creo que lo hacen porque fragmentar hace más rápida la escritura (es como la táctica del interleave en los discos). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqmfDcACgkQtTMYHG2NR9XKSwCaA4Ch500vharWks2q2IxTc+1I K+kAnijtvirkau5ZVHrtTbGFJL5O4vNE =kA7l -----END PGP SIGNATURE-----
El 2009-09-08 a las 17:45 +0200, Carlos E. R. escribió:
El 2009-09-08 a las 11:06 +0200, Camaleón escribió:
Tiene dos sintonizadores TDT que pueden funcionar simultaneamente, ambos grabando. Puedes estar viendo uno de los dos con, y con timeshift, o puedes ver una peli grabada previamente. Es una carga importante, con transporte USB. Ah, y puedes acceder via red para bajarte otra peli por ftp, pero eso no estaba soportado originalmente.
¿Y conectarlo vía ethernet, no sería más sencillo o te carga demasiado el ordenador? :-?
Si, pero... espera, que te lías.
¿Por qué lo dices? :-?
| | | | | ordenador | | PVR | | HD | -----------+ +----------+ +-----+ | | | | | \____________/ \__________/ eth usb
Este PVR puede grabar mediante samba en el ordenador, o tener un disco duro externo por USB; no tiene disco interno. También funciona sin disco, pero claro, perdiendo mucha funcionalidad.
¿No puedes volcar al disco duro del ordenador, directamente, sin usar uno externo vía usb? Esa era la pregunta :-)
No, tiene cientos de ficheros de megas.
[root@MORIA:~]# ls -l /usb/Recordings/.rec/0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 2048 Aug 24 15:54 0001E3FAE280_1251121209.fmpg -rw-r--r-- 1 root root 86376448 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg -rw-r--r-- 1 root root 6024 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.idx -rw-r--r-- 1 root root 72 Aug 24 15:42 0001E3FAE280_1251121209.fmpg.000.mpg.midx
(...)
Hay algo que no entiendo de estos chismes. Si la mayoría de las unidades que integran el disco duro (PVR o videograbadores) usan un formato FAT32 ¿cómo se las apañan con las grabaciones en HD? ¿parten el archivo cada 4 GB? >:-?
El mio parte antes de los 100 megas, lo ves arriba. Pero no todos usan FAT, muchos usan formatos Linux, sobre todo si el disco es interno. Uno que he visto usa varios tipos de formatos Linux, y otra partición FAT para compartir (como disco de backup en red y mediante USB).
La mayoría de videograbadores domésticos para salón (no para conectar al ordenador ni de tipo portátil) que he visto usan fat32, por eso lo decía. Los PVR, pues eso ya no lo sé :-?
Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-)
No creo que eso tenga que ver. Es linux.
¿Y que sea linux le exime de que tenga un fallo mecánico? No creo >:-)
Creo recordar que me refería a la parte anterior del párrafo.
¿A "cuála"? :-)
Bueno, el manual del aparato dice que el formato que usa para el el disco usb debe ser fat32 y además tiene una utilidad de defragmentado incluida en el chisme, o sea que lo tiene cotemplado (en el caso de que no se tuviera un equipo desde el que defragmentar).
Si le dejas que lo formatee él mismo, efectivamente lo hace en FAT. Pero si lo haces externamente, o desde telnet, puedes hacerlo en ext3, y de hecho, su rendimiento aumenta. Además, yo no uso el firmware original, sino la variante comunitaria siesta-lemmi:
Ah, pillín, entonces la fragmnetación del disco corre a cargo de los programadores de la "siesta del lémur" esa, en lugar de los ingenieros alemanes >:-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-08 a las 17:45 +0200, Carlos E. R. escribió:
El 2009-09-08 a las 11:06 +0200, Camaleón escribió:
Tiene dos sintonizadores TDT que pueden funcionar simultaneamente, ambos grabando. Puedes estar viendo uno de los dos con, y con timeshift, o puedes ver una peli grabada previamente. Es una carga importante, con transporte USB. Ah, y puedes acceder via red para bajarte otra peli por ftp, pero eso no estaba soportado originalmente.
¿Y conectarlo vía ethernet, no sería más sencillo o te carga demasiado el ordenador? :-?
Si, pero... espera, que te lías.
¿Por qué lo dices? :-?
| | | | | ordenador | | PVR | | HD | -----------+ +----------+ +-----+ | | | | | \____________/ \__________/ eth usb
Este PVR puede grabar mediante samba en el ordenador, o tener un disco duro externo por USB; no tiene disco interno. También funciona sin disco, pero claro, perdiendo mucha funcionalidad.
¿No puedes volcar al disco duro del ordenador, directamente, sin usar uno externo vía usb? Esa era la pregunta :-)
A ver. Este PVR viene sin disco duro propio. Ni lo tiene ni se le puede poner, no tiene puerto interno de ninguna clase. Pero puedes: a) enchufarle un disco duro externo mediante usb (puede ser un llavero flash). b) usar un directorio compartido mediante samba en la red. No estoy seguro de qué es lo que hace si tiene ambos métodos disponibles al mismo tiempo, pero se puede hacer. Si comparto un directorio del PC mediante samba, pues las pelis se graban ahí sin problemas. Sin usb, mediante eth. La pega es que tengo que tener encendido el ordenador siempre. Siempre que necesite grabar, claro, y tengo grabaciones programadas a horas intempestivas. Es más práctico comprar un disco duro y ponerselo, pero por narices ha de ser mediante usb. O un NAS por red. Tiene dos puertos USB, uno de ellos lo uso para activar un relé de 6 voltios que enciende el disco duro conectado al otro puerto. Una grabación hecha en ese disco me la puedo bajar al ordenador mediante el servicio ftp que activa el cacharrín. O puedo quitarle el disco y enchufarselo al ordenador, lo cual trabaja mucho más rápido, por cierto, pero mientras tanto la tele no puede grabar nada.
(...)
Hay algo que no entiendo de estos chismes. Si la mayoría de las unidades que integran el disco duro (PVR o videograbadores) usan un formato FAT32 ¿cómo se las apañan con las grabaciones en HD? ¿parten el archivo cada 4 GB? >:-?
El mio parte antes de los 100 megas, lo ves arriba. Pero no todos usan FAT, muchos usan formatos Linux, sobre todo si el disco es interno. Uno que he visto usa varios tipos de formatos Linux, y otra partición FAT para compartir (como disco de backup en red y mediante USB).
La mayoría de videograbadores domésticos para salón (no para conectar al ordenador ni de tipo portátil) que he visto usan fat32, por eso lo decía. Los PVR, pues eso ya no lo sé :-?
Y el mio también usa fat por defecto. Pero es linux, así que admite ext3. Cualquiera que use linux puede admitir ext3.
> Además, solo debe aguantar dos años, hasta que se acabe la garantía.
Je, eso suena tan perverso y tan malvado... que me encanta >;-)
No creo que eso tenga que ver. Es linux.
¿Y que sea linux le exime de que tenga un fallo mecánico? No creo >:-)
Creo recordar que me refería a la parte anterior del párrafo.
¿A "cuála"? :-)
No recuerdo. El parrafo entero es: ] >> Porque a lo mejor, para lo que sirve eso no tiene ninguna ] >> importancia. Estar fragmentado, no es bueno ni malo, depende del uso ] >> que se le da. ] ] > También es posible que la fragmentación sea elevada porque el tamaño ] > de los archivos es grande (supongo que hablamos de gigas)... en ext3 ] > no sé cómo irá eso, pero en ntfs el archivo de paginación que se ] > utiliza para el sistema (y que suele ser de gran tamaño) si está ] > fragmentado y analizas el disco con el defrag, resulta en un ] > porcentaje de fragmentación elevado (16-20%) cuando realmente sólo se ] > trata de un único archivo el que está fragmentado. ] ] >> Además, solo debe aguantar dos años, hasta que se acabe la garantía. ] ] > Je, eso suena tan perverso y tan malvado... que me encanta >;-) ] ] No creo que eso tenga que ver. Es linux. Entiendo que es el estado de la fragmentación la que debe aguantar sólo dos años, hasta que se acabe la garantía. Y yo dije que no importa, es linux. No se menciona el hardware en la parrafada.
Si le dejas que lo formatee él mismo, efectivamente lo hace en FAT. Pero si lo haces externamente, o desde telnet, puedes hacerlo en ext3, y de hecho, su rendimiento aumenta. Además, yo no uso el firmware original, sino la variante comunitaria siesta-lemmi:
Ah, pillín, entonces la fragmnetación del disco corre a cargo de los programadores de la "siesta del lémur" esa, en lugar de los ingenieros alemanes >:-P
No, en absoluto. Le puse ext3 desde el principio, con el software original. Y el firmware alternativo usa algunos módulos cerrados, propietarios, del original: 475 root 10 0 2356 2356 1476 S 7,1 5,2 2:12 play_backend 495 root 9 0 12676 4432 3852 S 0,3 9,9 0:11 wavebox Hablaron de un software alternativo sin usar esos módulos, haciendolo desde cero, pero desconozco si los han hecho; yo no lo he visto. Es que incluso los desarrolladores del soft abierto de estos chismes parece que desarrollan en cerrado, no publican los fuentes de lo que han hecho. No publican tampoco como funciona el cacharrín, el hardware, la arquitectura. De manera que alguien que quiera hacer una modificación pequeñita tendría que empezar desde cero o camelarse a esa gente para que les digan cómo se hace. Tiene guasa la cosa. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqmtZcACgkQtTMYHG2NR9WaTgCeJBt5Q2cYGqUtmm2JGs/Ek4qV eioAoIPnsdtndNEj7y0oL/fltKpIAC0h =EDDa -----END PGP SIGNATURE-----
El 2009-09-08 a las 21:50 +0200, Carlos E. R. escribió:
El 2009-09-08 a las 17:59 +0200, Camaleón escribió:
¿Y conectarlo vía ethernet, no sería más sencillo o te carga demasiado el ordenador? :-?
Si, pero... espera, que te lías.
¿Por qué lo dices? :-?
| | | | | ordenador | | PVR | | HD | -----------+ +----------+ +-----+ | | | | | \____________/ \__________/ eth usb
Este PVR puede grabar mediante samba en el ordenador, o tener un disco duro externo por USB; no tiene disco interno. También funciona sin disco, pero claro, perdiendo mucha funcionalidad.
¿No puedes volcar al disco duro del ordenador, directamente, sin usar uno externo vía usb? Esa era la pregunta :-)
A ver. Este PVR viene sin disco duro propio. Ni lo tiene ni se le puede poner, no tiene puerto interno de ninguna clase. Pero puedes:
a) enchufarle un disco duro externo mediante usb (puede ser un llavero flash).
b) usar un directorio compartido mediante samba en la red.
No estoy seguro de qué es lo que hace si tiene ambos métodos disponibles al mismo tiempo, pero se puede hacer.
Si comparto un directorio del PC mediante samba, pues las pelis se graban ahí sin problemas. Sin usb, mediante eth. La pega es que tengo que tener encendido el ordenador siempre. Siempre que necesite grabar, claro, y tengo grabaciones programadas a horas intempestivas.
Es más práctico comprar un disco duro y ponerselo, pero por narices ha de ser mediante usb. O un NAS por red. Tiene dos puertos USB, uno de ellos lo uso para activar un relé de 6 voltios que enciende el disco duro conectado al otro puerto.
Una grabación hecha en ese disco me la puedo bajar al ordenador mediante el servicio ftp que activa el cacharrín. O puedo quitarle el disco y enchufarselo al ordenador, lo cual trabaja mucho más rápido, por cierto, pero mientras tanto la tele no puede grabar nada.
Recuerda que soy de las que se lee el manual (sí, me le leído el manual del gigaset ese) :-) Eso es lo que preguntaba, si el chisme podía grabar directamente al ordenador, sin pasar por el disco externo usb. ¿Ventajas? Que el ordenador va a sai, que no necesitas otro aparato externo, etc... ¿Desventajas? Si el equipo es lento, usar samba para transferir los datos en tiempo real no le hará mucha gracia. Esa era la única pega que le veía.
El mio parte antes de los 100 megas, lo ves arriba. Pero no todos usan FAT, muchos usan formatos Linux, sobre todo si el disco es interno. Uno que he visto usa varios tipos de formatos Linux, y otra partición FAT para compartir (como disco de backup en red y mediante USB).
La mayoría de videograbadores domésticos para salón (no para conectar al ordenador ni de tipo portátil) que he visto usan fat32, por eso lo decía. Los PVR, pues eso ya no lo sé :-?
Y el mio también usa fat por defecto. Pero es linux, así que admite ext3. Cualquiera que use linux puede admitir ext3.
Bueno... eso depende ¿no? :-? Podrían haber quitado el soporte de ext3 del kernel (ext2 para uso interno) y dejado sólo el soporte de fat32, algo que sería tremendamente malévolo >:-)
No creo que eso tenga que ver. Es linux.
¿Y que sea linux le exime de que tenga un fallo mecánico? No creo >:-)
Creo recordar que me refería a la parte anterior del párrafo.
¿A "cuála"? :-)
No recuerdo.
El parrafo entero es:
] >> Porque a lo mejor, para lo que sirve eso no tiene ninguna ] >> importancia. Estar fragmentado, no es bueno ni malo, depende del uso ] >> que se le da. ] ] > También es posible que la fragmentación sea elevada porque el tamaño ] > de los archivos es grande (supongo que hablamos de gigas)... en ext3 ]
no sé cómo irá eso, pero en ntfs el archivo de paginación que se ] > utiliza para el sistema (y que suele ser de gran tamaño) si está ] > fragmentado y analizas el disco con el defrag, resulta en un ] > porcentaje de fragmentación elevado (16-20%) cuando realmente sólo se ] > trata de un único archivo el que está fragmentado. ] ] >> Además, solo debe aguantar dos años, hasta que se acabe la garantía. ] ] > Je, eso suena tan perverso y tan malvado... que me encanta >;-) ] ] No creo que eso tenga que ver. Es linux.
Entiendo que es el estado de la fragmentación la que debe aguantar sólo dos años, hasta que se acabe la garantía. Y yo dije que no importa, es linux. No se menciona el hardware en la parrafada.
Es que aún no sabía si el disco estaba integrado O:-)
Si le dejas que lo formatee él mismo, efectivamente lo hace en FAT. Pero si lo haces externamente, o desde telnet, puedes hacerlo en ext3, y de hecho, su rendimiento aumenta. Además, yo no uso el firmware original, sino la variante comunitaria siesta-lemmi:
Ah, pillín, entonces la fragmnetación del disco corre a cargo de los programadores de la "siesta del lémur" esa, en lugar de los ingenieros alemanes >:-P
No, en absoluto. Le puse ext3 desde el principio, con el software original. Y el firmware alternativo usa algunos módulos cerrados, propietarios, del original:
475 root 10 0 2356 2356 1476 S 7,1 5,2 2:12 play_backend 495 root 9 0 12676 4432 3852 S 0,3 9,9 0:11 wavebox
Hablaron de un software alternativo sin usar esos módulos, haciendolo desde cero, pero desconozco si los han hecho; yo no lo he visto.
Es que incluso los desarrolladores del soft abierto de estos chismes parece que desarrollan en cerrado, no publican los fuentes de lo que han hecho. No publican tampoco como funciona el cacharrín, el hardware, la arquitectura. De manera que alguien que quiera hacer una modificación pequeñita tendría que empezar desde cero o camelarse a esa gente para que les digan cómo se hace.
Tiene guasa la cosa.
¿Y qué ventajas tienes usando el software del lémur en lugar del original? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-08 a las 22:03 +0200, Camaleón escribió:
El 2009-09-08 a las 21:50 +0200, Carlos E. R. escribió:
...
Recuerda que soy de las que se lee el manual (sí, me le leído el manual del gigaset ese) :-)
Fale :-)
Eso es lo que preguntaba, si el chisme podía grabar directamente al ordenador, sin pasar por el disco externo usb.
Si, si puede. Lo hice al principio, no compré el disco duro. Probé con una flash de 2 G de kingston, pero no le gustó.
¿Ventajas? Que el ordenador va a sai, que no necesitas otro aparato externo, etc...
Cierto, y que es más barato. Lo de la sai no te sirve, porque el cacharrín necesitarí sai también.
¿Desventajas? Si el equipo es lento, usar samba para transferir los datos en tiempo real no le hará mucha gracia. Esa era la única pega que le veía.
Mi equipo es del 2000 y no ralentizaba apreciablemente. No, la pega real es que tienes que tener encendido el ordenador antes del cacharrín.
La mayoría de videograbadores domésticos para salón (no para conectar al ordenador ni de tipo portátil) que he visto usan fat32, por eso lo decía. Los PVR, pues eso ya no lo sé :-?
Y el mio también usa fat por defecto. Pero es linux, así que admite ext3. Cualquiera que use linux puede admitir ext3.
Bueno... eso depende ¿no? :-? Podrían haber quitado el soporte de ext3 del kernel (ext2 para uso interno) y dejado sólo el soporte de fat32, algo que sería tremendamente malévolo >:-)
Bastante.
¿Y qué ventajas tienes usando el software del lémur en lugar del original? :-?
El original tenía telnet. La segunda versión de siemens lo quitaron, para evitar que trasteásemos. Era ya tarde, ya habían hecho otros firmwares abiertos. Pero la pega práctica peor es que usa una guia de programas que es de pago, mientras que el software abierto de lemmi usa la EPG que es gratuita (hay otra versión abierta que usa la guia de pago). Además, la variante siesta tiene un servidor web mediante el que puedes hacer cosas como programar grabaciones, ver la parrilla completa de todas las cadenas (varios dias), cambiar configuraciones, o incluso editar las grabaciones para quitarles los anuncios. Es _mucho_ más potente. Oficialmente el modelo "carrefour" no tiene actualizaciones desde que lo compré o casi. El fabricante da una funcionalidad mucho más limitada que lo que el cacharro puede hacer por hardware. Leches, ¡que es un ordenador! Se puede hacer lo que te de la gana. Me parece que había hasta una mula... Otra curiosidad: uso una partición swap de 100 megas, via usb: 10:29pm up 1:16, 0 users, load average: 4,31, 4,30, 4,34 65 processes: 64 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 18.7% user, 24.9% system, 0.0% nice, 56.3% idle Mem: 44564K av, 42756K used, 1808K free, 0K shrd, 3256K buff Swap: 104412K av, 10580K used, 93832K free 21120K cached - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqmv7sACgkQtTMYHG2NR9U0SQCeJGKIp8Nn0qFdqlI9KL8IqCbY rZwAnisVakTy00DsnFE8tj5b1Gx7jTCr =oRZT -----END PGP SIGNATURE-----
El Martes, 8 de Septiembre de 2009, Carlos E. R. escribió: Hola
Hablaron de un software alternativo sin usar esos módulos, haciendolo desde cero, pero desconozco si los han hecho; yo no lo he visto.
El software alternativo es el VDR http://www.assembla.com/wiki/show/VDR-M7x0 Saludos. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-09 a las 08:23 +0200, manolo escribió:
El Martes, 8 de Septiembre de 2009, Carlos E. R. escribió: Hola
Hablaron de un software alternativo sin usar esos módulos, haciendolo desde cero, pero desconozco si los han hecho; yo no lo he visto.
El software alternativo es el VDR
¡Anda! Ese sitio no lo conocía. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqn/wQACgkQtTMYHG2NR9VGSQCdHJgGdAyyaZBMIWnJN/Hqd6HU eLUAn25N9qBtFBdYG/RD1pBVd0wE0Xw6 =zcBj -----END PGP SIGNATURE-----
Hola :) On Tuesday 08 September 2009 17:45:41 Carlos E. R. wrote:
Content-ID:
El 2009-09-08 a las 11:06 +0200, Camaleón escribió:
El 2009-09-07 a las 23:34 +0200, Carlos E. R. escribió:
El 2009-08-24 a las 15:57 +0200, Carlos E. R. escribió:
El 2009-08-23 a las 11:46 +0200, Camaleón escribió:
[...]
Defragmentar En Ext3 http://www.todopvr.com/foro/desfragmentar-en-ext3-vt2658.html
Ah, pues eso concretamente no lo he mirado, pero no me extraña. A ver, leamos.... ¡huy! Pues están totalmente equivocados:
#2 ] En ext3 el disco no se fragmenta, con lo que no es necesari ] defragmentar.
Eso es lo que sabemos de Linux, pero no es lo que ocurre en este caso concreto. [...] Ah, claro, el truco de reescribirlo todo para desfragmentar, es el más rápido, si tienes otro disco para ello.
Se ve que no está muy fino el Siemens en ese aspecto >:-)
Yo creo que no es eso. Es un Linux normal, si fragmenta es porque han tocado algo, y probablemente a propósito.
Esa es mi hipótesis.
Si están usando un Linux (kernel 2.4.21), y el Linux se sabe que no fragmenta, pero este sí lo hace, es que han cambiado algo. No creo que sea accidental. Creo que lo hacen porque fragmentar hace más rápida la escritura (es como la táctica del interleave en los discos).
Todo sistema de ficheros se fragmenta, nos guste o no y especialmente los sistemas de ficheros que: - gestionan/guardan ficheros grandes - escriben y borran muchos ficheros Otra cosa es que haya técnicas para mitigar la fragmentación (como el delayed allocation u otras). La prueba se puede hacer fácilmente con una partición de de por ejemplo 10 GB y creando y borrando ficheros de 1 a 3 GB aleatoriamente. Llega un momento en el que el sistema de ficheros se fragmenta y los ficheros también. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-08 a las 18:07 +0200, Rafa Griman escribió:
Todo sistema de ficheros se fragmenta, nos guste o no y especialmente los sistemas de ficheros que: - gestionan/guardan ficheros grandes - escriben y borran muchos ficheros
Otra cosa es que haya técnicas para mitigar la fragmentación (como el delayed allocation u otras).
La prueba se puede hacer fácilmente con una partición de de por ejemplo 10 GB y creando y borrando ficheros de 1 a 3 GB aleatoriamente. Llega un momento en el que el sistema de ficheros se fragmenta y los ficheros también.
Eso es cierto, pero es que en este caso los ficheros no son "grandes", no superan los ochenta megas, y muchos de ellos. Las grabaciones de varios gigas están partidas en docenas o cientos de ficheros de ochenta megas, y estos ficheros a su vez están fragmentados. Y cada grabación está en un directorio aparte. Lo que digo es que sospecho que están usando un algoritmo para minimizar el tiempo de escritura (que necesita ser en tiempo real), escribiendo en algún sector que encuentra antes o que reduce el movimiento del cabezal, en vez de esperar a meterlo en un sitio óptimo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqmrkwACgkQtTMYHG2NR9UneACdGKsFfWu3AOqxiPP2UlWiIRRn CG0An2zIQpH9fwtoC4hsBy0phvLRcmvM =57bs -----END PGP SIGNATURE-----
Hola :) On Tuesday 08 September 2009 21:19:33 Carlos E. R. wrote:
El 2009-09-08 a las 18:07 +0200, Rafa Griman escribió:
Todo sistema de ficheros se fragmenta, nos guste o no y especialmente los sistemas de ficheros que: - gestionan/guardan ficheros grandes - escriben y borran muchos ficheros
Otra cosa es que haya técnicas para mitigar la fragmentación (como el delayed allocation u otras).
La prueba se puede hacer fácilmente con una partición de de por ejemplo 10 GB y creando y borrando ficheros de 1 a 3 GB aleatoriamente. Llega un momento en el que el sistema de ficheros se fragmenta y los ficheros también.
Eso es cierto, pero es que en este caso los ficheros no son "grandes", no superan los ochenta megas, y muchos de ellos. Las grabaciones de varios gigas están partidas en docenas o cientos de ficheros de ochenta megas, y estos ficheros a su vez están fragmentados. Y cada grabación está en un directorio aparte.
Luego está fragmentado el fichero: si pillamos un vídeo/película (¿~800 MB?) y lo partimos en trozos de 80 MB ... está fragmentado ya que ext3 (y los demás sistemas de ficheros en Linux o por lo menos los más actuales) hacen un delayed allocation de ese fichero que mide 80 MB. Es decir, para el sistema de ficheros el fichero mide/pesa 80 MB y no los 800 MB, pero a nivel lógico (para la aplicación), el fichero mide/pesa 800 MB. Cada 80 MB se escribirán donde quepan dando lugar a fragmentación interna del fichero (no necesariamente del sistema de ficheros) y, en el momento que borres el fichero ... dará lugar a una gran fragmentación del sistema de ficheros (tanto del espacio ocupado como del espacio vacío). Si cada vídeo se almacena en un directorio propio, lo que se está intentando es tener los i-nodos cercanos (esto lo hace XFS también). Esto es muy útil para evitar que los IOPS se desperdiguen por todo el disco duro (mover el cabezal para una lectura/escritura mínima), pero: - el streaming de un vídeo no es el óptimo - se producen muchos IOPS para un único vídeo En todo caso la definición de "grande" depende de muchas cosas: tamaño de la partición, tamaño de los bloques que se están usando, ...
Lo que digo es que sospecho que están usando un algoritmo para minimizar el tiempo de escritura (que necesita ser en tiempo real), escribiendo en algún sector que encuentra antes o que reduce el movimiento del cabezal, en vez de esperar a meterlo en un sitio óptimo.
Lo del movimiento del cabezal sería lo de meter en un directorio todos los ficheros asociados, pero al mismo tiempo, por el hecho de hacer trozos de 80 MB ... aumentas los IOPS, lo cual es negativo. IMHO, lo que han hecho es buscar un tamaño de "bloque"/unidad mínima de datos ideal que son los 80 MB para cargar datos en buffer, caché, RAM, ... como lo quieras llamar. Es un tamaño suficientemente grande como para no agobiar al disco duro (no tener un IO wait eterno porque escribe a disco, que es lo que realmente mata el rendimiento de las aplicaciones). Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 9 de septiembre de 2009 04:12, Rafa Griman
Hola :)
On Tuesday 08 September 2009 21:19:33 Carlos E. R. wrote:
El 2009-09-08 a las 18:07 +0200, Rafa Griman escribió:
Todo sistema de ficheros se fragmenta, nos guste o no y especialmente los sistemas de ficheros que: - gestionan/guardan ficheros grandes - escriben y borran muchos ficheros
Otra cosa es que haya técnicas para mitigar la fragmentación (como el delayed allocation u otras).
La prueba se puede hacer fácilmente con una partición de de por ejemplo 10 GB y creando y borrando ficheros de 1 a 3 GB aleatoriamente. Llega un momento en el que el sistema de ficheros se fragmenta y los ficheros también.
Hoy acaba de salir en Linux Magazine unos benchmarking comparativo de los actuales FSS usados en Linux: http://www.linux-mag.com/cache/7518/1.html Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-09 a las 09:12 +0200, Rafa Griman escribió:
On Tuesday 08 September 2009 21:19:33 Carlos E. R. wrote:
Eso es cierto, pero es que en este caso los ficheros no son "grandes", no superan los ochenta megas, y muchos de ellos. Las grabaciones de varios gigas están partidas en docenas o cientos de ficheros de ochenta megas, y estos ficheros a su vez están fragmentados. Y cada grabación está en un directorio aparte.
Luego está fragmentado el fichero: si pillamos un vídeo/película (¿~800 MB?) y lo partimos en trozos de 80 MB ... está fragmentado ya que ext3 (y los demás sistemas de ficheros en Linux o por lo menos los más actuales) hacen un delayed allocation de ese fichero que mide 80 MB. Es decir, para el sistema de ficheros el fichero mide/pesa 80 MB y no los 800 MB, pero a nivel lógico (para la aplicación), el fichero mide/pesa 800 MB.
No te sigo. Cada grabación es un directorio, el cual contiene una multitud de ficheros, con sus nombres. Hay unos que parecen índices, y otros que son algún tipo de mpeg, de alrededor de 80 megas cada uno. No son ficheros de 800 megas fragmentados en trozos de 80. Son ficheros de 80, que se reproducen uno detrás de otro, encadenando. Y si el sistema operativo dice que hay fragmentación, puesto que lo que ve son los ficheros, son estos ficheros de 80 megas los que están fragmentados, supongo que en trozos de algunos megas.
Cada 80 MB se escribirán donde quepan dando lugar a fragmentación interna del fichero (no necesariamente del sistema de ficheros) y, en el momento que borres el fichero ... dará lugar a una gran fragmentación del sistema de ficheros (tanto del espacio ocupado como del espacio vacío).
Si cada vídeo se almacena en un directorio propio, lo que se está intentando es tener los i-nodos cercanos (esto lo hace XFS también). Esto es muy útil para evitar que los IOPS se desperdiguen por todo el disco duro (mover el cabezal para una lectura/escritura mínima), pero: - el streaming de un vídeo no es el óptimo - se producen muchos IOPS para un único vídeo
Sí, pero recuerda que lo diseñaron para fat, y en fat hay una penalización fuerte por tener una multitud de ficheros en un directorio (el directorio en sí es un fichero que lista el contenido del directorio: si crece, se añaden sectores al "fichero" que contiene el listado, y estará muy fragmentado): no pueden poner todas las películas en el mismo directorio por eso, han de ponerlas en varios, y cada peli en una es lo más fácil.
En todo caso la definición de "grande" depende de muchas cosas: tamaño de la partición, tamaño de los bloques que se están usando, ...
Lo que digo es que sospecho que están usando un algoritmo para minimizar el tiempo de escritura (que necesita ser en tiempo real), escribiendo en algún sector que encuentra antes o que reduce el movimiento del cabezal, en vez de esperar a meterlo en un sitio óptimo.
Lo del movimiento del cabezal sería lo de meter en un directorio todos los ficheros asociados, pero al mismo tiempo, por el hecho de hacer trozos de 80 MB ... aumentas los IOPS, lo cual es negativo.
IMHO, lo que han hecho es buscar un tamaño de "bloque"/unidad mínima de datos ideal que son los 80 MB para cargar datos en buffer, caché, RAM, ... como lo quieras llamar. Es un tamaño suficientemente grande como para no agobiar al disco duro (no tener un IO wait eterno porque escribe a disco, que es lo que realmente mata el rendimiento de las aplicaciones).
No pueden cargar 80 megas en un tampón, porque la memoria interna es de 44564K. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqoA9QACgkQtTMYHG2NR9U5rACfbf4+XCO9jS7sl8I24oZ9eVnE soYAn1kMvEsmZC/S712oWIWMTMwmfhDj =lJE4 -----END PGP SIGNATURE-----
Hola :) On Wednesday 09 September 2009 21:36:42 Carlos E. R. wrote:
El 2009-09-09 a las 09:12 +0200, Rafa Griman escribió:
On Tuesday 08 September 2009 21:19:33 Carlos E. R. wrote:
Eso es cierto, pero es que en este caso los ficheros no son "grandes", no superan los ochenta megas, y muchos de ellos. Las grabaciones de varios gigas están partidas en docenas o cientos de ficheros de ochenta megas, y estos ficheros a su vez están fragmentados. Y cada grabación está en un directorio aparte.
Luego está fragmentado el fichero: si pillamos un vídeo/película (¿~800 MB?) y lo partimos en trozos de 80 MB ... está fragmentado ya que ext3 (y los demás sistemas de ficheros en Linux o por lo menos los más actuales) hacen un delayed allocation de ese fichero que mide 80 MB. Es decir, para el sistema de ficheros el fichero mide/pesa 80 MB y no los 800 MB, pero a nivel lógico (para la aplicación), el fichero mide/pesa 800 MB.
No te sigo.
A ver si soy yo el que lo ha entendido mal 0:)
Cada grabación es un directorio, el cual contiene una multitud de ficheros, con sus nombres. Hay unos que parecen índices, y otros que son algún tipo de mpeg, de alrededor de 80 megas cada uno.
Si cada directorio es una grabación y contiene MPEGs de 80 MBytes, el vídeo (la película) tiene que estar partida en chunks de 80 MB porque una peli entero de 90 minutos (más o menos) no es puede comprimir en 80 MB ni en el mejor de los sueños ;) Luego una peli (pongamos por ejemplo Spirdeman 1) la parte en trozos de 80 MBytes. Por lo menos eso es lo que entiendo que hace.
No son ficheros de 800 megas fragmentados en trozos de 80. Son ficheros de 80, que se reproducen uno detrás de otro, encadenando. Y si el sistema operativo dice que hay fragmentación, puesto que lo que ve son los ficheros, son estos ficheros de 80 megas los que están fragmentados, supongo que en trozos de algunos megas.
Claro, pero tienes doble fragmentación: 1.- por un lado tienes que la peli de Spiderman se ha "roto" en fragmentos de 80 MBytes. Primera fragmentación. 2.- esos fragmentos de 80 MBytes a lo mejor no se han podido escribir secuencialmente en el disco duro. Segunda fragmentación. Todo esto es a mi entender sin tener el cacharro en mis manos, claro está 0;)
Cada 80 MB se escribirán donde quepan dando lugar a fragmentación interna del fichero (no necesariamente del sistema de ficheros) y, en el momento que borres el fichero ... dará lugar a una gran fragmentación del sistema de ficheros (tanto del espacio ocupado como del espacio vacío).
Si cada vídeo se almacena en un directorio propio, lo que se está intentando es tener los i-nodos cercanos (esto lo hace XFS también). Esto es muy útil para evitar que los IOPS se desperdiguen por todo el disco duro (mover el cabezal para una lectura/escritura mínima), pero: - el streaming de un vídeo no es el óptimo - se producen muchos IOPS para un único vídeo
Sí, pero recuerda que lo diseñaron para fat, y en fat hay una penalización fuerte por tener una multitud de ficheros en un directorio (el directorio en sí es un fichero que lista el contenido del directorio: si crece, se añaden sectores al "fichero" que contiene el listado, y estará muy fragmentado): no pueden poner todas las películas en el mismo directorio por eso, han de ponerlas en varios, y cada peli en una es lo más fácil.
En Linux, eso de tener todos los ficheros relacionados en un directorio es lo ideal :) A lo mejor me he explicado mal, no quería decir qu epongan todas las pelis en un direcotorio sino todos los ficheros relacionados a esa peli (Spiderman 1) en un directorio. Luego la peli de Spiderman 2 iría en el directorio 2. Creo que estamos diciendo lo mismo ;)
En todo caso la definición de "grande" depende de muchas cosas: tamaño de la partición, tamaño de los bloques que se están usando, ...
Lo que digo es que sospecho que están usando un algoritmo para minimizar el tiempo de escritura (que necesita ser en tiempo real), escribiendo en algún sector que encuentra antes o que reduce el movimiento del cabezal, en vez de esperar a meterlo en un sitio óptimo.
Lo del movimiento del cabezal sería lo de meter en un directorio todos los ficheros asociados, pero al mismo tiempo, por el hecho de hacer trozos de 80 MB ... aumentas los IOPS, lo cual es negativo.
IMHO, lo que han hecho es buscar un tamaño de "bloque"/unidad mínima de datos ideal que son los 80 MB para cargar datos en buffer, caché, RAM, ... como lo quieras llamar. Es un tamaño suficientemente grande como para no agobiar al disco duro (no tener un IO wait eterno porque escribe a disco, que es lo que realmente mata el rendimiento de las aplicaciones).
No pueden cargar 80 megas en un tampón, porque la memoria interna es de 44564K.
No me refería que cargasen 80 MBytes en memoria, sino que es un tamaño de fichero pequeño, fácil de gestionar. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-10 a las 10:07 +0200, Rafa Griman escribió:
Hola :)
On Wednesday 09 September 2009 21:36:42 Carlos E. R. wrote:
No te sigo.
A ver si soy yo el que lo ha entendido mal 0:)
:-)
Cada grabación es un directorio, el cual contiene una multitud de ficheros, con sus nombres. Hay unos que parecen índices, y otros que son algún tipo de mpeg, de alrededor de 80 megas cada uno.
Si cada directorio es una grabación y contiene MPEGs de 80 MBytes, el vídeo (la película) tiene que estar partida en chunks de 80 MB porque una peli entero de 90 minutos (más o menos) no es puede comprimir en 80 MB ni en el mejor de los sueños ;)
Correcto.
Luego una peli (pongamos por ejemplo Spirdeman 1) la parte en trozos de 80 MBytes. Por lo menos eso es lo que entiendo que hace.
Si.
No son ficheros de 800 megas fragmentados en trozos de 80. Son ficheros de 80, que se reproducen uno detrás de otro, encadenando. Y si el sistema operativo dice que hay fragmentación, puesto que lo que ve son los ficheros, son estos ficheros de 80 megas los que están fragmentados, supongo que en trozos de algunos megas.
Claro, pero tienes doble fragmentación:
1.- por un lado tienes que la peli de Spiderman se ha "roto" en fragmentos de 80 MBytes. Primera fragmentación.
2.- esos fragmentos de 80 MBytes a lo mejor no se han podido escribir secuencialmente en el disco duro. Segunda fragmentación.
Vale, si. Cierto. No me lo había planteado en esos términos.
Todo esto es a mi entender sin tener el cacharro en mis manos, claro está 0;)
Ese eso, en efecto.
Cada 80 MB se escribirán donde quepan dando lugar a fragmentación interna del fichero (no necesariamente del sistema de ficheros) y, en el momento que borres el fichero ... dará lugar a una gran fragmentación del sistema de ficheros (tanto del espacio ocupado como del espacio vacío).
Si cada vídeo se almacena en un directorio propio, lo que se está intentando es tener los i-nodos cercanos (esto lo hace XFS también). Esto es muy útil para evitar que los IOPS se desperdiguen por todo el disco duro (mover el cabezal para una lectura/escritura mínima), pero: - el streaming de un vídeo no es el óptimo - se producen muchos IOPS para un único vídeo
Sí, pero recuerda que lo diseñaron para fat, y en fat hay una penalización fuerte por tener una multitud de ficheros en un directorio (el directorio en sí es un fichero que lista el contenido del directorio: si crece, se añaden sectores al "fichero" que contiene el listado, y estará muy fragmentado): no pueden poner todas las películas en el mismo directorio por eso, han de ponerlas en varios, y cada peli en una es lo más fácil.
En Linux, eso de tener todos los ficheros relacionados en un directorio es lo ideal :)
Y en msdos/windows. En ntfs ni idea, pero supongo que también.
A lo mejor me he explicado mal, no quería decir qu epongan todas las pelis en un direcotorio sino todos los ficheros relacionados a esa peli (Spiderman 1) en un directorio. Luego la peli de Spiderman 2 iría en el directorio 2.
Si, eso es.
Creo que estamos diciendo lo mismo ;)
Pues si :-)
En todo caso la definición de "grande" depende de muchas cosas: tamaño de la partición, tamaño de los bloques que se están usando, ...
Lo que digo es que sospecho que están usando un algoritmo para minimizar el tiempo de escritura (que necesita ser en tiempo real), escribiendo en algún sector que encuentra antes o que reduce el movimiento del cabezal, en vez de esperar a meterlo en un sitio óptimo.
Lo del movimiento del cabezal sería lo de meter en un directorio todos los ficheros asociados, pero al mismo tiempo, por el hecho de hacer trozos de 80 MB ... aumentas los IOPS, lo cual es negativo.
IMHO, lo que han hecho es buscar un tamaño de "bloque"/unidad mínima de datos ideal que son los 80 MB para cargar datos en buffer, caché, RAM, ... como lo quieras llamar. Es un tamaño suficientemente grande como para no agobiar al disco duro (no tener un IO wait eterno porque escribe a disco, que es lo que realmente mata el rendimiento de las aplicaciones).
No pueden cargar 80 megas en un tampón, porque la memoria interna es de 44564K.
No me refería que cargasen 80 MBytes en memoria, sino que es un tamaño de fichero pequeño, fácil de gestionar.
Si, bueno... pero vaya, si sabes a priori que el tamaño máximo del timeshift son tres horas, pues puedes reservar un espacio continuo del tamaño suficiente para esa operación (creo que el mythtv hace eso). El problema es que si a mitad de programa el usuario decide que quiere grabar esa pelicula (que empezó hace una hora), pues el aparato lo hace; pero si hemos usado el algoritmo del tampón circular pues, o lo copias en otro segundo fichero, o lo desenganchas. Cualquiera de las soluciones no son efectivas. En cambio, el sitema que usan, es que instantáneamente reasignan los ficheros indexados que corresponden a la parte de la película a otra grabación, sin copiar más que los indices. Es muy eficaz. Creo que lo hacen así por eso, lo máximo que van a tener que copiar son ochenta megas. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqpTlMACgkQtTMYHG2NR9XyDgCfbCVjznLQpkMhTxnKQP3kWeHj WLcAnR1QogBx8rGuWRaxDamXy48RvFrj =GnS2 -----END PGP SIGNATURE-----
Hola :) On Sunday 23 August 2009 00:44:27 Lluis wrote:
On Saturday 22 August 2009 23:45:30 Camale�n wrote:
2009/8/22, Carlos E. R.:
Fijaos en esto, del disco de mi cacharr�n de la tele (es linux), que he enchufado a mi PC para comprobaci�n:
nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced.
(...)
Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ #
�No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso s�lo le pasa al windows :-P
(pensando en voz alta...)
La unidad de disco del cacharr�n no ha sido dise�ada teniendo en mente la conexi�n a un equipo con linux, principalmente, luego no me explico c�mo...
a) El aparato no dispone de una rutina de autocomprobaci�n aut�noma que verifique el estado del disco cada "x" tiempo.
b) Pueden aguantar el "tute" que se le da a estos chismes con esa fragmentaci�n y seguir funcionando como si nada.
Me pregunto en qu� estado se encontrar�n el resto de unidades que no se verifican nunca...
En un cacharro multimedia. �Es importante el tiempo de acceso? No lo se, solo lo pregunto. Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia.
Para un usuario final que lo va a usar para ver una peli, no es muy importante. ¿Recuerdas la época del VHS/Beta que tardaba un rato hasta que se veía la película? Pues lo mismo. Sí es cierto que los usuarios cada vez tienen menos paciencia y quieren que al darle al "Play", se reproduzca inmediatamente. A la hora de trabajar con vídeo, sí es importante para evitar pérdida de datos.
Estar fragmentado, no es bueno ni malo, depende del uso que se le da.
Estoy de acuerdo. COmo he dicho, si trabajas editando vídeo, sí es importante, pero no es el caso. Lo que sí puede ocurrir en este caso es que un mismo fichero esté fragmentado mucho por lo que al ver el vídeo, la película de saltos que son muy molestos y pierdas algún frame o algún trozo de diálogo. Basta con rebobinar y volver a empezar desde ese fragmento.
Adem�s, solo debe aguantar dos a�os, hasta que se acabe la garant�a.
Ja, ja, ja, ... MUY bueno !!! Y cierto ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Sunday 23 August 2009 00:44:27 Lluis wrote:
En un cacharro multimedia. ???Es importante el tiempo de acceso? No lo se, solo lo pregunto. Porque a lo mejor, para lo que sirve eso no tiene ninguna importancia.
Para un usuario final que lo va a usar para ver una peli, no es muy importante. ¿Recuerdas la época del VHS/Beta que tardaba un rato hasta que se veía la película? Pues lo mismo. Sí es cierto que los usuarios cada vez tienen menos paciencia y quieren que al darle al "Play", se reproduzca inmediatamente.
El caso es que reproduce inmediatamente, incluso estando cargado, y sin pausas ni cortes. Son el resto de funciones las que se retrasan, como mostrar el menú o atender peticiones externas del servidor web. Obviamente lo han diseñado bien.
A la hora de trabajar con vídeo, sí es importante para evitar pérdida de datos.
Y no los pierde.
Estar fragmentado, no es bueno ni malo, depende del uso que se le da.
Estoy de acuerdo. COmo he dicho, si trabajas editando vídeo, sí es importante, pero no es el caso.
Lo que sí puede ocurrir en este caso es que un mismo fichero esté fragmentado mucho por lo que al ver el vídeo, la película de saltos que son muy molestos y pierdas algún frame o algún trozo de diálogo. Basta con rebobinar y volver a empezar desde ese fragmento.
Pero no va a saltos. Y eso que el transporte del disco es via USB. - -- Saludos Carlos. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqSo3AACgkQtTMYHG2NR9VBUwCfWh3fV43M7PgMU42fczDZ7qoh m64An2BulmSKY1e8RK1T+LNNOMpg2xu+ =uoIB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-22 a las 23:45 +0200, Camaleón escribió:
2009/8/22, Carlos E. R.:
Fijaos en esto, del disco de mi cacharrín de la tele (es linux), que he enchufado a mi PC para comprobación:
nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced.
(...)
Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ #
¿No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso sólo le pasa al windows :-P
(pensando en voz alta...)
La unidad de disco del cacharrín no ha sido diseñada teniendo en mente la conexión a un equipo con linux, principalmente, luego no me explico cómo...
El disco es externo y lo hice yo a partir de un seagate sata y una caja usb (y sata que no uso), formateado en ext3, con otra pequeña partición swap (que usa el cacharrín). O sea, el disco es plenamente normal. Y el cacharrín en si es linux, sí: MORIA login: root Password: - ----------------------------------------- Host: MORIA Version FW: 2.3.61 Version SIESTA: 2.3.61.SL06beta6 SIESTA-Lemmi-06 Actualización: 2008-10-30 11:00:00 - ----------------------------------------- [root@MORIA:~]# uname -a Linux MORIA 2.4.21-xfs #646 Wed Aug 3 10:01:46 CEST 2005 mips unknown [root@MORIA:~]# ls --help BusyBox v1.01 (2006.11.30-16:43+0000) multi-call binary
a) El aparato no dispone de una rutina de autocomprobación autónoma que verifique el estado del disco cada "x" tiempo.
Eso es cierto, el fsck no es automático, porque los usuarios se desesperarían. Aunque la mayoría de la gente lo usa con fat, soporta ext3 y dicen que va mejor.
b) Pueden aguantar el "tute" que se le da a estos chismes con esa fragmentación y seguir funcionando como si nada.
Cierto. Pero eso es cosa del linux. La pega es que hace que el disco trabaje más y se caliente más. Tendría que pensar en usar un desfragmentador. Ah, y... a pesar de ser multimedia, usa ficheros de unos cien megas a lo sumo, muchísimos de ellos, en vez de un grande de varios gigas.
Me pregunto en qué estado se encontrarán el resto de unidades que no se verifican nunca...
:-?
Sip. Yo a lo que iba es que un ext3 puede tener una fragmentación terrible, el sistema no lo impide. O... :-? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqSmWEACgkQtTMYHG2NR9V76QCfQaf1fGZPltM2fHcr+dxdUV1P XvUAn24TLXmxJPsKsTcBQPdy0Wk3+jkh =ndaC -----END PGP SIGNATURE-----
2009/8/22 Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hola:
Fijaos en esto, del disco de mi cacharrín de la tele (es linux), que he enchufado a mi PC para comprobación:
nimrodel:~ # fsck /dev/sdb1 fsck 1.40.8 (13-Mar-2008) e2fsck 1.40.8 (13-Mar-2008) Moria_250 has been mounted 1574 times without being checked, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Pass 4: Checking reference counts Pass 5: Checking group summary information
Moria_250: ***** FILE SYSTEM WAS MODIFIED ***** Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960 blocks nimrodel:~ #
¿No veis algo peculiar en el porcentaje de ficheros no contiguos? Hala, pa'que me digais que eso sólo le pasa al windows :-P
ojo como todo disco externo , por ejemplo tengo un NAS de la Airlink101 que usa sistema de ficheros Ext2 , pero creo que si tu cacharrin es ext3 puedes darle una optimizada ... :) algo asi e2fsck -f -D /dev/mi cacharrín my 0.03 cents saludoss -- rickygm http://gnuforever.homelinux.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Sunday 23 August 2009 05:31:13 troxlinux wrote:
Moria_250 has been mounted 1574 times without being checked, check
Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960
No se que PVR será pero grabar-reproducir mientras el brazo del disco sigue el hilo debe ser como ver la moviola de un partido y decir que eso ha sido todo.
ojo como todo disco externo , por ejemplo tengo un NAS de la Airlink101 que usa sistema de ficheros Ext2 , pero creo que si tu cacharrin es ext3 puedes darle una optimizada ... :)
algo asi e2fsck -f -D /dev/mi cacharrín
Pues si, buena falta le hace. Yo diría que le viene como marcapasos a infartado. Despues del check ira mejor, pero el esfuerzo hecho hasta ahora es posible que haya hecho mella. Prueba las smartmoontools por si ya te canta algún warning. Saludos. Alfredo J.V.P. -- ... la inmensa mayoría de los seres necesitan impetuosamente tener una autoridad a la cual puedan admirar, bajo la que puedan someterse, por la que puedan ser dominados, y eventualmente, aún maltratados. -- Sigmund Freud --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-08-24 a las 12:15 +0200, Alfredo J. V. P. escribió:
On Sunday 23 August 2009 05:31:13 troxlinux wrote:
Moria_250 has been mounted 1574 times without being checked, check
Moria_250: 5872/30408704 files (62.6% non-contiguous), 34630399/60791960
No se que PVR será pero grabar-reproducir mientras el brazo del disco sigue el hilo debe ser como ver la moviola de un partido y decir que eso ha sido todo.
ojo como todo disco externo , por ejemplo tengo un NAS de la Airlink101 que usa sistema de ficheros Ext2 , pero creo que si tu cacharrin es ext3 puedes darle una optimizada ... :)
¿optimizar, como? Tiene lo que tiene. De hecho, es ext3 pero lo usa como ext2. Es un linux 2.4 con busybox.
algo asi e2fsck -f -D /dev/mi cacharrín
-f Force checking even if the file system seems clean. No hace falta forzrlo. -D Optimize directories in filesystem. This option causes e2fsck to try to optimize all directories, either by reindexing them if the filesystem supports directory indexing, or by sorting and compressing directories for smaller directories, or for filesystems using traditional linear directories. No estoy seguro que ext2 soporte eso, pero en cuaquier caso, no quita la fragmentación.
Pues si, buena falta le hace. Yo diría que le viene como marcapasos a infartado. Despues del check ira mejor, pero el esfuerzo hecho hasta ahora es posible que haya hecho mella. Prueba las smartmoontools por si ya te canta algún warning.
Nada de eso tiene que ver con la fragmentación del disco. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqSnaoACgkQtTMYHG2NR9UsFACggkUg1V1t2ZRZV5uNd9umQOMd BCwAnRgb0GLggR/SKLYxpnZlPI6+ayAj =4jvq -----END PGP SIGNATURE-----
participants (8)
-
Alfredo J. V. P. -
Camaleón -
Carlos E. R. -
Juan Erbes -
Lluis -
manolo -
Rafa Griman -
troxlinux