Schlafprobleme bei Festplatten

[syntaxys]

Hallo zusammen,

ich bin mir jetzt nicht sicher, ob ich ein Hard- oder Softwareproblem habe. Falls dieser Thread in der falschen Kategorie hängt, bitte einfach umziehen.
Zu diesem Problem habe ich auch schon in einem anderen Forum versucht, Unterstützung zu bekommen, das war aber bisher erfolglos. Falls jemand diesen Thread verfolgen möchte, der wird hier fündig:
https://serversupportforum.de/threads/s ... ost-402986

Zum Problem:
Seit einigen Tagen beobachte ich, daß inaktive Festplatten unerwartet aus dem Schlafmodus geholt werden. Ich habe zwei ältere HDDs als Datenfriedhof an einem zusätzlichen SATA-Controller (Marvell 88se9215 Chipsatz) im PCIe-Steckplatz hängen. Diese sind nicht permanent im System eingebunden, sondern werden nur für die Sicherungen der Daten auf den SSDs aktiviert. Damit mehr Ruhe herrscht und nicht unnötig Energie verbraucht wird, schalte ich diese Platten regelmäßig nach Gebrauch mit hdparm -Y /dev/sd[e-f] oder automatisch ab.

Im syslog kann ich immer solche Aufzeichnungen zum Zeitpunkt des Aufweckens finden:

Code: Alles auswählen

2024-03-26T06:35:01.787287+01:00 HomeServer CRON[327616]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
2024-03-26T06:36:33.720952+01:00 HomeServer kernel: [43588.471096] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
2024-03-26T06:36:33.720988+01:00 HomeServer kernel: [43588.471112] ata6.00: waking up from sleep
2024-03-26T06:36:33.720990+01:00 HomeServer kernel: [43588.471120] ata6: hard resetting link
2024-03-26T06:36:34.200620+01:00 HomeServer kernel: [43588.950935] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
2024-03-26T06:36:37.164573+01:00 HomeServer kernel: [43591.917313] ata6.00: configured for UDMA/133
2024-03-26T06:36:37.164600+01:00 HomeServer kernel: [43591.917331] ata6.00: retrying FLUSH 0xea Emask 0x0
2024-03-26T06:36:37.164602+01:00 HomeServer kernel: [43591.917492] ata6: EH complete
2024-03-26T06:36:37.416586+01:00 HomeServer kernel: [43592.167002] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
2024-03-26T06:36:37.416613+01:00 HomeServer kernel: [43592.167019] ata5.00: waking up from sleep
2024-03-26T06:36:37.416615+01:00 HomeServer kernel: [43592.167027] ata5: hard resetting link
2024-03-26T06:36:37.892625+01:00 HomeServer kernel: [43592.642965] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
2024-03-26T06:36:37.904587+01:00 HomeServer kernel: [43592.655940] ata5.00: configured for UDMA/133
2024-03-26T06:36:37.904614+01:00 HomeServer kernel: [43592.655956] ata5.00: retrying FLUSH 0xea Emask 0x0
2024-03-26T06:36:37.904615+01:00 HomeServer kernel: [43592.656099] ata5: EH complete

debian-sa1 hat mit dem sysstat Daemon zu tun, der die Platten alle 10 Minuten aufweckt und wird für's Monitoring gebraucht. Der Dienst findet scheinbar in diesem Zusammenhang einen Fehler mit beiden Laufwerken. Diesen verstehe ich nicht ganz und konnte dazu bisher auch nichts ergoogeln.

Maßnahmen zur Fehlereingrenzung:
Ich hatte diese beiden Platten auch schon am internen OnBoard-SATA-Port hängen, dort wurden sie nicht regelmäßig aus dem Schlaf gerissen. Ich möchte jedoch am OnBoard-SATA-Controller aus Performance-Gründen das SSD-Setup behalten. Eine andere HDD, die ich testweise am externen Controller hängen hatte, blieb auch dort im Schlafmodus bis zum beabsichtigten Zugriff.

Ich frage mich nun, was die Ursache ist. Die beiden HDDs sind völlig unterschiedlich, eine 2.5" von Hitachi und eine 3.5" von Samsung. Die Test-HDD, die sowohl am OnBoard-Controller, als auch am PCIe-SATA-Controller problemlos schläft, ist eine 3.5" von Seagate.
Die o. a. Fehlermeldung entsteht auch nur beim Schlafmodus der beiden Platten. Ansonsten gibt's laut syslog oder dmesg keine Probleme mit diesen, wenn der cronjob läuft.
Laut https://linux-hardware.org/index.php?id ... -1b4b-9215 gibt es mit aktuellem Kernel keine Auffälligkeiten in Bezug auf den Chipsatz des Controllers.

Folgende Fragen hätte ich zu dem Thema:

• Kann mir jemand erklären, was diese Fehlermeldung im syslog technisch bedeutet? Ich bin nicht so tief in Hardwarethemen drin, um das interpretieren zu können.

• Inwieweit ist der sysstat Daemon überlebenswichtig für den Systembetrieb? Kann man dem beibringen, daß er die Finger von diesem oder jenem Laufwerk lassen soll – so wie man das z. B. auch dem smartd beibringen kann?

• Hat von Euch jemand eine Idee, wonach ich suchen könnte, um das Problem in den Griff zu bekommen?

Vielen Dank für die Hilfe,
Achim

[Livingston]

Zu sysstat/debian-sa1: Schau doch mal nach, ob debian-sa1 überhaupt bei Dir vorhanden ist, am Besten so, wie cron selbst danach sucht:

Code: Alles auswählen

command -v debian-sa1

Bei mir befindet sich dieser Eintrag in der Datei /etc/cron.d/sysstat, aber debian-sa1 selbst ist nicht vorhanden.
Diese Zeile

Code: Alles auswählen

command -v debian-sa1 > /dev/null && debian-sa1 1 1

testet übrigens nur, ob debian-sa1 da ist, und führt es aus, wenn vorhanden. Ansonsten passiert gar nix.

[syntaxys]

Stimmt, der ist nicht installiert und ich habe den cronjob daher mal deaktiviert. Es ist wohl nur der kernel, der die Platte aufweckt:

Code: Alles auswählen

2024-03-30T06:09:24.922478+01:00 HomeServer kernel: [387561.703805] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
2024-03-30T06:09:24.922524+01:00 HomeServer kernel: [387561.703821] ata5.00: waking up from sleep
2024-03-30T06:09:24.925653+01:00 HomeServer kernel: [387561.703830] ata5: hard resetting link
2024-03-30T06:09:25.396629+01:00 HomeServer kernel: [387562.179743] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
2024-03-30T06:09:25.408577+01:00 HomeServer kernel: [387562.192530] ata5.00: configured for UDMA/133
2024-03-30T06:09:25.408606+01:00 HomeServer kernel: [387562.192545] ata5.00: retrying FLUSH 0xea Emask 0x0
2024-03-30T06:09:25.408610+01:00 HomeServer kernel: [387562.192679] ata5: EH complete

Das ist die aktuelle Ausgabe von lshw:

Code: Alles auswählen

*-sata
	description: SATA controller
	product: 88SE9215 PCIe 2.0 x1 4-port SATA 6 Gb/s Controller
	vendor: Marvell Technology Group Ltd.
	physical id: 0
	bus info: pci@0000:04:00.0
	logical name: scsi4
	logical name: scsi5
	version: 11
	width: 32 bits
	clock: 33MHz
	capabilities: sata pm msi pciexpress ahci_1.0 bus_master cap_list rom emulated
	configuration: driver=ahci latency=0
	resources: irq:128 ioport:c050(size=8) ioport:c040(size=4) ioport:c030(size=8) ioport:c020(size=4) ioport:c000(size=32) memory:91140000-911407ff memory:91100000-9113ffff
  *-disk:0
	   description: ATA Disk
	   product: SAMSUNG HD204UI
	   physical id: 0
	   bus info: scsi@4:0.0.0
	   logical name: /dev/sde
	   version: 0001
	   serial: ...
	   size: 1863GiB (2TB)
	   capabilities: removable
	   configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512

und hdparm -I /dev/sde

Code: Alles auswählen

ATA device, with non-removable media
        Model Number:       SAMSUNG HD204UI
        Serial Number:      ...
        Firmware Revision:  1AQ10001
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
        Used: unknown (minor revision code 0x0028)
        Supported: 8 7 6 5
        Likely used: 8
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:  3907029168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        device size with M = 1024*1024:     1907729 MBytes
        device size with M = 1000*1000:     2000398 MBytes (2000 GB)
        cache/buffer size  = unknown
        Form Factor: 3.5 inch
        Nominal Media Rotation Rate: 5400
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = ?
        Advanced power management level: 254
        Recommended acoustic management value: 254, current value: 128
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
                Power-Up In Standby feature set
           *    SET_FEATURES required to spinup after power up
                SET_MAX security extension
           *    Automatic Acoustic Management feature set
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    64-bit World wide name
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
           *    NCQ priority information
           *    DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Read/Write Long (AC1), obsolete
           *    SCT Write Same (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        340min for SECURITY ERASE UNIT. 340min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50024e9...
        NAA             : 5
        IEEE OUI        : 0024e9
        Unique ID       : ...
Checksum: correct

Ich habe mal explizit den Write Cache mit hdparm -W 0 /dev/sde deaktiviert. Hat auch nichts gebracht. Hmm?!?

EDIT:
An der Firmware liegt es wohl nicht, die Platte wurde zu einem späteren Zeitpunkt gekauft und mit der aktualisierten FW ausgeliefert:
https://www.heise.de/news/Firmware-Patc ... 50154.html
Da hat wohl jemand ein ähnliches Problem:
https://bbs.archlinux.org/viewtopic.php?id=199289
so wie hier im Forum @hikaru ebenso:
viewtopic.php?t=110919

Ich habe den Parameter sde=noprobe mal in der grub.cfg angehängt und neu gestartet, aber der kernel ignoriert die Anweisung.

[syntaxys]

Inzwischen habe ich mich durch einige Foren durchgearbeitet und habe festgestellt, daß andere User das gleiche Problem haben. Irgendetwas veranlasst den Kernel manche HDDs aus dem Schlafmodus zu holen. Was genau, ist nirgendwo klar ersichtlich gewesen.

Das einzige, was die Platten aktuell schlafen lässt, ist das Entfernen aus der aktuellen Systemkonfiguration, z. B.:

Code: Alles auswählen

echo 1 > /sys/block/sde/device/delete

Man bekommt die HDD wieder ins laufende System (oder nach einem Reboot) zurück mit:

Code: Alles auswählen

echo "- - -" > /sys/class/scsi_host/host4/scan

Das ist jedoch suboptimal, da es beim Booten gelegentlich vorkommt, daß sich die Gerätenamen ändern. Will man den Workaround automatisiert nutzen, läuft man Gefahr, auch mal die falsche Platte raus zu kicken.

[Livingston]

Hab grad keine Zeit, mich drin zu vertiefen, aber als Idee: Kann man die Platten nicht anhand einer UID erfassen und dann im /sys-Gerätebaum wiederfinden? Ich denke durchaus, dass sich die Platten eindeutig identifizieren lassen.

[syntaxys]

Ich habe dazu nichts Eindeutiges gefunden, aber man kann sich aber z. B. lsscsi installieren und mit

Code: Alles auswählen

root@HomeServer:~# lsscsi | grep 'HD204UI'
[4:0:0:0]    disk    ATA      SAMSUNG HD204UI  0001  /dev/sde

sowohl den Gerätenamen für's Entfernen der richtigen HDD, als auch die Host-Nr. für den Rescan zurückgeben lassen, um das im Script verwenden zu können. Sicher gibt's auch andere Tools, die beides auf Basis einer bestimmten Eigenschaft zurückgeben. Ich werde über Ostern mal schauen, was ich mir da basteln kann. Aber gut ist's schon mal, daß die Platte nun Ruhe hat – und ich auch

[Livingston]

Dann genieß' die Feiertage
Ich bleibe auch am Thema dran, da ich ein ähnliches Problem mit meinem debianisiertem Bufallo-NAS habe. Jetzt hab ich endlich mal 'nen Anlass, mich drum zu kümmern.

[syntaxys]

Ich habe das System mal um zwei weitere ungenutzte HDDs ohne Partitionierung ergänzt, um die Problematik auszuwerten.
Zuerst habe ich mal alles unter /etc/udisks2 gelöscht, was ich mit dem Gnome Disk-Utility über den Desktop für den Energiesparmodus der Platten angelegt hatte. Anschliessend habe ich einen Systemdienst angelegt, der beim Systemstart die gewünschten Geräte in den Schlafmodus schickt:

Code: Alles auswählen

cat <<EOT >> /etc/systemd/system/hdparm@.service
[Unit]
Description=hdparm sleep %I

[Service]
Type=simple
ExecStart=/usr/sbin/hdparm -S 120 -Y /dev/disk/by-id/%i

[Install]
WantedBy=multi-user.target
EOT

Die eindeutige Disk-ID, die man dem Dienst übergibt, findet man mit ls /dev/disk/by-id/, damit lässt sich der inkonsistente Wechsel der Gerätenamen beim Booten umgehen. Den Dienst für die jeweilige Platte startet man dann z. B. so:

Code: Alles auswählen

root@HomeServer:/# systemctl start hdparm@ata-ST3500830AS
root@HomeServer:/# systemctl enable hdparm@ata-ST3500830AS

Wichtig: die Disk-ID verwenden, nicht die Partitions-ID!

So weit funktioniert das prima, bis auf den Umstand, daß die Platten nach ein paar Minuten immer noch grundlos wieder aufgeweckt werden. Testweise habe ich das System mal in den Runlevel 3 gebootet, aber auch das hat keine Abhilfe gebracht. Inzwischen taucht zu den Vorgängen auch nichts mehr im syslog auf. Die Platten fahren hoch, nur um gleich wieder in den StandBy-Modus zu gehen. Eine der ergänzten Laufwerke, die Seagate, geht nach dem Aufwachen gar nicht mehr schlafen.

Ich habe mir daher zwei Scripte gebaut, um die Laufwerke aus der Konfiguration zu kicken. Das Script disk-eject übernimmt als Parameter die gewünschte Disk-ID, holt sich den aktuellen Gerätenamen, schreibt die aktuelle Konfiguration der Disk in eine Datei und kickt sie aus der Konfiguration:

Code: Alles auswählen

cat <<EOT >> /sbin/disk-eject
#!/bin/sh

if test -h "/dev/disk/by-id/$1"
then
    disk=$(readlink -e "/dev/disk/by-id/$1")
else
    disk="$1"
fi

lsscsi | grep $(basename "$disk") > "/etc/udisks2/$1"

if test -b "$disk"
then
    echo 1 >/sys/block/$(basename "$disk")/device/delete
else
    echo "$0: Kein Blockgerät: $1" >&2
    exit 1
fi

Man ruft das Script dann z. B. mit disk-eject ata-ST3500830AS auf. Für das System ist die Platte danach völlig unsichtbar. Will man sie wieder in das System einbinden, muss man den Bus kennen, an dem sie hängt und diesen neu scannen. Das macht dann das folgende Script:

Code: Alles auswählen

cat <<EOT >> /sbin/disk-rescan
#!/bin/sh
host=$(cat "/etc/udisks2/$1" | head -c 2 | tail -c 1)
echo "- - -" > /sys/class/scsi_host/host$host/scan

Man ruft das Script dann z. B. mit disk-rescan ata-ST3500830AS auf und die Platte ist nach ein paar Sekunden des Hochfahrens wieder ganz normal im System verfügbar. Die Partitionen können gemountet werden, das Backup drauf gespielt und schwups ist das Ding wieder raus und gibt Ruhe.

Auf dieser Basis kann man sich dann auch einen Dienst basteln, der die gewünschten Platten gleich nach dem Booten aus der Konfiguration wirft.

Wichtiger Hinweis:
Ich meine irgendwo gelesen zu haben, daß ein Rescan des Busses angeblich zu einer kurzen Unterbrechung zum angehängten Medium führt. Das kann vielleicht bei Platten, auf denen gerade ein RAID aktiv ist oder die SWAP läuft, zu unerwarteten Reaktionen führen. Daher ist es wichtig, den aktuellen Bus zu kennen, an dem die Platte hängt. Nach einem Reboot des Systems sind alle Platten wieder eingebunden.