Preciso de ajuda com alguns discos rígidos que meu sistema fica gravando constantemente 4kb de dados neles por meio de um processo chamado jbd2
. A gravação nunca termina e está deixando meus discos extremamente quentes devido à atividade constante neles.
Primeiro vou contar todo o contexto de como cheguei aqui:
Tenho um laptop antigo executando o servidor Ubuntu que tenho usado como servidor para executar coisas como Nextcloud e, mais recentemente, Jellyfin.
Linux nextcloudlenovo 5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
O armazenamento para minha biblioteca de mídia Jellyfin tem sido um antigo disco rígido de 500 GB formatado usando EXT4 que foi copiado com um trabalho crontab em outro disco rígido de 500 GB. Ambas as unidades foram conectadas usando um dock de unidade USB de 2 baias como este: Inland USB 2 Bay Docking Station
Tudo estava funcionando perfeitamente com meus discos antigos, até que recentemente comprei novos discos rígidos de 8 TB para substituir os de 500 GB, que agora estão cheios.
Como você pode notar, a Docking Station também é uma clonadora de disco, então, antes de instalar meus novos drives no laptop, desconectei a docking station dele e a usei de forma autônoma para clonar os dados de 500 GB para 8 TB. Depois de conectar a docking station ao servidor novamente com os novos drives, o processo parece ter sido bem-sucedido (todos os meus dados estão nos novos drives e posso acessá-los sem problemas).
Com todo esse contexto resolvido...
O problema que estou tendo agora é que assim que meus novos drives são montados, jdb2
constantemente faço gravações de 4kb em cada um deles. Aqui está uma impressão que fiz depois de deixar o drive montado por alguns minutos (sda2-8 é o drive afetado):
Average: UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
Average: 0 1 749.83 209.51 0.08 0 systemd
Average: 0 90 5.53 0.00 0.00 0 kworker/u4:1-flush-8:0
Average: 0 99 0.22 0.00 0.00 0 kworker/u4:3-loop5
Average: 0 303 0.00 19.00 0.00 0 jbd2/sda2-8
Average: 0 375 0.00 14.76 0.00 0 systemd-journal
Average: 107 714 0.00 0.28 0.00 0 rsyslogd
Average: 0 717 1794.02 3103.34 34.04 0 snapd
Average: 0 722 1.12 0.00 0.00 0 udisksd
Average: 0 970 0.00 0.03 0.02 0 nmbd
Average: 0 3682 0.00 0.64 0.00 0 jbd2/sdc1-8
Average: 0 3684 58.33 0.00 0.00 0 ext4lazyinit
Average: 0 3967 1.62 0.00 0.00 0 kworker/u4:0-events_unbound
Average: 0 4793 984.14 71.50 49.24 0 run-httpd
Average: 0 4799 0.03 0.00 0.00 0 nextcloud-fixer
Average: 0 4810 0.36 0.00 0.00 0 start-php-fpm
Average: 0 4816 120.85 0.02 0.00 0 start_mysql
Average: 0 4827 29.23 0.00 0.00 0 nextcloud-cron
Average: 0 4851 0.49 0.00 0.00 0 start-redis-ser
Average: 0 4860 110.75 0.03 0.02 0 renew-certs
Average: 0 5040 36.26 0.05 0.00 0 redis-server
Average: 0 5349 4.76 0.00 0.00 0 mysqld_safe
Average: 0 5580 10.60 133.39 0.06 0 mysqld
Average: 0 5711 32.41 0.03 0.00 0 php-fpm
Average: 0 6365 0.01 0.00 0.00 0 httpd-wrapper
Average: 0 6420 4.42 0.03 0.00 0 httpd
Average: 0 6422 0.08 0.00 0.00 0 httpd
Average: 0 6570 0.73 0.00 0.00 0 php
No começo, pensei que fosse uma duplicata desta pergunta , então adicionei o noatime
ao fstab, e não mudou nada. Então pensei que poderia ser uma duplicata desta outra pergunta , mas não vejo um arquivo em .local/share/gvfs-metadata
. Então estou ficando sem opções e ideias.
Tentei conectar a estação de acoplamento USB em um raspberry pi 4, que é o único outro computador Linux que tenho disponível, para ver se os drives se comportariam de forma diferente (ou seja, não executariam as gravações de 4kb com jdb2), mas lá, assim que eu monto os drives, ext4lazyinit
demora uma ETERNIDADE para rodar. Deixei rodando no pi por mais de 1 hora e ele ainda estava inicializando os drives, enquanto no laptop ext4lazyinit
termina em 1 minuto.
Sou meio novato como administrador de sistemas, então qualquer ajuda é muito bem-vinda!
Se você quiser ainda mais detalhes sobre o laptop, caso isso ajude de alguma forma, aqui está meu dump lscpu:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
Model name: Pentium(R) Dual-Core CPU T4400 @ 2.20GHz
CPU family: 6
Model: 23
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Stepping: 10
CPU max MHz: 2200.0000
CPU min MHz: 1200.0000
BogoMIPS: 4389.61
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_pe
rfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm pti dtherm
Caches (sum of all):
L1d: 64 KiB (2 instances)
L1i: 64 KiB (2 instances)
L2: 1 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0,1
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: KVM: Mitigation: VMX unsupported
L1tf: Mitigation; PTE Inversion
Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Meltdown: Mitigation; PTI
Mmio stale data: Unknown: No mitigations
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Vulnerable
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds: Not affected
Tsx async abort: Not affected