Portada
mis comunidades
otras secciones
#3:
¿Crear un fichero vacío que poder borrar por si se llena el disco? ¿Todavía no hemos descubierto Nagios y los sistemas de alarma o me he perdido algún detalle?
Comentarios
¿Crear un fichero vacío que poder borrar por si se llena el disco? ¿Todavía no hemos descubierto Nagios y los sistemas de alarma o me he perdido algún detalle?
#2
Yo llevo 4 años con el de modo profesional y estoy encantadísimo, a pesar de que reconozco sus carencias, empezando por el rendimiento1 y terminando por la falta de encriptación nativa.
Por ejemplo, tengo que trabajar con directorios muy grandes (muchos archivos y muy grandes, del orden de 70 GB por directorio), pero en la mayoría de los casos contienen exactamente lo mismo menos unos pocos archivos. Para eso las snapshots son dios.
O, mejor aún (con esto sí que estoy encantado), es que tengo varios discos duros, todos ellos con Btrfs y formando un único disco lógico, que es más o menos lo mismo que se puede conseguir con LVM+ext4, con la salvedad de que cambiar un disco degradado con Btrfs es miles de veces más sencillo y más seguro que cambiarlo con LVM. Incluso si es el disco principal (el que contiene el boot y/o GRUB). También doy fe de ello.
1 A partir de Linux 5.11 el rendimiento se incrementa de forma brutal, y parece que a partir de Linux 5.12 más todavía.
#3 ¿Nagios a estas alturas? ¡Si está obsoleto! Nosotros usamos Prometheus y/o Zabbix con Grafana.
#2 #4 Aquí probando Btrfs para mi seedbox y puedo comentar ciertas ventajas: en un sistema de 32bit como es RaspberryOS (de momento) mola mucho poder montar un RAID de más de 16TB (cosa imposible con otros sistemas de archivos). Como pegas, he notado que el uso de CPU es más elevado y la fragmentación también sube.
#7 Desde e2fsprog 1.43.4 puede realizar una conversión de un EXT4 32bits a 64bits con resize2fs -b [...]
En sistemas con volúmenes grandes esta conversión puede necesitar mucha ram, de varios gigabytes.
#9 Eso no me vale de nada si el kernel que estoy usando es de 32bit. En realidad estaba alargando la situación pensando que no quedaría mucho para el RasperryOS de 64bit, pero no parece que avance mucho. Así que al final tuve que utilizar la única opción viable.
#7 Por curiosidad, ¿cómo montas un RAID en una raspberry? ¿Los discos van por USB? ¿No es un poco lento?
Se que se puede hacer, pero no tengo claro que sea útil realmente.
#24 Si, con discos externos USB. La Raspberry Pi 4 tiene 2 puertos USB3. En teoría (depende que tipo de RAID montes) tendrías el doble de velocidad que con un sólo USB3. Es más que aceptable para un uso doméstico. Luego si lees cosas de estas por ahí verás quejas sobre que los RAID software vía mdadm son "demasiado lentos" y que con Btrfs y su RAID integrado va todo más rápido.
Añado que algunos chismes ARM de estos tienen placas de expansión con conectores SATA directos, incluso se vende alguno con soportes "de tostadora" para dos discos.
#4 sin duda en cuanto a prestaciones es una maravilla. Es un sistema de segunda (o tercera) generación.
Ya llevo tiempo oyendo que por fin es estable y está bien, pero no termina de cuajar.
¿Cómo anda ahora respecto a ZFS? Siempre oí que este tiene mejor rendimiento.
#3 Sí, es muy retorcida la solución. Monitorizas el sistema y te pones una alarma cuando el disco este por debajo de un umbral que consideres peligroso.
Pero vamos, que si hace eso con el disco entiendo que tampoco debe estar controlando memoria, CPU, i/o, red y demás cosas que deberías tener controladas por defecto por lo que pueda pasar, no quieres que te avisen cuando se cae el servidor sino evitar el problema antes de que se produzca.
#5 voy a poner un cat /dev/zero >/dev/null que consuma una CPU para matarlo por si se peta el procesador.
#12 Principiante!!!! /dev/random
Me has dado una idea:
cat /dev/random | sha512sum
De top:
878 root 20 0 90604 3224 2356 R 100,0 0,0 2:55.51 rngd
Y si, como root! No sea que falle
#15 bueno, con /dev/zero te cepillas el 100% exactamente igual.
#16 Yo como cuando he borrado un disco con dd, random va mucho mas lento que zero, no he pensado mas. Directamente me he dicho "exprime mas la CPU"
#17 si dejas a /dev/zero y a /dev/random generar bits durante un tiempo definido el primero engendrará un número muchísimo mayor, de ahí que tardes muchísimo más en machacar un disco con el segundo; pero ambos estarán consumiendo un núcleo completo igualmente mientras estén funcionando. Pruébalo y verás. Yo he utilizado /dev/zero para muchos test de estrés caseros.
#16 Lo se, lo se, pero luego lees lo de los 35 borrados y piensas... me habré quedado corto?
#19 para borrados te aconsejo mejor shred, que está pensado específicamente para eso y tiene varias opciones muy interesantes. /dev/random no es una buena idea porque si agotas la fuente de entropía y un proceso tira de ese dispositivo para alguna tarea se puede quedar bloqueado. Si quieres utilizar dd mejor con /dev/zero o /dev/urandom.
#21 Lo tendré en cuenta, gracias, cuando he usado eso es por discos que he quitado de RAIDs, por errores de bloques e intentado reutilizar para cosas "mundanas y descartables" y probar con eso y badblocks que pasaba antes de darles otro uso. (aparte de ver que me decía SMART, claro)
#3 Aparte, igual es sólo para particiones Ext, pero aunque se te llene el disco, root siempre tiene un cierto espacio reservado cuando se formatea, así que eso de que puede fallar el copiado o borrado de archivos será en otros tipos de particiones.
Con Nagios además puedes ejecutar scripts cuando detecta la falta de espacio, así que no tienes ni que preocuparte tú en mover archivos o borrar cachés
#3 en mi caso el flowd.log de OPNSense, como te descuides se come el disco, y encima es pequeño porque le meti un SSD viejillo, que mejoraba mucho el rendimiento.
#3 Esto es un señor que va por la selva con una cabina telefónica al hombro y se encuentra a otro señor de frente con un yunque en brazos. El señor del yunque pregunta al otro, ¿por qué llevas una cabina?. El otro responde que es para los leones, que si ve uno se mete dentro y espera a salvo a que se canse y se vaya. Éste a su vez le pregunta al oto que por qué lleva un yunque. También es para los leones responde, si veo uno lo suelto y no veas cómo corro.
Pues eso, un yunque de 8GB.
Doy fe de que cuando tienes un disco formateado con Btrfs y este se llena, es un poco infierno recuperarlo. No he probado esta “solución”, pero quizás sea una buena idea echarle un vistazo.
#1 Btrfs, el grafeno de los sistemas de ficheros. El Guti del software.
Un asunto que esta resulto hace mas de 20 años con lvm.
https://wiki.archlinux.org/index.php/LVM_(Espa%C3%B1ol)
Se extienden los volúmenes lógicos cuando se necesite.
Eso lo inventaron los que volaban en globo hace 200 años. Se llama soltar lastre.
Con ext4 (y ext3), cuando se formatea una partición, por defecto se reserva un 5% de bloques que solo puede usar el usuario root cuando se llena el disco. Si se saca ese límite, todavía te queda un 5% de espacio. No es necesario ni LVM ni crear archivos ni nada, sacas la reserva con "tune2fs" y listo.
https://ma.ttias.be/change-reserved-blocks-ext3-ext4-filesystem-linux/
De nada 😉
#0 Why All My Servers Have an 8GB Empty File -> Por qué todos mis servidores tienen un archivo vacío de 8 GB
No hay pregunta. El artículo explica exactamente por qué etc etc y el titular así lo refleja.
Según cómo se mire, el truco puede compararse con llevar piedras en una mochila cuando te persigue un león: si las arrojas al suelo, corres más rápido y escapas más fácilmente… pero podrías no llevarlas desde un principio y quizá así no te perseguiría el león. Para eso algunos atletas entrenan con piedras, para anticiparse a un "escenario peor". https://www.microsiervos.com/archivo/internet/truco-archivo-vacio-8-gb.html ¿Por qué todos mis servidores tienen un archivo vacío de 8 GB? [ENG]
¿Por qué todos mis servidores tienen un archivo va...
brianschrader.com