Mailinglist Archive: opensuse-es (1882 mails)

< Previous Next >
Re: [opensuse-es] Modulo ntfs-3g en dispositivo usb
  • From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
  • Date: Fri, 5 Oct 2007 21:31:17 +0200 (CEST)
  • Message-id: <alpine.LSU.0.9999.0710052117090.7514@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


El 2007-10-05 a las 17:20 +0200, Camaleón escribió:

El 5/10/07, agr.suzdal escribió:

Una de las grandes diferencias es el journal de transacciones.
Diria que fat no tiene, y no he estudiado su estructura, pero lo que si
te puedo decir es que si escribes en fat, cuando termina (con o sin
cache), el sistema de ficheros no escribe nada más, ni recuerda que has
echo ni que ha leido ni escrito ni si hay algo pendiente.

Fat no tiene log.

Yo sí me estudié la estructura del fat, en su día me la conocí muy bien. Una de las diferencias con ntfs es que el FAT está documentado completamente por Microsoft: lo sé, me compré la guía de referencia del programador editado por ellos. Por tanto, vfat en linux es muy estable, más que en windows (porque en msdos/windows los programas pueden escribir a disco fat por su cuenta saltandose el sistema, en linux no).


Correcto, pero el fat también es vulnerable a las corrupciones del
sistema de ficheros, debido a un corte de energía, por ejemplo. El
usuario debe saberlo y actuar en consecuencia (mediante la extracción
segura del dispositivo usb o realizando un mantenimiento periódico de
la estructura del disco para verificar errores).

El problema es que "no me creo" que por desconectar un disco usb en
caliente sin haber activado la extracción segura se haya producido una
corrupción del volumen... más aún si la extracción del disco "a lo
bruto" se ha realizado sólo una vez :-/

El fat es menos vulnerable a la extracción en caliente, porque no mantiene log ni estructuras en memoria, /en windows/. Si el windows ha parado de escribir a disco, es casi siempre seguro extraerlo. En cambio, en Linux, la escritura a disco puede estar retrasada varios segundos. Por ello tenemos la opción de montaje "sync", que han estado jugando con ella de versión a versión.

Pero en windows con ntfs, la escritura puede también estar diferida, y hay un log de transacciones que lo demuestra. El ntfs-3g advierte que es el windows el que cerró mal el disco, según demuestra el que el logfile contenga datos.

Lo que creo es que el driver ntfs-g3 "no sabe" realmente cómo está el
volumen ntfs y recomienda un chequeo, nada más, pero desconoce si hay
algún error real o no. Esa es mi queja :-P.

Pero eso es igual con reiserfs o ext3: el driver se niega a montar, y te recomienda chequearlo. Pruébalo, es así.

Lo que ocurre es que hay un script de arranque que hace esa comprobación durante el arranque de todas las particiones que están listadas en el fstab: y es el chequeador quien lee el log, y decide si todo está bien o hay que corregir alguna cosa. No es el comando "mount" quien hace esa comprobación.


La cosa es que ntfs-3g al estar por ingenieria inversa, no contempla al
100% todas las posibilidades y por eso, en caso de error, pues deja al
usuario el control del tema, pues no todo se puede recuperar de forma
automática. La cosa es, y esto lo puedes comprovar "a mano", es en
windows crea un fichero corrupto y veras las burradas que hace windows,
ya que el te recupera los datos a su antojo, y no siempre hace lo
correcto, ya que muchas veces en casos criticos rompe más de lo que arregla.

Una de las pocas cosas que no me han causado problemas en los sistemas
windows son los discos duros. Ni en las versiones antiguas (95-98 con
fat32) ni en las más modernas (2000-xp con ntfs) he tenido problemas
de corrupción del sistema de archivos por culpa de apagones "a lo
bruto" o de otra índole... al menos en ese aspecto, ojo, problemas de
otro tipo sí he tenido.

Problemas no... el windows comprueba el disco y corrige los errores - casi siempre. Yo a veces he perdido algún fichero que estaba escribiendo en ese momento.


Y en sistemas ntfs (que deberían ser más robustos que los fat32) sí he
visto sistemas de archivos destrozados por culpa de no llevar un
mantenimiento de los discos duros ni de tener los equipos con unidades
sai. En esas circunstancias (sistema de archivos destrozado) los
equipos ni siquiera podían arrancar ;-).

Claro.

Porque se mantienen estructuras del disco en memoria para mayor rapidez. Con fat te puede pasar casi igual (en windows) si activas la caché de escritura.

- -- Saludos
       Carlos E.R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFHBpEGtTMYHG2NR9URAisZAJ4+JCgnerbKNqy+WQ5o2Ck5JiqDhACdFcSy
3pzqb83Uk4W56621P20aXfc=
=6lFr
-----END PGP SIGNATURE-----
< Previous Next >