forum.frank-mankel.org

flockeee

Du liegst vollkommen richtig. Es liegt am RemoteMount, welchen ich über OMV eingebunden habe. Evtl. habe ich da aber auch etwas falsch konfiguriert. Denke nicht, dass es an OMV liegt.
Ohne diesen geht der headless Boot problemlos.

Mittlerweile kann ich deine Ansichten bzgl WebUi usw. durchaus nachvollziehen. Per Hand lernt man auch noch dazu.
Wegen der UART Konsole habe ich Deine Erfahrungen in einem anderen Thread entdeckt. Danke dafür. Werde ich mir bei Gelegenheit näher anschauen.

flockeee

@FrankM Vielen Dank, brauchst Du nicht. Habe es gerade getestet und es funktioniert alles.

flockeee

@flockeee sagte in SATA Karte Marvell 88SE9230 Chipsatz:

Leider sind beim Stress Testen des Controllers (kopieren von 500GB vom SW-RAID1 parallel auf beide SSDs)
wiederholt folgende Fehler in dmesg aufgetaucht:

[177554.379675] ata3.00: exception Emask 0x0 SAct 0x1f000000 SErr 0x0 action 0x6 frozen
[177554.382198] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.384513] ata3.00: cmd 61/08:c0:00:09:80/00:00:16:00:00/40 tag 24 ncq dma 4096 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.389434] ata3.00: status: { DRDY }
[177554.391423] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.393559] ata3.00: cmd 61/10:c8:10:09:81/00:00:16:00:00/40 tag 25 ncq dma 8192 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.398530] ata3.00: status: { DRDY }
[177554.400704] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.402878] ata3.00: cmd 61/08:d0:38:45:86/00:00:16:00:00/40 tag 26 ncq dma 4096 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.407762] ata3.00: status: { DRDY }
[177554.409759] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.411909] ata3.00: cmd 61/08:d8:b8:08:00/00:00:00:00:00/40 tag 27 ncq dma 4096 out
                         res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.416582] ata3.00: status: { DRDY }
[177554.418559] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.420735] ata3.00: cmd 61/28:e0:38:08:00/00:00:0b:00:00/40 tag 28 ncq dma 20480 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.425796] ata3.00: status: { DRDY }
[177554.428043] ata3: hard resetting link
[177554.748386] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[177554.752956] ata3.00: configured for UDMA/133
[177554.755160] ata3: EH complete
[177677.262098] ata3.00: NCQ disabled due to excessive errors

Der Kopierprozess auf die jeweilige SSD welche dann resetet stockt dann einige Sekunden und wird dann fortgesetzt. >Dies passiert bisher nur bei den SSDs und nicht parallel.
...

Ich habe oben genannte Probleme mit einem Firmwareupdate* des 88SE9230 in den Griff bekommen. Ein erneuter Stresstest produziert keine der obengenannten Fehlermeldungen mehr bei gleichem Testmuster.

Bios Ver. 1.0.0.1027 / Firmware Vers. 2.3.0.1076 : http://ftp.assmann.com/pub/DS-/DS-30104-1___4016032330240/DS-30104-1_firmware_mul_DS-30104-1 Firmware_20181221.zip

Zum Flashen des Controllers bin ich folgendermaßen vorgegangen:

Sata Controller (hier: DeLOCK 89395) in ein x64/x86 system stecken
Bootbaren USB Stick mit FreeDos präparieren und Dateien aus obengenanntem Archiv ins Hauptverzeichnis legen
Vom USB Stick ins FreeDos booten
In der Kommandozeile "go.bat -y" ausführen
Warten bis der Flash vollständig ist
Neustart

ACHTUNG: DIESE METHODE BEINHALTET KEIN (FUNKTIONIERENDES) BACKUP DER VORHANDENEN FIRMWARE DES CONTROLLERS! FLASHEN AUF EIGENES RISIKO!

Ich habe zuerst die allerneuste Version 1.0.0.1028 bios + 2.3.0.1078 fw geflasht. Mit dieser Version gab es Fehlermeldungen in dmesg über den controller init und die angeschlossenen Platten wurden nicht angezeigt. Ein Downgrade auf obengenannte Version löste das Problem.

Viele Grüße,
Florian

flockeee

Ich bin gerade dabei ein Raid zu erstellen (dauert noch etwas). Danach wollen rund 3 TB darauf kopiert werden. Mal gucken was sich danach so in dmesg findet. Das sollte aus erster Stabilitätstest genügen.

Geschwindigkeitstests werden im Anschluß folgen.

Grüße

flockeee

Vielen Dank fürs Testen.
Ich nehme an Du hast das Pine64 Wifi Modul getestet.

Momentan sind die Geschwindigkeiten ja noch recht mau, oder?
Welche theoretische Geschwindigkeit und Kanalbreite wurde denn zwischen Router und RP64 ausgehandelt?

Viele Grüße,
Florian

flockeee

@FrankM Vielen Dank, brauchst Du nicht. Habe es gerade getestet und es funktioniert alles.

flockeee

Läuft damit auch der delock Sata Controller?
Ich befürchte du testest auf einem separatem RP64, oder?

flockeee

@FrankM sagte in [HOWTO]ROCKPro64 - NAS bauen Teil 1:

Hallo smx52,

...

Einziges Problem, du müsstest dir Gedanken über eine vernünftige Stromversorgung machen.

Zur Stromversorgung:
Ich betreibe 2 HDD (WD Red 2TB) + 2 SSD am 12V Port des RP64.
Dazu brauch man natürlich ein ordentliches Netzteil (bei mir 12V/7.5A) und Adapter.
Ich habe den, welcher zum NAS case beigelegt war(ROCKPro64 Power Cable for dual SATA Drives und einen Verteiler in Verwendung (S-ATA Strom-Adapter).

Ich bin mir nicht sicher welche Leistung der 12V Port des RP64 liefern kann, habe dazu leider keine specs gefunden. Mein Setup sollte maximal 6A unter Last für die Laufwerke ziehen. Für den RP64 sollte man auch nochmal max 2A rechnen. Demzufolge könnte mein NT unter Last hier schon an seine Grenzen gelangen (wird auch "handwarm" unter Last).
Bei der Benutzung von 4xHDDs braucht man natürlich mehr Leistung (>=120W) und ich weiß wie gesagt auch nicht, wieviel Leistung der 12V Anschluß zu liefern vermag. Das sollte man dabei bedenken.

flockeee

@flockeee sagte in SATA Karte Marvell 88SE9230 Chipsatz:

Leider sind beim Stress Testen des Controllers (kopieren von 500GB vom SW-RAID1 parallel auf beide SSDs)
wiederholt folgende Fehler in dmesg aufgetaucht:

[177554.379675] ata3.00: exception Emask 0x0 SAct 0x1f000000 SErr 0x0 action 0x6 frozen
[177554.382198] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.384513] ata3.00: cmd 61/08:c0:00:09:80/00:00:16:00:00/40 tag 24 ncq dma 4096 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.389434] ata3.00: status: { DRDY }
[177554.391423] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.393559] ata3.00: cmd 61/10:c8:10:09:81/00:00:16:00:00/40 tag 25 ncq dma 8192 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.398530] ata3.00: status: { DRDY }
[177554.400704] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.402878] ata3.00: cmd 61/08:d0:38:45:86/00:00:16:00:00/40 tag 26 ncq dma 4096 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.407762] ata3.00: status: { DRDY }
[177554.409759] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.411909] ata3.00: cmd 61/08:d8:b8:08:00/00:00:00:00:00/40 tag 27 ncq dma 4096 out
                         res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.416582] ata3.00: status: { DRDY }
[177554.418559] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.420735] ata3.00: cmd 61/28:e0:38:08:00/00:00:0b:00:00/40 tag 28 ncq dma 20480 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.425796] ata3.00: status: { DRDY }
[177554.428043] ata3: hard resetting link
[177554.748386] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[177554.752956] ata3.00: configured for UDMA/133
[177554.755160] ata3: EH complete
[177677.262098] ata3.00: NCQ disabled due to excessive errors

Der Kopierprozess auf die jeweilige SSD welche dann resetet stockt dann einige Sekunden und wird dann fortgesetzt. >Dies passiert bisher nur bei den SSDs und nicht parallel.
...

Ich habe oben genannte Probleme mit einem Firmwareupdate* des 88SE9230 in den Griff bekommen. Ein erneuter Stresstest produziert keine der obengenannten Fehlermeldungen mehr bei gleichem Testmuster.

Bios Ver. 1.0.0.1027 / Firmware Vers. 2.3.0.1076 : http://ftp.assmann.com/pub/DS-/DS-30104-1___4016032330240/DS-30104-1_firmware_mul_DS-30104-1 Firmware_20181221.zip

Zum Flashen des Controllers bin ich folgendermaßen vorgegangen:

Sata Controller (hier: DeLOCK 89395) in ein x64/x86 system stecken
Bootbaren USB Stick mit FreeDos präparieren und Dateien aus obengenanntem Archiv ins Hauptverzeichnis legen
Vom USB Stick ins FreeDos booten
In der Kommandozeile "go.bat -y" ausführen
Warten bis der Flash vollständig ist
Neustart

ACHTUNG: DIESE METHODE BEINHALTET KEIN (FUNKTIONIERENDES) BACKUP DER VORHANDENEN FIRMWARE DES CONTROLLERS! FLASHEN AUF EIGENES RISIKO!

Ich habe zuerst die allerneuste Version 1.0.0.1028 bios + 2.3.0.1078 fw geflasht. Mit dieser Version gab es Fehlermeldungen in dmesg über den controller init und die angeschlossenen Platten wurden nicht angezeigt. Ein Downgrade auf obengenannte Version löste das Problem.

Viele Grüße,
Florian

flockeee

Leider sind beim Stress Testen des Controllers (kopieren von 500GB vom SW-RAID1 parallel auf beide SSDs)
wiederholt folgende Fehler in dmesg aufgetaucht:

[177554.379675] ata3.00: exception Emask 0x0 SAct 0x1f000000 SErr 0x0 action 0x6 frozen
[177554.382198] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.384513] ata3.00: cmd 61/08:c0:00:09:80/00:00:16:00:00/40 tag 24 ncq dma 4096 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.389434] ata3.00: status: { DRDY }
[177554.391423] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.393559] ata3.00: cmd 61/10:c8:10:09:81/00:00:16:00:00/40 tag 25 ncq dma 8192 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.398530] ata3.00: status: { DRDY }
[177554.400704] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.402878] ata3.00: cmd 61/08:d0:38:45:86/00:00:16:00:00/40 tag 26 ncq dma 4096 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.407762] ata3.00: status: { DRDY }
[177554.409759] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.411909] ata3.00: cmd 61/08:d8:b8:08:00/00:00:00:00:00/40 tag 27 ncq dma 4096 out
                         res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.416582] ata3.00: status: { DRDY }
[177554.418559] ata3.00: failed command: WRITE FPDMA QUEUED
[177554.420735] ata3.00: cmd 61/28:e0:38:08:00/00:00:0b:00:00/40 tag 28 ncq dma 20480 out
                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[177554.425796] ata3.00: status: { DRDY }
[177554.428043] ata3: hard resetting link
[177554.748386] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[177554.752956] ata3.00: configured for UDMA/133
[177554.755160] ata3: EH complete
[177677.262098] ata3.00: NCQ disabled due to excessive errors

Der Kopierprozess auf die jeweilige SSD welche dann resetet stockt dann einige Sekunden und wird dann fortgesetzt. Dies passiert bisher nur bei den SSDs und nicht parallel.
Die Lesegeschwindigkeit vom RAID1 sind meiner Meinung nach gut und begrenzt natürlich die Schreibgeschwindigkeiten auf die SSDs:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.47    0.00   27.39   26.88    0.00   45.26

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
mtdblock0         0.00         0.00         0.00          0          0
mtdblock1         0.00         0.00         0.00          0          0
mtdblock2         0.00         0.00         0.00          0          0
mmcblk1          16.40         0.06         0.00          0          0
mmcblk1boot1      0.00         0.00         0.00          0          0
mmcblk1boot0      0.00         0.00         0.00          0          0
mmcblk0           0.00         0.00         0.00          0          0
sdc             197.40         0.00       101.42          0        507
sdd             467.60       116.38         0.01        581          0
sdb             476.60       118.60         0.01        592          0
sda             345.60         0.00       116.34          0        581
md0             942.40       235.03         0.00       1175          0

Viele Grüße

flockeee

Du liegst vollkommen richtig. Es liegt am RemoteMount, welchen ich über OMV eingebunden habe. Evtl. habe ich da aber auch etwas falsch konfiguriert. Denke nicht, dass es an OMV liegt.
Ohne diesen geht der headless Boot problemlos.

Mittlerweile kann ich deine Ansichten bzgl WebUi usw. durchaus nachvollziehen. Per Hand lernt man auch noch dazu.
Wegen der UART Konsole habe ich Deine Erfahrungen in einem anderen Thread entdeckt. Danke dafür. Werde ich mir bei Gelegenheit näher anschauen.

flockeee

@FrankM Schonmal danke für den Hinweis. Ist es dabei egal ob mmc oder uSD? Ich habe zusätzlich das Problem, dass auch ein Kaltstart an der Situation nichts ändert. Bedeutet das System fährt hoch, bezieht seine gewöhnliche IP,bleibt allerdings unadministrierbar (Port 22 geschlossen).

Ich denke die einzig verbleibende Möglichkeit ist per UART Informationen zu bekommen. Habe ich leider noch nicht gemacht und auch kein Kit zur Verfügung.

Ich teste mal, ob mit uSD ähnliches Verhalten auftritt (kein ssh service nach reboot) und berichte hier.

EDIT:
Ich habe es nochmal mit angeschlossenem Monitor versucht und beim Booten wird gestoppt und nach dem Root Passwort verlangt.

"Give root password for maintenance or press CTRL+D to continue"

Das passierte direkt nach dem initialisieren der Netzwerkkarte bevor ein CIFS mount geladen wird. Ich habe in OMV einen RemoteMount über die Weboberfläche angelegt, welcher letzlich zu beschriebenem Problem führte.

flockeee

@FrankM :
Leider werden die Ergebnisse noch etwas dauern. Das Raid1 wurde problemlos erstellt, allerdings ist das System nach einem Neustart nicht mehr administrierbar. Siehe https://forum.frank-mankel.org/topic/445/emmc-boot-stuck-after-reboot .

Grüße,
Florian

EDIT:
Das System ist wieder administrierbar (siehe verlinkten Thread).
Als Stabilitätstest werden jetzt per RSync 3.8TB Daten aufs SW-Raid1 kopiert.
Mal schauen wie die Sata Karte sich macht und was dmesg sagt.
Ich werde berichten.

EDIT2:
Der Stabilitätstest ist durch. Die 3.8TB Daten wurde ohne Fehlermeldungen in dmesg kopiert.

Speedtest:

SW-RAID1 (2xWD-RED 6TB):

dd:

pi@rockpro64:/srv/dev-disk-by-label-Raid1Storage$ sudo dd if=/dev/zero of=sd77.img bs=1M count=4096 conv=fdatasync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 38.6309 s, 111 MB/s

iozone:

pi@rockpro64:/srv/dev-disk-by-label-Raid1Storage$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Wed Jan 30 19:53:19 2019

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride          
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    25464    36685    50427    49394      888     1729                                       
          102400      16    40165    58097    68316    91524     3412     6889                                       
          102400     512    95485    99343   107161   131298    52080    78677                                       
          102400    1024    81958    91971   104137   128435    73100    80979                                       
          102400   16384    89566   102283   102792   140921   144198   100731                                       

iozone test complete.

SSD1 (Kingston SSDNow 500GB)

dd:

pi@rockpro64:/srv/dev-disk-by-label-Export$ sudo dd if=/dev/zero of=sd77.img bs=1M count=4096 conv=fdatasync         4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 16.2036 s, 265 MB/s

iozone:

pi@rockpro64:/srv/dev-disk-by-label-Export$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Wed Jan 30 20:09:46 2019

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride          
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    45141    66137    69723    70946    21840    63277                                       
          102400      16   136172   140168   154485   183570    55734   146870                                       
          102400     512   388396   361469   298032   306411   272152   360291                                       
          102400    1024   395404   379891   336627   335560   326960   387305                                       
          102400   16384   150878   170563   133750   147378   116889   484788                                       

iozone test complete.

SSD2 (Samsung SSD850 500GB):

dd:

pi@rockpro64:/srv/dev-disk-by-label-SSD850$ sudo dd if=/dev/zero of=sd77.img bs=1M count=4096 conv=fdatasync         4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 13.6532 s, 315 MB/s

iozone:

pi@rockpro64:/srv/dev-disk-by-label-SSD850$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Wed Jan 30 20:13:46 2019

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride          
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    40543    70208    73986    73104    30564    68626                                       
          102400      16   118034   156574   173566   190123    91171   156537                                       
          102400     512   393457   364015   360967   355865   332180   359108                                       
          102400    1024   410187   393582   401007   391708   368777   401934                                       
          102400   16384   414139   486653   484318   487278   483865   479006                                       

iozone test complete.

Während der Tests wurden keinerlei Fehlermeldungen in dmesg erzeugt.

Grüße.

flockeee

Hallo,

mir ist es jetzt schon des Öfteren passiert, dass mein System problemlos läuft es allerdings nach einem reboot nicht mehr erreichbar ist. Der RockPro bootet hoch, die weiße LED geht an und die Festplatten drehen auch hoch allerdings startet scheinbar kein SSH service mehr. Ich kann den RockPro in der Netzwerkumgebung zwar sehen, jedoch ist kein Port 22 mehr geöffnet.

Gebootet wurde stets von mmc(64gb).
Ist dieses Problem jemandem bekannt?

Viele Grüße

flockeee

@flockeee

Best posts made by flockeee

Latest posts made by flockeee