Ich verwende pxelinux, um eine In-RAM-Version von TinyCore (Linux-Version 4.19.10-tinycore) bereitzustellen. Es läuft auf einem Z270-A-Motherboard mit dem neuesten BIOS (Stand heute). PXE wird im Legacy-Modus gebootet.
Ich habe eine Java-Anwendung geschrieben, die SSD-Images über das Netzwerk verteilt und sie mit RandomAccessFile schreibt. Beim Schreiben habe ich ein seltsames Verhalten festgestellt, insbesondere Folgendes:
print_req_error: I/O error, dev sda, sector 42319888
Buffer I/O error on dev sda, logical block 5289986, async page read
ata1: EH complete
ata1.00: Enabling discard_zeroes_data
ata1.00: exception Emask 0x0 SAct 0x40000 SErr 0x0 action 0x0
ata1.00: irq_stat 0x40000008
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/08:90:10:c0:85/00:00:02:00:00/40 tag 18 ncq dma 4096 in
res 41/40:00:10:c0:85/00:00:02:00:00/40 Emask 0x409 (media error) <F>
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/133
sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
sd 0:0:0:0: [sda] tag#18 Sense Key : 0x3 [current]
sd 0:0:0:0: [sda] tag#18 ASC=0x11 ASCQ=0x4
sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x28 28 00 02 85 c0 10 00 00 08 00
print_req_error: I/O error, dev sda, sector 42319888
Buffer I/O error on dev sda, logical block 5289986, async page read
ata1: EH complete
ata1.00: Enabling discard_zeroes_data
Ich habe versucht, NCQ zu deaktivieren, libata.force=noncqaber ohne Erfolg.
Das Seltsame ist,Es treten keine derartigen Fehler auf, wenn ich das Gerät lösche dd if=/dev/zero of=/dev/sda bs=1Mund dann versuche, mit meinem Programm erneut Daten zu schreiben. Es sieht so aus, als würde das Problem behoben, indem das Laufwerk mit Nullen gefüllt wird, aber das dauert sehr lange und ist nicht förderlich für die Funktionsfähigkeit des Geräts.
Aus diesem Grund habe ich das Programm, das das Bild schreibt, so implementiert, dass vor dem Schreiben der eigentlichen Daten Nullen geschrieben werden, um den obigen Befehl zu simulieren. Trotzdem tritt der Fehler weiterhin auf.
smartctl -a /dev/sdazeigt keine schlechten Anzeichen. Ich habe dies bei mehreren Geräten gesehen, wie z. B. Silicon Power S55 und Micron 1100. Diesnurpassiert in diesem Setup. Es ist nie mit einer installierten Version von Ubuntu 18.04 passiert (lief von einer Festplatte, nicht vom RAM).
Der RAM ist nicht defekt, getestet mit Memtest. Alle Kabel sind in Ordnung, laufen über einen Corsair RM1000i.
Hier ist eine Ausgabe vondmesg. Ich kann anscheinend keinen Weg finden, das zu beheben, ich bin an diesem Punkt verloren. Außerdem gibt es hiersmartctlAusgabe.
EDIT: Es passiert nicht immer im selben Sektor. Manchmal passiert es in einem Sektor, der in der Vergangenheit einwandfrei funktioniert hat. Es sieht zufällig aus.
EDIT2: Mein Programm öffnet sich /dev/sdaals Datei und führt I/O darauf aus (so schreibe ich auf die Festplatte)
Antwort1
Es sieht so aus, als wären die Meldungen tatsächlich falsche Fehler. Ich habe meinen Java-Code geändert und verwende jetzt statt FileOutputStreamdieser praktischen Bibliothek:http://www.nicecode.eu/java-streams-for-direct-io/
Es bietet nativen I/O-Zugriff auf Dateien mit JNA, und ich kann das Flag O_DIRECT aktivieren. Ich habe die Bibliothek geändert und den Puffer von BLOCK_SIZE (512 Bytes) auf 512 KB (512*1024) vergrößert. Die Puffergröße muss ein Vielfaches der Blockgröße sein, die für O_DIRECT 512 Bytes betragen muss. Auf diese Weise sind die Geschwindigkeiten angemessen und mit der nicht-nativen Implementierung von Java vergleichbar.
Es liegen keine Fehler mehr vor, alle Daten sind gültig (mit bestätigt md5sum), weder für die bisher getestete Silicon Power SSD noch für die neue Micron.