HDD spint up om de zoveel dagen

[blackmage2v]

Mijn vraag
Ik heb een Odroid H4+ met daarin een SSD en 2x een HDD Toshiba MG07ACA14TE (512e). De ene HDD is voor data wat af en toe benaderd wordt en de andere is voor backup/parity. Standaard staan deze HDD's in standby mode en worden alleen actief 's nachts voor een paar jobs of wanneer er overdag iets nodig is.

Het is me opgevallen dat beide HDD's eens per zoveel (13/14/15) dagen actief worden en voor een paar dagen blijven draaien. Daarna gaan ze gewoon weer in standby mode en is er niks aan de hand. Ik begrijp niet waar dit vandaan komt of wat dit triggert. Vannacht is bijv. sda actief geworden. HDPARM toont de status ook ineens active/idle, terwijl dit normaal active of idle is. Ik heb een keer met testen sdb ontkoppeld voor een dag, waardoor deze nu een dag later in de active/idle modus schiet. Ik kan dus met zekerheid zeggen dat komende nacht sdb ook in active/idle modus schiet.

Heeft iemand toevallig een idee wat dit kan triggeren? Of wat de schijven aan het doen zijn? Ik heb al flink wat gezocht op Internet, maar ik kan niks vinden wat hier op lijkt.

Relevante software en hardware die ik gebruik
Odroid H4+ met Debian
HDD Toshiba MG07ACA14TE (512e) - EXT4 geformatteerd

Wat ik al gevonden of geprobeerd heb
Fatrace -c levert niks op
Met iotop -a zie ik wel jbd2/dm-0-8, maar deze draait volgens mij altijd.
Ik heb geen cronjob aangemaakt wat dit triggert.

[Hero of Time]

Kijk eens met smartctl wanneer de laatste short en long test zijn gedraaid. Dat zou het uit zichzelf moeten doen als onderdeel van de hele SMART functionaliteit, dat zit in de schijf zelf gebakken. Het is dus mogelijk dat de schijf hiervoor wakker wordt.

Het kan ook komen door wat file system zaken. Je zegt niet welke je gebruikt, dus dat is gissen.

[blackmage2v]

Beide schrijven zijn EXT4 geformatteerd.

Dit is de output van de smartctl -a:

code:

smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-28-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba MG07ACA... Enterprise Capacity HDD
Device Model:     TOSHIBA MG07ACA14TE
Serial Number:    83X0A04XF94G
LU WWN Device Id: 5 000039 cb8d15f4d
Firmware Version: 0104
User Capacity:    14,000,519,643,136 bytes [14.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Feb 28 21:06:35 2025 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x84) Offline data collection activity
                    was suspended by an interrupting command from host.
                    Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        (  120) seconds.
Offline data collection
capabilities:            (0x5b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   2) minutes.
Extended self-test routine
recommended polling time:    (1344) minutes.
SCT capabilities:          (0x003d) SCT Status supported.
                    SCT Error Recovery Control supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       7701
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       456
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   092   092   000    Old_age   Always       -       3427
 10 Spin_Retry_Count        0x0033   100   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       117
 23 Helium_Condition_Lower  0x0023   100   100   075    Pre-fail  Always       -       0
 24 Helium_Condition_Upper  0x0023   100   100   075    Pre-fail  Always       -       0
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       43
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       486
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       30 (Min/Max 10/36)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       117440513
222 Loaded_Hours            0x0032   099   099   000    Old_age   Always       -       569
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       580
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

[blackmage2v]

ik heb even een short test gedaan, dit is het resultaat:

code:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      3427         -

[blackmage2v]

Ik heb ook nog een Long test gedaan:

code:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      3462         -
# 2  Short offline       Completed without error       00%      3427         -

Zoals voorspeld was afgelopen weekend de andere HDD ook gaan draaien. Deze heeft wel een stuk korter gedraaid. Inmiddels zijn beide schijven weer in standby.

@Hero of Time Weet je toevallig, of dit gedrag voorkomt voor bij Ext4 of überhaupt herkenbaar is bij hdd's?

[Hero of Time]

Sorry, ik zit helemaal niet in die technische hoek. Wat ik wel kan doen, is dit topic naar Opslag en Backup verplaatsen, wellicht weet men daar meer over wat er gaande is. Als je overigens weet wanneer de schijf actief wordt kan je altijd nog in de logs kijken wat er mogelijk gestart wordt rond die tijd.

[blackmage2v]

@Hero of Time Ja, lijkt me een goed plan. Thanks

[Renault]

Je SMART tabel ziet er prima uit, daar mankeert niets aan en er is helemaal niets mis.
Een harddisk wordt alleen wakker als er iets aan wordt gevraagd.
Dus óf het apparaat waar de harddisk in zit zelf, óf een aangesloten rechthebbend apparaat (je pc?) Vráágt iets aan die harddisk.
Je zou op het moment dat de harddisk opspint, bv. eens in Taakbeheer of in systemlogs kunnen kijken welk proces exact op dat moment actief werd: zo vind je op welk verzoek de harddisk actief werd.

[PD2JK]

Zitten ze in een RAID array?
Scrubbing job misschien?

[blackmage2v]

Renault schreef op maandag 3 maart 2025 @ 20:20:
Je SMART tabel ziet er prima uit, daar mankeert niets aan en er is helemaal niets mis.
Een harddisk wordt alleen wakker als er iets aan wordt gevraagd.
Dus óf het apparaat waar de harddisk in zit zelf, óf een aangesloten rechthebbend apparaat (je pc?) Vráágt iets aan die harddisk.
Je zou op het moment dat de harddisk opspint, bv. eens in Taakbeheer of in systemlogs kunnen kijken welk proces exact op dat moment actief werd: zo vind je op welk verzoek de harddisk actief werd.

Ik zal eens kijken of ik iets in de logging kan vinden op het moment dat het speelt.

Enige wat ik met zekerheid weet, is dat rond de 13e straks dit weer voor gaat komen. In de nacht draaien wat scripts en nadat de schijf uit standby is, blijft deze dus draaien voor een dag of 2 en kan niet in slaapstand komen. Het vreemde is dan ook, dat als ik de scripts niet zou draaien, de hdd ook gewoon in slaapstand blijft. Tot deze wakker wordt gemaakt en deze vervolgens "iets" gaat doen.

PD2JK schreef op maandag 3 maart 2025 @ 20:25:
Zitten ze in een RAID array?
Scrubbing job misschien?

Nee, geen raid. Ik heb wel Snapraid en 's nachts draait Snapraid-AIO. Dit script doet wel scrubbing, maar alleen een klein percentage.

[blackmage2v]

We hebben inmiddels weer 1 van de 2 schijven die "iets" aan het doen is. Ik kom er maar niet achter wat het kan zijn:

code:

iotop -a

Geen resultaat. Had nog het idee dat het mogelijk jbd2 kon zijn, maar helaas was dit het niet.

code:

blktrace

8,0    3        3     2.016189910 448224  D   N 0 [kworker/3:1]
  8,0    3        4     2.016213357    31  C   N [0]

geen resultaat. Voor zover ik kan inschatten betekent deze regel als output niks.

code:

iostat

geen resultaat

code:

fatrace -c

geen resultaat

code:

lsof | grep sda

geen resultaat

Ik heb inmiddels ook Cockpit geïnstalleerd. Helaas ook hier in de storage monitoring komt er niks voorbij. Ook een test gedaan met Beszel, maar helaas ook niks.

Enige wat me is opgevallen, is dat wanneer dit speelt, hdparm de status "Active/Idle" gebruikt. Normaal geeft hdparm wel netjes enkelvoudig de status Active, Idle of Standby aan.

Heeft er iemand een idee wat het kan zijn, of wat ik eventueel nog kan doen qua testen? Ik begin een beetje te neigen naar een bug in Ext4. Ik wil binnenkort even testen met een van de hdd's om te zetten naar XFS en kijken of dit probleem dan nog steeds speelt.

[MartinMeijerink]

Zijn ze standaard gemount, of worden ze gemount als het gebeurt?
En wat zegt

ps -ef|grep ext4

[blackmage2v]

MartinMeijerink schreef op maandag 31 maart 2025 @ 19:33:
Zijn ze standaard gemount, of worden ze gemount als het gebeurt?
En wat zegt

ps -ef|grep ext4

Ja, de schijven zijn standaard gemount. Dit is in mijn fstab file:

code:

UUID=XXXXXXXXXXXXXX /data/sda1    ext4    defaults,noatime,acl    0       0
UUID=XXXXXXXXXXXXXX /data/sdb1    ext4    defaults,noatime,acl    0       0

code:

ps -ef|grep ext4
root         244       2  0 Mar30 ?        00:00:00 [ext4-rsv-conver]
root         665       2  0 Mar30 ?        00:00:00 [ext4-rsv-conver]
root         683       2  0 Mar30 ?        00:00:00 [ext4-rsv-conver]
root         684       2  0 Mar30 ?        00:00:00 [ext4-rsv-conver]
root      477205  331148  0 19:34 pts/1    00:00:00 grep ext4

Kan het die ext4-rsv-conver zijn?

[MartinMeijerink]

Ik zou ze standaard geunmount laten (als jouw use case dat toelaat) en alleen mounten als het nodig is. En anders met

ps -ef --sort=start_time

kijken wat er net gestart is als ze het weer doen (die laatste optie is alleen voor het sorteren op datum, zodat alle processen netjes chronologisch worden weergegeven)

En je had sdb voor een dag ontkoppeld, bedoel je geunmount? Dan zou ik ook aan ext4-rsv-conver denken...
Wellicht lost het alleen mounten als het nodig is het op, en anders lijkt testen met een ander fs me dan ook een logische volgende stap.

[blackmage2v]

MartinMeijerink schreef op maandag 31 maart 2025 @ 20:08:
Ik zou ze standaard geunmount laten (als jouw use case dat toelaat) en alleen mounten als het nodig is. En anders met

ps -ef --sort=start_time

kijken wat er net gestart is als ze het weer doen (die laatste optie is alleen voor het sorteren op datum, zodat alle processen netjes chronologisch worden weergegeven)

En je had sdb voor een dag ontkoppeld, bedoel je geunmount? Dan zou ik ook aan ext4-rsv-conver denken...
Wellicht lost het alleen mounten als het nodig is het op, en anders lijkt testen met een ander fs me dan ook een logische volgende stap.

Helaas gaat dat niet werken. De sda wordt gebruikt als archief, welke nog wel benaderbaar moet zijn. Sdb is een parity schijf, waar dit mogelijk wel een optie is, gezien deze alleen 's nachts voor een job draait.

Ja, ik had sdb zeker geunmount en misschien zelfs ook fysiek ontkoppeld om te testen. Dit zou misschien ook verklaren waarom sdb een dag later opspint dan sda.

Ik probeer me te verdiepen in ext4-rsv-conver, alleen er is nogal weinig info over te vinden. Wat ik begrijp is dat het een queue is met taken die out-of-band zijn en nog uitgevoerd moeten worden. Maar wat het exact is/doet geen idee . Vrijwel alles verwijst naar dit topic
@MartinMeijerink Weet jij er meer over? Je geeft bijv. aan dat "alleen mounten als nodig is" Betekent dit dat ext4-rsv-conver dan niet getriggerd wordt? Ik zit dan alleen te denken als deze queue taken bevat die wel uitgevoerd moeten worden en deze worden vervolgens niet uitgevoerd, gaat dit dan niet op termijn voor problemen zorgen?

Om te testen heb ik de schijf opnieuw geformatteerd. Ik heb ergens gelezen dat mogelijk de lazy_itable_init=0,lazy_journal_init=0 bij het formatteren voor problemen kunnen zorgen. Ik heb deze dus voor nu weggelaten en laat de schijf volledig de ext4lazyinit doen. Zal wel even duren voor dat dit klaar is, maar ik ben dan wel benieuwd of het gaat helpen.
Zodra deze schijf klaar is, wordt de sdb (parity) omgezet naar xfs om te testen.

[MartinMeijerink]

Dat lazy_itable_init is weer een ander verhaal, wel goed dat je deze bij het formatteren op 0 hebt gezet, ik had dat een keer bij een schijf niet gedaan, en na het formatteren meteen een kopieeractie aangezet, dat ging toen tergend langzaam, die schijf bleef maar rammelen (omdat ie tijdens het kopiëren het formatteren eigenlijk nog niet echt klaar was; er werden dus nog steeds nieuwe inodes gemaakt)

Maar nu weer even terug naar ext4-rsv-conver. Ik weet alleen dat dit process voor elke ext2/3/4 mount in square brackets in de process list te zien is, het zijn dus kernel-threads.
In jouw post van 31 maart 19:42 bijvoorbeeld is dan ook te zien dat je 4x een ext2/3/4 partitie hebt gemount.

Wat ext4-rsv-conver verder doet weet helemaal niemand

[blackmage2v]

@MartinMeijerink Dan gaan we kijken of we zelf een verklaring kunnen aantonen

Ik heb inmiddels de sda schijf opnieuw opgebouwd en opvallend is dat ext4lazyinit al klaar is. De schijf is op moment van schrijven in standby mode. De andere schijf sdb heb ik geformatteerd naar XFS en staat nu op active/idle. Ik ga er vanuit dat deze nog wel even bezig is. Vervolgens ben ik wel benieuwd of dit een verschil gaat maken. We gaan het zien.

Update:

sdb is nu ook klaar. Beide schijven staan nu netjes in standby:

code:

/dev/sda:
 drive state is:  standby

/dev/sdb:
 drive state is:  standby

[ Voor 16% gewijzigd door blackmage2v op 03-04-2025 13:00 ]