-----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-----