tsc_chazz's questions

Temos um sistema que é usado para um banco de dados GIS (com Postgres como o mecanismo subjacente) que está usando uma matriz RAID 5 de software de SSDs Samsung EVO870 SATA de 4x2 TB como unidade de banco de dados. Há um script de backup noturno que despeja as tabelas em um diretório temporário local, GZipa-as e as transfere para uma máquina separada (com mv). Normalmente o backup começa às 18h30 e vai até as 05h00; sim, é um backup grande. Há cerca de um mês, o sistema externo caiu e, portanto, omvstep parou de funcionar e a área de armazenamento temporário foi preenchida com arquivos não movidos. Depois que o sistema externo foi reparado, notamos que a área temporária estava cheia e excluímos tudo dela - cerca de 3,5 TB de arquivos. Cerca de duas semanas atrás, notamos que o backup diário não estava sendo concluído até 1000. Minha suspeita é que as coisas ficaram mais lentas porque o diretório temporário, embora apagado, não está sendo removido, então quando temos que escrever um novo arquivo temporário como parte do backup, temos que limpar os blocos SSD antes de reescrevê-los.

fstrim -avnão imprime nada, o que sugere que nenhum sistema de arquivos está dizendo que tem suporte para DISCARD.

Este sistema tem LVM no topo da matriz RAID. O banco de dados e os diretórios temporários estão em um sistema de arquivos ext4 (era ext2, mas coisas aconteceram) em seu próprio LV montado em /db; fstrim -v /dbrelatórios File system does not support DISCARD.

Versão do SO: Debian Linux 8 (jessie), Linux 3.16.0-4-amd64 x86_64

Informações do RAID:

root@local-database:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sda1[7] sdd1[4] sdc1[5] sdb1[6]
      5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 1/2 pages [4KB], 524288KB chunk

root@local-database:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Sun Dec 27 17:55:35 2015
     Raid Level : raid5
     Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Aug  8 14:07:27 2023
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : local-database:0  (local to host local-database)
           UUID : 18d38d9a:daaa0652:8e43a020:133e5a4f
         Events : 53431

    Number   Major   Minor   RaidDevice State
       7       8        1        0      active sync   /dev/sda1
       6       8       17        1      active sync   /dev/sdb1
       5       8       33        2      active sync   /dev/sdc1
       4       8       49        3      active sync   /dev/sdd1

Informações sobre o LV específico usado para o banco de dados e áreas temporárias:

  --- Logical volume ---
  LV Path                /dev/MainDisk/postgres
  LV Name                postgres
  VG Name                MainDisk
  LV UUID                TpKgGe-oHKS-Y341-029v-jkir-lJn8-jo8xmZ
  LV Write Access        read/write
  LV Creation host, time local-database, 2015-12-27 18:04:04 -0800
  LV Status              available
  # open                 1
  LV Size                4.78 TiB
  Current LE             1251942
  Segments               4
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     6144
  Block device           253:2

Informações do PV:

root@local-database:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md0
  VG Name               MainDisk
  PV Size               5.46 TiB / not usable 2.50 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              1430699
  Free PE               121538
  Allocated PE          1309161
  PV UUID               N3tcTa-LBw2-D8gI-6Jg4-9v3T-KWn2-5CDVzK

Eu realmente gostaria de reduzir os tempos de backup para 11 horas, para que não colidissemos com os tempos reais de trabalho. Existe algo nas opções TRIM que eu possa fazer aqui ou há algo mais que eu perdi? Eu verifiquei se o banco de dados não aumentou repentinamente nenhuma nova tabela ou cresceu 50% da noite para o dia; não há problemas de conexão de rede, não houve nada estranho que tenha acontecido com a rede ou o servidor externo pouco antes de começarmos a levar 16 horas para fazer o backup, pelo que posso ver. Há mais alguma coisa que estou perdendo?

Editar devido aos comentários: os SSDs reais têm apenas um ano e meio, substituindo os SSDs originais de 250 GB em abril de 2022. (Ficou sem espaço e a matriz RAID, LV e sistema de arquivos foram expandidos no local.) Estamos usando RAID de software, Linux de padrão ósseo com mdadm.

Edite em resposta aos comentários:

root@local-database:~# lsblk -d
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda    8:0    0  1.8T  0 disk
sdb    8:16   0  1.8T  0 disk
sdc    8:32   0  1.8T  0 disk
sdd    8:48   0  1.8T  0 disk

root@local-database:~# cat /sys/module/raid456/parameters/devices_handle_discard_safely
N

root@local-database:~# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD FX(tm)-8320 Eight-Core Processor
Stepping:              0
CPU MHz:               1400.000
CPU max MHz:           3500.0000
CPU min MHz:           1400.0000
BogoMIPS:              7023.19
Virtualization:        AMD-V
L1d cache:             16K
L1i cache:             64K
L2 cache:              2048K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7

De acordo com um artigo vinculado por Nikita Kyprianov nos comentários abaixo, o Samsung EVO 870s tem sérios problemas com hardware AMD, o que claramente é. Então isso parece ser isso. Acho que teremos que conviver com isso...

Este é um sistema Linux Mint 21.1 x64, que ao longo dos anos teve discos adicionados a matrizes RAID até que agora temos uma matriz de 10 3 TB e uma matriz de 5 6 TB. Quatro HDs saíram dos arrays, dois de cada, aparentemente como resultado da falha de um controlador. Substituímos os controladores, mas isso não restaurou o funcionamento dos arrays. mdadm --assemblerelatórios incapazes de iniciar qualquer array, discos insuficientes (com dois falharam em cada um, não estou surpreso); mdadm --runrelata erro de E/S (o syslog parece sugerir que isso ocorre porque não pode iniciar todas as unidades, mas não há indicação de que tentou iniciar as duas aparentemente infelizes), mas ainda posso discos com falha e eles parecem absolutamente mdadm --examinenormais . Aqui está a saída de uma unidade funcional:

mdadm --examine /dev/sda
/dev/sda:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 829c0c49:033a810b:7f5bb415:913c91ed
           Name : DataBackup:back  (local to host DataBackup)
  Creation Time : Mon Feb 15 13:43:15 2021
     Raid Level : raid5
   Raid Devices : 10

 Avail Dev Size : 5860268976 sectors (2.73 TiB 3.00 TB)
     Array Size : 26371206144 KiB (24.56 TiB 27.00 TB)
  Used Dev Size : 5860268032 sectors (2.73 TiB 3.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=944 sectors
          State : clean
    Device UUID : 6e072616:2f7079b0:b336c1a7:f222c711

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Apr  2 04:30:27 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 2faf0b93 - correct
         Events : 21397

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 9
   Array State : AAAAAA..AA ('A' == active, '.' == missing, 'R' == replacing)

E aqui está a saída de uma unidade com falha:

mdadm --examine /dev/sdk
/dev/sdk:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 829c0c49:033a810b:7f5bb415:913c91ed
           Name : DataBackup:back  (local to host DataBackup)
  Creation Time : Mon Feb 15 13:43:15 2021
     Raid Level : raid5
   Raid Devices : 10

 Avail Dev Size : 5860268976 sectors (2.73 TiB 3.00 TB)
     Array Size : 26371206144 KiB (24.56 TiB 27.00 TB)
  Used Dev Size : 5860268032 sectors (2.73 TiB 3.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=944 sectors
          State : clean
    Device UUID : d62b85bc:fb108c56:4710850c:477c0c06

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Apr  2 04:27:31 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : d53202fe - correct
         Events : 21392

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 6
   Array State : AAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)

Editar: Aqui está o relatório --examine da segunda unidade com falha; como você pode ver, ele falhou ao mesmo tempo em que todo o array caiu fora de linha.

# mdadm --examine /dev/sdl
/dev/sdl:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 829c0c49:033a810b:7f5bb415:913c91ed
           Name : DataBackup:back  (local to host DataBackup)
  Creation Time : Mon Feb 15 13:43:15 2021
     Raid Level : raid5
   Raid Devices : 10

 Avail Dev Size : 5860268976 sectors (2.73 TiB 3.00 TB)
     Array Size : 26371206144 KiB (24.56 TiB 27.00 TB)
  Used Dev Size : 5860268032 sectors (2.73 TiB 3.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=944 sectors
          State : clean
    Device UUID : 35ebf7d9:55148a4a:e190671d:6db1c2cf

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Apr  2 04:27:31 2023
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : c13b7b79 - correct
         Events : 21392

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 7
   Array State : AAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)

A segunda matriz, 5x6TB, caiu dois minutos depois, quando dois discos foram encerrados. Os dois discos com falha nesta matriz e os dois na outra matriz, todos conectados a uma única placa controladora SATA de 4 portas que agora foi substituída.

A principal coisa que acho interessante sobre isso é que a unidade com falha parece se relatar como viva, mas mdadmnão concorda com isso. journalctlnão parece remontar a 2 de abril, então talvez não consiga descobrir o que aconteceu. Alguém tem alguma idéia sobre o que posso fazer para trazer essa fera de volta online?

Estou tentando fazer com que o SMTP-AUTH funcione em uma máquina Mint Linux 20.2 e estou tendo problemas para fazer a autenticação acontecer. Eu instalei o Cyrus sasl2 e aparentemente configurei corretamente - testsaslauthd -u <user> -p <password> -s smtpretorna 0: OK "Success."Mas quando tento enviar e-mail do meu cliente usando as mesmas credenciais, o sendmail não pode autenticar. O que é curioso para mim é que quando eu uso testsaslauthdentradas são geradas no meu log de autenticação, mas quando o Sendmail tenta, não há nada. Tentar usar a testsaslauthdpartir de um contexto não raiz também resulta em nenhuma entrada de autenticação, o que me leva a acreditar que sendmailnão tem permissão suficiente para se conectar ao daemon sasl ou que não sabe onde está esse pipe e está adivinhando errado . Então, acho que a questão é: como sendmailencontrar esse cachimbo e quem está sendo quando faz isso?