Schlafprobleme bei Festplatten

S

syntaxys

Webentwickler
Hallo zusammen,
seit einigen Tagen habe ich das Problem, daß inaktive Festplatten unerwartet aus dem Schlafmodus geholt werden. Ich habe zwei ältere HDDs als Datengrab an einem zusätzlichen SATA-Controller im PCIe-Steckplatz hängen. Diese sind nicht permanent 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 die Platten regelmäßig ab.

Im syslog konnte ich diese Aufzeichnungen zum Problem finden:
Bash: 
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 wird für's Monitoring gebraucht und findet wohl in diesem Zusammenhang einen Fehler mit beiden Laufwerken. Diesen verstehe ich nicht ganz und konnte dazu bisher auch nichts ergoogeln.
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 intern, als auch am PCIe-SATA-Controller problemlos schläft, ist eine 3.5" von Seagate.

Hat von Euch jemand eine Idee, wonach ich suchen könnte?

Vielen Dank für die Hilfe,
Achim

Nachtrag:
Die o. a. Fehlermeldung entsteht nur beim Schlafmodus der beiden Platten. Ansonsten gibt's keine Probleme, wenn der cronjob läuft.
 
Last edited:
Du könntest Mal mit irgend einem Inotify-Tool (inotifywatch?) schauen, auf was da an Dateien so zugegriffen wird. Logging dazu in den RAM (/dev/shm/...).
 
Naja, es gibt keine Dateizugriffe auf der Platte, weil keine Partition der Platte gemountet ist. Wie ich oben erwähnt habe, werden die Partitionen nur per Script für's Backup eingebunden und danach wieder ausgeworfen, danach mit hdparm -Y /dev/sd[e-f] eingeschläfert.
Es ist der sysstat Daemon, der die Platten alle 10 Minuten aufweckt und ich versuche noch herauszufinden, wozu der laufen muss, oder ob man dem auch sagen kann, daß er die Finger von diesem oder jenem Laufwerk lassen soll – so wie man das z. B. auch dem smartd beibringen kann.
Ich kann den Log-Auszug nicht richtig interpretieren, ob das vielleicht auch mit dem Marvell-Chip des SATA-Controllers im PCIe-Port zu tun hat. Dafür bräuchte ich Hilfe.
 
sysstat ist eine Art Monitoring-Tool, welches auf Debian standardmäßig nicht installiert ist. Also hast du es wohl selber manuell installiert oder es wurde als Abhängigkeit von einem anderen Monitoring-Tool installiert. Entsprechend musst du selber wissen, warum der läuft.
 
Nach einiger Recherche habe ich festgestellt, daß nicht sysstat der Schuldige ist, sondern daß der Kernel für die Reaktivierung der HDDs verantwortlich ist. Inzwischen habe ich mich durch einige Foren durchgearbeitet und festgestellt, daß andere User das gleiche Problem haben. Irgendetwas veranlasst den Kernel zumindest manche HDDs aus dem Schlafmodus zu holen. Was genau und warum, ist nirgendwo klar ersichtlich gewesen.

Das einzige, was die Platten aktuell schlafen lässt, ist das Entfernen aus der aktuellen Systemkonfiguration, z. B.:
Code: 
echo 1 > /sys/block/sde/device/delete
Man bekommt die HDD wieder ins laufende System (oder nach einem Reboot) zurück mit:
Code: 
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 diesen Workaround automatisiert nutzen, läuft man Gefahr, auch mal die falsche Platte raus zu kicken.
Der Vorteil bei dieser Radikalmethode ist aber, daß die HDDs auch im Tiefschlaf bleiben, wenn man z. B. fdisk aufruft oder einen inaktiven ZFS-Pool importieren möchte, der mit den schlafenden HDDs nichts zu tun hat.
 
syntaxys said:
...
Das ist jedoch suboptimal, da es beim Booten gelegentlich vorkommt, daß sich die Gerätenamen ändern. Will man diesen Workaround automatisiert nutzen, läuft man Gefahr, auch mal die falsche Platte raus zu kicken.
Click to expand...
Das ist ein gelöstes Problem.

Festplatten und Partitionen/Dateisysteme sind seit vielen Jahren eindeutig identifizierbar und persistent. Die traditionellen Namen /dev/sd{a,b,c,...,} und ähnliche sind es allerdings nicht.

blkid ist Dein Freund. Ansonsten gibt es da noch die Verzeichnisse/dev/disk/by-..., mit der die Festplatten anhand verschiedener Merkmale benannt sind.


btw: Dann nochmal zur Verknüpfung in beide Richtungen:

Schlafprobleme bei Festplatten - debianforum.de

debianforum.de
 
Last edited:
Dann versuch mal bitte unterhalb von /sys/block/ eine ID zu finden, die Du entfernen kannst …

Man kann sich aber z. B. lsscsi installieren und mit
Code: 
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.
 
/sys/block würde ich nicht nehmen. Ich würde - wie geschrieben - lsblk verwenden. Mit lsscsi kommst Du natürlich auf die gleichen Informationen. lsscsi ist aber üblicherweise nicht per default installiert.

Z. B. so ...

Code: 
# lsblk --scsi -o KNAME,UUID,VENDOR,MODEL,SERIAL --json
{
   "blockdevices": [
      {"kname":"sda", "uuid":null, "vendor":"ATA     ", "model":"Verbatim_Vi550_S3", "serial":"4935015148310507"},
      {"kname":"sdb", "uuid":null, "vendor":"ATA     ", "model":"Verbatim_Vi550_S3", "serial":"4935015148312639"},
      {"kname":"sdc", "uuid":null, "vendor":"ATA     ", "model":"ST16000NM000G-2KH103", "serial":"ZL201QAZ"},
      {"kname":"sdd", "uuid":null, "vendor":"ATA     ", "model":"ST16000NM000G-2KH103", "serial":"ZL201QA8"},
      {"kname":"sde", "uuid":null, "vendor":"ATA     ", "model":"ST16000NM000G-2KH103", "serial":"ZL201QA5"},
      {"kname":"sdf", "uuid":null, "vendor":"ATA     ", "model":"ST16000NM000G-2KH103", "serial":"ZL201QAH"}
   ]
}

Btw. man sieht hier, dass die UUID nur für das Dateisystem vergeben wird und nicht für das Blockdevice an sich. Allerdings ist der Name in /dev/disk/by-id/... persistent und eindeutig. Dieser Name ist ein Symlink auf den aktuellen Kernelnamen des Blockdevices, was man für das Ansprechen in Deinem Sinne unterhalb von /sys/block benötigt.

Die Ausgabe korrespondiert mit den Einträgen in /dev/disk/by-id:

Code: 
cd /dev/disk/by-id
# ls -l |grep -v part| grep -v md|grep ata
lrwxrwxrwx 1 root root  9 26. Feb 18:13 ata-ST16000NM000G-2KH103_ZL201QA5 -> ../../sde
lrwxrwxrwx 1 root root  9 26. Feb 18:13 ata-ST16000NM000G-2KH103_ZL201QA8 -> ../../sdd
lrwxrwxrwx 1 root root  9 26. Feb 18:13 ata-ST16000NM000G-2KH103_ZL201QAH -> ../../sdf
lrwxrwxrwx 1 root root  9 26. Feb 18:13 ata-ST16000NM000G-2KH103_ZL201QAZ -> ../../sdc
lrwxrwxrwx 1 root root  9 26. Feb 18:13 ata-Verbatim_Vi550_S3_4935015148310507 -> ../../sda
lrwxrwxrwx 1 root root  9 26. Feb 18:13 ata-Verbatim_Vi550_S3_4935015148312639 -> ../../sdb
 
Last edited:
Da hast Du Recht, das JSON-Array ist auch besser zu verwerten. Hier wird mir jedoch nicht die Nummer des Host-Ports für den späteren Rescan zurückgegeben, um die Platte wieder ansprechen zu können. Ich vermute jetzt mal, daß die Nummer sich eh nie ändert, so lange die Platte am Controller nicht umgestöpselt wird. Oder doch?
Wenn das Gerät aus der aktuellen Konfiguration gelöscht ist, bleibt es unsichtbar. Dann müsste man den Bus erraten, an dem die Platte hängt.

Aktuell liefert mir lshw -class disk -class storage (hier wäre ja auch alles Nötige drin ;)):
Code: 
*-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
 
Ich meine ich hätte das auch schon mal gesucht, aber ich hatte damals keine befriedigende Lösung gefunden.

Hier ist noch ein Thread, den ich gerade eben gefunden habe, aber noch nicht durchgearbeitet ...

superuser.com

Mapping ata device number to logical device name

I'm getting kernel messages about 'ata3'. How do I figure out what device (/dev/sd_) that corresponds to?
superuser.com superuser.com

lshw kann ansonsten auch JSON-Ausgabe, aber jq kann die bei mir nicht parsen. Und ja: Wenn Du nur darauf aus bist, Dein konkretes Problem zu lösen und nicht eine generische Lösung suchst, dann werden die hostX-Einträge ohne HW-Änderung vermutlich auch gleich bleiben.
 
Last edited:
Nun, eine generische Lösung wäre mir auch viel lieber, da dieser Workaround nicht wirklich sauber ist.
Worüber ich immer noch grüble ist: Was triggert den Kernel zu diesem Verhalten?
Es ist ja nicht so, daß der Kernel sofort eingreift, wenn das Medium mit hdparm -Y /dev/sde eingeschläfert wird. Das passiert erst nach etwa 5 Minuten, daß die Platte wieder hochgefahren wird. Weiter assoziiere ich mit so einem Log-Eintrag wie ata6.00: retrying FLUSH 0xea Emask 0x0 eine Art Cache, der geleert/zurückgeschrieben werden soll.
  • Auf der Platte ist jedoch der WriteCache deaktiviert,
  • es ist keine Partition eingebunden,
  • alle ZFS-Pools sind exportiert und somit offline,
  • smartd ist angewiesen, das Laufwerk zu ignorieren und der macht das auch.
Was ich mir als Trigger noch vorstellen könnte, ist vielleicht der Pool-Cache von ZFS. Der merkt sich ja, wo welche inaktiven Pools rumgammeln.

Ich habe hier noch 2 HDDs herumliegen und an dem Controller sind noch 2 Ports frei. Da werde ich die Kiste halt nochmal aufschrauben und damit herumspielen.

EDIT:
Hier ist mal ein Auszug des Log, wenn die Platte ins System zurückgeholt wurde:
Code: 
2024-03-31T08:37:27.167493+02:00 HomeServer kernel: [89035.454341] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
2024-03-31T08:37:27.171441+02:00 HomeServer kernel: [89035.460585] ata5.00: ATA-8: SAMSUNG HD204UI, 1AQ10001, max UDMA/133
2024-03-31T08:37:36.735482+02:00 HomeServer kernel: [89045.025990] ata5.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 32), AA
2024-03-31T08:37:36.743411+02:00 HomeServer kernel: [89045.032631] ata5.00: configured for UDMA/133
2024-03-31T08:37:36.743442+02:00 HomeServer kernel: [89045.033051] scsi 4:0:0:0: Direct-Access     ATA      SAMSUNG HD204UI  0001 PQ: 0 ANSI: 5
2024-03-31T08:37:36.743445+02:00 HomeServer kernel: [89045.033777] sd 4:0:0:0: [sde] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
2024-03-31T08:37:36.743447+02:00 HomeServer kernel: [89045.033807] sd 4:0:0:0: [sde] Write Protect is off
2024-03-31T08:37:36.743448+02:00 HomeServer kernel: [89045.033811] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
2024-03-31T08:37:36.743449+02:00 HomeServer kernel: [89045.033839] sd 4:0:0:0: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
2024-03-31T08:37:36.743451+02:00 HomeServer kernel: [89045.033891] sd 4:0:0:0: Attached scsi generic sg4 type 0
2024-03-31T08:37:36.743452+02:00 HomeServer kernel: [89045.033900] sd 4:0:0:0: [sde] Preferred minimum I/O size 512 bytes
2024-03-31T08:37:36.791440+02:00 HomeServer kernel: [89045.080715]  sde: sde1 sde2 sde3 sde4 sde5
2024-03-31T08:37:36.791471+02:00 HomeServer kernel: [89045.081406] sd 4:0:0:0: [sde] Attached SCSI removable disk
2024-03-31T08:37:37.352752+02:00 HomeServer udisksd[2241]: Applying configuration from /etc/udisks2/SAMSUNG-HD204UI.conf to /dev/sde
2024-03-31T08:37:37.410525+02:00 HomeServer udisksd[2241]: Set standby timer to 600 seconds (value 120) on /dev/sde [SAMSUNG-HD204UI]
Ich habe sie gut eine halbe Stunde laufen lassen und bei der Gelegenheit ist mir aufgefallen, daß sie nicht automatisch nach 10 Min. in den StandBy geht. Mit hdparm -Y /dev/sde ging sie dann in den Ruhemodus, nur um etwa 5 Minuten Später wieder geweckt zu werden. Allerdings stand dieses Mal nichts dazu im syslog. Hmmm?!?
 
Last edited:
Im debianforum(.de) hat der Benutzer "Wanne" mal gemeint, dass da systemd recht viele seltsame Dinge tut. Also irgendwie die HW prüfen sobald diese angeschlossen wurde, wozu auch gehören würde, dass temporär auch einfach Mal erkannte Dateisysteme schreibbar eingehängt und verändert würden, aus Gründen, über die ich nahezu Null Ahnung habe.

Auch gab es da vor Kurzem dort einen Thread, der sich der Frage widmete, warum denn die Prüfsumme eines Dateisystemes, das mit dd geklont wurde und sonst nicht angefasst wurde nicht identisch ist. Hier wäre das erste Argument eine mögliche Erklärung.

Nur Mal so als Anregung weiter zu forschen, falls Dich das interessiert.
 
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: 
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: 
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: 
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: 
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.
 
Zur Frage nochmal wie man vom Kernel - Device - Namen auf den passenden SATA-Anschluß kommt. Es scheint doch einen Weg zu geben, auch wenn ich den noch nicht universell in ein Script packen kann, da das Anschlußlayout ja immer unterschiedlich sein kann.

Aber mal beispielhaft für ein System hier mit 2 x SSD + 4 Festplatten:

Code: 
 ls -l /dev/disk/by-path/|grep -v part
insgesamt 0
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:00:1f.2-ata-1 -> ../../sde
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:00:1f.2-ata-1.0 -> ../../sde
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:00:1f.2-ata-2 -> ../../sdf
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:00:1f.2-ata-2.0 -> ../../sdf
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:0b:00.0-sas-phy0-lun-0 -> ../../sda
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:0b:00.0-sas-phy1-lun-0 -> ../../sdb
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:0b:00.0-sas-phy2-lun-0 -> ../../sdc
lrwxrwxrwx 1 root root  9 26. Feb 18:13 pci-0000:0b:00.0-sas-phy3-lun-0 -> ../../sdd

Die Links für die Partitionen habe ich entfernt. Bei sde + sdf sind da interessanterweise Dopplungen drin.

Dann die Controller in meinem System:

Code: 
lspci |grep -i sata
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
0b:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)

Anschließend suche ich unterhalb von /sys nochmal nach host[0-9] für die SATA-Anschlüsse:

Code: 
# cd /sys; find . -iname "host[0-9]"
...
./class/scsi_host/host5
./class/scsi_host/host3
./class/scsi_host/host1
./class/scsi_host/host6
./class/scsi_host/host4
./class/scsi_host/host2
./class/scsi_host/host0
./devices/pci0000:00/0000:00:1f.2/ata1/host1
./devices/pci0000:00/0000:00:1f.2/ata1/host1/scsi_host/host1
./devices/pci0000:00/0000:00:1f.2/ata6/host6
./devices/pci0000:00/0000:00:1f.2/ata6/host6/scsi_host/host6
./devices/pci0000:00/0000:00:1f.2/ata4/host4
./devices/pci0000:00/0000:00:1f.2/ata4/host4/scsi_host/host4
./devices/pci0000:00/0000:00:1f.2/ata2/host2
./devices/pci0000:00/0000:00:1f.2/ata2/host2/scsi_host/host2
./devices/pci0000:00/0000:00:1f.2/ata5/host5
./devices/pci0000:00/0000:00:1f.2/ata5/host5/scsi_host/host5
./devices/pci0000:00/0000:00:1f.2/ata3/host3
./devices/pci0000:00/0000:00:1f.2/ata3/host3/scsi_host/host3
./devices/pci0000:00/0000:00:11.0/0000:0b:00.0/host0
./devices/pci0000:00/0000:00:11.0/0000:0b:00.0/host0/sas_host/host0
./devices/pci0000:00/0000:00:11.0/0000:0b:00.0/host0/scsi_host/host0

Hmmm. Ich dachte ich bin damit am Ziel. Aber scheinbar noch überhaupt nicht.

Ich weiss jetzt, dass 2 Geräte an 2 Ports von dem SATA-Controller hängen - von denen jedes an einem Port hängt, dass durch eine eigene "host#" Pseudoatei spezifiziert ist und 4 andere Geräte an dem SAS-Controller hängen für den es insgesamt nur den host0 - Pseudodateinamen gibt. Ein rescan ist da nur für den ganzen Controller möglich.

Das mit dem Rescan - wie von Dir beschrieben - dürfte aber nur für Standard-SATA oder bei manchen SAS-Controllern möglich sein. Wenn man da andere RAID-Controller verwendet müsste man dann da das entsprechende CLI-Tool des Herstellers verwenden. Und einen Rescan dort auszuführen, habe ich bisher eigentlich immer im normalen Betrieb getan - ohne großartige Sorge, dass das schief laufen könnte.
 
Last edited:
Also der einfachste Weg ist über lsscsi, damit hast Du zumindest alle Informationen für die Problemlösung hier mit den Rotationsmedien:
Code: 
root@HomeServer:~# lsscsi -w -i
[0:0:0:0]    disk    ATA      SAMSUNG SSD 830  3B1Q                                  /dev/sda   -
[1:0:0:0]    disk    ATA      Samsung SSD 860  1B6Q                                  /dev/sdb   -
[2:0:0:0]    disk    ATA      WDC  WDS500G1R0A 00WR                                  /dev/sdc   -
[3:0:0:0]    disk    ATA      WDC  WDS500G1R0A 00WR                                  /dev/sdd   -
[5:0:0:0]    disk    ATA      Hitachi HTS54503 C60W                                  /dev/sdf   -
[8:0:0:0]    disk    Generic- SD/MMC           1.00                                  /dev/sdi   Generic-_SD_MMC_20060413092100000-0:0
[9:0:0:0]    disk    Intenso  USB 3.0 Device   0                                     /dev/sdj   Intenso_USB_3.0_Device_31000000000000005647-0:0
Die Hosts 4,6 & 7 fehlen bei mir gerade, da sie stillgelegt sind.
Mit lshw bekommst Du eine Ausgabe in JSON formatiert, die Du weiterverwenden kannst, z. B.
Code: 
root@HomeServer:~# lshw -json -class disk
[
  {
    "id" : "disk:0",
    "class" : "disk",
    "claimed" : true,
    "handle" : "GUID:53739ce7-49ee-7e45-bf1a-a01f192ac80b",
    "description" : "ATA Disk",
    "product" : "SAMSUNG SSD 830",
    "physid" : "0",
    "businfo" : "scsi@0:0.0.0",
    "logicalname" : "/dev/sda",
    "dev" : "8:0",
    "version" : "3B1Q",
    "serial" : "...",
    "units" : "bytes",
    "size" : 128035676160,
    "configuration" : {
      "ansiversion" : "5",
      "guid" : "53739ce7-49ee-7e45-bf1a-a01f192ac80b",
      "logicalsectorsize" : "512",
      "sectorsize" : "512"
    },
    "capabilities" : {
      "gpt-1.00" : "GUID Partition Table version 1.00",
      "partitioned" : "Partitioned disk",
      "partitioned:gpt" : "GUID partition table"
    }
  },
...
Hiermit kannst Du auf die guid der Disk referenzieren. Wenn man das Array umschichtet, kann man sich alle nötigen Infos zur GUID zusammenfassen. Über ein Shell-Script wird's aber etwas komplex, ich würde mir das mit PHP erledigen. Hier ein paar Anleitungen, wie man das direkt in der Shell hinbekommen könnte:
https://stackoverflow.com/questions/38364261/parse-json-to-array-in-a-shell-script
https://linuxsimply.com/bash-scripting-tutorial/array/array-operations/json-to-array/
 
You must log in or register to reply here.
Back
Top