En un post de muylinux.com, pude ver a dos o tres usuarios peleando sobre la fiabilidad de ext4 o ntfs, no se que tiene que ver con el post en si que trataba de gnome3 pero bueno, aclaro algunos puntos para los que quieran saber mas, sobre como cuidar sus datos sin tener un RAID o un disco SSD.
Tanto Ext3-4 como NTFS son FS (filesystem) con journal de metadatos.
Los dos tiene caracteristicas similares, solo que segun lei en foros de gente que sabe mas que yo, el journal de Ext4 es bastante mas superior al de NTFS y digo esto porque un comentarista llamado xbit decia como vio perdida de datos en cortes de energia en una empresa donde estuvo trabajando, donde usaban Ext4 y no asi usando NTFS y menos aun el nuevo FS de Microsoft llamado ReFS un FS copy-on-write como es ZFS o Btrfs (pero solo esta para Windows Server 2012 asi que no se que carajos habla, dudo que un workstation use Windows Server).
Ahora bien, para el usuario de a pie, el que no usa RAID ni UPS (vamos que no son caras), no interesan las soluciones de RAID, asi que voy a dar algunos consejos para los que sufren cortes de luz o bien tienen sistemas colgados y al reiniciar han perdido datos.
Primero que nada, voy a aclarar que todo lo que pongo aca esta en la documentacion de Ext4, y dejaré el link de la misma.
Existen 3 formas de montaje para Ext4, que son: ordered, journal, writeback
A grades razgos, estas son:
ordered:
Todos los datos están forzados directamente al sistema de archivos antes de que sus metadatos sea enviado al journal
writeback:
El ordenamiento de datos no se conserva, los datos pueden ser escritos en el sistema de archivos principal despues de que los metadatos sean enviados al journal
journal:
Todos los datos son enviados al journal antes de que sean escritos en el sistema de archivos. Activando esto se desactiva "delayed allocation"
Brevemente, a primera vista vemos que journal desactiva los 5 segundos de retardo de Ext4 al escribir (esos 5 segundos que vuelven tan veloz a Ext4), lo cual, claro esta, sacrifica rendimiento en pro de fiabilidad.
Yo hice un test con mi notebook, un disco Samsung Spin Point SATA II 500GB 5400RPM ACHI Intel, kernel 3.2.63 PREEMPT con el comando DD y quiero que vean el resultado entre writeback (sin proteccion) a journal (proteccion total):
data=writeback (no protection)
dd if=/dev/zero of=ddfile bs=8k count=2000000 && sync
2000000+0 records in
2000000+0 records out
16384000000 bytes (16 GB) copied, 210,233 s, 77,9 MB/s
data=journal (max protection)
dd if=/dev/zero of=ddfile bs=8k count=2000000 && sync
2000000+0 records in
2000000+0 records out
16384000000 bytes (16 GB) copied, 464,203 s, 35,3 MB/s
Se aprecia claramente, como la opcion journal no solo reduce de 77MB/s la transferencia a 35.3 (la transferencia que me da Windows 7 x64) sino que de 210 segundos pasamos a 464, lo que se traduce en realidad a 3.55 minutos a 7.73 minutos, una enorme diferencia.
Cabe aclarar que el test fue realizado con mi querido script de high_io para que no se me freezara el sistema, quizas si lo desactivo tendria mejores resultados, pero al costo de un congelamiento del sistema, y que lo hice, porque cuando creaba un disco estatico en virtualbox, 8GB, el sistema se quedaba estupido hasta terminar, para los que les pase lo mismo les dejo el link
Ahora bien, yo tambien he sufrido perdida de datos en Ext3 usando Ubuntu 8.04, como comenta el usuario xbit en muylinux, pero luego me di cuenta de que era por el kernel de Ubuntu, no por el FS, dado que al cambiar de distro, haciendo el mismo test (apagon en seco 5 veces) no habia perdido datos, pero con Ubuntu al tercero ya no tenia sistema.
Mi consejo, para los sysadmin criticones como xbit... y problematicos, es que LEAN, porque eso es ser un MAL sysadmin. A que voy con esto?. Si vos administras una empresa, donde las maquinas tienen datos vitales sin backup, como ser un estudio contable pero no hacen backup, es obligado poner data=journal a los discos, sino el error ES TUYO, no de Ext4.
Por si no lo notaron, cuando colocan journal a Ext4 tienen el mismo rendimiento que en NTFS... que es sincronico (no data delayed), me explico?, o sea, se puede tener sincronia e incluso journal de datos, cosa que NTFS no tiene simplemente editando fstab.
Porque digo esto?, facil, ReFS que es el equivalente a ZFS, solo esta disponible en Windows Server 2012, no asi en Windows 8.1, con lo cual, de que le sirve a los usuarios de Windows la tecnologia nueva si no pueden usarla?...
Asi que el que crea/piense que su Windows 8.1 es menos propenso a fallos ante cortes de luz por su NTFS, lo invito a que prueba un Linux con data=journal en fstab y compare par a par, a ver cual pierde primero.
Tambien existe otro parametro, que es commit=nrsec el cual determina la cantidad de segundos que espera el sistema antes de hacer una escritura al disco de todo lo que no se ha volcado (fsync).
Con lo cual podemos bajar o subir los segundos de 5 a 1, 0 es default, asi que no lo usen.
Para un usuario de a pie, conviene usar en / data=journal para si en caso de cortes de luz repetidos (Argentina en verano sin UPS) al menos no perder el sistema entero y /home con ordered que es el que viene por defecto, si no les interesa perder datos, writeback o mas bien ganar velocidad.
Si quieren no perder datos, usen journal en las dos particiones, no asi en /boot y ademas de eso recomiendo bajar el commit a 1.
Piensen los que critican, que estas cosas fueron pensadas incluso para alargar la vida util de los discos, y me refiero a los 5 segundos de volcado o a que sea asincronico, por algo en una epoca se decia que Windows mataba los discos de las notebook, ademas de porque reducia la velocidad de giro de los mismos y con discos viejos esto era un riesgo.
Si usan Btrfs no tienen que preocuparse por nada de esto dado que es un sistema de archivos copy on write mucho mas consistente, ya bastante rendimiento van a perder usandolo, porque claro nada es gratis, es mucho mas lento que Ext4, y en cuanto a XFS, solo tiene log, no journal, pero se que se han hecho cambios recientes.
Ahora, a los hechos, para un usuario COMUN, usar journal en las particiones / y /home, no supone un cambio al uso diario, es decir, firefox, chrome, etc, no se nota en lo mas minimo a menos que copien grandes archivos, porque se nota solo al crearlos no al leerlos y realmente, para los que no usen notebook o no tengan UPS, es una forma de preservar sus cosas, yo personalmente lo recomiendo incluso para los que bajan torrent, porque la velocidad de creado es realmente baja para los discos modernos, asi que si quieren un sistema mas seguro en cuanto a datos, usen journal, ahora, no se quejen cuando crean un archivo de 16GB o bien copian desde otro disco ok?.
Por ultimo, si poseen una particion montada usando ntfs-3g, recomiendo usar la opcion compression, la cual comprime los datos al copiarlos como hace Windows (algo que Brtfs ya trae, compresion y defragmentacion on the fly) y realmente no solo reduce espacio sino que por ejemplo al leer 1000 mp3 de un NTFS, se leen mucho mas rapido y realmente no supone un sacrificio para el CPU, creanme, no al menos con el kernel 3.2.63.
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
Tanto Ext3-4 como NTFS son FS (filesystem) con journal de metadatos.
Los dos tiene caracteristicas similares, solo que segun lei en foros de gente que sabe mas que yo, el journal de Ext4 es bastante mas superior al de NTFS y digo esto porque un comentarista llamado xbit decia como vio perdida de datos en cortes de energia en una empresa donde estuvo trabajando, donde usaban Ext4 y no asi usando NTFS y menos aun el nuevo FS de Microsoft llamado ReFS un FS copy-on-write como es ZFS o Btrfs (pero solo esta para Windows Server 2012 asi que no se que carajos habla, dudo que un workstation use Windows Server).
Ahora bien, para el usuario de a pie, el que no usa RAID ni UPS (vamos que no son caras), no interesan las soluciones de RAID, asi que voy a dar algunos consejos para los que sufren cortes de luz o bien tienen sistemas colgados y al reiniciar han perdido datos.
Primero que nada, voy a aclarar que todo lo que pongo aca esta en la documentacion de Ext4, y dejaré el link de la misma.
Existen 3 formas de montaje para Ext4, que son: ordered, journal, writeback
A grades razgos, estas son:
ordered:
Todos los datos están forzados directamente al sistema de archivos antes de que sus metadatos sea enviado al journal
writeback:
El ordenamiento de datos no se conserva, los datos pueden ser escritos en el sistema de archivos principal despues de que los metadatos sean enviados al journal
journal:
Todos los datos son enviados al journal antes de que sean escritos en el sistema de archivos. Activando esto se desactiva "delayed allocation"
Brevemente, a primera vista vemos que journal desactiva los 5 segundos de retardo de Ext4 al escribir (esos 5 segundos que vuelven tan veloz a Ext4), lo cual, claro esta, sacrifica rendimiento en pro de fiabilidad.
Yo hice un test con mi notebook, un disco Samsung Spin Point SATA II 500GB 5400RPM ACHI Intel, kernel 3.2.63 PREEMPT con el comando DD y quiero que vean el resultado entre writeback (sin proteccion) a journal (proteccion total):
data=writeback (no protection)
dd if=/dev/zero of=ddfile bs=8k count=2000000 && sync
2000000+0 records in
2000000+0 records out
16384000000 bytes (16 GB) copied, 210,233 s, 77,9 MB/s
data=journal (max protection)
dd if=/dev/zero of=ddfile bs=8k count=2000000 && sync
2000000+0 records in
2000000+0 records out
16384000000 bytes (16 GB) copied, 464,203 s, 35,3 MB/s
Se aprecia claramente, como la opcion journal no solo reduce de 77MB/s la transferencia a 35.3 (la transferencia que me da Windows 7 x64) sino que de 210 segundos pasamos a 464, lo que se traduce en realidad a 3.55 minutos a 7.73 minutos, una enorme diferencia.
Cabe aclarar que el test fue realizado con mi querido script de high_io para que no se me freezara el sistema, quizas si lo desactivo tendria mejores resultados, pero al costo de un congelamiento del sistema, y que lo hice, porque cuando creaba un disco estatico en virtualbox, 8GB, el sistema se quedaba estupido hasta terminar, para los que les pase lo mismo les dejo el link
Ahora bien, yo tambien he sufrido perdida de datos en Ext3 usando Ubuntu 8.04, como comenta el usuario xbit en muylinux, pero luego me di cuenta de que era por el kernel de Ubuntu, no por el FS, dado que al cambiar de distro, haciendo el mismo test (apagon en seco 5 veces) no habia perdido datos, pero con Ubuntu al tercero ya no tenia sistema.
Mi consejo, para los sysadmin criticones como xbit... y problematicos, es que LEAN, porque eso es ser un MAL sysadmin. A que voy con esto?. Si vos administras una empresa, donde las maquinas tienen datos vitales sin backup, como ser un estudio contable pero no hacen backup, es obligado poner data=journal a los discos, sino el error ES TUYO, no de Ext4.
Por si no lo notaron, cuando colocan journal a Ext4 tienen el mismo rendimiento que en NTFS... que es sincronico (no data delayed), me explico?, o sea, se puede tener sincronia e incluso journal de datos, cosa que NTFS no tiene simplemente editando fstab.
Porque digo esto?, facil, ReFS que es el equivalente a ZFS, solo esta disponible en Windows Server 2012, no asi en Windows 8.1, con lo cual, de que le sirve a los usuarios de Windows la tecnologia nueva si no pueden usarla?...
Asi que el que crea/piense que su Windows 8.1 es menos propenso a fallos ante cortes de luz por su NTFS, lo invito a que prueba un Linux con data=journal en fstab y compare par a par, a ver cual pierde primero.
Tambien existe otro parametro, que es commit=nrsec el cual determina la cantidad de segundos que espera el sistema antes de hacer una escritura al disco de todo lo que no se ha volcado (fsync).
Con lo cual podemos bajar o subir los segundos de 5 a 1, 0 es default, asi que no lo usen.
Para un usuario de a pie, conviene usar en / data=journal para si en caso de cortes de luz repetidos (Argentina en verano sin UPS) al menos no perder el sistema entero y /home con ordered que es el que viene por defecto, si no les interesa perder datos, writeback o mas bien ganar velocidad.
Si quieren no perder datos, usen journal en las dos particiones, no asi en /boot y ademas de eso recomiendo bajar el commit a 1.
Piensen los que critican, que estas cosas fueron pensadas incluso para alargar la vida util de los discos, y me refiero a los 5 segundos de volcado o a que sea asincronico, por algo en una epoca se decia que Windows mataba los discos de las notebook, ademas de porque reducia la velocidad de giro de los mismos y con discos viejos esto era un riesgo.
Si usan Btrfs no tienen que preocuparse por nada de esto dado que es un sistema de archivos copy on write mucho mas consistente, ya bastante rendimiento van a perder usandolo, porque claro nada es gratis, es mucho mas lento que Ext4, y en cuanto a XFS, solo tiene log, no journal, pero se que se han hecho cambios recientes.
Ahora, a los hechos, para un usuario COMUN, usar journal en las particiones / y /home, no supone un cambio al uso diario, es decir, firefox, chrome, etc, no se nota en lo mas minimo a menos que copien grandes archivos, porque se nota solo al crearlos no al leerlos y realmente, para los que no usen notebook o no tengan UPS, es una forma de preservar sus cosas, yo personalmente lo recomiendo incluso para los que bajan torrent, porque la velocidad de creado es realmente baja para los discos modernos, asi que si quieren un sistema mas seguro en cuanto a datos, usen journal, ahora, no se quejen cuando crean un archivo de 16GB o bien copian desde otro disco ok?.
Por ultimo, si poseen una particion montada usando ntfs-3g, recomiendo usar la opcion compression, la cual comprime los datos al copiarlos como hace Windows (algo que Brtfs ya trae, compresion y defragmentacion on the fly) y realmente no solo reduce espacio sino que por ejemplo al leer 1000 mp3 de un NTFS, se leen mucho mas rapido y realmente no supone un sacrificio para el CPU, creanme, no al menos con el kernel 3.2.63.
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
No hay comentarios:
Publicar un comentario
Dejá tu comentario