Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: ZAJDAN 08. 06. 2020, 12:50:35
-
Ahoj,
měl jsem podezdření, že je poškozen Disk, ale mám informace, že přes iDrac vidí disk zdravý.
Každopádně mne znepokojuje tento výstup:
[Mon Jun 1 14:15:19 2020] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[Tue Jun 2 14:15:19 2020] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[Tue Jun 2 14:15:21 2020] BTRFS info (device dm-0): relocating block group 99182706688 flags system|dup
[Tue Jun 2 14:15:21 2020] BTRFS info (device dm-0): relocating block group 99216261120 flags system|dup
[Tue Jun 2 14:15:21 2020] BTRFS info (device dm-0): relocating block group 99249815552 flags system|dup
[Tue Jun 2 14:15:21 2020] BTRFS info (device dm-0): relocating block group 99283369984 flags system|dup
[Tue Jun 2 14:15:21 2020] BTRFS info (device dm-0): relocating block group 99316924416 flags system|dup
[Tue Jun 2 14:18:22 2020] sd 0:0:0:0: timing out command, waited 180s
[Tue Jun 2 14:18:22 2020] scsi_io_completion: 53 callbacks suppressed
[Tue Jun 2 14:18:22 2020] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Tue Jun 2 14:18:22 2020] sd 0:0:0:0: [sda] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Jun 2 14:18:22 2020] print_req_error: 53 callbacks suppressed
[Tue Jun 2 14:18:22 2020] print_req_error: I/O error, dev sda, sector 113114912
[Tue Jun 2 14:18:22 2020] BTRFS warning (device dm-0): failed to trim 1 block group(s), last error -5
[Tue Jun 2 14:21:22 2020] sd 0:0:0:0: timing out command, waited 180s
[Tue Jun 2 14:21:22 2020] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Tue Jun 2 14:21:22 2020] sd 0:0:0:0: [sda] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Jun 2 14:21:22 2020] print_req_error: I/O error, dev sda, sector 86159360
[Tue Jun 2 14:21:22 2020] BTRFS warning (device dm-0): failed to trim 1 device(s), last error -5
[Tue Jun 2 19:45:54 2020] httpd[5803]: segfault at 7f31a940b600 ip 00007f31929a6855 sp 00007f3188c58cf0 error 4
[Wed Jun 3 14:15:20 2020] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[Thu Jun 4 14:15:19 2020] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[Fri Jun 5 14:15:18 2020] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[Sat Jun 6 14:15:19 2020] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[Sun Jun 7 14:15:19 2020] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)a rád bych věděl co se tam děje špatně.
Dell server(SSD, Raid5)->VMWare(SUSE,btrfs)
jste zde někdo znalejší s BTRFS?
-
[Tue Jun 2 14:18:22 2020] sd 0:0:0:0: timing out command, waited 180s
[Tue Jun 2 14:18:22 2020] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Tue Jun 2 14:18:22 2020] sd 0:0:0:0: [sda] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Jun 2 14:18:22 2020] print_req_error: I/O error, dev sda, sector 113114912
[Tue Jun 2 14:18:22 2020] BTRFS warning (device dm-0): failed to trim 1 block group(s), last error -5
[Tue Jun 2 14:21:22 2020] sd 0:0:0:0: timing out command, waited 180s
[Tue Jun 2 14:21:22 2020] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Tue Jun 2 14:21:22 2020] sd 0:0:0:0: [sda] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[Tue Jun 2 14:21:22 2020] print_req_error: I/O error, dev sda, sector 86159360
[Tue Jun 2 14:21:22 2020] BTRFS warning (device dm-0): failed to trim 1 device(s), last error -5
Tyhle řádky celkem jednoznačně říkají, že selhává zařízení sda. Pravděpodobně během TRIMu. S btrfs nesouvisí.
-
Tyhle řádky celkem jednoznačně říkají, že selhává zařízení sda. Pravděpodobně během TRIMu. S btrfs nesouvisí.
podle iDrac by disky měli být OK. Měl bych podezřívat nastavení backendu VMWare+Veeam?
-
to máte ten TRIM zapnutej jak na hostu tak i na virtuálce (tam imho nemá co dělat - mohl by to i být zdroj potíží...)?
-
to máte ten TRIM zapnutej jak na hostu tak i na virtuálce (tam imho nemá co dělat - mohl by to i být zdroj potíží...)?
nechci házet macháčka, a přiznám se, že s SSD mám malé zkušenosti a ani by mne nenapadlo jít po TRIMu.
Na guestovi/virtuálu se zdá být zaplý
systemctl list-units --type=service |grep fstrim
fstrim.service loaded activating start start Discard unused blocksprověřím jak je tomu na hypervisoru. Každopádně bych rád věděl, zda je opravdu vhodné ho na virtuálce vypínat.
děkuji
-
to máte ten TRIM zapnutej jak na hostu tak i na virtuálce (tam imho nemá co dělat - mohl by to i být zdroj potíží...)?
Proc by mel byt spravne tunelovanej a premapovanej trim problem?
-
pokud hypervisor ESXi nepodporuje TRIM, má vůbec smysl ho na guestovi zapínat?
-
pokud hypervisor ESXi nepodporuje TRIM, má vůbec smysl ho na guestovi zapínat?
TRIM nejde explicitne zapnout, jde jenom nevypnout.
Kdyz nektera vrstva nepropaguje spravne trim a/nebo jeho metadata, tak mate rekl bych dosti rozbity system. Tj. muzete mit tunelovany ATA pakety k identifikaci disku, ktere prozradi ze trim funguje, ale kdyz tohle projde, tak proc by hypervisor aktivne filtroval TRIM prikazy? Nicmene, nestane se zadna katastrofa, kdyz guest si bude myslet, ze trim prosel.
Opacny pripad je, ze metadata nebudou propagovana, ale TRIM prikazy by fungovaly. Ale zde vam "zapnuti" nepomuze, protoze aby trim fungoval, jsou potreba ty informace - zejme jaka je granularita trimu (512, 4K, 1M?) a maximalni velikost mazatelne casti v jednom prikazu (nekdy 1M, nekdy 2G)... viz prikaz
# lsblk --discard /dev/sd?
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 2G 0
├─sda1 0 512B 2G 0
├─sda2 0 512B 2G 0
└─sda3 0 512B 2G 0
Nejhorsi varianta co muze byt je, ze se tuneluji spatne parametry nebo premapovani adres je provedeno spatne. Takze pak disk samozrejme smaze neco, co guest vubec mazat nechtel. Ale tohle spada do kategorie rozbitej/vadnej system.
Samotna technologie TRIM za vase ztracena data nemuze. Vzdy je tam nejaky prvek, ktery je implementovan spatne.. a ze takovych nepovedenych firmwaru je.. staci se podivat na blacklist v jadre :)
-
podival jsem se na status fstrim.service a evidentně jde vidět, že jsou opravdu trable s tím TRIMem
systemctl status fstrim.service
● fstrim.service - Discard unused blocks
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled)
Active: activating (start) since Mon 2020-06-08 22:32:20 CEST; 8min ago
Main PID: 4461 (fstrim)
Tasks: 1 (limit: 512)
CGroup: /system.slice/fstrim.service
└─4461 /usr/sbin/fstrim -av
Jun 08 22:32:20 suse systemd[1]: Starting Discard unused blocks...
Jun 08 22:38:20 suse fstrim[4461]: fstrim: /home: FITRIM ioctl failed: Input/output error
trimuje se jak na /dev/sda tak i na /dev/sdb
lsblk --discard /dev/sda
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 4K 2G 0
└─sda1 0 4K 2G 0
├─system-root 0 4K 2G 0
├─system-swap 0 4K 2G 0
└─system-home 0 4K 2G 0
-
každopádně čím více o TRIMu čtu, tak se domnívám, že vypínat TRIM na guestovi je nesmysl, protože to naprosto zruší podstatu té funkce.
Modern Operating Systems use the TRIM command to inform the SSD controller when they delete a block so that it can add the associated Flash cell to its free list and knows that it can be overwritten.
jenom samotný OS ví co smazal a tuto informaci pošle řadiči.
-
další věc co zjišťuji že u XFS(které na hodně partitions mám) bude potřeba úprava v fstab, přidáním option 'discard'
https://xfs.org/index.php/FITRIM/discard
-
Doporucovanou technikou je spise nechat fstab na pokoji a zapnout trimovani v klidnych dobach (protoze discard ve fstab zbytecne snizuje vykon disku) - neco jako "systemctl enable fstrim.timer" u centosu