La semana pasada fue una semana poco movida aquí en CTIO. Los Ploneros, provenientes de Viña del Mar, luchaban contra las fuerzas del sueño para encontrar algún trabajo y sentirse útiles. Sin embargo, en una de las conversaciones culturales y tecnológicas apareció el tema de la Fibra Óptica.
Tras la larga conversación, uno de nuestros compañeros del departamento de informatica y seguridad (CISS), nos invitó a recorrer las instalaciones TI de la empresa. En una primera instancia nos describió los procedimientos de se maneja la fibra óptica, desde cuales son los proovedores y como se construía una de estas y los multiples procesos hasta llegar a ser un medio físico tan poderoso.
Uno de estos procesos es la de preparar la fibra y colocarle los conectores correspondiente al tipo de éstas. Para esto necesita en total 3 maletas con diferentes herramientas: crimpeadoras, pegamentos, cortadoras, lijas, etc.
¿Se pueden imaginar que existen instrumentos para ver un pelo de fibra microscopicamente para verificar que no tenga impurezas en su nucleo?
Luego de finalizar el tour por la capa física, fuimos a recorrer las salas de computadores donde están alojados todos los equipos de redes tales como: switches, routers, centrales telefónicas y los del tipo almacenamiento que son servidores. Aparte de la seguridad para poder entrar a dicha sala, me sorprendió todos los equipos que manejan la fibra óptica y lo grueso que pueden llegar a ser los cables, la cantidad de cables cat5 en los switches y routers Cisco era realmente sorprendete (sólo hay que ver las fotos para saber que alguien tuvo que darse la lata de ordenar todo de una manera minusiosa). Finalmente llegamos a la parte donde se encontraban los dispositivos de almacenamiento de datos, servidores de varios tipos (hasta servidores Apple) formaban el ejercito de discos duros que almacenan millones de bytes en información relacionadas con los observatorios.
Ayer leyendo en la red me encontré con una ‘choreza’. Se trata de GodMode, una opción que quizás a muchos les parecerá interesante.
¿Cómo obtener este modo?
Pueden ver este pequeño tutorial en youtube
En resumidas cuentas la idea es crear una nueva carpeta en algun lugar de tu disco con el siguiente nombre:
GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
Finalmente el icono de la carpeta cambia de forma y se convierte en un nuevo panel de control.
¿Interesante no?
El dia de ayer miércoles fue un día triste para el avance del proyecto “backblaze pod”.
Pero, ¿Qué fue lo que pasó? . En realidad no mucho. Hemos estado luchando con la configuración de RAID 1+0.
¿Problemas? Sí, bastantes. Sin embargo, estamos haciendo las pruebas de posibles fallas de dispositivos I/O de inmediato para así realizar un sistema ‘failproof’.
¿Cuál ha sido el mayor inconveniente en estos días? Al hacer el sistema de archivos de forma que abarque todos los dispositivos SATA II (sdx) al simular una falla de un dispositivo y querer montar el sistema nuevamente con el comando mount el sistema no es capaz de reconstruir el sistema de archivos de manera que éste quede operacional nuevamente.
Los comandos que hemos utilizado son los siguientes (extraídos de la página oficial de btrfs):
Replacing Failed Devices
The btrfs-vol example above can be used to remove a failed device if the super block can still be read. But, if a device is missing or the super block has been corrupted, the filesystem will need to be mounted in degraded mode:
mkfs.btrfs -m raid1 /dev/sdb /dev/sdc /dev/sdd /dev/sde
# sdd is destroyed or removed, use -o degraded to force the mount
# to ignore missing devices
mount -o degraded /dev/sdb /mnt
# 'missing' is a special device name
btrfs-vol -r missing /mnt
btrfs-vol -r missing tells btrfs to remove the first device that is described by the filesystem metadata but not present when the FS was mounted.
El error que nos indica el sistema con el comando:
device fsid 40895d47368bf3-5ee445d21006ee99 devid 1 transid 35 /dev/sdb1
btrfs: allowing degraded mounts
btrfs: failed to read chunk root on sdb1
btrfs: open_ctree failed
device fsid 40895d47368bf3-5ee445d21006ee99 devid 1 transid 35 /dev/sdb1
btrfs: allowing degraded mount
btrfs: failed to read chunk root on sdb1
btrfs: open_ctree failed
He ahí el dilema de btrfs al tratar de montar el sistema incompleto y las hipótesis de porque el sistema no lo permite está en alguna de estas posibles razones:
- El error indica que no es posible leer la raíz del chunktree que se encuentra en el dispositivo sdb1 es por esto que al montar el sistema de archivos el sistema reclame al estar incompleto.
- El kernel que utilizamos en Fedora 12 no soporte de manera optima la utilización de multi discos y la supuesto fix o force mount que tratamos de utilizar no está funcionando.
Tan sólo cabe esperar por nuevos features del kernel nuevo o simplemente esperar a que la misticidad nos ayude a recuperar un sistema incompleto.
Proximamente se viene la presentación del ‘rojito’ , la instalación de Fedora12 y posiblemente algunos discos corriendo en BTRFS.
Alguien dijo: