Y la defragmentación y otras cosas menores, claro.

Voy a intentar que esto parezca más un artículo de IT clásico que un puñetero lartazo de BOFH (pero no escatimaré en recursos de control luseriano como esto, que hay que conservar las tradiciones).

 

Empecemos por partes, y con paciencia.

Parte 0: Todo lo que siempre quiso saber sobre el hierro y nunca se atrevió a preguntar.

Vale, ya me he pasado otra vez con una referencia cruzada entre una isla con volcanes y una película de los Monty Python.

El hierro, ese gran desconocido.

El componente que recibe las hostias cuando falla el software.

Que me voy. BOFHmode=off.

A lo que voy. No voy a entrar en discusiones sobre qué tipo de disco, o que tecnología o que otras puñetas existen, porque en cuanto pasen unos segundos, paso a estar obsoleto. Eso lo dejamos para los «especialistas» que cobran por ello.

En lo que nos atañe, y para un usuario de a pie, que se compra un cojoequipo y quiere que todo patine por la superficie como el equipo ruso de patinaje sobre hielo, o para los que tienen un trasto del pleistoceno y han visto nuestro último hangout de 2017 sobre arqueología informática, para poner un disco SSD a un trasto que lo más seguro es que muera por RAM o procesador más que por disco, pero aun así…

Bueno, pues tenemos en concepto que un disco SSD es un disco que no tiene partes mecánicas, es todo electrónica, y suelen ser más pequeños y caros que los mecánicos, que se basan en discos rotatorios y el fenómeno físico de la magnetoresistencia gigante de spin. (Si, lo soltaron en TBBT un día).

Hay que dejar de pensar en el disco como en una gran nave industrial dividida por salas, pasillos de estanterías y alturas (concepto CHS) ya que, aunque esto siga siendo necesario en discos mecánicos, hace mucho que quedó superado por necesidades de crecimiento. Lo explicaré si hace falta en otro artículo.

Solo voy a bajar a este nivel para explicar el concepto de la alineación de las particiones.

Para que la BIOS (sea cual sea, todas las interfaces de disco pasan por la BIOS que reinterpreta lo que la controladora envía) pueda presentar un dispositivo de disco al sistema operativo, prepara una interfaz en LBA (large block addressing) que viene a ser el mapa del disco físico para la unidad presentada.

El resultado de eso es que tenemos un fraccionamiento, en unidades de asignación, que no suele variar para la inmensa mayoría de los casos domésticos. Sólo en caso de RAID o algunos temas en Linux, puede ser necesario profundizar más.

El concepto es simple. y tiene dos derivadas.

Pon tu partición al principio de una unidad de asignación

Usa unidades completas.

Vale. Un traguito a lo que sea que eche humo en la taza, que de momento esto está siendo denso.

Volviendo al símil del almacén, cuando yo, el IPL del sistema operativo, pido a la BIOS que me mande el flujo de los ficheros que necesito para el arranque, la BIOS pedirá a la controladora dicho chorro de material.

¿Qué pasa si la partición no está alineada?

Pues muy simple, que obligas a la BIOS a realizar dos peticiones. Uno para la unidad de asignación donde empieza la partición y otro para la unidad de asignación donde continúa la partición. El chino tendrá que hacer dos viajes. En casos extremos, esto puede ocurrir hasta dos veces por cada unidad de asignación. El impacto es brutal.

¿Cómo se puede ver la alineación de una unidad?

Pues muy simple también. Desde mi querida línea de comandos.

wmic partition get BlockSize, StartingOffset, Name, Index


Como se puede apreciar, todos los valores de StartingOffset son múltiplos perfectos de 1024^2 (1048576) lo cual indica un correcto alineamiento.

Puede suceder, en sistemas como XP o anteriores (y en algún posterior lo he visto, por crear particiones a mano o instalar sin formatear para conservar datos), o en instaladores automáticos de ciertas distribuciones Linux (si, esa) cuando se le obliga a reducir espacio conservando lo que hay.

Aquí, en esto que tiene un W7 y un Linux (si, ese) y 4 discos, se ve claramente que se le ha obligado a vivir con particiones que fueron creadas en la época de XP, probablemente para conservar los datos, y han quedado desalineadas en los dos primeros. Los otros dos discos están correctos, para un usuario doméstico convencional.

Soluciones:

Pues es muy simple. Automáticamente desde:

Sistema	Instalador	Utilidad gráfica	Utilidad de línea de comandos
Windows XP Windows 2003	Ni de coña En todo caso con utilidades de terceros y con cuidado…	Solo en discos dinámicos	A partir del 2003R2 con diskpart, y había que forzarlo En XP no lo he probado, pudiera ser.
Windows Vista Windows 2008	Los instaladores a partir de la ISO del SP1	Lo mismo, desde el SP1	Si, sin forzarlo va a 32k.
Windows 7 y posteriores Windows 2008R2 y posteriores	Todos*	Todos	Es mejor especificar el desplazamiento
Windows 10 Windows 2016	Todos*	Todos	Es mejor especificar el desplazamiento

Donde pongo Todos* es simplemente porque todos los instaladores lo hacen si es ese instalador quien crea el esquema de particiones. Si el esquema de particiones viene heredado, o se ha manipulado (vía herramientas de clonado o de redimensionado), o lo crea otro tipo de instalador (existen, pero no abriré ese melón hoy).

Hay vida después haber cometido esos errores, solo que no existe una utilidad nativa de Windows.

Con una distribución de Linux capaz de arrancar desde CD o USB, parted o gparted y un poco de habilidad, y previa copia de seguridad de los datos importantes, es posible realizar las correcciones necesarias.

Parte 1: Acerca de los parámetros de Windows y los demás siniestros modos de trabajo del disco.

Bueno, es simple. Todos son parámetros de software.

Como siempre en Windows, casi todo se toca por registro o directiva (que en el fondo es tocar el registro también), pero como soy amigo de las consolas, voy a hacer el esfuerzo de utilizar todo lo que pueda por consola, con herramientas nativas y sin provocar esfuerzos innecesarios.

• El primero de todos sería la fecha/hora de último acceso a fichero. No suele estar habilitado por defecto, pero a veces, en modo auditoria, y con otros propósitos, es posible que hasta un simple dir marque como accedidos los ficheros con una actualización de metadatos. Impacta negativamente en el rendimiento.

Según la technet debemos aplicar el valor 1. Si tiene valor 0, comerá rendimiento.

Pero visto desde la línea de comandos, es más simple:

fsutil behavior query disablelastaccess 1

Para cambiar este parámetro, fsutil behavior set disablelastaccess 1 y reiniciar.

• El siguiente parámetro podría ser el soporte para TRIM, que a grandes rasgos es una evolución de lo que hacía FAT para borrar ficheros. Básicamente le dice al sistema de ficheros «Cuando recibas la orden de borrar algo, déjalo donde está, y elimina su entrada del índice».

Pensándolo así, esto es guay ¿no? Los borrados irán a toda pastilla porque solo hay que tocar un punto, un acceso, pero ¿qué pasa con los datos?

Pues que siguen estando ahí, y son recuperables, porque, realmente ¿qué es un borrado? ¿es que va a ir a donde estaba el fichero y va a llenar de ceros lo que antes era una carta de amor?

Son preguntas que a mí también se me pasan por la cabeza, pero a un usuario de a pie le va bien el tema, así puede usar el recuva o cualquier otro y no perder las fotos de la comunión del sobrino del cuñado que ha borrado pensando que era otra cosa. Vamos, lo mismo que hacíamos con undelete o recover hace 25 años. Si hace falta, podría hacer un pequeño resumen de cómo funciona el borrado/rellenado de ceros, Peter Guttman o el método Gauss, e incluso los EargedZeroed y thin diversos con recuperación de espacio… Pero eso es otro cuento que a un usuario de a pie ni le va ni le viene, salvo que seas tesorero de un partido.

Según la technet debemos aplicar el valor 0. Si tiene valor 1, comerá rendimiento.

fsutil behavior query DisableDeleteNotify 0

Para cambiar este parámetro, fsutil behavior set DisableDeleteNotify 0 y reiniciar.

Creo que TRIM merece una mejor explicación, pero yo no puedo darla y sería increíblemente difusa y diversa a lo largo de todo el artículo, así que mejor os dejo por aquí un enlace de una explicación que convence bastante a @RFOG pero que a mi me deja frío.

• Otro parámetro es la compresión nativa de ficheros de forma transparente. No digo que sea un parámetro que se deba tocar si la persona que usa el sistema tiene los conocimientos adecuados y no hace el cafre como me tocó vivir en la odisea de los discos comprimidos.

Aquí no me voy a extender demasiado, por lo que ya he explicado. Solo es una ayuda que, en caso de necesidad, impida al usuario comprimir cuando llena el disco.

Es lo que hacían doblespace, drivespace y staker hace 25 años, y es un horror, y un dolor, cuando llega el clásico manazas que borra medio sistema para meter a saber qué, y encima lo hace irreparable por falta de espacio.

Según la technet debemos aplicar el valor 1. Si tiene valor 0, permitirá compresión.

fsutil behavior query disablecompression 1

Para cambiar este parámetro, fsutil behavior set disablecompression 1 y reiniciar.

• Por último, vamos de nuevo a la interfaz con el hardware. ¿Sigues aun usando discos IDE? ¿El ESDI funcionaba mejor? ¿MFM RLL era más robusto? ¿SCSI porque casi lo es? (chiste malo puesto a posta).

Bueno, como imagino, la gran mayoría de los equipos domésticos ya trabajarán con discos SATA en cualquiera de sus variantes, pero a veces, y depende de la controladora de la BIOS, puede que no funcionen en modo nativo si no en modo compatible.

En la gran mayoría de los casos, nos interesa que la BIOS tenga AHCI como modo de funcionamiento, ya que el rendimiento es muy superior a los modos PIO/UDMA.

Esto es un procedimiento complejo, que no voy a desarrollar aquí. pero puedo hacerlo a parte si es necesario. De todas formas ni es común ni hay otras configuraciones en BIOS nuevas. Solo afectaría a los casos de arqueología que comentaba en el inicio del post o instalaciones de W7 y W10 en equipos no tan modernos.

Por cierto, para hacer esto, hay que volver a la mentalidad de NT donde hasta los drivers eran tratados como servicios.

Parte 2: Acerca de los servicios de Windows, y otras flores mitológicas.

Igual que antes, esto también es simple. Todos son parámetros de software.

Los servicios se pueden tocar de diferentes maneras, y aquí también prefiero usar las consolas, a sabiendas que puede haber formas más simples, a pesar del esfuerzo innecesario que supone usar esas formas más simples.

• Servicios de indexación de disco.

En este caso hay que diferenciar entre los diferentes servicios (WSearch que es el nativo, SQL CE, o incluso Google desktop) con su configuración.

Frente a diversos blogs y usuarios que directamente dicen que se desactive, yo prefiero una configuración correcta.

Si fuera solo por desactivarlo… ¿Qué gracia tendría la ingente cantidad de pasta que invierten los centros de datos en discos SSD para dar servicio de BBDD? Al fin y al cabo, la indexación es convertir todo el sistema en una gran base de datos y atacar por el índice. ¿Alguien recuerda OFS en Cairo o WinFS en Odyssey? Qué pena de proyectos cancelados.

¿Y cómo es una configuración correcta?

Pues muy sencillo en mi caso. Uso WSearch contra el perfil y unas cuantas ubicaciones adicionales, por lo que si lo quito, Cortana se va a quejar.

Simplemente hay que desactivar una casilla en las propiedades del volumen (o los volúmenes) en SSD.

Hay una interfaz mucho más avanzada en el panel de control, que permite ajustes mucho más finos, pero con esto, en principio, es suficiente.

Aquí hay una clara desventaja, pero claro, solo para mí y cuatro habituales de los atajos. Al desactivar la indexación de la unidad, pierdo el poder invocar algo por su nombre desde cortana, si está fuera de la variable path.

• Servicios de rendimiento: Prefetch

Es una lástima, pero todo sea por el SSD. Con el fantástico trabajo (de verdad) que venían haciendo desde XP y Vista…

Pero empecemos por el primero, Prefetch.

Es un servicio de predicción que funciona bastante bien, y no voy a compararlo con el Branch Predictor de los procesadores, pero por ahí van los tiros. Básicamente carga en memoria lo que Windows piensa que se va a ejecutar o acceder en los próximos momentos, y si, tiene una orientación claramente empresarial, porque no es lo mismo un equipo de empresa que ejecuta siempre lo mismo, en aproximadamente el mismo orden y en unos determinados momentos, que el ordenador de paquita donde tiene las recetas, el hijo mete fotos, la sobrina hace vídeos y el padre lee literatura deportiva variada. En efecto.  Un puñetero carajal.

Ante todo, literatura.

Hay 4 modos de funcionamiento:

Modo	Resultado esperado
0	Deshabilitado
1	Estudio y aplicación de mejoras de lanzamiento de aplicaciones.
2	Estudio y aplicación de mejoras de arranque.
3	Estudio y aplicación de mejoras de lanzamiento de aplicaciones y arranque.

Dado que la velocidad de lectura y del bus es lo suficientemente alta, podemos permitirnos deshabilitar esta maquinaria, recuperando los ciclos de proceso y la RAM que usa.

Solo habría una excepción, y es que en un segundo disco mecánico existieran muchos ejecutables de uso frecuente, donde me plantearía un 1 como valor. No veo justificación para máquinas virtuales de entorno de usuario.

De nuevo, para la modificación, hay que remangarse puesto que la vía sencilla es por el registro.

Pero claro, por consola es mucho más rápido:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 0

Y queda así de mono.

• Servicios de rendimiento: Superfetch

Superfetch es otro servicio, al estilo del anterior, y claro, complementario al mismo, pero con una asombrosamente mala descripción. Literalmente pone «Maintains and improves system performance over time.» «Mantiene y mejora el rendimiento del sistema a lo largo del tiempo.»

Muchos tenemos la impresión de que Windows es más lento que el coche de los malos cuando lleva 4 días funcionando sin parar, pero es por otros motivos y no porque esto no funcione, que hace lo que puede…

No voy a extenderme demasiado porque los motivos son los mismos.

Vamos al código, y como se puede hacer de varias maneras…
Lo más simple, con SC, service controller:

sc config "SysMain" start=DISABLED

Otro método, wmic:

wmic service where name='SysMain' call ChangeStartmode Disabled

Y esto me recuerda que wmic es muy poderoso, tanto como para poder hacer:

wmic service where "caption like '%SysMain%' and Startmode<>'Disabled'" call ChangeStartmode Disabled

Pero al final, siempre nos quedará el registro, por línea de comandos, claro:

REG add "HKLM\SYSTEM\CurrentControlSet\services\SysMain" /v Start /t REG_DWORD /d 0 /f

• Servicios de protección del sistema.

Ante todo, esto tiene más nombres que un yerbajo en la facultad de biología. Volume Snapshot Service, del que hablaré en profundidad luego por otros motivos, Previous Versions en Windows Vista o XP, Shadow Copies for Shared Folders en Windows Server… e incluso File History.

Todo esto viene a ser una serie de nombres de lo que probablemente es la funcionalidad más chula que puede tener el sistema. Se llama System Restore, o System Protection en Windows 10.

La funcionalidad permite enfriar una parte del sistema operativo en un área del disco, que queda como solo lectura, y continuar escribiendo en otra. En caso de fallo, simplemente se vuelve atrás y queda como si nunca se hubiese alterado.

Todo a cambio de un porcentaje de reserva del disco. Nada usurero, menos de un 20%, que conozco tarjetas con mayor tasa de interés.

Pero claro, ¿qué mejor que verlo en acción? simplemente esperad a ver un parche de WindowsUpdate de los que revientan… Funciona automáticamente, pero, se puede mejorar.

¿Al desinstalar el programa X se me ha cascado el programa Y con el que comparte la biblioteca Z? no hay problema. Volvemos al último punto de restauración.

Y esto es a grandes rasgos el servicio de protección del sistema. A cambio de eso yo pago gustoso el peaje de reservar unos pocos gigas del disco.

Así que yo no aconsejo deshabilitar o poner a 0 este servicio. Si es que encima funciona, y bastante bien.

• Servicios de snapshot, instantáneas de volumen (no, VSS no es el rifle Vintorez)

La parte de abajo del servicio de protección del sistema es un proveedor de instantáneas, el servicio VSS, Volume Snapshot Service.

En principio, esto es el servicio que se encarga de interactuar con el sistema de ficheros de forma que, aun existiendo diferentes versiones de un mismo contenido, el acceso y la protección se presenten por capas. Una explicación muy técnica, la verdad.

Y ¿para qué sirve? Muy sencillo, es el proveedor de instantáneas, que permite congelar el sistema, para copiar de forma consistente, la información. Se puede ver de la forma que pongo. Y en este momento tengo 3 snapshots activas, más la información en curso.

No voy meterme mucho más en profundidad, me lo reservo para un artículo sobre backups.

Por cierto, hay más servicios que el nativo de Windows. Por ejemplo, el de Acronis, o el de Symantec, o el de Naviko, o incluso el propio SQL Server tiene uno que sirve a sus propósitos.

Lo os digo que, en su momento, llegué a usar ghost sobre un XP por terminal services, para copiar la máquina remota y traerme la imagen desde el cliente hasta mi equipo con los servicios de carpetas de terminal services. Y todo consistente gracias al VSS de Windows XP.

Bueno. Igual que en otros casos, con esto se puede parar cualquier servicio de VSS de los que conozco, aunque yo no lo aconsejo. Son muy superiores los beneficios que su gasto.

esto me recuerda que wmic es muy poderoso, tanto como para poder hacer:

wmic service where "caption like '%VSS%' and Startmode<>'Disabled'" call ChangeStartmode Disabled

• Ficheros de paginación.

Vale. Ahí ya me ha salido la vena del BOFH y ha petado.

Estoy harto de leer de multitud de «expertos» con rótulo y sin título (o al menos, conocimiento) que hay que desactivar la paginación cuando tienes un SSD. ¿Cualquiera de estos «espertos» se ha parado a pensar que le pasa al kernel de NT cuando no tiene fichero de paginación? Por no hablar de la posibilidad de analizar un volcado de memoria, pero estos mismos «espertos» también aconsejan deshabilitar el volcado, y reducir al mínimo los registros de eventos, y claro, eliminar cualquier posibilidad de un posible análisis de una caída del sistema.

Vale, calma… otro sorbo de esa taza que ya no humea.

Existe una posibilidad alternativa, que necesito comprobar con mayor detalle. La idea es dejar el fichero en la unidad SSD en lo mínimo para las funcionalidades requeridas propias que comento arriba, y poner el resto en un disco, mecánico o no, secundario y auxiliar. No sirven las unidades de red, USB o iSCSI.

Esto lo tengo que estudiar más en profundidad porque tiene más implicaciones. Ya comentaré al respecto en otro artículo.

No creo que sea prudente ni rentable realizar esto, porque el espacio recuperado del SSD será cercano al tamaño de la RAM, pero el impacto en el rendimiento será brutal, y no hay posibilidad real de duplicar el tamaño de la RAM en la gran mayoría de los sistemas, sea por precio, zócalos, soporte de la placa, del micro o del sistema. Vamos, que por lo mismo me compro otro SSD, aunque sea malo para meter ahí la paginación que, por cierto, le pasa lo mismo que a la hibernación, mejora un porrón, pero no me adelanto.

• Servicios de energía y otras configuraciones.

Aquí hay mucho de mitos y leyendas, por lo que empezaré:

– Mito del «High Power Plan»: Bueno, es básico saber que, en cuanto a discos, solo hay dos parámetros en todos los planes que afecten a su comportamiento, el de cuando se apagan por inactividad y uno relacionado con la multimedia, que no se si alguien usa.

Por lo que, en fin, el arranque de un disco mecánico tras la parada y aparcamiento es de un par de segundos, frente al arranque instantáneo de un SSD. Esto val gusto del usuario, pero no hay una justificación clara.

– Mito de la hibernación: La hibernación es el volcado de la memoria completa, incluso el kernel, a disco, y con la posibilidad de restaurar toda la memoria al estado en el que se encontraba al recibir la orden.

Esto funciona. Yo no aconsejaría desactivarlo, puesto que ¿hay alguna razón para hacerlo? Si, el no querer. pero, aun así, el fichero de hibernación se seguirá usando, puesto que sirve para la funcionalidad QuickBoot (FastBoot de Windows 8), y claro, de eso nadie se acuerda de desactivarlo, sirviendo para casi lo mismo. Es el responsable de cerrar todos los programas hasta dejar el sistema mínimo e hibernar dicho sistema.

Recuperar el espacio, que es ligeramente inferior al tamaño de la RAM, no compensa.

– Mito del «No GUI Boot» y mito de «Time to Display a List of Operating Systems»: Aún recuerdo cuando nos hacíamos los guais en Windows 95, 98 y Me, deshabilitando los logos de arranque del sistema… Yo lo hacía por depurar y acceder a otras funciones, claro, pero era la nostalgia, o las semillas de los aficionados a cambiar los logos y banners del sistema.

La idea de evitar que el IPL cargue los logos durante el arranque del sistema, logos, barrita en movimiento, círculos de puntitos… es para evitar la demora en la carga y reducir el tráfico de datos. Puede que ayude en un disco mecánico, pero no en un SSD.

En cuanto a la lista de sistemas, bueno, es posible que algún administrador serio o usuario avanzado, pueda tener en mente usar BCD (el grub de Windows para que se me entienda) para arrancar un sistema alternativo en un disco/partición diferente, imágenes VHD sin necesidad de cargarlas en el hipervisor, o incluso restaurar ficheros hiberfil.sys procedentes de otros equipos, o incluso de depuraciones, cosa que quiero probar.

Por defecto, la lista no se muestra ni tiene plazo de espera (en casos especiales, como reinstalaciones modificadas, puede aparecer este menú en Windows 7). En principio tampoco es excesivamente justificable para un usuario común.

Lo de mito cazado, lo estaba deseando.

Parte 3: Acerca de la defragmentación. La batalla final.

Ale. Gollum contra pollo.

Aquí voy a revelarme. @RFOG, tras hablarlo en el canal, me ha sugerido la literatura siguiente sobre el defragmentado de SSD.

El autor, que tiene bastante de ubuntero para raspis, comenta que TRIM es necesario y el defragmentador en estos casos se comporta como un recolector de basura. Oye mira, es su opinión y hay que respetarla, pero de ahí a establecer canon…

Por supuesto yo tengo la mía.

Empecemos por el concepto «Conoce tu disco».

Mi disco es un Kingston SV300S37A/120G y tiene una esperanza de vida de 64 tb.

Copio de la nota técnica

Total de bytes escritos (TBW) 120GB: 64TB El total de bytes escritos (TBW), se refiere a la cantidad total de datos que se pueden escribir en un SSD para una determinada carga de trabajo, antes que la unidad llegue a su límite de resistencia.)

Muy bien. Entendido, pero ahora necesito algo que evalúe la vida y el estado del disco, y no las mierdas habituales de los servicios crapware que vienen en los equipos OEM… No, ya estoy mayor para eso.

Esta es la imagen del programa que publiqué un día antes de crear este artículo.

¿Que tal esto?

Es un programita freeware que permite analizar todo tipo de unidades, siempre que Windows tenga driver para ello, claro, y que la BIOS sea capaz de manejarlas. Lo dejo por aquí.

Claro. Solo hay que dejar el defragmentador un par de noches, y que VSS y WU hagan de las suyas, para apreciar el crecimiento del valor Total Host Writes.

Es que ni un día, y hay un crecimiento de 30 GB, de una hibernación y un parche de WindowsUpdate, sí, ese.

Por todo esto, y para mí, esta es la configuración que debo dejar.

A partir de aquí, que cada uno se la coja con papel o lo que quiera. Sé que no soy propietario de la verdad suprema.

Parte 4: ¿Linux?

Proximamente, con un artículo completo dedicado.