El jue, 28 jul 2022 a las 21:56, Juan Erbes (<jerbes@gmail.com>) escribió:El jue, 28 jul 2022 a las 13:01, Karl García Gestido (<karlggest@gmail.com>) escribió:Hola!Si haces instantáneas, no creas. O si alojas máquinas virtuales etc. Un
sistema con btrfs moderno 100 los pide con facilidad, aunque puede apañarse
con menos.En la partición de Tumbleweed anterior tenía 68 GB y debía estar controlando y borrando los snapshots más viejos para mantenerlo en un 70%.Un apunte:
Hay un bug en baloo (el indexador de Plasma) que hace que cada vez que
reinicias añade una entrada para cada fichero de cada snapshot, como si cada
fichero de cada snapshot fuera uno diferente aunque naturalmente indica la
misma ubicación.
Y es una pena porque yo montaba todo el disco SSD como raíz y otro disco como
"almacén", al que enlazaba después las carpetas Documentos, Descargas, etc.
Así que ahora o bien monto /home directamente en el otro disco o bien
configuro baloo para que evite la raíz del usuario /home/<usuario>.¿No se supone que baloo solamente opera en la partición de usuario solamente?
Otra consideración respecto a usar SSD para swap. Naturalmente, usar swap en
un SSD es una gran idea en términos de rendimiento. Sin embargo, dado que la
durabilidad de SSD sigue siendo inferior, para usos de swap muy esporádicos
puede ser un problema. SSD sigue siendo mejor para uso de solo lectura (o de
casi solo lectura)."Mal de muchos, consuelo de tontos""Puede" instalarse con 20GiB+btrfs, pero no es que sea una buena idea. A ver, cuanto más pequeña sea la partición más probable es que tengas que ajustar el uso de snapper manualmente y es posible que no quieras hacer eso. Lo suyo son al menos 70GiB y 100 no es mucho. Si tienes máquinas virtuales, irán en /var y necesitarás el espacio que ocupen.Intenté cambiar el tamaño de las particiones, pero no me dejaba como en las versiones anteriores del particionador y tendría que haber hecho todo manual arrancando desde cero, con la historia de la partición GPT y demás.Esta es la documentación actual:Bueno, es un poco un rollo pero en el peor de los casos te cargas /home, reduces el tamaño de la raíz y creas /home de nuevo, tampoco es el fin del mundo xdTengo de respaldo el /home viejoFinalmente, lo dejé con la propuesta de 165/300. Veré si puedo modificarlas después.Con la primera puedes hacer lo que quieras. Dando por sentado que has usado los 300 para /home con xfs, no. Puedes reducir la raíz, crear una partición en el hueco y montarla en cualquier lugar, pero no añadirla a /home (btrfs soporta esas cosas, como LVM, pero xfs que yo sepa no).Salud!!nota: he intentado contestar al correo anterior con kmail y por lo que sea no he podido. Así que no descarto que realmente lleguen duplicados, lo siento.Lo que hice fue:zypper rm btrfsmaintenance
To prevent it from being reinstalled:
zypper al btrfsmaintenance
(también borre el script manualmente)
y
systemctl enable fstrim.timerProbé manualmente:
fstrim -Av
/home: 249,8 GiB (268243951616 bytes) recortados en /dev/sdb3
/: 156,2 GiB (167762698240 bytes) recortados en /dev/sdb2Con respecto al swap, me activó el del otro disco duro.
Finalmente, llegó LA HORA DE LA VERDAD, lo que dicen los testeos con hdparm:SSD SATA3:
hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 9050 MB in 2.00 seconds = 4530.29 MB/sec
Timing buffered disk reads: 1140 MB in 3.00 seconds = 379.69 MB/sec
/dev/sdb:
Timing cached reads: 8910 MB in 2.00 seconds = 4460.52 MB/sec
Timing buffered disk reads: 1140 MB in 3.00 seconds = 379.44 MB/sec
HDD En SATA2
/dev/sda:
Timing cached reads: 8848 MB in 2.00 seconds = 4429.44 MB/sec
Timing buffered disk reads: 546 MB in 3.01 seconds = 181.52 MB/sec
HDD En SATA3
hdparm -tT /dev/sdc
/dev/sdc:
Timing cached reads: 9426 MB in 2.00 seconds = 4719.29 MB/sec
Timing buffered disk reads: 552 MB in 3.00 seconds = 183.82 MB/sec
-t Perform timings of device reads for benchmark and comparison purposes. For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory. This displays the speed of reading through the buffer cache to the disk without any prior caching of data. This measurement is an indication of how fast the drive can sustain sequential data reads under Linux, without any filesystem overhead. To ensure accurate measurements, the buffer cache is flushed during the processing of -t using the BLKFLSBUF ioctl.
-T Perform timings of cache reads for benchmark and comparison purposes. For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory. This displays the speed of reading directly from the Linux buffer cache without disk access. This measurement is essentially an indication of the throughput of the processor, cache, and memory of the system under test.Es cierto que en el SSD las 2 particiones estaban montadas y activas como sistema, swap en sda y la antigua partición de usuario linkeada en sdc.Otro detalle, es que con discos convencionales no se aprecia la diferencia entre SATA2 y SATA3.Tal como sospechaba al comienzo, un SSD al estar restringido a una interfaz SATA3 solamente duplica la velocidad de un disco convencional (WD Blue 1TB y Toshiba DT01ACA200, 2 TB)Por ese motivo que ya sospechaba compré un SSD de solamente 500 GB, porque la diferencia real está utilizando una interfaz NVME o PCIe 4x de los actuales M.2, que llegan a dar valores de transferencia 9 veces más altos que el actual SSD SATA3.Con respecto al tiempo de carga del sistema, es cierto que desde la pulsación del botón de arranque tarda unos 15 segundos hasta que aparece la pantalla de grub, donde prácticamente no interviene la velocidad del SSD, pero al darle el enter a grub, allí si, son otros 15 segundos en la carga del sistema hasta la pantalla del ingreso de clave de usuario y realmente se ve la diferencia allí.