Cuando se realiza una instalación nueva, SmartOS crea un dataset de SWAP del mismo tamaño que la memoria RAM del ordenador. Esto puede ser apropiado para máquinas grandes, pero cuando vamos escasos de memoria un SWAP tan pequeño es problemático porque bajo Illumos (Solaris) no existe el concepto de overcommit de memoria como en Linux. Es decir, un kernel Illumos limita el espacio de direccionamiento disponible para los programas a la suma de la memoria RAM y el espacio de intercambio (SWAP).

Por tanto, en SmartOS es común ampliar el espacio de intercambio.

Una de mis máquinas tiene solo 8GB de RAM y veo lo siguiente:

[root@X ~]# swap -s
total: 3928724k bytes allocated + 221992k reserved = 4150716k used, 8223728k available

[root@X ~]# zfs get all zones/swap
NAME        PROPERTY              VALUE                    SOURCE
zones/swap  type                  volume                   -
zones/swap  creation              vie. dic.  2  8:38 2022  -
zones/swap  used                  8,22G                    -
zones/swap  available             614G                     -
zones/swap  referenced            3,71G                    -
zones/swap  compressratio         2.18x                    -
zones/swap  reservation           none                     default
zones/swap  volsize               7,97G                    local
zones/swap  volblocksize          8K                       default
zones/swap  checksum              on                       default
zones/swap  compression           lz4                      inherited from zones
zones/swap  readonly              off                      default
zones/swap  createtxg             92                       -
zones/swap  copies                1                        default
zones/swap  refreservation        8,22G                    local
zones/swap  guid                  1242262060458694733      -
zones/swap  primarycache          all                      default
zones/swap  secondarycache        all                      default
zones/swap  usedbysnapshots       0                        -
zones/swap  usedbydataset         3,71G                    -
zones/swap  usedbychildren        0                        -
zones/swap  usedbyrefreservation  4,52G                    -
zones/swap  logbias               latency                  default
zones/swap  dedup                 off                      default
zones/swap  mlslabel              none                     default
zones/swap  sync                  standard                 default
zones/swap  refcompressratio      2.18x                    -
zones/swap  written               3,71G                    -
zones/swap  logicalused           8,01G                    -
zones/swap  logicalreferenced     8,01G                    -
zones/swap  snapshot_limit        none                     default
zones/swap  snapshot_count        none                     default
zones/swap  redundant_metadata    all                      default
zones/swap  encryption            off                      default
zones/swap  keylocation           none                     default
zones/swap  keyformat             none                     default
zones/swap  pbkdf2iters           0                        default

Por necesidades de servicio, requiero ampliar bastante el espacio de intercambio que, como he dicho, limita el espacio de direccionamiento total disponible para todos los programas.

Leer más…

Por motivos complicados necesitaba conocer el tamaño de una función en C, una vez compilada a código objeto. A priori no hay forma simple de saberlo.

Acabé volcando el listado de funciones y sus direcciones a partir del código objeto, ordenando las funciones por su dirección, buscando la dirección de la función que me interesa y buscando la dirección de la función que la sigue. Restando ambas obtenía el tamaño de la función.

Años más tarde volví a revisar el tema. Lo que me molestaba era lo que sigue:

Tomemos el siguiente código C:

1
2
3

 int a(int x) {
     return 2*x;
 }

Si compilamos el código anterior y generamos código fuente en ensamblador de x86 con gcc -S -O9 a.c, vemos lo siguiente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

         .file   "a.c"
         .text
         .p2align 4
         .globl  a
         .type   a, @function
 a:
 .LFB0:
         .cfi_startproc
         endbr64
         leal    (%rdi,%rdi), %eax
         ret
         .cfi_endproc
 .LFE0:
         .size   a, .-a
         .ident  "GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0"
         .section        .note.GNU-stack,"",@progbits
         .section        .note.gnu.property,"a"
         .align 8
         .long    1f - 0f
         .long    4f - 1f
         .long    5
 0:
         .string  "GNU"
 1:
         .align 8
         .long    0xc0000002
         .long    3f - 2f
 2:
         .long    0x3
 3:
         .align 8
 4:

La clave del asunto es la línea 14: .size a, .-a. Según el manual de gas, eso guarda como tamaño de la función a la resta entre la posición actual del ensamblador y la primera instrucción de a. Es decir, resta a la dirección final de la función la dirección inicial. Es decir, obtenemos el tamaño.

Aparentemente, entonces, se está generando esa información y se guarda en el código objeto. ¿Cómo acceder a ella?

Leer más…

Este código en Python se escribió en 2015 para generar con facilidad un CSR que se pudiese enviar a una autoridad de certificación para que nos proporcionase un certificado X.509 firmado que pudiésemos instalar en el servidor web.

El procedimiento normal es utiizar OpenSSL y así lo estuve haciendo durante décadas, pero, invirtiendo unos minutos para pasar el proceso a Python, el resultado es más sencillo, más configurable y más automatizado.

Hoy en día utilizo Let's Encrypt y este proceso ya no es necesario, pero lo documento aquí por si le resulta de interés a alguien.

Leer más…

Artículos previos:

• Novedades SmartOS de 20181011 a 20190829.
• Novedades SmartOS de 20190829 a 20200520.

Lo cierto es que los proyectos SmartOS e Illumos son muy activos y tienen muchísima actividad. Proporcionar un repaso exhaustivo es mucho trabajo para mí, así que me limitaré a detallar lo que me parece más interesante desde un punto de vista personal.

Puedes ver los cambios con detalle en inglés.

Probablemente lo más llamativo en este período es que Joyent se ha retirado de SmartOS. Su puesto lo ha ocupado MNX. Espero mantengan el extraordinario nivel al que nos tiene acostumbrados Illumos y SmartOS.

Algunos parches relevantes:

• OS-8370: Welcome MNX.
• TRITON-2304: New image server names.

También se está retirando el soporte de SPARC. Algunos parches relevantes:

• Bug #14841: remove SPARC support from mdb.
• Bug #14786: remove packaging support for SPARC.
• Bug #14828: remove SPARC FMA support.

Leer más…