Lo intento grabar en el propio equipo, demasiado volumen. Problema, Mac solo lee los NTFS; no escribe en ellos, salvo compra de aplicación intermedia.
Suficiente. No hace falta decir más.
Mostrando entradas con la etiqueta NTFS. Mostrar todas las entradas
Mostrando entradas con la etiqueta NTFS. Mostrar todas las entradas
lunes, 12 de septiembre de 2016
Lo que no hace un Mac
Entrada sencilla, en la que muestro lo poco que sé de los Mac. Para ser breves; me piden unos ficheros multimedia; los grabo en un disco externo en NTFS y me acerco a la casa de la persona que los había pedido. Intento grabarlos en otro disco externo NTFS usando su equipo, un iBook. Imposible.
Lo intento grabar en el propio equipo, demasiado volumen. Problema, Mac solo lee los NTFS; no escribe en ellos, salvo compra de aplicación intermedia.
Suficiente. No hace falta decir más.
Lo intento grabar en el propio equipo, demasiado volumen. Problema, Mac solo lee los NTFS; no escribe en ellos, salvo compra de aplicación intermedia.
Suficiente. No hace falta decir más.
viernes, 31 de enero de 2014
Unidades USB baratas; recomendable la paciencia
Estos días he tenido la necesidad de utilizar unidades USB para mis exposiciones. Antes me comunicaba directamente a mi Dropbox o usaba Slideshare, pero realmente reconozco la ventaja y comodidad de usar impressive en una unidad USB. Más sencillo, sin riesgos, si no hay conexión a la red, se mantienen las presentaciones como tú quieres, aunque tengas que lidiar con un sistema que no es el tuyo (véase Windows).
Sin embargo, he tenido un problema. Originariamente pensé que era técnico, pero realmente era solo falta de paciencia.
Suelo llevar conmigo dos unidades USB. Una,un Kingston DT R3.0, que es mi unidad principal. Suelo llevar en ella una copia de todo lo necesario, incluido emergencias, software, ISOs etc... Es una unidad bastante rápida de la que se puede esperar lo mejor.
Por comodidad, debido a que entra en el bolsillo de las monedas, llevo una segunda unidad. Fue mucho más barata, a pesar de tener la misma capacidad, y no es USB 3.0. Todo ello se traduce en que es MUCHO MÁS LENTA en la escritura.
En mis exposiciones uso esta segunda unidad, ya que llevo solo lo necesario en cada momento, y si se daña o se pierde, tiene menos importancia y cuesta menos. En la primera prueba de las exposiciones, me fallaba continuamente. Impressive no arrancaba, indicando errores de faltas de dlls y no era capaz de abrir los PDFs. Achaqué la culpa al formato NTFS realizado en Linux, así que formateé en un ordenador con Windows 7 y lo volví a intentar, pero aparecían los mismos errores.
La solución es simple... copia los ficheros necesarios y ESPERA, y aun después de desmontar la unidad, espera otro poco. Las unidades baratas lo son por lentas, no por malas, al menos en marcas conocidas como Sandisk. Mi primer dispositivo USB me costo 65€ con solo 256MB por que era muy rápido. Luego tuve un Kingston de 125€ que era capaz de copiar un avi de 700MB en 40 segundos, mientras que las unidades normales tardaban más de un cuarto de hora. Con las unidades con USB 3.0 ya no es necesario ir tan alto en la gama, pero si compramos unidades de unos pocos eurillos, ¡tengamos PACIENCIA!
Y no tengo nada que decir en contra de Sandisk, marca de la que tengo muchos dispositivos que funcionan perfectamente. Simplemente, por comodidad y economía me he comprado una unidad barata y, por tanto, lenta.
Sin embargo, he tenido un problema. Originariamente pensé que era técnico, pero realmente era solo falta de paciencia.
Suelo llevar conmigo dos unidades USB. Una,un Kingston DT R3.0, que es mi unidad principal. Suelo llevar en ella una copia de todo lo necesario, incluido emergencias, software, ISOs etc... Es una unidad bastante rápida de la que se puede esperar lo mejor.
Por comodidad, debido a que entra en el bolsillo de las monedas, llevo una segunda unidad. Fue mucho más barata, a pesar de tener la misma capacidad, y no es USB 3.0. Todo ello se traduce en que es MUCHO MÁS LENTA en la escritura.
En mis exposiciones uso esta segunda unidad, ya que llevo solo lo necesario en cada momento, y si se daña o se pierde, tiene menos importancia y cuesta menos. En la primera prueba de las exposiciones, me fallaba continuamente. Impressive no arrancaba, indicando errores de faltas de dlls y no era capaz de abrir los PDFs. Achaqué la culpa al formato NTFS realizado en Linux, así que formateé en un ordenador con Windows 7 y lo volví a intentar, pero aparecían los mismos errores.
La solución es simple... copia los ficheros necesarios y ESPERA, y aun después de desmontar la unidad, espera otro poco. Las unidades baratas lo son por lentas, no por malas, al menos en marcas conocidas como Sandisk. Mi primer dispositivo USB me costo 65€ con solo 256MB por que era muy rápido. Luego tuve un Kingston de 125€ que era capaz de copiar un avi de 700MB en 40 segundos, mientras que las unidades normales tardaban más de un cuarto de hora. Con las unidades con USB 3.0 ya no es necesario ir tan alto en la gama, pero si compramos unidades de unos pocos eurillos, ¡tengamos PACIENCIA!
Y no tengo nada que decir en contra de Sandisk, marca de la que tengo muchos dispositivos que funcionan perfectamente. Simplemente, por comodidad y economía me he comprado una unidad barata y, por tanto, lenta.
jueves, 8 de marzo de 2012
Sistema de archivos NTFS: formatear en Windows
A lo largo del tiempo he tenido muchos problemas con los discos que formateo en NTFS (véase 1,2 y muchos más). Realmente el problema mayor me había aparecido en Ubuntu 11.04, debido seguramente a algún bug en parted o gparted. Sin embargo, en estas dos últimas semanas he tenido repetidos errores en el formateo a NTFS en Fedora 16. En primer lugar varios lápices que funcionan correctamente en mi equipo al formatearlos, y a los que les he copiado diferentes ficheros, al intentar leerlos de nuevo, tanto en windows como en diferentes distribuciones de Linux dan un error que exige la aplicación de chkdsk -f y desmontado dos veces para poder recuperar el contenido. Finalmente, un disco de 2TB, formateado también en gparted (0.12.0-1.fc16, parted 3.0-4.fc16, mkfs, ntfsprogs) me ha generado un problema de entrada-salida al copiar ficheros grandes en él. Decididamente, o dejamos de usar NTFS (maldita compatibilidad), que sería lo mejor y más prudente, o formateamos en un ordenador con Windows (donde estás, que no te veo). He aquí una magnifica razón para dejar de usar unidades NTFS.
miércoles, 15 de febrero de 2012
Discos de más de 2TB. Posibilidades de uso
El día que me enteré de las inundaciones en Tailandia fui corriendo a mi tienda habitual de material informático a comprar discos duros, y solo me vendieron uno, con lo que hice un recorrido "amplio" por la ciudad y me compré 3, por si tenía luego problemas de suministro. Apresuradamente compré dos unidades de más de 2 TB, que eran inútiles en mi antigua unidad WDTV. Después de haber comprobado que el firmware no se ha cambiado en mucho tiempo, y que por tanto es un dispositivo sin futuro, lo he transferido a otra televisión y en la que se usaba habitualmente he instalado un nuevo WD TV Live. Este nuevo dispositivo sí lee los discos de más de 2TB, así que ahora solo nos queda decidir la forma en la que se van a usar.
Como es sabido, las tablas de partición basadas en MBR (Master Boot Record), la famosa partición msdos que llevamos haciendo desde ya no se sabe cuando, no permiten particiones mayores de 2TB, por diferentes razones que en vez de explicar aquí serán más fácil de entender si las miramos aquí. El resultado final es que tenemos dos discos de 2,5 TB (WD Elements) y 3TB (WD My Book) al que tenemos que darle uso.
El uso de estos discos como arranque genera un problema en la BIOS, que tiene que ser capaz de arrancar en formato EFI (Extensible Firmware Interface), en vez de MBR, ya que así podemos utilizar tablas de partición GPT (GUID Partition Table). Es decir, debemos poder cambiar el tipo de arranque en la BIOS. En mi caso no me preocupa. Primero, uso discos de sistema de 30GB y 34GB en mis ordenadores principales. En los demás no uso nunca discos muy grandes (trabajo, pasó el resultado a Dropbox y punto). Mi principal objetivo para estos discos es almacenamiento. Para ello he probado diferentes formas de distribuir los discos:
1. Lo más sencillo es hacer dos particiones, de tal manera que ninguna tenga más de 2TB. Me surge la duda de si eso es posible si la partición se realiza en sectores de 512 bytes, ya que en ese caso chocaríamos con el límite de número de sectores (ver de nuevo aquí). De todas maneras, ahora la partición estándar en gparted es ahora en sectores de 4096 bytes, así que no tenemos ese problema. En este caso el disco de 2,5TB fue particionado tipo msdos (MBR), con dos particiones inferiores a 2TB
El dispositivo WD TV Live como se ve lee perfectamente las dos particiones y sus ficheros. Por supuesto, no es posible ni ext3, ni ext4. El dispositivo solo lee fat, fat32 y NTFS.
Es decir, una forma de usarlos para simple almacenamiento sería particionarlo "tradicionalmente" con dos particiones (o más) inferiores a 2TB. Para asegurar, formatearemos con sectores de 4096 bytes o más.
2. Por supuesto, lo más adecuado -o quizás no- sería particionarlo una sola vez en una tabla GPT. Lo he aplicado sobre el disco de 3TB y por curiosidad he aplicado inicialmente un formateo en ext4. El dispositivo detectaba el disco,
pero era incapaz de encontrar los ficheros.
Sin embargo, con la tabla de partición GPT, pero formateado a NTFS, el dispositivo lo lee perfectamente
Esto nos da una segunda opción; una tabla de partición GPT con una sola partición (o varias si se prefiere). La decisión depende de varios factores. Sin embargo, por comodidad, seguridad y compatibilidad, quizás lo más adecuado en este momento sea hacer dos particiones o más del disco, ya que un fallo en una partición podría no afectar a la otra y se podrían salvar al menos la mitad de las copias priv..., quiero decir de las manzanas (más de una cesta) y en una tabla MBR.
El uso de las particiones GPT para arranque no es, por ahora, algo que me preocupe, ya que tiendo a utilizar el disco más pequeño que encuentro para el sistema. En estos momentos uso discos sólidos para eso, ya que ahora mismo empieza a ser muy difícil conseguir un disco magnético menor de 1 TB, y prefiero tener separados el sistema y home.
Eso sí, lo reconozco, y se ve en las fotos; he particionado de forma gráfica, a través de gparted. Para los que prefieran hacerlo de forma manual, puede ser útil esta entrada. Sin embargo, una vez particionado y formateado queda asignado al grupo root (gparted solo actua desde root), y el cambio de grupo y los permisos se hicieron en terminal (chgrp y chmod). Son costumbres de trabajo. Sea como fuere, ambos discos funcionan, son utilizables en el ordenador (casi 4 años, no precisamente de hoy) y el WD TV Live también los lee. Tenemos estas opciones y funcionan.
Como es sabido, las tablas de partición basadas en MBR (Master Boot Record), la famosa partición msdos que llevamos haciendo desde ya no se sabe cuando, no permiten particiones mayores de 2TB, por diferentes razones que en vez de explicar aquí serán más fácil de entender si las miramos aquí. El resultado final es que tenemos dos discos de 2,5 TB (WD Elements) y 3TB (WD My Book) al que tenemos que darle uso.
El uso de estos discos como arranque genera un problema en la BIOS, que tiene que ser capaz de arrancar en formato EFI (Extensible Firmware Interface), en vez de MBR, ya que así podemos utilizar tablas de partición GPT (GUID Partition Table). Es decir, debemos poder cambiar el tipo de arranque en la BIOS. En mi caso no me preocupa. Primero, uso discos de sistema de 30GB y 34GB en mis ordenadores principales. En los demás no uso nunca discos muy grandes (trabajo, pasó el resultado a Dropbox y punto). Mi principal objetivo para estos discos es almacenamiento. Para ello he probado diferentes formas de distribuir los discos:
1. Lo más sencillo es hacer dos particiones, de tal manera que ninguna tenga más de 2TB. Me surge la duda de si eso es posible si la partición se realiza en sectores de 512 bytes, ya que en ese caso chocaríamos con el límite de número de sectores (ver de nuevo aquí). De todas maneras, ahora la partición estándar en gparted es ahora en sectores de 4096 bytes, así que no tenemos ese problema. En este caso el disco de 2,5TB fue particionado tipo msdos (MBR), con dos particiones inferiores a 2TB
El dispositivo WD TV Live como se ve lee perfectamente las dos particiones y sus ficheros. Por supuesto, no es posible ni ext3, ni ext4. El dispositivo solo lee fat, fat32 y NTFS.
Es decir, una forma de usarlos para simple almacenamiento sería particionarlo "tradicionalmente" con dos particiones (o más) inferiores a 2TB. Para asegurar, formatearemos con sectores de 4096 bytes o más.
2. Por supuesto, lo más adecuado -o quizás no- sería particionarlo una sola vez en una tabla GPT. Lo he aplicado sobre el disco de 3TB y por curiosidad he aplicado inicialmente un formateo en ext4. El dispositivo detectaba el disco,
pero era incapaz de encontrar los ficheros.
Sin embargo, con la tabla de partición GPT, pero formateado a NTFS, el dispositivo lo lee perfectamente
Esto nos da una segunda opción; una tabla de partición GPT con una sola partición (o varias si se prefiere). La decisión depende de varios factores. Sin embargo, por comodidad, seguridad y compatibilidad, quizás lo más adecuado en este momento sea hacer dos particiones o más del disco, ya que un fallo en una partición podría no afectar a la otra y se podrían salvar al menos la mitad de las copias priv..., quiero decir de las manzanas (más de una cesta) y en una tabla MBR.
El uso de las particiones GPT para arranque no es, por ahora, algo que me preocupe, ya que tiendo a utilizar el disco más pequeño que encuentro para el sistema. En estos momentos uso discos sólidos para eso, ya que ahora mismo empieza a ser muy difícil conseguir un disco magnético menor de 1 TB, y prefiero tener separados el sistema y home.
Eso sí, lo reconozco, y se ve en las fotos; he particionado de forma gráfica, a través de gparted. Para los que prefieran hacerlo de forma manual, puede ser útil esta entrada. Sin embargo, una vez particionado y formateado queda asignado al grupo root (gparted solo actua desde root), y el cambio de grupo y los permisos se hicieron en terminal (chgrp y chmod). Son costumbres de trabajo. Sea como fuere, ambos discos funcionan, son utilizables en el ordenador (casi 4 años, no precisamente de hoy) y el WD TV Live también los lee. Tenemos estas opciones y funcionan.
martes, 7 de febrero de 2012
Fedora, cpulimit y discos NTFS
Debido a mis problemas con los discos NTFS decidí seguir los consejos de hckorootx (véase comentarios aquí). Esto nos lleva a algunos problemas. El primero, cpulimit no esta en los repositorios estándar de Fedora, así que nos queda instalarlo desde un paquete rpm (32 bits o 64 bits), o bien introducir el repositorio sphere. Por ejemplo, la forma más fácil es como administrador
$ su -
palabrita de administrador
# gedit
en ese documento pegamos el texto que podemos extraer de esos enlaces
[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/repodata/repomd.xml.key
enabled=1
gpgcheck=1
y luego lo guardamos en el directorio de los repositorios (/etc/yum.repos.d) como rpm-sphere.repo.
Actualizamos (nos basta un simple # yum update y ya se recargan los repositorios) y lo instalamos directamente
# yum install cpulimit
Sin embargo surgen nuevas dudas a partir de aquí. Si nos fijamos en los comentarios de hckoroot, la forma más fácil de usar cpulimit es, en vez de identificar el comando a controlar por su PID, lo mejor es identificarlo por su nombre. Nos quedaría
cpulimit --path=/ruta/ejecutable --limit=N
lo que nos lleva a como copiamos:
- Si usamos cp en terminal, el comando es cp, claro
- Si usamos rsync, que a mi me gusta particulamente, el comando es rsync
El problema radica en que la mayor parte copiará con Nautilus, que lleva embebido los comandos, y no genera una nueva instancia para copiar, si no que todo lo que hagamos con Nautilus se hace dentro de la misma instancia. A eso se suma que el gran consumo del sistema al copiar en discos NTFS se produce no en la copia, si no en el propio manejo del NTFS a través de mount.ntfs. Por ejemplo este top copiando con Nautilus en un disco formateado NTFS:
Y si a ello le sumamos otras aplicaciones que consuman recursos, por ejemplo Chromium y aMule, llegamos al bloqueo del sistema
¿Podemos solucionarlo con cpulimit? Desde mi punto de vista no. Si el límite que le ponemos es sobrepasado, la aplicación deja de funcionar; si de corta mount.ntfs, probablemente perderemos el contenido que hayamos copiado en él, ya que no se guardarán las nuevas tablas, como ya me ha pasado a mi sin incluir cpulimit. Además, ¿cuál sería el límite? Como se puede ver en esa instancia, mount.ntfs estaba momentáneamente por encima de 50%; probablemente esté a veces por debajo y otras veces por arriba. Si llegamos hasta un 70%, ¿cuanto queda para lo demás?
Conclusión: una única recomendación para copiar en discos formateados en NTFS en Linux - paciencia y nunca hacer saltar el sistema. Mejor esperar. Un segundo apunte, que me aplico en estos momentos, copiar en lotes pequeños, como mucho 30-40GB, por que la paciencia tiene un límite y tendemos a ponernos nerviosos.
Si alguien quiere probar cpulimit en la copia sobre NTFS, que lo haga y nos diga que límite hay que poner. Yo prefiero aplicar la paciencia y no perder más material.
$ su -
palabrita de administrador
# gedit
en ese documento pegamos el texto que podemos extraer de esos enlaces
[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/repodata/repomd.xml.key
enabled=1
gpgcheck=1
y luego lo guardamos en el directorio de los repositorios (/etc/yum.repos.d) como rpm-sphere.repo.
Actualizamos (nos basta un simple # yum update y ya se recargan los repositorios) y lo instalamos directamente
# yum install cpulimit
Sin embargo surgen nuevas dudas a partir de aquí. Si nos fijamos en los comentarios de hckoroot, la forma más fácil de usar cpulimit es, en vez de identificar el comando a controlar por su PID, lo mejor es identificarlo por su nombre. Nos quedaría
cpulimit --path=/ruta/ejecutable --limit=N
lo que nos lleva a como copiamos:
- Si usamos cp en terminal, el comando es cp, claro
- Si usamos rsync, que a mi me gusta particulamente, el comando es rsync
El problema radica en que la mayor parte copiará con Nautilus, que lleva embebido los comandos, y no genera una nueva instancia para copiar, si no que todo lo que hagamos con Nautilus se hace dentro de la misma instancia. A eso se suma que el gran consumo del sistema al copiar en discos NTFS se produce no en la copia, si no en el propio manejo del NTFS a través de mount.ntfs. Por ejemplo este top copiando con Nautilus en un disco formateado NTFS:
Y si a ello le sumamos otras aplicaciones que consuman recursos, por ejemplo Chromium y aMule, llegamos al bloqueo del sistema
¿Podemos solucionarlo con cpulimit? Desde mi punto de vista no. Si el límite que le ponemos es sobrepasado, la aplicación deja de funcionar; si de corta mount.ntfs, probablemente perderemos el contenido que hayamos copiado en él, ya que no se guardarán las nuevas tablas, como ya me ha pasado a mi sin incluir cpulimit. Además, ¿cuál sería el límite? Como se puede ver en esa instancia, mount.ntfs estaba momentáneamente por encima de 50%; probablemente esté a veces por debajo y otras veces por arriba. Si llegamos hasta un 70%, ¿cuanto queda para lo demás?
Conclusión: una única recomendación para copiar en discos formateados en NTFS en Linux - paciencia y nunca hacer saltar el sistema. Mejor esperar. Un segundo apunte, que me aplico en estos momentos, copiar en lotes pequeños, como mucho 30-40GB, por que la paciencia tiene un límite y tendemos a ponernos nerviosos.
Si alguien quiere probar cpulimit en la copia sobre NTFS, que lo haga y nos diga que límite hay que poner. Yo prefiero aplicar la paciencia y no perder más material.
jueves, 19 de enero de 2012
NTFS, MKV y totem
He detectado un nuevo problema en el uso de discos externos. Coincide además con discos NTFS. La copia es la siguiente, de un disco NTFS a otro NTFS, con un ordenador con Fedora 16 64bits como "ejecutor" de la acción, y siendo los ficheros multimedia contenedores matroska de vídeo. La orden de copia se hace desde un nautilus como administrador llamado desde un terminal
$ su -
palabra
# nautilus
A lo largo de la larga copia aparece en el terminal un mensaje cada minuto diciendo que totem-video-thumbnailer era incapaz de leer la imagen, lo que contribuye al consumo de recursos (no grabé ninguna imagen por que el ordenador estaba muy "ocupado"). Para terminar, al intentar desmontar de forma gráfica, aparece este bloqueo.
Tuve que desmontar en terminal. Este error solo aparece en discos con ficheros matroska (MKV). Quizá totem sea una de las causas de este gran consumo de CPU.
$ su -
palabra
# nautilus
A lo largo de la larga copia aparece en el terminal un mensaje cada minuto diciendo que totem-video-thumbnailer era incapaz de leer la imagen, lo que contribuye al consumo de recursos (no grabé ninguna imagen por que el ordenador estaba muy "ocupado"). Para terminar, al intentar desmontar de forma gráfica, aparece este bloqueo.
Tuve que desmontar en terminal. Este error solo aparece en discos con ficheros matroska (MKV). Quizá totem sea una de las causas de este gran consumo de CPU.
miércoles, 18 de enero de 2012
Unidades externas NTFS. Lentitud y consumo de recursos
Hoy he intentado terminar con mis problemas de copias a unidades externas NTFS y he visto el verdadero problema - la lentitud (ver también aquí). He dado la orden de copia de 386 GB de material multimedia de una unidad conectada en un S-ATA interno formateado en NTFS a un disco externo también formateado en NTFS y conectado por un USB externo. El sistema no se bloquea completamente, simplemente copia muy lentamente y consume la mayor parte del sistema. El resultado han sido 9 horas de copia, a una velocidad de 12MB/s y con un sistema en el que no se podía hacer nada. No se podía llamar a ninguna aplicación gráfica y en terminal tardaban 10 minutos en ejecutarse ordenes tan simples como cd .. o ls. Lo mejor de todo es que he realizado la misma orden en un ordenador con Windows 7 y copia a la misma velocidad (12MB/s); eso si, el sistema está disponible para hacer otras cosas.
Soluciones:
- No usar discos NTFS, lo que es difícil si queremos mantener compatibilidad con otros ordenadores no Windows y con aparatos multimedia que solo entienden FAT y NTFS.
- Si hay que usarlos, copiar en un ordenador libre y con mucha paciencia. Además, si se dispone de él, usar un ordenador con Windows.
- Si se dispone de un solo ordenador, evitar el bloqueo de pantalla, ya que de lo contrario tendremos un ordenador con una pantalla en negro un tiempo muy largo y que no se sabe cuanto va a durar. Evitar mal carácter y nunca reiniciar por las malas, ya que no se desmontan bien las unidades y nos montamos un lío, perdemos ficheros y acabaremos reparando el ordenador en las fstab.
Soluciones:
- No usar discos NTFS, lo que es difícil si queremos mantener compatibilidad con otros ordenadores no Windows y con aparatos multimedia que solo entienden FAT y NTFS.
- Si hay que usarlos, copiar en un ordenador libre y con mucha paciencia. Además, si se dispone de él, usar un ordenador con Windows.
- Si se dispone de un solo ordenador, evitar el bloqueo de pantalla, ya que de lo contrario tendremos un ordenador con una pantalla en negro un tiempo muy largo y que no se sabe cuanto va a durar. Evitar mal carácter y nunca reiniciar por las malas, ya que no se desmontan bien las unidades y nos montamos un lío, perdemos ficheros y acabaremos reparando el ordenador en las fstab.
lunes, 19 de diciembre de 2011
Unidades USB. Uso de Hubs alimentados
La solución para el uso de los dispositivos externos pasa por dos acciones.
Primero, dar permiso a los dispositivos externos mediante ntfs-config, que hay que arrancar como administrador, en Fedora, por falta de gksu, se hace desde terminal
$ su -
(password)
# yum install ntfs-config
Para llamar a la aplicación tenemos que generar directorios -como administrador- que en las últimas actualizaciones de kernel ya no existen (véase aquí)
# mkdir /etc/hal
# mkdir /etc/hal/fdi
# mkdir /etc/hal/fdi/policy
y ya podemos llamar a ntfs-config -seguimos como administrador-
# ntfs-config
donde permitimos el uso de dispositivos externos.
Segundo, y no menos importante, por lo que me ha pasado a mi, poner los lápices USB en un puerto bien alimentado. La copia que tardó 26 minutos se hizo en 2 minutos y medio poniendo el mismo lápiz USB en un hub alimentado, lo que se denomina hub "self-powered", es decir autoalimentado. El intento anterior se hizo en un puerto USB situado en el monitor, que se une mediante un cable de 1m a otro hub sin alimentación. Esto nos indica que el monitor no debe alimentar ese puerto, y por lo tanto no es de extrañar que tardara tanto. Lo que me extraña es que acabara la copia o que se detecte a la unidad.
Queda una prueba por realizar, que es la copia en disco duro. No puedo negar que la temo, por que en los dos últimos intentos he perdido 600GB de material multimedia, pero tarde o temprano la tendré que hacer.
Primero, dar permiso a los dispositivos externos mediante ntfs-config, que hay que arrancar como administrador, en Fedora, por falta de gksu, se hace desde terminal
$ su -
(password)
# yum install ntfs-config
Para llamar a la aplicación tenemos que generar directorios -como administrador- que en las últimas actualizaciones de kernel ya no existen (véase aquí)
# mkdir /etc/hal
# mkdir /etc/hal/fdi
# mkdir /etc/hal/fdi/policy
y ya podemos llamar a ntfs-config -seguimos como administrador-
# ntfs-config
donde permitimos el uso de dispositivos externos.
Segundo, y no menos importante, por lo que me ha pasado a mi, poner los lápices USB en un puerto bien alimentado. La copia que tardó 26 minutos se hizo en 2 minutos y medio poniendo el mismo lápiz USB en un hub alimentado, lo que se denomina hub "self-powered", es decir autoalimentado. El intento anterior se hizo en un puerto USB situado en el monitor, que se une mediante un cable de 1m a otro hub sin alimentación. Esto nos indica que el monitor no debe alimentar ese puerto, y por lo tanto no es de extrañar que tardara tanto. Lo que me extraña es que acabara la copia o que se detecte a la unidad.
Queda una prueba por realizar, que es la copia en disco duro. No puedo negar que la temo, por que en los dos últimos intentos he perdido 600GB de material multimedia, pero tarde o temprano la tendré que hacer.
sábado, 17 de diciembre de 2011
Fedora 16. Copia en dispositivos externos NTFS
Una de los problemas que aun estoy teniendo en Fedora es la copia a dispositivos externos. Como es bien sabido, el permiso para copia en dispositivos externos tiene que ser autorizado. Eso me ha pasado en Ubuntu, y también aquí. El problema se resume hasta ahora mismo así:
1. Primer intento. Copia de un fichero de 2,2GB a una unidad USB Kingston DataTraveler 400 de 4GB. Después de hora y media de aburrimiento, lo desmonto y el resultado es que la unidad no tiene el índice de contenidos adecuado y el fichero de 2,2GB no aparece. Son "visibles", en teoría, 4 ficheros más pequeños que habían sido borrados.
2. Segundo intento. Reintento de copia en la misma unidad USB dejándole toda la noche; desmontado normal. Mismo resultado.Por lo tanto deduzco que me está pasando que la copia en los dispositivos externos no está permitido. En Ubuntu siempre lo he solucionado llamando a ntfs-config y permitiendo la copia a dispositivos externos formateados en NTFS con ntfs-3g. Instalo el paquete desde PackageKit (me sigue gustando más Synaptic).
La sorpresa surgió de que al llamar a la aplicación surge este aviso:
Es decir, a aquellos usuarios que nos sentimos cómodos en Linux, pero solamente por que nos hemos movido por Ubuntu, nos entra una pequeña "flojera" al ver que realmente aun no sabemos tanto. Damos por sentado que gksu está instalada "per se", y no es así. En su página Web se puede observar de que aunque se define como librería para uso gráfico de su y sudo, realmente está desarrollada por gente de Debian, y por ello no está instalada en distribuciones rpm. Más aun, ni siquiera está empaquetada por Fedora, así que no está disponible en los repositorios
Tenemos disponible beesu, pero según algunos comentarios en la red genera o puede generar problemas en el arranque de los ordenadores.
Yo lo he intentado solucionar de manera terminal a través de sudo
Sin embargo el resultado, hasta ahora, no es satisfactorio. He copiado el mismo fichero de 2,2GB a un dispositivo Kingston DT R500, teóricamente más rápido en escritura y, aunque sí se ha copiado y funciona en otros ordenadores y en la unidad WDTV, ha tardado más de 20 minutos a una velocidad media final de 1,4 MB/s, que es la décima parte de la velocidad con la que debería copiar este lápiz.
Próximos intentos:
- Ya he instalado, como se ve en la imagen superior, beesu, aunque cuando lo llamo sin su o sudo, no veo que funcione como gksu, que automáticamente daba la posibilidad de autentificarse como administrador y permitir el uso de la aplicación que lo necesitase (aunque en el fondo es también una quiebra en la seguridad). Por ahora no supone ninguna diferencia.
- Me queda por probar dispositivos externos en ext4, para saber si se debe a ser dispositivos externos o por estar formateados en NTFS, que en general, podrían ir más lentos (ver aquí).
- Si funciona más rápido en ext4, lo siguiente será probar discos duros externos en NTFS (no me atrevo desde el último intento con 600GB perdidos).
- Si los DD NTFS funcionan, entonces empezaré a usar diferentes puertos para los lápices.
Seguiremos con el asunto
1. Primer intento. Copia de un fichero de 2,2GB a una unidad USB Kingston DataTraveler 400 de 4GB. Después de hora y media de aburrimiento, lo desmonto y el resultado es que la unidad no tiene el índice de contenidos adecuado y el fichero de 2,2GB no aparece. Son "visibles", en teoría, 4 ficheros más pequeños que habían sido borrados.
2. Segundo intento. Reintento de copia en la misma unidad USB dejándole toda la noche; desmontado normal. Mismo resultado.Por lo tanto deduzco que me está pasando que la copia en los dispositivos externos no está permitido. En Ubuntu siempre lo he solucionado llamando a ntfs-config y permitiendo la copia a dispositivos externos formateados en NTFS con ntfs-3g. Instalo el paquete desde PackageKit (me sigue gustando más Synaptic).
La sorpresa surgió de que al llamar a la aplicación surge este aviso:
Es decir, a aquellos usuarios que nos sentimos cómodos en Linux, pero solamente por que nos hemos movido por Ubuntu, nos entra una pequeña "flojera" al ver que realmente aun no sabemos tanto. Damos por sentado que gksu está instalada "per se", y no es así. En su página Web se puede observar de que aunque se define como librería para uso gráfico de su y sudo, realmente está desarrollada por gente de Debian, y por ello no está instalada en distribuciones rpm. Más aun, ni siquiera está empaquetada por Fedora, así que no está disponible en los repositorios
Tenemos disponible beesu, pero según algunos comentarios en la red genera o puede generar problemas en el arranque de los ordenadores.
Yo lo he intentado solucionar de manera terminal a través de sudo
Sin embargo el resultado, hasta ahora, no es satisfactorio. He copiado el mismo fichero de 2,2GB a un dispositivo Kingston DT R500, teóricamente más rápido en escritura y, aunque sí se ha copiado y funciona en otros ordenadores y en la unidad WDTV, ha tardado más de 20 minutos a una velocidad media final de 1,4 MB/s, que es la décima parte de la velocidad con la que debería copiar este lápiz.
Próximos intentos:
- Ya he instalado, como se ve en la imagen superior, beesu, aunque cuando lo llamo sin su o sudo, no veo que funcione como gksu, que automáticamente daba la posibilidad de autentificarse como administrador y permitir el uso de la aplicación que lo necesitase (aunque en el fondo es también una quiebra en la seguridad). Por ahora no supone ninguna diferencia.
- Me queda por probar dispositivos externos en ext4, para saber si se debe a ser dispositivos externos o por estar formateados en NTFS, que en general, podrían ir más lentos (ver aquí).
- Si funciona más rápido en ext4, lo siguiente será probar discos duros externos en NTFS (no me atrevo desde el último intento con 600GB perdidos).
- Si los DD NTFS funcionan, entonces empezaré a usar diferentes puertos para los lápices.
Seguiremos con el asunto
martes, 29 de noviembre de 2011
Desmontado discos duros NTFS
Los últimos dos arranques de mi ordenador han sido un suplicio. Se queda en negro esperando algo ¿Qué será ese algo? Y así minutos y minutos. Dándole a muchas teclas, y no sé cual es la buena, se recibe una pantalla con esta respuesta:
Como se ve, la he capturado con una cámara. Aparte de unos errores de red que se deben a una confusión que tuve en la identificación de las dos tarjetas de red que tiene el ordenador al configurar la conexión en la instalación nueva de Ubuntu 11.10 -que se autocorrige- el problema estaba en que el sistema espera encontrar un disco externo Toshiba que, teóricamente, no fue bien desmontado. Sin embargo yo recuerdo haber desmontado correctamente el disco, así que asumo que el problema está en el espacio vacio en la etiqueta del disco -TOSHIBA EXT-, ya que los espacios vacíos generan errores en la ejecución de comandos en Linux. El problema es que en en el directorio /media quedaba siempre la presencia del dispositivo TOSHIBA EXT, por mucho que lo desmontemos
Lo primero que hice fue cambiarle la etiqueta al disco, para evitar el espacio vacío. Para ello usé palimpsest
Aun así el dispositivo TOSHIBA EXT aun existía en /media. Siguiendo la recomendación de hckorootx edité a nivel de administrador el fichero /etc/fstab, donde quedan registrados los dispositivos del ordenador
sudo gedit /etc/fstab
para eliminar las líneas seleccionadas (color naranja), donde se identifica el dispositivo TOSHIBA\40EXT. Es recomendable hacer una copia de seguridad inicial, por ejemplo guardar un fstab.bak por si borramos el dispositivo / (el raíz), en cuyo caso el ordenador no arrancaría. Sin embargo, si hemos guardado una copia de seguridad con un CD Live podríamos recuperar el sistema. El fichero guardado queda así
Al reiniciar, el arranque es normal. Sea cual sea la razón, recomendable eliminar los espacios en las etiquetas de nuestros discos esternos (y unidades USB en general).
Como se ve, la he capturado con una cámara. Aparte de unos errores de red que se deben a una confusión que tuve en la identificación de las dos tarjetas de red que tiene el ordenador al configurar la conexión en la instalación nueva de Ubuntu 11.10 -que se autocorrige- el problema estaba en que el sistema espera encontrar un disco externo Toshiba que, teóricamente, no fue bien desmontado. Sin embargo yo recuerdo haber desmontado correctamente el disco, así que asumo que el problema está en el espacio vacio en la etiqueta del disco -TOSHIBA EXT-, ya que los espacios vacíos generan errores en la ejecución de comandos en Linux. El problema es que en en el directorio /media quedaba siempre la presencia del dispositivo TOSHIBA EXT, por mucho que lo desmontemos
Lo primero que hice fue cambiarle la etiqueta al disco, para evitar el espacio vacío. Para ello usé palimpsest
Aun así el dispositivo TOSHIBA EXT aun existía en /media. Siguiendo la recomendación de hckorootx edité a nivel de administrador el fichero /etc/fstab, donde quedan registrados los dispositivos del ordenador
sudo gedit /etc/fstab
para eliminar las líneas seleccionadas (color naranja), donde se identifica el dispositivo TOSHIBA\40EXT. Es recomendable hacer una copia de seguridad inicial, por ejemplo guardar un fstab.bak por si borramos el dispositivo / (el raíz), en cuyo caso el ordenador no arrancaría. Sin embargo, si hemos guardado una copia de seguridad con un CD Live podríamos recuperar el sistema. El fichero guardado queda así
Al reiniciar, el arranque es normal. Sea cual sea la razón, recomendable eliminar los espacios en las etiquetas de nuestros discos esternos (y unidades USB en general).
lunes, 21 de noviembre de 2011
Ubuntu. Inconvenientes de una instalación en limpio
Como he dicho en la entrada anterior, he realizado una instalación sobre cero. Eso supone, en principio, no arrastrar "herencias negativas" de atrás, fundamentalmente por que la instalación de Ubuntu 11.10 supone también el salto a kernel 3.x y también, y mucho más importante, a Gnome 3.x. Sin embargo, tiene varios inconvenientes. Primero, aunque poco importante, supone tener que copiar todos los datos importantes, los discos virtuales de las máquinas virtuales (que redundancia), que en mi caso tienen un tamaño fijo para VirtualBox y variable para VMWare (en total 4 discos virtuales, unos 125GB), los directorios .amule, .jdownloader, .thunderbird (copia de seguridad de mi correo profesional) y las configuraciones de Firefox. En total han sido 1,1TB, 4 horas y algo de copieteo a una media de 75MB/s (dos Caviar Green del mismo lote conectados en SATA, uno sobre el otro).
Segundo, y mucho más importante, no podía abrir los dispositivos externos formateados en NTFS. Eso no me había pasado en las últimas versiones, en las que instalaba sobre un home completo. Instalé ntfs-config, pero no arrancaba. Y es la primera vez que me ha gustado el Centro de Software de Ubuntu, por que en vez de tener que buscar el error en la red debido a directorios no creados automáticamente, un amable ubuntero ya lo había puesto allí:
Así que si a alguno le pasa lo mismo, con buscar en el Centro de Software. No está tan mal, después de todo.
Segundo, y mucho más importante, no podía abrir los dispositivos externos formateados en NTFS. Eso no me había pasado en las últimas versiones, en las que instalaba sobre un home completo. Instalé ntfs-config, pero no arrancaba. Y es la primera vez que me ha gustado el Centro de Software de Ubuntu, por que en vez de tener que buscar el error en la red debido a directorios no creados automáticamente, un amable ubuntero ya lo había puesto allí:
Así que si a alguno le pasa lo mismo, con buscar en el Centro de Software. No está tan mal, después de todo.
viernes, 2 de septiembre de 2011
Vuelta de vacaciones. Destrucción completa de home
He vuelto de unas vacaciones en las que no he dado palo al agua. En un mes entero solo he mirado 4 veces el correo; en resumen, perfectas. Justo a la vuelta de vacaciones y, perdonen los lectores, antes de saludar, decidí arreglar un formateo erróneo de un disco en NTFS, similar al que había señalado aquí, y la fastidié definitivamente, y por eso he tardado "un poco" en poder escribir una entrada (y la vagancia, por que realmente puedo utilizar 6 ordenadores diferentes para meter una entrada).
La "historia del arte" fue así. Justo antes de vacaciones me compré 2 discos duros Western Digital Caviar Green de 2TB, para almacenar "copias de seguridad" de material multimedia. Aun sabiendo que gparted no formatea bien en NTFS, y que hay un bug reconocido (1, 2), le di una última oportunidad (y para no encender el ordenador de Windows) para formatearlos en NTFS. Por supuesto generó un disco con 4 trozos, el primero de 104GB, en teoría NTFS y 3 particiones más irreconocibles. Como no tenía más tiempo, me fui de vacaciones y así quedó todo. A la vuelta, lo primero que hice fue extraer el disco -el que yo pensaba que era ese disco- y lo formateé en un ordenador con Windows. Por desgracia yo pongo mis discos frontalmente y para poder extraerlos rápidamente
y en vez de sacar el superior, que era el mal formateado, saque el que era home. Los dos eran discos idénticos (WD Caviar Green de 2TB), y como quería encender rápidamente, me fui sin comprobar que disco había extraído. Además, al intentar formatearlo en disco, no era posible por que era una GPT Protective Partition, es decir, era una partición que Windows no puede leer -en este caso ext4- y que ha sido realizado por otro Sistema, pero yo asumí que se debía a la mala partición realizada, así que para destruirla utilicé en Windows disk part, siguiendo las instrucciones de aquí. En resumen, por si es necesario para alguien, hacemos Inicio - Ejecutar - cmd (para llegar al terminal de Windows) y ejecutamos disk part; para identificar el disco tecleamos list disk, luego select disk x (siendo x el número que identifica al disco que nos interesa formatear) y ejecutamos clean, que limpia todas las tablas de partición, sea la que sea y queda sin asignar y listo para ser formateado. Y eso hice.
Al volver al ordenador con ubuntu, simplemente no arrancó, ya que le faltaba home. Cosas de estas le pasan a cualquiera. He intentado recuperar la partición mediante testdisk, pero despues de quick search, buscando particiones debajo de la NTFS, el resultado fue este
lo que es lógico; no puede detectar las tablas de partición anteriores por que clean en disk part las ha borrado. Después intenté una búsqueda más profunda -deeper- pero no ha podido localizar nada que no fuera la partición NTFS
Aun así le pedí el listado de los ficheros, pero claro, son solo los de la partición detectada, la de NTFS, o sea, ninguno
Podría teóricamente (al haber aplicado en disk part clean solo borra las tablas de partición; si hubiera aplicado clean all hubiera borrado y sobreescrito TODO) recuperar los ficheros mediante foremost, pero serían más de 500.000, y al faltar las tablas de partición se recuperarían sin identificación y habría que ir identificando uno a uno. Además, tenía una copia de seguridad de todos mis trabajos y música (550GB, más de 470000 ficheros), así que lo perdido es solo 1,2TB de vídeos, algunos irremplazables pero, ¡qué se le va a hacer! A ver si aprendo algún día, aunque lo dudo.
En la siguiente entrada hablaré de nuevo de la tortura provocada en la instalación de esta versión 11.04, altamente inestable.
La "historia del arte" fue así. Justo antes de vacaciones me compré 2 discos duros Western Digital Caviar Green de 2TB, para almacenar "copias de seguridad" de material multimedia. Aun sabiendo que gparted no formatea bien en NTFS, y que hay un bug reconocido (1, 2), le di una última oportunidad (y para no encender el ordenador de Windows) para formatearlos en NTFS. Por supuesto generó un disco con 4 trozos, el primero de 104GB, en teoría NTFS y 3 particiones más irreconocibles. Como no tenía más tiempo, me fui de vacaciones y así quedó todo. A la vuelta, lo primero que hice fue extraer el disco -el que yo pensaba que era ese disco- y lo formateé en un ordenador con Windows. Por desgracia yo pongo mis discos frontalmente y para poder extraerlos rápidamente
y en vez de sacar el superior, que era el mal formateado, saque el que era home. Los dos eran discos idénticos (WD Caviar Green de 2TB), y como quería encender rápidamente, me fui sin comprobar que disco había extraído. Además, al intentar formatearlo en disco, no era posible por que era una GPT Protective Partition, es decir, era una partición que Windows no puede leer -en este caso ext4- y que ha sido realizado por otro Sistema, pero yo asumí que se debía a la mala partición realizada, así que para destruirla utilicé en Windows disk part, siguiendo las instrucciones de aquí. En resumen, por si es necesario para alguien, hacemos Inicio - Ejecutar - cmd (para llegar al terminal de Windows) y ejecutamos disk part; para identificar el disco tecleamos list disk, luego select disk x (siendo x el número que identifica al disco que nos interesa formatear) y ejecutamos clean, que limpia todas las tablas de partición, sea la que sea y queda sin asignar y listo para ser formateado. Y eso hice.
Al volver al ordenador con ubuntu, simplemente no arrancó, ya que le faltaba home. Cosas de estas le pasan a cualquiera. He intentado recuperar la partición mediante testdisk, pero despues de quick search, buscando particiones debajo de la NTFS, el resultado fue este
lo que es lógico; no puede detectar las tablas de partición anteriores por que clean en disk part las ha borrado. Después intenté una búsqueda más profunda -deeper- pero no ha podido localizar nada que no fuera la partición NTFS
testdisk
Aun así le pedí el listado de los ficheros, pero claro, son solo los de la partición detectada, la de NTFS, o sea, ninguno
Podría teóricamente (al haber aplicado en disk part clean solo borra las tablas de partición; si hubiera aplicado clean all hubiera borrado y sobreescrito TODO) recuperar los ficheros mediante foremost, pero serían más de 500.000, y al faltar las tablas de partición se recuperarían sin identificación y habría que ir identificando uno a uno. Además, tenía una copia de seguridad de todos mis trabajos y música (550GB, más de 470000 ficheros), así que lo perdido es solo 1,2TB de vídeos, algunos irremplazables pero, ¡qué se le va a hacer! A ver si aprendo algún día, aunque lo dudo.
En la siguiente entrada hablaré de nuevo de la tortura provocada en la instalación de esta versión 11.04, altamente inestable.
miércoles, 20 de julio de 2011
Ubuntu 11.04 y el formateo en NTFS de los discos duros
He tenido un nuevo "poltergeist" en el formateo en NTFS de un disco duro. En este caso he "intentado" formatear un Western Digital Caviar Green de 2TB en una caja Conceptronics para discos SATA. El disco es de la misma marca y modelo que utilizo en mi ordenador principal como home. El disco que hace de home fue formateado en la instalación de 11.04 en ext4 sin ningún problema. Modelos similares WD Caviar Green de 1TB y 1,5TB formateados a NTFS los uso habitualmente en cajas Conceptronics idénticas a la del disco en cuestión para almacenar material y poder disponer de él en Linux, en Windows y en WD TV Player. Para formatearlo, he seguido mi rutina habitual. Monto el disco ("OEM", tomado de una caja que trae un montón iguales y sin formato) en una caja Conceptronics, lo detecto con gparted y configuro un formateo en NTFS; lo vuelvo a montar con Palimpsest y empiezo la copia de los ficheros; sorprendentemente (no tanto, por que es la segunda vez que me pasa), la velocidad de copia prevista es de 200 a 300kb por segundo, con lo que nos amenaza con miles de horas de copia. Visto el resultado tras varios minutos sin aumento de la velocidad, lo desmonto e intento formatear desde Palimpsest, aun suponiendo que el efecto será el mismo, ya que recurrirá a los mismos paquetes que gparted. Sorprendentemente, se niega a formatear ya que dice que el "daemon" está capturado. Directamente reinicio el equipo y vuelvo a intentarlo con palimpsest sin pasar por gparted, pero me dice lo mismo (¿qué error es este?). Por tanto, sigo las indicaciones de hckorootx en los comentarios de la entrada anterior sobre discos duros y de la entrada que realizó a partir de eso en nosinmiubuntu, y en terminal defino el disco con fdisk y luego lo formateo con mkntfs. Mejor dicho, lo intento, por que el equipo se bloquea completamente sin respuesta a atajos de teclado de reinicio gráfico (ni el moderno en Ubuntu AltGr+ImpPant+K ni el tradicional Ctrl+Alt+Backspace) ni tampoco a los atajos AltGr+ImpPant+REISUO. Otro factor que me sorprendió, y que debemos tener en cuenta sobre un posible bug, fue que las características del disco varían según el formateo con gparted o fdisk. Por desgracia, cuando hacemos estas cosas no nos paramos a guardar los resultados. Como lo haré próximamente, tengo que grabar las lecturas de los discos. Por supuesto, podemos culpar al disco o a la caja, pero le hice un formateo rápido en Windows XP (mismo disco, misma caja) y lo puse a copiar en Ubuntu y ya lo hace a una velocidad razonable (18-19MB/s). Esto nunca me había pasado antes, y nunca he tenido que formatear discos en NTFS en Windows desde que uso Ubuntu 7.10. Algun bug tiene que estar ahí dentro, pero no he encontrado nada parecido en la red y no sé como definir lo que está pasando.
lunes, 11 de julio de 2011
Formateo de discos duros
Un compañero me ha pasado un disco duro para que le copiara unos ficheros (¿donde están los diskettes de antes? con 600 arreglábamos el asunto). Al ver el disco me doy cuenta de que esta en formato FAT32, es decir, inutilizabe (no admite ficheros de más de 4GB).
A través de gparted se lo pasé mediante formateo rápido a NTFS, pero resulta que el disco no funcionaba bien (nautilus calculaba 900 horas para copiar el directorio). La única solución fue un formateo completo, y así funcionó razonablemente (900GB en 9 horas).
Sí iscario, lo hice con un ordenador con Windows, ya que no sé como decirle a gparted que haga un formateo completo (unas cuantas horas que tardó el tal Windows) y no sabía que tamaño de cluster darle al disco; mkfs.ntfs asigna por defecto 4096, que en los Western Digital está bien, pero en este disco no estaba seguro, así que le dejé a Windows XP que decidiera por si mismo. Además, como en casa tengo todavía un ordenador con Windows XP, era la forma más fácil y rápida. De todas maneras, tengo usar más el terminal.
A través de gparted se lo pasé mediante formateo rápido a NTFS, pero resulta que el disco no funcionaba bien (nautilus calculaba 900 horas para copiar el directorio). La única solución fue un formateo completo, y así funcionó razonablemente (900GB en 9 horas).
Sí iscario, lo hice con un ordenador con Windows, ya que no sé como decirle a gparted que haga un formateo completo (unas cuantas horas que tardó el tal Windows) y no sabía que tamaño de cluster darle al disco; mkfs.ntfs asigna por defecto 4096, que en los Western Digital está bien, pero en este disco no estaba seguro, así que le dejé a Windows XP que decidiera por si mismo. Además, como en casa tengo todavía un ordenador con Windows XP, era la forma más fácil y rápida. De todas maneras, tengo usar más el terminal.
jueves, 10 de junio de 2010
Formateo de unidades NTFS
He tenido un error en un disco que ya me había pronosticado la utilidad de disco de Ubuntu, diciendome que había un numero de sectores recolocados. Desgraciadamente no le había hecho caso y se ha perdido un fichero que no he podido sacar de la unidad. Es un disco duro externo WD Elements de 1TB. Debido a que lo tenía que mantener en NTFS, nunca lo había formateado y estaba como cuando vino de fábrica. Ahora he decidido formatearlo de manera completa, no en formateo rápido. El problema es que siempre había formateado a través de una utilidad gráfica (gparted) y el resultado es un formateo rápido. Lo he intentado con partition manager y ha pasado lo mismo. Bien sea por que no sé o por que de manera gráfica no se puede llegar a configurar un formateo profundo, me he fijado en la orden que envía gparted y luego he llamado al terminal
mkntfs -Q -v -L "ETIQUETA" /dev/sdc1 (en este caso el disco es sdc)
Analizando las opciones -Q es la opción Quick, que evita escribir la unidad en ceros y chequear la presencia de sectores erróneos. Inmediatamente he dado la orden sin -Q para que revise los sectores
mkntfs -v -L "ETIQUETA" /dev/sdc1
Y todo va bien, supongo, por que no me había dado cuenta que escribe con ceros un disco DE ¡¡1TB!! y lleva 7 horas y aun está en el 74%. Esperemos que mañana este terminado y correctamente formateado. Comentaremos después sobre ello. Por desgracia el formateo a bajo nivel empieza dejando los discos limpios, así que hay que esperar. Sí, ya se que no es lo que originalmente se llamaba formateo a bajo nivel, pero nos entendemos.
Quizá alguno se estará haciendo la pregunta del millón, ¿para qué se quiere una unidad en NTFS si soy usuario de Linux? La razón se llama WD TV HD Media Player, que no tiene a bien leer ext4 o cualquier otro sistema de archivos que no sea FAT32 o NTFS, así que no tengo solución y mantengo 8 discos en NTFS, y creciendo en número.
mkntfs -Q -v -L "ETIQUETA" /dev/sdc1 (en este caso el disco es sdc)
Analizando las opciones -Q es la opción Quick, que evita escribir la unidad en ceros y chequear la presencia de sectores erróneos. Inmediatamente he dado la orden sin -Q para que revise los sectores
mkntfs -v -L "ETIQUETA" /dev/sdc1
Y todo va bien, supongo, por que no me había dado cuenta que escribe con ceros un disco DE ¡¡1TB!! y lleva 7 horas y aun está en el 74%. Esperemos que mañana este terminado y correctamente formateado. Comentaremos después sobre ello. Por desgracia el formateo a bajo nivel empieza dejando los discos limpios, así que hay que esperar. Sí, ya se que no es lo que originalmente se llamaba formateo a bajo nivel, pero nos entendemos.
Quizá alguno se estará haciendo la pregunta del millón, ¿para qué se quiere una unidad en NTFS si soy usuario de Linux? La razón se llama WD TV HD Media Player, que no tiene a bien leer ext4 o cualquier otro sistema de archivos que no sea FAT32 o NTFS, así que no tengo solución y mantengo 8 discos en NTFS, y creciendo en número.
miércoles, 9 de diciembre de 2009
Ubuntu 9.10 y NTFS
Curiosamente este fin de semana se ha actualizado alguna librería sobre el manejo de unidades y discos; lo había leído de pasada al actualizar el Aspire One el fin de semana. al llegar a casa actualicé el ordenador de sobre mesa (sin fijarme en absoluto en lo que entraba) y a partir de ese momento dejó de montar los discos externos al conectarlos por USB. He tenido que instalar ntfs-config y activar soporte de escritura de dispositivos externos para que se activaran automáticamente al conectarlos. Eso me pasa por no saber lo suficiente. Tendré que mirar algo más para ver como manejar los dispositivos en terminal.
Suscribirse a:
Entradas (Atom)