reklama

Velmi časté hrabání na disk

Velmi časté hrabání na disk
« kdy: 11. 03. 2020, 22:03:26 »
Ahoj,
mám takový problém se serverem HP microserver g8. Do serveru jsem přidal nový disk -WD Red Pro, 6TB jako druhý datový disk k puvodnímu WD Green 3TB, systémovému SSD v bay a usb klíčence s /boot. Při té příležitosti jsem upgradoval systém na poslední Debian GNU/Linux 10 (buster) Kernel 4.19.0-8-amd64. Všude je ext4.
Od té doby mi systém, na kterém běží v podstatě jen samba s logitechmedia serverem, co vteřinu hrabe na disk, aniž by někdo tu sambu nebo LMS používal.

V iotops se objevují tyto hlášky:
Kód: [Vybrat]
   13 be/4 root          0.00 B      0.00 B  0.00 %  0.01 % [kworker/0:1-events_freezable_power_]
   13 be/4 root          0.00 B      0.00 B  0.00 %  0.01 % [kworker/0:1-events]
   13 be/4 root          0.00 B      0.00 B  0.00 %  0.01 % [kworker/0:1-events_power_efficient]

Problém jsem googlil ale moudrý z toho nejsem - je to asi v tomto

Kód: [Vybrat]
journal_async_commit mount option seems to mitigate excessive disk write access
Ale co kam napsat/vypnout/zapnout nevim.
Poradil by mi někdo prosím?

To je výpis problematických míst v dmesg jestli to k něčemu je:
Kód: [Vybrat]
[    0.008792] RAMDISK: [mem 0x34ec1000-0x36757fff]
[    0.008796] ACPI: Early table checksum verification disabled
[    0.008862] ACPI: RSDP 0x00000000000F4F00 000024 (v02 HP    )
[    0.008866] ACPI: XSDT 0x00000000F1DE6400 0000B4 (v01 HP     ProLiant 00000002 \xd2?   0000162E)
[    0.008872] ACPI: FACP 0x00000000F1DE6540 0000F4 (v03 HP     ProLiant 00000002 \xd2?   0000162E)
[    0.008876] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32 (20180810/tbfadt-569)
[    0.008878] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm2ControlBlock: 8/32 (20180810/tbfadt-569)
[    0.008880] ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20180810/tbfadt-674)
[    0.008881] ACPI BIOS Warning (bug): Invalid length for FADT/Pm2ControlBlock: 32, using default 8 (20180810/tbfadt-674)
[    0.008884] ACPI: DSDT 0x00000000F1DE6640 001C1A (v01 HP     DSDT     00000001 INTL 20030228)
[    0.008888] ACPI: FACS 0x00000000F1DE4140 000040
[    0.008890] ACPI: FACS 0x00000000F1DE4140 000040
[    0.008892] ACPI: SPCR 0x00000000F1DE4180 000050 (v01 HP     SPCRRBSU 00000001 \xd2?   0000162E)

[    0.065152] ACPI: IRQ0 used by override.
[    0.065153] ACPI: IRQ9 used by override.
[    0.065155] Using ACPI (MADT) for SMP configuration information
[    0.065156] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.065161] ACPI: SPCR: SPCR table version 1
[    0.065161] ACPI: SPCR: Unexpected SPCR Access Width.  Defaulting to byte size
[    0.065164] ACPI: SPCR: console: uart,mmio,0x0,9600
[    0.065167] smpboot: Allowing 64 CPUs, 62 hotplug CPUs

[    1.238477] tg3.c:v3.137 (May 11, 2014)
[    1.242031] uhci_hcd: USB Universal Host Controller Interface driver
[    1.245204] ACPI Warning: SystemIO range 0x0000000000000928-0x000000000000092F conflicts with OpRegion 0x0000000000000920-0x000000000000092F (\SGPE) (20180810/utaddress-213)
[    1.245210] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    1.245233] lpc_ich: Resource conflict(s) found affecting gpio_ich
[    1.254178] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[    1.254242] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[    1.254243] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1

[    4.613519] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
[    4.613912] ACPI: Power Button [PWRF]
[    4.624855] systemd-journald[219]: Received request to flush runtime journal from PID 1
[    4.630792] power_meter ACPI000D:00: Found ACPI power meter.
[    4.630815] power_meter ACPI000D:00: Ignoring unsafe software power cap!
[    4.630819] power_meter ACPI000D:00: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
[    4.631951] version 39.2
[    4.633623] ipmi device interface
[    4.637757] IPMI System Interface driver.
[    4.637777] ipmi_si dmi-ipmi-si.0: ipmi_platform: probing via SMBIOS



reklama


k3dAR

  • *****
  • 1 350
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Velmi časté hrabání na disk
« Odpověď #1 kdy: 12. 03. 2020, 17:28:03 »
ciste k tomu kam pridat mount parametrt, do /etc/fstab, 4sloupec u radku oddilu prislusneho disku, nebo pri rucnim pripojeni "mount -o parametr,parametr2 /dev/co /mnt/kam
(nevim/nezkoumal sem zda je to vhodne reseni, ci jen workaround, pripadne nevhodne)


Re:Velmi časté hrabání na disk
« Odpověď #2 kdy: 12. 03. 2020, 18:38:07 »
Tak jsem to tim docela dojebal, ale opetne vyhozeni journal_async_commit z fstab to spravilo...
Nepomohla by nejaka kontrola/oprava (e2fsck) ext4?
Nebo nejaky tuning (tune2fs)?

Kód: [Vybrat]
[    5.281129] EXT4-fs (sdb1): can't mount with journal_async_commit in data=ordered mode
..
[    5.339634] EXT4-fs (sda2): can't mount with journal_async_commit in data=ordered mode
..
[    5.470573] EXT4-fs (sda1): can't mount with journal_async_commit in data=ordered mode
[    5.577076] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)

e3k

Re:Velmi časté hrabání na disk
« Odpověď #3 kdy: 12. 03. 2020, 18:47:29 »
iste skontrolovat smart a fsck je dobry napad. ale este stale to moze byt:
Kód: [Vybrat]
[    4.624855] systemd-journald[219]: Received request to flush runtime journal from PID 1

Re:Velmi časté hrabání na disk
« Odpověď #4 kdy: 12. 03. 2020, 18:55:38 »
iste skontrolovat smart a fsck je dobry napad. ale este stale to moze byt:
Kód: [Vybrat]
[    4.624855] systemd-journald[219]: Received request to flush runtime journal from PID 1

Ok...   A mel bych s timto udelat co presne, respektive co to znamena?

reklama


Re:Velmi časté hrabání na disk
« Odpověď #5 kdy: 12. 03. 2020, 22:08:44 »
Není to SMR, tedy šindelový disk?

k3dAR

  • *****
  • 1 350
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Velmi časté hrabání na disk
« Odpověď #6 kdy: 12. 03. 2020, 22:24:34 »
Není to SMR, tedy šindelový disk?
Nevyhrozuj :-D nedavno sem byl v soku kdyz nekdo napsal ze "WD Red" (=NAS 24/7) muzou byt prevlecene WD Archive SMR a ze aspon "WD Red Pro" ne, jestli by WD i za Red Pro zacal prvlikat Archive tak potes :-D

Re:Velmi časté hrabání na disk
« Odpověď #7 kdy: 13. 03. 2020, 07:15:31 »
Není to SMR, tedy šindelový disk?
Doufám že ne. Je to WD6003FFBX kdyby to chtěl někdo ověřit.
Nicméně,  problém je možná větší než se zdá. Oba rotační disky jsem umountnul ale hlášky iotops events freezable power atd se objevují stále.  Společně, a to je divné, se zvukem přístupu na rotační disk. Je to možné?
Večer rot. disky projdu a pokud nutno opravim fsck a systém na ssd a flešce přeinstaluju.
Nebo máte jiný nápad?

RDa

  • *****
  • 846
    • Zobrazit profil
    • E-mail
Re:Velmi časté hrabání na disk
« Odpověď #8 kdy: 13. 03. 2020, 10:26:09 »
Zde je reseni:
https://bbs.archlinux.org/viewtopic.php?pid=1817283#p1817283

A o par radku nize je vysvetleno, ze je to spatnym nastavenim kernelu, ktere se lisi od defconfigu.

Re:Velmi časté hrabání na disk
« Odpověď #9 kdy: 13. 03. 2020, 12:05:52 »
Zde je reseni:
https://bbs.archlinux.org/viewtopic.php?pid=1817283#p1817283

A o par radku nize je vysvetleno, ze je to spatnym nastavenim kernelu, ktere se lisi od defconfigu.
Ano, tohle forum jsem nasel, ale reseni v nem bohuzel nevidim.
Je tam:
Kód: [Vybrat]
Well, as per seth advice I have added an udev rule regarding usb autosuspend and the disk began going autosleep. Though those "freezable" threads keep exist, they are seemingly don't disturb storage devices. So I mark this thread solved.
Jake udev pravidlo ohledne autosuspend a kam co mam napsat? :-(

Nebo
Kód: [Vybrat]
The kernel config flag is WQ_POWER_EFFICIENT_DEFAULT and should be off by default. There is a good reason this is off in the kernel defconfig.
Kernel config flag je parametr pri kompilaci, ne? Anebo je to boot option?

Jako boot option:
Kód: [Vybrat]
adding the boot option workqueue.power_efficient=0 resolve the issue on your system?Odpoved
Kód: [Vybrat]
Booting with workqueue.power_efficient doesn't seem to change much:
Nicmene to vyzkousim.

No a nakonec je tam posledni post na ktery jsem upozornoval v prvnim prispevku:
Kód: [Vybrat]
I have been suffering the same issue using since... 4.20 maybe?
journal_async_commit mount option seems to mitigate excessive disk write access
https://wiki.archlinux.org/index.php/ext4
I have yet to try disabling journal altogether.

Ale i tak dik...


e3k

Re:Velmi časté hrabání na disk
« Odpověď #10 kdy: 13. 03. 2020, 13:41:48 »
iste skontrolovat smart a fsck je dobry napad. ale este stale to moze byt:
Kód: [Vybrat]
[    4.624855] systemd-journald[219]: Received request to flush runtime journal from PID 1

Ok...   A mel bych s timto udelat co presne, respektive co to znamena?
ze ti systemd sype journal na disk. teraz je otazka co v tom journaly je. napr. ci ti tam nespamuje nieco DEBUG logmi a pod. skus pozret co v tom journaly vlastne je a kolko toho je.

ByCzech

  • *****
  • 1 742
    • Zobrazit profil
    • E-mail
Re:Velmi časté hrabání na disk
« Odpověď #11 kdy: 13. 03. 2020, 15:38:11 »
Není to SMR, tedy šindelový disk?
Doufám že ne. Je to WD6003FFBX kdyby to chtěl někdo ověřit.

Pokud se dá věřit tomuhle zdroji (zatím orientačně vždy pomohl): https://www.mobibrw.com/2020/22727 (je tam fajn i ta excelová tabulka s parametry hromady disků)

Tak vypadá, že to je PMR disk.

Re:Velmi časté hrabání na disk
« Odpověď #12 kdy: 14. 03. 2020, 10:11:39 »
Tak jsem asi v pérdeli.
Zřejmě vše výše uvedené s hlukem od disku nesouvisí. Dělá to ten WD Pro sám od sebe. Prostě každých 2-5 s trtne, jako by asi parkoval hlavičky nebo zapisoval. Ani nemusí být mountnutý. Je to k zešílení :-( server mám pod pracovním stolem.

Je to nejspíš stejný problém jako popisují zde:

https://community.wd.com/t/wd-red-pro-4-tb-constant-noise-when-idle/180213

Věděl by někdo co s tím? Reklamovat?

Re:Velmi časté hrabání na disk
« Odpověď #13 kdy: 14. 03. 2020, 18:32:26 »
Tak asi částečně vyřešeno.
Disk má defaultně nastaveno APM
Kód: [Vybrat]
# hdparm -B /dev/sdb
/dev/sdb:
 APM_level      = 254

Nastavením např.
Kód: [Vybrat]
# hdparm -B 127 -S 127 /dev/sdb

/dev/sdb:
 setting Advanced Power Management level to 0x7f (127)
 setting standby to 127 (10 minutes + 35 seconds)
 APM_level      = 127

hluk od disku cca po 2 minutách ustane.
Ovšem stačí do disku "ťuknout" třeba fdisk -l a trtká zase pár minut (cca 2)...

Otázka do pléna
Chtěl tenhle nový disk použít jako /home a druhý (původní tichý) disk namapovat jako /home/shared, kde budou blbiny typu filmy a mp3.   
Jelikož budu používat převážně /home/shared (na /home/user mám pouze zálohy uživatelů) tak se mi ten /home probudí vždycky když přistoupím na /home/shared, že jo?

Anebo  - kam mapujete sdílené disky?

ByCzech

  • *****
  • 1 742
    • Zobrazit profil
    • E-mail
Re:Velmi časté hrabání na disk
« Odpověď #14 kdy: 14. 03. 2020, 19:36:16 »
Tak asi částečně vyřešeno.
Disk má defaultně nastaveno APM
Kód: [Vybrat]
# hdparm -B /dev/sdb
/dev/sdb:
 APM_level      = 254

Nastavením např.
Kód: [Vybrat]
# hdparm -B 127 -S 127 /dev/sdb

/dev/sdb:
 setting Advanced Power Management level to 0x7f (127)
 setting standby to 127 (10 minutes + 35 seconds)
 APM_level      = 127

A co si zkusit ještě pohrát s AAM? Viz. hdparm -M


hluk od disku cca po 2 minutách ustane.
Ovšem stačí do disku "ťuknout" třeba fdisk -l a trtká zase pár minut (cca 2)...

Otázka do pléna
Chtěl tenhle nový disk použít jako /home a druhý (původní tichý) disk namapovat jako /home/shared, kde budou blbiny typu filmy a mp3.   
Jelikož budu používat převážně /home/shared (na /home/user mám pouze zálohy uživatelů) tak se mi ten /home probudí vždycky když přistoupím na /home/shared, že jo?

Anebo  - kam mapujete sdílené disky?

Podle mě se bude budit jen zařízení, na které je přístup.

 

reklama