Re: Corrupción de datos

Hola Juan, lo recomendado es no usar el discard en el fstab porque los SSD
manejan mejor el trim en bloques más grandes, y ponerlo en el fstab hace
que cada vez que se haga una operación de borrado el SO ejecute el ltrim.
Por esto es que los fabricantes como Intel recomiendan hacer un fstrim cada
cierto período de tiempo que puede ser una tarea programada en el cron.

Horacio, lo del acceso a esos dispositivos no creo que me los den, además
de que no sé que servidores están usando por detrás pero creo que son DELL.
Y los SSD fue lo que seleccionaron cuando pidieron los servidores, hay 2
servidores físicos dedicados a PostgreSQL que tienen SSD y funcionan
perfectamente y con mucha más carga de trabajo.

El vie., 29 mar. 2019 a las 19:55, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
escribió:

>
> On 30/03/2019 2:36 PM, Juan wrote:
>
> Hola,
> Para aclarar algo puntual UUID=909cea79-2ab4-4812-8eb7-c5csf3fd7c78
> / ext4 discard,errors=remount-ro 0
> Los SSD necesitan el discard porque a diferencia de los discos comunes, no
> sólidos tienen blocks los SSD no h reserva parámetro indica eso.
>
> Hay documentos que dicen que sí otros que no. depende del Vendor y los
> foros.
>
> aquí se siguere que sí. https://wiki.gentoo.org/wiki/SSD
>
> lee esto ( si mira los tiempos de los sync. )
> https://patrick-nagel.net/blog/archives/337
>
> Como lo veo el discard ayuda a mantener la salud de los bloques libres del
> SSD, por naturaleza los bloques borrados no son reusados sin discards lo
> que explica que el Kernel borra los datos de esos bloques para volverlos a
> usar ( es como funcionan los SSD ), los datos son escritos siempre a
> bloques que no tienen datos no bloques que fueron marcados estas libre ( es
> como los indices en postgres ) se marcan los registros como borrados pero
> hay data ahi.
>
> Oracle con los indices se comporta igual por un tema de velocidad no reusa
> los espacios marcados como borrados, por eso en Oracle es unportante
> rehacer los indices de vez en cuando, en postgresql tenermo vacummdb, los
> SSD tienen discard ( pero hay que entender para que sirve, que hace y
> cuando no usarlo ).
>
> En palabras simples, no usar discard en systems que son altamente
> transaccionales, otra razon para no usar SSD en bases de datos. como cache
> son buenos... Prefiero IO accelerators
>
> @Frank, puedes preguntar si te pueden dar acceso a estos dispositivos ?
> https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c03318648&docLocale=en_US
>
> @Frank, por otra parte, realmente necesitas SSD en tu sistema ?
>
>
> El vie., 29 de mar. de 2019 22:20, Horacio Miranda <hmiranda(at)gmail(dot)com>
> escribió:
>
>> Ehhh una de las reglas de Oro que tengo es /var/lib/pgsql se va a una
>> particio dedicada con XFS ( XFS es personal ).
>>
>> tener todo en el / es super peligroso. Sobre todo cuando algo se come el
>> espacio todo se queda sin espacio.
>>
>> Cuando algo falla, falla el FileSystem de todo...
>>
>>
>> Sí esto es cloud, pide que necesitas reinstalar todo en otra maquina por
>> que la maquina actual no te da confianza con la siquiente configuración.
>>
>> / ( 10 G o más ).
>>
>> /var/lib/pgsql ( con el espacio que necesitas para operar ) puedes usar
>> VG Volumen Groups para hacer crecer el volumen logico si necesitas más
>> espacio.
>>
>> ( yo me movería de la configuración actual ), pero ese sería yo.
>> On 30/03/2019 2:00 PM, Frank Alberto Rodriguez Solana wrote:
>>
>> Hola Horacio, este es el fstab:
>>
>> UUID=909cea79-2ab4-4812-8eb7-c5csf3fd7c78 / ext4
>> discard,errors=remount-ro 0 1
>>
>> Pide aclaración de por que esta ese parametro ahí, mientras tanto pide
>> que lo saquen. ( no cacho por que no usar el default ahi ).
>>
>>
>> Lo que me llama la atención es el discard, porque los discos son NVMe
>> SSD, y aunque no sé cómo está la infraestructura de almacenamiento de ese
>> cloud, según lo que he leído en internet el uso del TRIM en el fstab no es
>> recomendado por los fabricantes como Intel:
>>
>> (Al final del PDF viene con letras azules en grande las recomendaciónes,
>> y debajo: IMPORTANT: Do not discard blocks in filesystem usage.)
>>
>>
>> https://www.intel.com/content/dam/support/us/en/documents/ssdc/data-center-ssds/Intel_Linux_NVMe_Guide_330602-002.pdf
>>
>> En cuanto a la ram estos son los resultados:
>>
>> El Doc dice bien claro no usar discard, yo tendría respaldos más
>> regulares.
>>
>> Ignoro si quieres seguir alimentando este thread, esto no es postgresql
>> es más S.O.
>>
>> @Alvaro, sería interesante que postgresql entregue un warning si esta
>> corriendo en un filesystem con el flag discard. ( ignoro como hacer esta
>> sugerencia o sí es posible detectar esto desde el PostgresSQL ).
>>
>> # snap refresh
>> All snaps up to date.
>> # snap changes
>> ID Status Spawn Ready Summary
>> 2 Done today at 00:53 UTC today at 00:53 UTC Refresh all snaps:
>> no updates
>> # snap tasks 2
>> Status Spawn Ready Summary
>>
>> Saludos
>>
>> El vie., 29 mar. 2019 a las 17:57, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
>> escribió:
>>
>>> Que te sale en las lineas anteiores que dispositivo es ?
>>>
>>> sobre la RAM, puede que tengas un problemas de corrupción de RAM, si son
>>> maquinas virtuales estoy asumiendo que usas vmware.
>>>
>>> Tienes instalado los paquetes para linux del vmware ?
>>>
>>>
>>> Mira este thread.
>>> https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682/9
>>>
>>> snap refreshsnap changessnap tasks 30
>>>
>>> Tienes algun filesystem de red ?
>>> /etc/fstab ( revisa los parametros ).
>>>
>>> On 30/03/2019 11:38 AM, Frank Alberto Rodriguez Solana wrote:
>>>
>>> print_req_error: I/O error, dev loop0, sector 0
>>>
>>>