Inicio > codear, linux, tests, ubuntu-ar > Discos Rígidos con Sectores de 4KB en Linux

Discos Rígidos con Sectores de 4KB en Linux

Domingo, 13 de junio de 2010 Dejar un comentario Ir a comentarios

Actualización (Julio 2010): Armé y redacté no tan informalmente este post en forma de artículo; el mismo está disponible para su consulta, crítica y mejoras en la sección de Publicaciones del sitio.

Los nuevos discos de Western Digital

En estos días tuve la oportunidad de comprar y configurar una máquina Ubuntu con un disco rígido Western Digital de 1,5 Terabytes (1500 Gigabytes aprox.); más precisamente el modelo WD15EARS, con 64 MB de caché, velocidad de rotación que varía entre 5400 y 7200 RPMs (llamado “IntelliSeek“), interfaz SATA II (3 Gb/seg), y que incluye una nueva tecnología de la marca conocida como “Advanced Format Drive” (paper aquí).

Si bien yo pensé que estaba comprando un disco más aunque sólo de mayor capacidad, luego al mirarlo más de cerca en su etiqueta decía:

Resumiendo, dice que:

  • Si va a utilizar el disco con Windows XP con una sola partición en el disco, sólo ponga el Jumper en los pins 7-8 del HD.
  • Si va a utilizar el disco con Windows XP con más de una partición en el disco, use la utilidad “WD Align”.
  • Si va a utilizar otro SO (Windows Vista/7, Mac OS X, o Linux), el disco no requiere preparación adicional para el particionamiento.

“Bueno, total no uso Windows”, pensé. Particioné y formatié con el GParted el disco y me puse a utilizarlo normalmente. No noté nada raro, hasta que unos días después googleando sobre experiencias con éste disco y Linux me encontré con este hilo en el foro de WD (“Problem with WD Advanced Format drive in LINUX (WD15EARS)“). Al parecer, mucha gente utilizando Linux con estos discos notaba una lentitud excesiva en cada cosa que hacía, como si hubiera un problema, no del hardware fallando y perdiendo datos, sino de demoras muy grandes en lectura/escritura. Resultó que aún usando Linux, el disco sí requiere preparación adicional, al contrario de lo que dice el fabricante, como veremos más adelante.

Sectores de 4 KBytes en vez de 512 Bytes, ¿Por qué?

Desde los primeros días de los discos rígidos, la mínima unidad de almacenamiento direccionable fue el sector, de 512 Bytes de capacidad. Esta granularidad se eligió porque siempre fue un buen balance entre la fragmentación interna de los archivos* y el manejo físico del disco relativo a la corrección de errores, flags de inicio/fin del sector más la separación inter-sector (gap). Toda la industria de la PC y el software creado para ella se apoyó en este estándar de facto, y casi ningún utilitario, BIOSes, ni Sistema Operativo se pensaron para un posible cambio… sólo hasta hace unos pocos años.

Western Digital es una de las primeras marcas en sacar al mercado discos con sectores 8 veces más grandes que los anteriores, de 4 KBytes (4096 Bytes); estos discos son etiquetados como que poseen “Advanced Format Technology” (“Tecnología de Formato Avanzado”), y es lo primero que uno debería empezar a mirar al comprar discos nuevos de gran tamaño (1 TB o superior), ya sean de WD o de otros fabricantes. Casualmente (o no tanto), esto incluye al disco que compré.

El motivo del cambio, según lo que explica este excelente post de AnandTech, se debe a que existen 3 factores esenciales que deben compensarse para buscar capacidades de almacenamiento cada vez mayores en el mismo tamaño de disco (que por lo general es de 3,5 pulgadas):

  1. Densidad de área: Cuántos bits se pueden guardar en un área determinada (Bits/Pulgada cuadrada). Hasta ahora, con la Grabación Perpendicular, estamos en el orden de unos 300/500 Gigabits por pulgada cuadrada (12).
  2. Relación Señal/Ruido: Al leer de los platos del disco, pueden ocurrir fallos, ya que el almacenamiento magnético en definitiva es analógico; y la señal, para ser convertida desde/hacia binario, debe ser procesada. Cuanto mejor sea la relación de la señal con respecto al ruido en el momento de leer o escribir en los platos, más confiable es la operación.
  3. El uso del Código de Corrección de Errores – ECC: Cada sector del disco incluye un área reservada para almacenar el ECC, imprescindible para recuperarse ante cualquier error de lectura/escritura.

A medida que la Densidad del Area se incrementa, los sectores (siempre de 512 Bytes) lógicamente se reducen en el área que ocupan físicamente. Esto hace que se incremente el Ruido con respecto a la Señal porque las señales son más débiles y hay más interferencia de los datos adyacentes; por lo tanto el valor de SNR disminuye, y a su vez, la probabilidad de errores de lectura aumenta. Entonces, es necesario mejorar la capacidad del ECC para detectar y corregir errores, generalmente agregándole más bits. Esto requiere de más espacio físico reservado para un sector (siempre de 512 Bytes), y aquí volvemos a empezar.

Lo que sucede es que aquí está el punto; se está llegando a un límite donde no se puede seguir con sectores de 512 Bytes y aumentar el tamaño total del disco, ya que todo este nuevo espacio obtenido con una mayor densidad termina no siendo utilizable, sino que será mayormente para el ECC (es decir, redundancia para contemplar posibles errores).

La solución al problema es que, para almacenar más información globalmente, hay que incrementar la eficiencia del ECC. Y esto se logra haciendo que éste abarque más datos que sólo 512 Bytes; el ECC es mucho más eficiente (ocupa menos espacio en comparación) si su código de corrección abarca más datos, digamos, 4096 Bytes.

Por ejemplo, para detectar y corregir corregir 4096 Bytes divididos en 8 sectores de 512 Bytes (de la vieja forma), necesitamos “gastar” 320 Bytes de ECC (ya que tenemos 40 Bytes por cada ECC de 512 Bytes), mientras que si usamos 1 sector de 4096 Bytes sólo vamos a usar 100 Bytes de ECC. Como se puede ver, uno se ahorra 220 Bytes de overhead por cada 4KB que tiene el disco para guardar cosas; en 1500 GB (= 1.500.000.000 KB / 4 = 375.000.000 sectores de 4 KB * 0,22 KB) son 82,5 GB más de espacio disponible para almacenar datos de usuario y no ECC (un 5,5% más). Esto y sin contar el espacio “desperdiciado” para los gaps entre sectores y el flag de sincronización/inicio de sector (para 4 KB, antes eran 8 y ahora es sólo 1). Además, estos 100 Bytes de ECC mejoran en un 50% la capacidad de detectar errores en “ráfaga” comparado con el anterior, es decir, el nuevo es un mejor y más eficiente ECC.

Por todo esto, para tamaños tan grandes de disco, usar sectores de 4KB nos permite aprovechar de manera más eficiente la mayor densidad del área que disponemos. ¿Y por qué 4 KB? No es un número al azar; coincide con el tamaño de las páginas de memoria en la arquitectura x86 y con el tamaño de cluster por defecto de la mayoría de los sistemas de archivos que pululan por ahí, con lo cual la velocidad de transferencia de páginas desde/hacia el disco no se ve afectada, y la fragmentación interna de los archivos almacenados es la misma que con sectores de 512 Bytes.

Quizás con el gráfico se entienda un poco más; allí se ve cómo ocupan más lugar los 8 sectores de 512 Bytes puestos a la par del sector de 4 KB:

Nuevamente (espero comentarios y corrijo en todo caso), toda esta info está bien explicada en el artículo de AnandTech, en este artículo de Ars Technica, en el Paper de WD y en este artículo de IBM.

Bien, “¿Y qué gano con sectores más grandes? ¿en qué me afecta?”, es lo primero que uno se pregunta. Claramente, y por lo explicado recientemente, se gana en confiabilidad y capacidad de almacenamiento hoy y a futuro. ¿Cuáles son las contras? básicamente, el proceso de migración, que como ya se dijo, deben afrontarse desde varias capas de software, desde el BIOS, pasando por el Sistema Operativo y llegando a las herramientas de defragmentación, clonado y administración de discos.

¿Y qué problema hay con Linux? Particiones desalineadas.

Teniendo en mente esto, esta serie de discos de WD emula ser un disco con sectores “lógicos”de 512 bytes, pero en realidad trabaja internamente con sectores “físicos” de 4 KB. De esta manera, los sectores de 512 bytes lógicos se ven así, dentro de uno de 4 KB:

Recordemos, la mínima unidad “direccionable” real del disco son 4 KB (un sector), y el tamaño de cluster por defecto (la mínima unidad “direccionable” por el sistema de archivos) son 4 KB; esto quiere decir en definitiva que el disco, cada vez que lee y escribe lo hace en unidades de 4 KB. Luego le agregamos la capa de emulación, para hacerlo compatible con los SOs que tenemos ahora. Bien, supongamos que vamos a crear una sola partición en el disco. ¿Qué pasa si esta partición, donde vamos a guardar los datos, comienza en el sector 1 (o cualquier sector no múltiplo de 8 ) del disco en vez del sector 0? Va a pasar esto:

Lo que sucede es que el primer cluster empieza y termina en dos sectores físicos; está “desalineado” con respecto a ellos. En realidad, todos los clusters de la partición estarán de esta forma, comenzando y finalizando a “destiempo” respecto de los bloques físicos. El problema que esto conlleva es que si el SO va a escribir algo en el disco (donde el “algo” es como mínimo generalmente un cluster de 4 KB), supongamos el cluster resaltado en azul, esto se transforma físicamente en:

  1. Leer los 4 KB del sector físico 0.
  2. Modificar los 7 sectores lógicos afectados por esta operación.
  3. Grabar los 4 KB del sector físico 0.
  4. Leer los 4 KB del sector físico 1.
  5. Modificar el 8vo sector lógico.
  6. Grabar los 4 KB del sector físico 1.

Esto es, 2 operaciones de Leer-Modificar-Grabar (RMW) atómicas, una para cada sector físico, que involucra una vuelta (spin) de disco por cada lectura/escritura de la lista enumerada. Es decir, que una partición comience en un sector lógico de 512 Bytes no múltiplo de 8 hace excesivamente lento el acceso al disco porque las operaciones llevan mucho, mucho más tiempo que antes.

Y la cuestión reside aquí; si bien Linux a esta altura ya está preparado para manejar discos con sectores de 4 KB, el problema es que el disco “le dice” a Linux que tiene sectores físicos de 512 bytes por la emulación, cuando internamente trabaja con 4 KB:

marcelo@marcelo:~$ sudo hdparm -I /dev/sdb | grep Sector
	Logical/Physical Sector size:           512 bytes

¿Y cuál es la consecuencia? La posibilidad de no tener los sectores alineados. Fdisk y cualquier software particionador de discos de Linux comienza la primer partición en el sector 63 de aquellos discos que reconoce como de sectores de 512 Bytes**. Esto hace que el disco funcione muy lento, como se describía en el foro de WD que cité al comienzo.

Cómo particionar estos discos en general y en Linux en particular

Bueno, ¿cómo se hace para crear particiones de manera alineada? Es relativamente fácil. Según Ted Ts’o, donde explica que hay un problema parecido con los nuevos discos SSD, hay que ejecutar fdisk con los parámetros “-H 224 -S 56 /dev/sdX”, siendo /dev/sdX el disco en cuestión; esto hace que todas las particiones se creen en la sesión interactiva de fdisk en sectores múltiplos de 8. Otra opción es usar GNU Parted con los parámetros “unit s”, y de esta manera deja a uno configurar el primer sector de cada partición (más info acá).

En mi caso necesitaba crear 4 particiones. Este es un ejemplo de particiones bien alineadas, el último comando es para mostrar el tamaño de cada partición nada más:

marcelo@marcelo:~$ sudo parted /dev/sdb unit s print
Modelo: ATA WDC WD15EARS-00S (scsi)
Disco /dev/sdb: 2930277168s
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos
 
Numero  Inicio       Fin          Tamaño       Tipo     Sistema de ficheros  Banderas
 1      56s          41959679s    41959624s    primary  ext4
 2      41959680s    46161919s    4202240s     primary
 3      46161920s    1673570303s  1627408384s  primary  ext4
 4      1673570304s  2930265855s  1256695552s  primary                       raid
 
marcelo@marcelo:~$ sudo fdisk -lu /dev/sdb
 
Disco /dev/sdb: 1500.3 GB, 1500301910016 bytes
224 cabezas, 56 sectores/pista, 233599 cilindros, 2930277168 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 512 bytes
Identificador de disco: 0x00094da1
 
Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdb1   *          56    41959679    20979812   83  Linux
/dev/sdb2        41959680    46161919     2101120   82  Linux swap / Solaris
/dev/sdb3        46161920  1673570303   813704192   83  Linux
/dev/sdb4      1673570304  2930265855   628347776   fd  Linux raid autodetect
 
marcelo@marcelo:~$ sudo parted /dev/sdb print
Modelo: ATA WDC WD15EARS-00S (scsi)
Disco /dev/sdb: 1500GB
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos
 
Numero  Inicio  Fin     Tamaño  Tipo     Sistema de ficheros  Banderas
 1      28,7kB  21,5GB  21,5GB  primary  ext4
 2      21,5GB  23,6GB  2152MB  primary
 3      23,6GB  857GB   833GB   primary  ext4
 4      857GB   1500GB  643GB   primary                       raid

Nuevamente: Lo más importante para que los clusters estén alineados con los sectores físicos del disco es que cada partición debe comenzar en un sector múltiplo de 8, como el 56, 41959680, 46161920 y 1673570304 de este caso.

Conclusión

Bueno, fue un artículo muy largo, donde me pareció que servía explayarse en el porqué de los sectores más grandes y qué problemas trae.  Tuve la grata oportunidad de intercambiar algunos mails al respecto con Aleksander Adamowski, la persona que en la lista de util-linux-ngdescubrió” el inconveniente de la lentitud con esta serie de discos WD a base de un lote de pruebas disponible aquí.

Aleksander me recomendó, en resumidas cuentas, al trabajar con discos > 1 TB “sospechosos” de tener sectores de 4 KB:

  • “Las unidades de medida son críticas. Asegúrate que estás realmente operando a nivel de sectores***
  • Después , hacer un test de performance es buena idea.
  • Para esto, primero trata de crear una partición desalineada, crea un sistema de archivos, y ejecuta el benchmark de postmark usando el archivo de configuración que publiqué (http://olo.org.pl/files/hw/postmark-automated/postmark-quick.conf – por supuesto, modifica la opción “location” en ese archivo acorde al disco a comprobar.
  • Luego, borra todas las particiones y haz lo mismo en una partición alineada. Los resultados deben ser mucho mejores en cuanto al rendimiento. Si no lo son, el disco probablemente tiene sectores físicos de 512 Bytes.”

En resumen, hay que estar atentos. Sería bueno que los futuros discos que salgan con sectores de 4 KB informaran al SO qué estructura real tienen, y eliminar el “modo compatibilidad” de una vez por todas.

Espero que les sirva.
Saludos

* En tiempos donde la capacidad de los discos era muy pequeña comparada con los de ahora, el tamaño de un cluster del sistema de archivos era igual al de un sector.

** La utilización del sector 63 corresponde a que generalmente (y por herencia histórica del modelo de direccionamiento CHS) es el primer sector del track número 1. El track 0 siempre se utilizó para el MBR / Master Boot Record.

*** Esto porque por defecto las herramientas de particionamiento Linux no trabajan con sectores; fdisk trabaja con cilindros por ejemplo.

Categories: codear, linux, tests, ubuntu-ar Tags:
  1. Efraim
    Lunes, 14 de junio de 2010 a las 12:01 | #1

    Muy bueno y muy completo, excelente Marce

  2. Martes, 15 de junio de 2010 a las 16:05 | #2
  3. Martes, 15 de junio de 2010 a las 16:13 | #3

    Peter :

    Excelente artículo!! http://preguntaslinux.org/-howto-discos-con-sectores-de-4kb-t-6155.html

    Ja, fijate cuando me citaste, ¡mi nombre es Marcelo Fernández, no Ramirez! 😛

    Saludos

  4. Eduardo
    Miércoles, 16 de junio de 2010 a las 05:57 | #4

    Artículo muy detallado.
    Estoy por comprar un disco nuevo y tenía dudas, leerte me las despejó por completo, GRACIAS.

  5. Claudio
    Lunes, 5 de julio de 2010 a las 19:14 | #5

    Del manual de Oracle 11gR2

    1.8.1.4 Support 4 KB Sector Disk Drives
    Today, disk drives have 512 byte sectors. Disk drive manufacturers are moving to 4 KB sector drives because it allows them to offer higher capacity with lower overhead. If customers use 4 KB sector drives as 512 byte sector drives, then there is likely to be a performance penalty (because they have to run in 512 byte emulation mode). This feature allows Oracle to work with 4 KB (and 512 byte) sector drives without a performance penalty. There is also the capability in Automatic Storage Management (ASM) to allow migration of a disk group from 512 byte sector drives to 4 KB sector drives.

    This feature allows customers to take full advantage of new generation, higher capacity disk drives.

  6. Jueves, 15 de julio de 2010 a las 22:07 | #6

    Disculpa la estupidez de mi pregunta.
    Ante el echo de encontrarme con cerca de un terabyte de datos en un disco duro de 1 1/2. ¿No existe alguna forma de corregir ese asunto de los sectores sin tener que formatear?
    Disculpa si la pregunta es tonta, pues entiendo que hay que formatear. Pero tengo tres discos, 2 de 1 terabyte y el tercero de 1500 gigas y los de 1 terabyte están casi llenos y si me presentan el problema que a la hora de escribir datos no son muy rápidos. Y bueno si hay que respaldar problemon el mío que no tengo donde hacerlo.

    Salu2

  7. Jueves, 15 de julio de 2010 a las 23:40 | #7

    Ahora acabo de leer un problema con las unidades barracuda, que es como la que yo uso.

    http://techreport.com/discussions.x/15863

    Bonita cosa. 🙁

  8. Viernes, 16 de julio de 2010 a las 15:15 | #8

    Hola Alfonso, ante todo no hay preguntas estúpidas. 🙂

    En principio no hay manera de reparticionar todo de vuelta con las herramientas típicas de Linux. Quizás puedas probar la herramienta de WD que menciono en el artículo que tiene el objetivo de “reacomodar” todos los sectores en forma alineada, aunque funciona sólo tenés una única partición definida en el disco y además es NTFS; puede que sea tu caso.

    Saludos

  9. Viernes, 16 de julio de 2010 a las 15:19 | #9

    Alfonso, el “diagnóstico” de la gente de la página que dejás es muy parecido al que encontré en los foros de WD con este disco, “freezes” repentinos de unos cuantos segundos… por lo que intuyo que sea muy probable que este Barracuda esté usando sectores de 4KB tranquilamente.

    Para corroborarlo, habría que limpiar el disco y correr el lote de pruebas (un script de bash que llama a la herramienta postmark)… los reportes son muy fáciles de leer, incluso si entrás al directorio ese están los resultados de las corridas contra el disco WD en cuestión.

    Saludos

  10. Martes, 20 de julio de 2010 a las 00:27 | #10

    Hola Marcelo, te cuento que mi disco duro me lo cambiaron por garantía.

    Bien lo formatee y montee de manera normal, use el Gparted y la prueba de rendimiento me arrojo:

    imagen

    Después hice lo que recomiendas en tu blog y la prueba de rendimiento me arrojo esto:

    imagen

    Si pudieras echarme la mano a interpretarlo. hice algunas pruebas copiando archivos de 20 y 30 gigas y la verdad no note alguna diferencia sustancial. La transferencia en ambos casos rondo de los 80 kbs a 120 kbs.

    Salu2.

  11. Martes, 20 de julio de 2010 a las 10:25 | #11

    Hola Alfonso,

    Los gráficos dicen lo mismo. No sé bien qué manera usa de testear los discos el GParted, pero estimo que no usa Postmark (de hecho hay que instalarlo luego de Ubuntu, no viene por defecto). Además, Aleksander, la persona que hizo los tests que menciono en el artículo [1], descartó bonnie++ e iozone por no cumplir los requisitos para “develar” el problema.

    Si querés hacer más pruebas, usá los scripts que hizo Aleksander [2]… no se ve usando GParted.

    [1] http://article.gmane.org/gmane.linux.utilities.util-linux-ng/2955
    [2] http://olo.org.pl/files/hw/postmark-automated/

    Saludos

  12. chuki7
    Miércoles, 28 de julio de 2010 a las 10:09 | #12

    Entiendo que con la utilidad “gparted” no funciona aunque esté activo la opción “redondeo de cilindros”.

  13. Jueves, 25 de octubre de 2012 a las 16:11 | #13

    Mejor que parted es usar gdisk [1], tuve los mismos inconvenientes y llegué a casi las mismas conclusiones por otro lado.

    Incluso me cambiaron 7 discos de 2tb WD Green que compré por su mala perfomance, despues llegué a la conclusión que no eran los discos sino justamente el tema del tamaño de los sectores.

    Aunque aún no logré resolverlo en OpenIndiana (tengo que levantar un storage con ZFS dentro de poco)

    Saludos

    [1] http://www.rodsbooks.com/gdisk/

  14. Lunes, 6 de mayo de 2013 a las 14:31 | #14

    en donde colocas (parte de otras infos dudosas):

    ¿Y por qué 4 KB? No es un número al azar; coincide con el tamaño de las páginas de memoria en la arquitectura x86 y con el tamaño de cluster por defecto de la mayoría de los sistemas de archivos que pululan por ahí,

    eso no es tan cierto… en sistemas de transferencia si el fragmento de sector es grande (ejem 4k) los archivos grandes pasan mejor, pero si es pequeño, no mucho..

    ademas el problema viene pro el jalabolismo a mocosoft.. el sistema de ficheros NTFS 5 solo fragmenta a 1, 2 o 4k, los ntfs version 6 y 7 solo a 4k, y si esto coordina con el fisico, el rendimiento es mauyor, esa era la presion de ese numero .. solo beneficio a sistemas ubunwindows…

    acerca de ECC, es lo mismo en 512 que 4k, la diferencia es cuando se mueve dartos grandes, los discos de 4k para particiones de proxi son ineficientes, ya que los datos son muy pequeños y se desperdicia espacio, esto explica porque misteriosamente se llena mas rapido particiones pequeñas en discos grandes…

    dado hoy dia todos los usuarios pierden el tiempo en la red, los datos que descargan tienden a ser grandes por defecto, y este tamaño termino siendo bueno apra guiinndows… en linux no hay mucha diferencia si implementas un DataStorage en base de datos, ya que mas bien, moviendo de 512 a 40896 elk performace decrece, ya que los datos que maneja son siempre pequeños, y el ECC es ineficiente…

  15. Sábado, 10 de mayo de 2014 a las 16:09 | #15

    Hola , vereis he particionado a la perfección con fdisk pero a la hora de instalar linux me modifica el sector en el que empieza la partición 3 que es la extendida , en un principio el sector en el que empezaba era múltiplo de 8 pero a instalar linux lo modificó quedando de la siguiente manera:

    /dev/sda3 239493118 976773167 368640025 5 Extendida
    La partición 3 no se inició en el limite físico del sector
    /dev/sda5 239493120 312709916 36608398+ 83 Linux

    Si o fijáis el sector en el que empieza la partición /dev/sda3 es sólo 2 sectores menos, y esto me lo hace siempre sólo el instalador de linux cada que que lo instalo , puedo poner que la partición /dev/sda5 empieze en el sector 32569871524 por ejemplo y el /dev/sda3 en el 15646548487 que a la hora de instalarlo le cambiará el sector de inicio a la partición 3 y la dejará justo 2 sectores menos que la partición /dev/sda5 de tal manera que quedase así:

    /dev/sda3 32569871522
    La partición 3 no se inició en el limite físico del sector
    /dev/sda5 32569871524

    Y entonces el sector en el que empieza la partición 3 no es la correcta y me sale el siguiente mensaje , nose que hacer ya.

  16. Sábado, 10 de mayo de 2014 a las 17:23 | #16

    Hola Román,

    Estas instrucciones aplican para versiones de Linux algo viejas, las modernas (Ubuntu 14.04, por ejemplo) manejan los discos con sectores de 4 KB perfectamente. ¿Qué versión de linux estás usando?

    Saludos

  1. Martes, 15 de junio de 2010 a las 11:15 | #1
  2. Domingo, 20 de junio de 2010 a las 16:35 | #2
  3. Viernes, 14 de enero de 2011 a las 21:28 | #3